Tuning your server for optimal Drupal performance
http://drupal.org/node/2601 I have made some significant updates to this page. Please review and provide comments. Cheers, Kieran
Kieran Lal wrote:
I have made some significant updates to this page. Please review and provide comments.
Cheers, Kieran
path.module is costly? pathauto can be a killer on 4.6, but not path IMO. we still do all the lookups for aliases if path is disabled. "Move .htaccess configuration to httpd.conf for security and performance reasons" I would omit security here. There might be some OS level tuning as well. There are subpages about PHP caches and persistent connections that should be linked from this page
Moshe Weitzman wrote:
Kieran Lal wrote:
I have made some significant updates to this page. Please review and provide comments.
Cheers, Kieran
path.module is costly? pathauto can be a killer on 4.6, but not path IMO. we still do all the lookups for aliases if path is disabled.
path.module is costly in 4.6 if you have several hand added aliases (like we had on a site for every node of a certain type). Grabbing the whole list of aliases into memory, then getting and returning the array on *every* call to the get_normal_path, and flipping the array on *every call* to this function is extremely costly! The fact that pathauto is costly is because path.module is costly itself with a lot of aliases. Pathauto only helps you to quickly have these enourmous number of aliases. Goba
path.module is costly in 4.6 if you have several hand added aliases (like we had on a site for every node of a certain type). Grabbing the whole list of aliases into memory, then getting and returning the array on *every* call to the get_normal_path, and flipping the array on *every call* to this function is extremely costly! The fact that pathauto is costly is because path.module is costly itself with a lot of aliases. Pathauto only helps you to quickly have these enourmous number of aliases.
all this is right, but path.module is not at fault. this path machinery works with path.module disabled. path.module is just a UI to manage the url_alias table.
Moshe Weitzman wrote:
path.module is costly in 4.6 if you have several hand added aliases
(like we had on a site for every node of a certain type). Grabbing the whole list of aliases into memory, then getting and returning the array on *every* call to the get_normal_path, and flipping the array on *every call* to this function is extremely costly! The fact that pathauto is costly is because path.module is costly itself with a lot of aliases. Pathauto only helps you to quickly have these enourmous number of aliases.
all this is right, but path.module is not at fault. this path machinery works with path.module disabled. path.module is just a UI to manage the url_alias table.
Ah, right, if you mean that disabling it does not help performance. I meant enabling it is enough to cause performance problems (without patauto). So seems like we are talking about the same thing. Goba
Moshe Weitzman wrote:
Kieran Lal wrote:
I have made some significant updates to this page. Please review and provide comments.
Cheers, Kieran
path.module is costly? pathauto can be a killer on 4.6, but not path IMO. we still do all the lookups for aliases if path is disabled.
"Move .htaccess configuration to httpd.conf for security and performance reasons" I would omit security here.
There might be some OS level tuning as well.
There's probably plenty. But should that be in the Drupal handbook?
There are subpages about PHP caches and persistent connections that should be linked from this page
Right. "Analyse the memory usage <http://lists.drupal.org/archives/development/2005-08/msg00314.html> of modules and add more RAM to your server." You probably want to say that you should increase the amount of memory that php may use. This is however only true if you run of memory somewhere. I don't think it helps performance otherwise. "Don't run PHP as CGI if you can avoid it" is also worth putting there... "Use the devel module <http://cvs.drupal.org/viewcvs/drupal/contributions/modules/devel/> to measure the performance of individual modules" could use some explanation. Maybe rather write "performance impact" or "performance of individual pages. Cheers, Gerhard
On 1/8/06 11:00 AM, Gerhard Killesreiter wrote:
"Don't run PHP as CGI if you can avoid it" is also worth putting there...
Well... unless you're running it under fastcgi... I'm not sure that's an entirely accurate tip. -- James Walker :: http://walkah.net/ :: xmpp:walkah@walkah.net
James Walker wrote:
On 1/8/06 11:00 AM, Gerhard Killesreiter wrote:
"Don't run PHP as CGI if you can avoid it" is also worth putting there...
Well... unless you're running it under fastcgi... I'm not sure that's an entirely accurate tip.
If I had meant fast-cgi I would have written it. :p I am a fast-cgi advocate and thing it is the only secure way to run Drupal if you don't want either CGI or full chroot environments for your users. Cheers, Gerhard
participants (5)
-
Gabor Hojtsy -
Gerhard Killesreiter -
James Walker -
Kieran Lal -
Moshe Weitzman