Hi guys,
Has anyone noticed a performance impact when the Drupal 5.x database is split for a multisite setup?
I am building local community websites which share same functionality and similar theming and after I built the first one, I decided to split the database to shared and site-specific so I can afterwards use the shared one for my next website. I get a 1 sec page execution time difference for authenticated visitors on my front page: from 1.5 sec when I use a single database to 2.5 sec when I use the split model. Page execution time for anonymous visitors is not affected and is in the region of 150 ms with page cache enabled. I use one and the same MySQL server which is placed on the same machine as my Apache web server.
The weirder problem is that the DB queries seem not to be the problem as it is executing about 800 queries in about 150 ms for both setups.
The only thing that is different is the $db_prefix array in my settings.php file which now contains the 160 names of the tables in the shared database with their "shareddb." prefix. Can this be causing the problem?
One more related performance question - I use a handful contrib modules, is there anyway for me to find out why there is 10 to 20 times higher page execution times than the DB queries times? For me 1.5 sec or 2.5 are not good enough as I am aiming at less than a second, preferably up to 600-700 ms for authenticated users. I searched a lot on the web site but the replies I found hinted for:
- DNS lookups - seems not to be the problem in my case
- sockets interaction - no modules using it
- consuming web services - not doing it
- PHP compilation - I am using eAccelerator which drastically reduced the web site memory footprint and a bit the page execution time
- reducing enabled modules - I've cleared everything unnecessary but still handful left
Any suggestions and hints would be greatly appreciated.
- Tisho
Comments
I tried reproduce your
I tried reproduce your situation, I create 50 installation on one server and don't have different results for 'login' action.
I tried to 'login' emulation (curl based) in threads, but don't receive big different.
Did you uninstall third party modules? or use clear installation for tests?
Post the settings.php or a link to it
Your description gives an overview of what the problem is, and the configuration. But it is not detailed enough.
Create a copy of the settings.php file as a .txt, replace the password and sensitive info (e.g. dbname), and then post it where people can review it.
Drupal performance tuning, development, customization and consulting: 2bits.com, Inc..
Personal blog: Baheyeldin.com.
Drupal performance tuning, development, customization and consulting: 2bits.com, Inc..
Personal blog: Baheyeldin.com.
Thank you for the replies
Hi Alexandr,
I use a poisoned with contrib modules setup. Thank you for taking the time to try and reproduce the issue, I guess my assumptions that it is something in my setup will turn out correct.
Hi kbahey,
Excuse me for not being clear enough. I am now attaching the settings.php file. Hopefully this will shed a bit more light on the setup.
http://tntwebso.com/settings.txt
I found a solution to the problem
I found a solution to the problem. Obviously I was on the right track that the problem lies in the $db_prefix array (160 table names). There is a proposed patch here which totally removed the 1 second overhead:
http://drupal.org/node/42827
Sadly, I still cannot find where the bottleneck of my 1.5 sec page execution time is. I've done more reading on the topic (thanks kbahey for the great 2bits site!!!) and I profiled the module load times as I expected this to be a problem (I have 100 or so modules enabled) but with PHP eAccelerator installed on the server this turned out not to be the problem and I get a total of 8.45 ms modules load time.
I understand that with this php eAccelerator a problem again may be the work with arrays (as in the case with the $db_prefix array) as it does not impact the performance of working with them. I'll try to dig into this a bit more and hopefully if I find out where the bottleneck is, I'll update the thread.
Just a word of caution: I
Just a word of caution:
I learned the hard way that the combination of phpAccelerator and Drupal sometimes doesn't work as expected. I had quite some issues on one server with D5, while on another server also running a midsize D5 everything worked fine. The effect was, that sometimes you got a WSOD (because of segmentation faults) for some nodes and had to restart apache (running up-to-date versions of apache and mod_php with suexec, suhosin patch and mod_security on Debian Etch 64 bit) to fix that.
Switching to APC was the solution. That's what Drupal.org also uses for PHP bytecode caching.
Alex