Submitted by jasongayson on Thu, 02/07/2013 - 22:36
Currently, all fastcgi_param bindings are located outside the ".php$" check, meaning that they are evaluated and bound to a value no matter if the user loads a .bmp or .js file or any other format.
Better performance is achieved by binding all params ONLY when the .php filetype has matched, by moving them inside the block.
Status:
Active
Comments
Submitted by JamieCameron on Thu, 02/07/2013 - 22:47 Comment #1
I'll look into changing this..
What is the actual performance impact though?
Submitted by jasongayson on Thu, 02/07/2013 - 23:08 Comment #2
In terms of NGINX, it's both "minor" and "significant" at the same time.
NGINX prides itself on extremely fast, asynchronous performance, with extremely high req/sec performance. By adding needless directives, it adds complexity and extra validation/variable expansion for each new connection thread, thus limiting the number of reqs/second it can handle.
True numbers? Who knows, maybe 1-2%? But it's still best to put it where it belongs: Inside the .php match-block, right before the fastcgi_pass call. That way it doesn't calculate a bunch of variables on every connection. Only when PHP is really involved.
The thing with NGINX variables is that they are runtime-expanded when-needed, rather than all being available in memory all at once. So, the more variables you request, the more work for the server before it returns the response.
In short: Yes, move it all into the PHP block.
Submitted by JamieCameron on Thu, 02/07/2013 - 23:48 Comment #3
I'll take a look at this when I get some free time.
By the way, for sub-critical requests like this you could greatly increase the chance of them being included in future Virtualmin releases by sending in a code patch.
Submitted by aitte on Sat, 02/23/2013 - 11:50 Comment #4
Jason is right but still wrong.
Replace this:
With this (also restructured and tiny fixes here and there):
/etc/nginx/fastcgi_params is installed by the official Nginx repo version and most (all?) distros. In case it doesn't exist, you can just install it for people with the following official content. Note that it does not contain "SCRIPT_FILENAME", which is a non-standard parameter that PHP relies on, which is why we have to add it ourselves, as shown above.
Submitted by aitte on Sat, 02/23/2013 - 11:44 Comment #5
I made this little repair script for now.
pastebin.com/nhWqiW2p