Jump to content

NGINX HOWTO FTW

cthree

Recommended Posts

cthree Explorer

cthree

Posted
  • Author
Posted

Not sure on your worker or connections but NGINX loves more workes less connections if you spread it out.



So for an example if your config has:



nginx_workers=1


nginx_connections=5000



That basicly means one worker can use 5000, Now if you adjust those values to:



nginx_workers=5


nginx_connections=1000



you have exactly the same values and connection, But you will see better performance overall.




Where are you getting this information from?

Increasing workers makes NO PRACTICAL DIFFERENCE.

The ONLY reason to increase workers would be if connections are doing things which would cause the worker to block which would block all connections handled by that worker.

PHP is proxied with fastCGI and will never cause the worker to block. NGINX is asynchronous, it passes the request to the php-fpm managed fastcgi backend and then puts it aside while is handles more requests. It doesn't block and it is not affected by php scripts that do.

Apache doesn't work that way. each child manages each connection start to finish. If the PHP script blocks (like on a DB query, whatever) then the whole child blocks with it. Since apache doesn't handle more than one request per child that isn't a problem.

If your connections aren't blocking then your worker isn't blocking and you don't need more of them.
Gary. Explorer

Gary.

Posted
Posted

Just through playing over time, It may not work as I mentioned it but on 5 different servers I tested it on, Including several IPB client's it did work out best.

It's just a suggestion so others can test, Also gzip level, I was watching the cached content of this and what it was doing, I also found it to run better around the 2/3 region rather than the default 6 which is mentioned on most websites about optimization.

Luke Mentor

Luke

Posted
Posted

Not sure on your worker or connections but NGINX loves more workes less connections if you spread it out.



So for an example if your config has:



nginx_workers=1


nginx_connections=5000



That basicly means one worker can use 5000, Now if you adjust those values to:



nginx_workers=5


nginx_connections=1000



you have exactly the same values and connection, But you will see better performance overall.




This is bad advice. "worker_processes" (not "nginx_workers") should be equal or less than the number of processor cores. For example a Pentium 4 should be no more than 1, a Core Duo would be no more than 2. A quad core system would be no more than 4. "5" would only work if you had 6-12 cores. Most affordable servers are going to be 1-2 cores, maybe 4 cores.

With worker_connections you'll be limited by what ever "ulimit -n" results in (enter that on linux/osx command line). So worker_processes * worker_connections <= ulimit -n. You can raise this limit though. worker_processes * worker_connections should also be divisible by 4, so 1024 (default) is a better number than 1000. I would keep it set to multiples of 1024.


PHP is proxied with fastCGI and will never cause the worker to block. NGINX is asynchronous, it passes the request to the php-fpm managed fastcgi backend and then puts it aside while is handles more requests. It doesn't block and it is not affected by php scripts that do.




It's true that workers are non-blocking because Nginx is asynchronous. But each process is still limited by worker_connections. Also a single process can not process two requests at exactly the same time. The time it takes to go from one to the other is fast because it proxies the request (or passes it on) to where it needs to go without waiting. That means there is still some latency, just nothing compared to how Apache handles requests (as you mentioned). Having more than one process reduces this latency because more than one process can handle requests simultaneously. It just doesn't serve any benefit to have more worker processes than processor cores. (Setting proceses above the number of cores actually hurts performance.)
cthree Explorer

cthree

Posted
  • Author
Posted

Bloating this configuration is not making it better, simpler or more robust. The point is for someone who wants to try NGINX but needs a good starting point to take the basic config here, plug it into their server and with few modification get the thing running. All of the other info about NGINX and IPB is old and worse, non-functional. Nothing is worse that trying to figure out why something you don't know or understand doesn't work.

Obviously you are going to modify it to suit your site and your hardware in the fullness of time. nginx_workers and nginx_connection configuration options are site and hardware specific. The defaults work perfectly fine for the purpose of this exercise.

raindog308 Explorer

raindog308

Posted
Posted

Another nginx user here :-)

I like nginx performance but find it incredibly finicky. For example, this does not work:

  location ~ \.php$ {

    fastcgi_split_path_info ^(.+\.php)(.*)$;

    fastcgi_pass unix:/var/run/www/php-fpm.sock;

    fastcgi_index index.php;

    fastcgi_param  SCRIPT_FILENAME  /somepath/www.example.com/html$fastcgi_script_name;

    include /etc/nginx/fastcgi_params;

  }

But this does: 

  location ~ \.php$ {

    fastcgi_split_path_info ^(.+\.php)(.*)$;

    include /etc/nginx/fastcgi_params;

    fastcgi_pass unix:/var/run/www/php-fpm.sock;

    fastcgi_index index.php;

    fastcgi_param  SCRIPT_FILENAME  /somepath/www.example.com/html$fastcgi_script_name;

  }

The only difference is the localtion of the fastcgi_params include. Grrr. Apache is so much easier, consistent, and reliable...too bad it's so slow. Then again, I have a long history with it, so it might just be familiarity. BTW, possibly a side question...my IPB generates links like this: 

http://www.example.com/index.php?/members/

Ugly! But this also works if I type it in my browser: 

http://www.example.com/members/


So is getting IPB to generate the latter URL instead of the ugly index.php?/members an IPB setting?

cthree Explorer

cthree

Posted
  • Author
Posted

If you look in /etc/nginx/fastcgi_params you'll see it's a list of default fastcgi_param values including SCRIPT_FILENAME

I thought about it and I *think* NGINX takes the first param value on my system so it only works for me if my SCRIPT_FILENAME param is before the include of the others. I did look at this and wonder why the override for SCRIPT_FILENAME would come before the include of a seeming replacement but for me it works as if the value for SCRIPT_FILENAME is immutable once set.

I didn't look further. Are you running Linux of some kind? Maybe compile options or version might make a difference.

Luke Mentor

Luke

Posted
Posted

Actually the fastcgi_params file does not have SCRIPT_FILENAME in it. The fastcgi.conf file has everything fastcgi_params has plus SCRIPT_FILENAME though.

Part of the problem (and this is the default config's fault) is you shouldn't use this:

fastcgi_param  SCRIPT_FILENAME  /somepath/www.example.com/html$fastcgi_script_name;

It should be this: 

fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;



You should set your absolute path using the "root" directive.

(See http://wiki.nginx.org/Pitfalls)

Also not sure why you're using fastcgi_split_path_info... Should set cgi.fix_pathinfo to 0 in php.ini. Will be slightly faster if you don't have the regular expression.

And the order of declaration does matter with fastcgi_param... Although fastcgi_params should not have SCRIPT_FILENAME in it... So it shouldn't have mattered.

  • 4 weeks later...
ssslippy Apprentice

ssslippy

Posted
Posted

Actually the fastcgi_params file does not have SCRIPT_FILENAME in it. The fastcgi.conf file has everything fastcgi_params has plus SCRIPT_FILENAME though.



Part of the problem (and this is the default config's fault) is you shouldn't use this:



fastcgi_param  SCRIPT_FILENAME  /somepath/www.example.com/html$fastcgi_script_name;

It should be this: 

fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;



You should set your absolute path using the "root" directive.

(See http://wiki.nginx.org/Pitfalls)

Also not sure why you're using fastcgi_split_path_info... Should set cgi.fix_pathinfo to 0 in php.ini. Will be slightly faster if you don't have the regular expression.

And the order of declaration does matter with fastcgi_param... Although fastcgi_params should not have SCRIPT_FILENAME in it... So it shouldn't have mattered.


According to everything I have read cgi.fixpathinfo could break applications running on your server if they use the path info variable.
Luke Mentor

Luke

Posted
Posted

According to everything I have read cgi.fixpathinfo could break applications running on your server if they use the path info variable.




It depends on the application. If it relies on something like /index.php/dosomething then yes it will break that. But most modern applications these days use that as a FURL fall back. If you configure the locations correctly you won't even need that.

For example something you can do is this:


location /

{

...

try_files $uri $uri/ @application

...

}


location @application

{

...

fastcgi_param  SCRIPT_FILENAME  $document_root/index.php?$args;

...

}



(Will need to confirm the above when I get to work)

No other .php files can be executed and all requests are sent to your "bootstrap" index.php. Of course you may need to tweak that depending on what your app needs.

  • 5 months later...
Huai Apprentice

Huai

Posted
Posted

Hi, Is anyone using latest IP.Content with nginx?
I cannot get it the FRUL to work for my pages :no:

I've put my forum in the root folder.

If I have a page called "news.php"
I should be able to access by: http://abc.com/news.php
But I only get 404.

Here is my setting:



server {

    listen       80;

    server_name  abc.com;

    #access_log  /var/www/vhosts/dev/logs/main_access.log;

    root        /var/www/vhosts/dev/html;

    index       index.php index.html;

    location / {

        try_files $uri $uri/ /index.php;

    }

    #error_page  404              /404.html;

    # redirect server error pages to the static page /50x.html

    #error_page   500 502 503 504  /50x.html;

    #location = /50x.html {

    #    root   html;

    #}


    #For IPB specific settings

    location ~ ^/cache/.*.(php|pl|php3|php4|php5|php6|phtml|shtml) {

        deny all;

    }


    location ~ ^/hooks/.*.(php|cgi|pl|php3|php4|php5|php6|phtml|shtml) {

        deny all;

    }


    location ~ ^/public/style_(css|images)/.*.(php|cgi|pl|php3|php4|php5|php6|phtml|shtml) {

        deny all;

    }


    location /admin/applications_addonipscssskin_cpeditorsckeditor {

        types {

            application/x-javascript js;

            text/css css;

            text/xml xml;


        }

    }


    #End of IPB specific settings


    # proxy the PHP scripts to Apache listening on 127.0.0.1:80

    #

    #location ~ .php$ {

    #    proxy_pass   http://127.0.0.1;

    #}

     # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000

    #

    location ~ .php$ {

        fastcgi_split_path_info ^(.+.php)(.*)$;

        try_files $uri =404;

        fastcgi_pass   127.0.0.1:9001;

        fastcgi_index  index.php;

        fastcgi_connect_timeout 300s;

        fastcgi_send_timeout 300s;

        fastcgi_read_timeout 300s;

        fastcgi_param  SCRIPT_FILENAME  /var/www/vhosts/dev/html$fastcgi_script_name;

        include        fastcgi_params;

    }

    # deny access to .htaccess files, if Apache's document root

    # concurs with nginx's one

    #

    location ~ /.ht {

        deny  all;

    }

}

  • 1 month later...
Marquinhos Apprentice

Marquinhos

Posted
Posted

Recently we have been migrate my apacher server to ningx server on our host provider
But we have a lot of issues:

1st sometimes the users get 404 error, this error as been solved configuring the "mod_rewrite".
2nd sometimes get error 502 and 500 from server response, the host provider said to us than it was because we have slow querys(1,2gb of database and it is MYISAM, maybe innodb solve it.) I make new index on slow tables(this tables have more than 60k of rows) to optimize the querys.Mysteriously was fixed, but, this errors return random and i don't know why.

Now the forum ins estable for 40 hours but have a lot of erros like:

Warning: mb_substr_count() expects at most 3 parameters, 4 given in /home/l2jbrasil/www/admin/sources/classes/bbcode/custom/defaults.php on line 2320



Warning: Cannot modify header information - headers already sent by (output started at /home/l2jbrasil/www/admin/sources/classes/bbcode/custom/defaults.php:2320) in /home/l2jbrasil/www/admin/sources/classes/output/formats/html/htmlOutput.php on line 114


And have issues to use "quickly reply post" too on http://www.l2jbrasil.com

My hands are tied because the IPBoard does not support the Nginx and my hosting provider puts the blame on my system (IPB), claiming he is too heavy and its turn this so slow and make some over loads.

Archived

This topic is now archived and is closed to further replies.

Go to topic listing

  • Recently Browsing   0 members

    • No registered users viewing this page.
Invision Community © 2024 IPS, Inc.
×
×
  • Create New...