By robertdouglass on
With Roadsend compiler you can create a binary version of your PHP code and apparently gain significant performance benefits. I'd be really interested in hearing whether anyone has tried this with Drupal, and what the benefits or disadvantages of such an approach would be over a PHP cache. Should we distribute a binary release of Drupal for people who want to gain maximum performance?
Comments
We Really Need Something Like That...
I have not run it, but let's support it as long as it works.
Plus include more help on optimizing, especially at the system level (Linux, Apache, MySQL, PHP).
That compiler does not seem
That compiler does not seem to be Free Software (as in speech). I see no reason to specially support it.
--
Drupal services
My Drupal services
--
Drupal services
My Drupal services
I am not very impressed. An
I am not very impressed. An interesting comparison would be against PHP with an opcode cache, a comparison against plain PHP does not make much sense as you of course always will have the byte-compile overhead.
Edit:
And no, we shouldn't distribute a compiled version of Drupal. First of all, that compiler is non-free, why support it? Also, the compiler has a few issues (does not cross-compile, no Apache2) which would only give us support hassles).
--
Drupal services
My Drupal services
--
Drupal services
My Drupal services
Can we find any better compilers
Can we find any better compilers to hang our hat on?
Well, do you need a
Well, do you need a compiler? Does you website have that many visitors? If you answer is yes: You should install an opcode cache such as eAccellerator or APC.
--
Drupal services
My Drupal services
--
Drupal services
My Drupal services
I just installed APC on
I just installed APC with PHP5. The frontpage still takes ~15-20 sec to load with only one user. phpinfo confirms that APC is installed with these settings:
Directive | Local Value | Master Value
apc.cache_by_default On On
apc.enable_cli Off Off
apc.enabled On On
apc.file_update_protection 2 2
apc.filters no value no value
apc.gc_ttl 3600 3600
apc.max_file_size 1M 1M
apc.mmap_file_mask no value no value
apc.num_files_hint 1000 1000
apc.optimization Off Off
apc.shm_segments 1 1
apc.shm_size 30 30
apc.slam_defense Off Off
apc.ttl 0 0
apc.user_entries_hint 100 100
apc.user_ttl 0 0
What could be happening here ???
he, I didn't say I am an APC
he, I didn't say I am an APC expert. But f your front page takes that long to load, there must be something wrong. On what hardware are you running?
--
Drupal services
My Drupal services
--
Drupal services
My Drupal services
Here are the stats...
This used to work fine with a few hundred nodes, but now with 2000 is slowing down...
[dkruglyak@localhost ~]$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 1
model name : Intel(R) Celeron(R) CPU 1.80GHz
stepping : 3
cpu MHz : 1795.988
cache size : 128 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm
bogomips : 3538.94
[dkruglyak@localhost ~]$
[dkruglyak@localhost ~]$ cat /proc/meminfo
MemTotal: 515676 kB
MemFree: 280136 kB
Buffers: 12200 kB
Cached: 139264 kB
SwapCached: 0 kB
Active: 106376 kB
Inactive: 105824 kB
HighTotal: 0 kB
HighFree: 0 kB
LowTotal: 515676 kB
LowFree: 280136 kB
SwapTotal: 1052216 kB
SwapFree: 1052216 kB
Dirty: 60 kB
Writeback: 0 kB
Mapped: 88532 kB
Slab: 17632 kB
Committed_AS: 423244 kB
PageTables: 2204 kB
VmallocTotal: 499704 kB
VmallocUsed: 2468 kB
VmallocChunk: 496776 kB
HugePages_Total: 0
HugePages_Free: 0
Hugepagesize: 4096 kB
[dkruglyak@localhost ~]$
Is this THAT bad ???
15 to 20 SECONDS?
Did you say SECONDS?
With or without APC, things should not be that bad.
What modules do you have active? Which one have components on the home page?
Better move this into its own dicussion, since it is not about Roadsend anymore.
--
Drupal development and customization: 2bits.com
Personal: Baheyeldin.com
--
Drupal performance tuning and optimization, hosting, development, and consulting: 2bits.com, Inc. and Twitter at: @2bits
Personal blog: Ba
I think this may be pathauto's fault.
I think this may be pathauto's fault.
We have a url_alias table of 8,000 entries / 1M and now even when we turn off path & pathauto modules it is still being fully loaded, slowing the site to a crawl (15-40 sec load). We cannot get rid of url_alias table, as search traffic depends on it...
There was talk of fixing this for 4.6 but I have not seen anything come out of this. We are probably not alone in this.
I filed an issue to pathauto: http://drupal.org/node/43712
Not pathauto's fault
This is a problem with how Drupal loads custom paths in Drupal 4.6. This is greatly improved in Drupal 4.7.
--
Drupal services
My Drupal services
--
Drupal services
My Drupal services
So what can I do???
So, based on my url_alias stats, does this look like the root cause?
If yes, is there any way at all to patch this in 4.6? Any kind of hack to get me out of the pickle?
Confirmed, this is the cause...
I created a copy DB and after "DELETE FROM url_alias" the frontpage load time drops from 20 sec to 1 sec.
So what is the answer for those unfortunate enough to be stuck with 8K aliases on 4.6? I filed an issue: http://drupal.org/node/43712
The answer is to help with
The answer is to help with fixing bugs for 4.7 so that it can be released sooner. :)
--
Drupal services
My Drupal services
--
Drupal services
My Drupal services
This is not the answer
Happy to help with 4.7, but this is not the answer. Many people will have to keep running 4.6 in production for quite a while for a variety of reasons.
Can you provide any practical tips on patching up 4.6?
You can try to hunt down the
You can try to hunt down the original patch. It was applied quite early in the release cycle, so it might apply to Drupal 4.6.5.
--
Drupal services
My Drupal services
--
Drupal services
My Drupal services
Found the patch, have questions.
Found the patch, have questions. It is introduced here http://drupal.org/node/22035#comment-29593, with disclaimer that it is broken.
Could you help me understand what version that patch applied to? HEAD/4.7? 4.6.x? How different is it from 4.6.5? I can try hacking but any guidance is much appreciated. Maybe you could point me to which functions to work on and where to start modifying 4.6.5...
I created a new issue for this, perhaps we should move the discussion there: http://drupal.org/node/43712
Thanks for the help
The actually applied patch
The actually applied patch can be gathered by collecting the individual pieces linked to from here:
http://drupal.org/cvs?commit=16021
You should try to apply them to Drupal 4.6.5. As I said: Wait for 4.7 if you need this feature.
--
Drupal services
My Drupal services
--
Drupal services
My Drupal services
backport available
I've backported the improvement from CVS HEAD. The pieces in commit 16021 were broken, but were a good head start.
i just added a warning to pathauto project page
this isn't pathauto's fault, but its users are the ones who need to know.
Problems
NONE array_multisort
PLANNED mysql_real_escape_string
PLANNED getimagesize
PARTIAL ini_get
PARTIAL mail additional parameters option is not supported.
PARTIAL strtotime partial implementation
most of these can be worked around but array_multisort will break block. Sure, you can live without nice sort in it, but still.
mail will cause problems, but of course you can use an SMTP library.
Who knows what bugs are there -- yes there are bugs in Zend Engine, too, but there are magnitudes more people working with that, so they are shallow...
So, I agree with killes: as a core team member I do not wish to support this.
--
Read my developer blog on Drupal4hu. | The news is Now Public
--
Drupal development: making the world better, one patch at a time. | A bedroom without a teddy is like a face without a smile.
Post your apache
Post your apache settings
-
KeepAlive
MaxKeepAliveRequests
KeepAliveTimeout
MinSpareServers
MaxSpareServers
StartServers
MaxClients
Here are Apache settings
Here are Apache settings...
KeepAlive Off
MaxKeepAliveRequests 100
KeepAliveTimeout 15
StartServers 8
MinSpareServers 5
MaxSpareServers 20
ServerLimit 256
MaxClients 256
MaxRequestsPerChild 4000
But another possible cause is url_alias per my comment above...
Never tried it, but...
I'd expect the performance increase to be very similar to the results you get from caching PHP.
We use eAccelerator, which looks like the best choice. It's free and updated regularly, and simple to configure and install.
demolicious | leafish
An example of the benefits
An example of the benefits of PHP caching from our test server, on a site in development:
Before
Page execution time was 650 ms
After
Page execution time was 220 ms
These are rough averages, ignoring any spikes. The same (or better) results should be expected from this compiler. PHP caching can make a massive difference, and (assuming it doesn't cause any problems) should be enabled on any busy site. I would expect the performance increase to be more noticable on older hardware or sites on shared hosting.
demolicious | leafish
Are you using APC or eAccelerator?
Are you using APC or eAccelerator? With what PHP version? On what platform?
eAccelerator, on an Athlon
eAccelerator, on an Athlon 2400, 512mb, PHP5, Apache2.
demolicious | leafish
With a bit of httpd.conf and
With a bit of httpd.conf and my.cnf tuning, page generation time on this test site is now down to ~25ms. Groovy.
demolicious | leafish
What kind of config
What kind of config changes?
--
Drupal services
My Drupal services
--
Drupal services
My Drupal services
Mainly stripping out
Mainly stripping out uneccesary modules from Apache, reducing the number of server processes, and lowering the keepalive timout. This is with the prefork MPM.
MySQL config was tweaked to better match the buffers and cache to the server's memory (512mb).
I've found that the defaults (or common settings) are great if you have seperate servers for web and database, but they tend to hog too much memory and CPU time if you're forced to run both off one box.
I also disabled Apache2's caching and compression modules, assuming that as all of our content is dynamic we would get better performance relying on PHP caching through eAccelerator and Drupal's compressed (but broken) cache.
When I've benchmarked these changes properly and finished playing with everything, I'll write this up as a possible addition to the handbook. The problem is that the tweaks are very specific to the server's hardware (single CPU, 512mb memory, nothing but Drupal sites, using symlinks to the .php and .module files to help caching), and will probably be changed again when the server is fully live and under a heavier load. I also haven't really profiled the mySQL and Apache performance to find the true bottlenecks.
demolicious | leafish
I thnk the setup is quite
I thnk the setup is quite typical and a detailed description would be helpful for a number of people (including myself).
--
Drupal services
My Drupal services
--
Drupal services
My Drupal services
I second killes
I second killes' request:
Please post your Apache and MySQL configuration in its enterity (of course change server and directory names and any other sensitive into)
--
Drupal development and customization: 2bits.com
Personal: Baheyeldin.com
--
Drupal performance tuning and optimization, hosting, development, and consulting: 2bits.com, Inc. and Twitter at: @2bits
Personal blog: Ba
I'll post the configs (with
I'll post the configs (with comments) after the server's been up under heavy loads for a few weeks. Until then, here's an article about optimizing PHP that I found today while working on ways to reduce memory usage. It's highly relevant, and is a good summary of all the research and information I mined Google for while optimizing our server.
Anybody able to add this article to the handbook's "optimizing Drupal" section?
demolicious | leafish
Yes, you can
Got to where you want to add the page, click the add a child page link on the bottom. Create your content. It goes into moderation for review.
-sp
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
I don't want to add a page,
I don't want to add a page, just make an addition to an existing one. I don't have permission to do that, so I just added it as a comment for now.
demolicious | leafish
after reading this thread I
after reading this thread I decided to try the eaccelerator extension.
I'm really really impressed!!!
My homepage before the eaccelerator install was rendered in 250ms.
Now it renders in 30ms. Wonderful!
I'm using apache 1.3, php 4.4.1, eaccelerator 0.9.4 rc1 .
Rendering time is provided by devel.module .
I will try eaccelerator more...
Does it is ready for production environment???
Thanks
Fabio
eAccelerator known to crash
EAccelerator is known to crash. I understand they are doing a complete re-write to fix it.
Kieran Lal
eAccelerator
eAccelerator is somewhat less than stable in PHP5. The encoder in particular is utterly broken in PHP5 - plain caching may work.
In PHP4, it is quite stable, as long as your web server is running a preforking MPM - most crash bugs came from running it in inappropriate environments, Recent PHP4 and eAccelerator versions prevent it in a threaded environment for safeties' sake.
Sevo
Have you tested FastCGI?
Have you tested FastCGI?
In this case code is also parsed and ready to use.
fastCGI
FastCGI converts standalone CGI interpreters into a embedded server process - this is most useful if you use CGI scripts in a language less tightly integrated than PHP.
With PHP, it is about equivalent in performance to mod_php, but has session and database management peculiarities that can break some (arguably sloppy) code that works fine with mod_php, and cannot benefit from PHP/Zend bytecode caches like eAccelerator.
Sevo
The biggest advantage of
The biggest advantage of fast-cgi is that it runs under the user's account and not apache's.
I haven't checked whether it takes advantage of opcode caches or not.
--
Drupal services
My Drupal services
--
Drupal services
My Drupal services
Security is a serious question
I'm quite agree with you.
Running PHP as separate process with user privileges gives us ability to use file permissions and resource (memory, cpu, etc...) control at OS level, rather than at PHP level. The latter is less reliable.
At recent time I'm thinking about running PHP as FastCGI in chroot environment. Do you know about Drupal behavior in this situation? Is there some issues?
I am running Drupal under
I am running Drupal under fcgi and did not have any issues. I don't use chroot though.
--
Drupal services
My Drupal services
--
Drupal services
My Drupal services
Php was noted to have
Php was noted to have different acceleration from moving to FastCGI mode. Some people said about up to 700% of boost-up. My test with Drupal currently had not gave such result. I think it depends on script. May be little scripts gets more advantage.
My opinions - it requires some investigations.
Roadsend now open source
Just a quick note to say that Roadsend PHP compiler is now free and open source for those who want to test Drupal with it.
Post your experiences/benchmarks here.
--
Drupal development and customization: 2bits.com
Personal: Baheyeldin.com
--
Drupal performance tuning and optimization, hosting, development, and consulting: 2bits.com, Inc. and Twitter at: @2bits
Personal blog: Ba