Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I I've been trying to get NGINX up and running on my OSX 10.7 Lion computer. I have it running however simple html pages every few are taking a long time to load; for example:

<html> 
  <body>
    test
  </body> 
</html>

Same thing happens with php:

<?php
  echo('hi');
?>

If i hit refresh, it seems as it's almost rebuilding the entire page before it renders and creating some kind of object. Just painfully slow..

This seems to be most frequent if I do some coding then go back to refresh a page. (10-20+ seconds then going back and refreshing a page takes a good 4-6 seconds).. It almost appears that once idle it takes a while to re-wake back up.

i'm pulling my hair out trying to understand what is going on, hopefully someone can shed some light on this for me.

System Configuration:

  • OS: OSX 10.7.2

  • Processor: 2 x 2.66 GHZ Dual-Core Intel Xeon

  • Memory: 8gb 667 MHz

Nginx Version: 1.0.11

PHP Version: 5.3.9

I have installed this from a clean format of OSX (Which I thought was initially my error, sadly it wasn't).

Update

After updating my error_log file to contain debug per Fox's suggestion in comments I'm now seeing the following message appear in my error_log:

2012/01/23 11:57:02 [info] 88015#0: *26 client closed prematurely connection 
while reading client request line, client: 127.0.0.1, server: sandbox.local

Update Two

Upon inspecting with chrome I did find that it seems DNS resolving is taking a bit? enter image description here

Update Three - SOLVED

After Update Two fixed /etc/hosts file to use:

127.0.0.1 sandbox.local

AND

::1 sandbox.local

Thanks to @thinice I was able to go through strace and notice that all requests targeting localhost directly from telnet were always instant; which then prompted DNS checking and finally led to finding this!

OSX /etc/hosts Bugs

I'm not sure if this is a nginx bug; as when I previously had appache installed this was working just fine.

============

Here are my config files:

NGINX Config

user petrogad staff;
worker_processes  2;

#error_log  logs/error.log;
#error_log  logs/error.log  notice;
#error_log  logs/error.log  info;

pid        /usr/local/ngnix/var/run/nginx.pid;

events {
    worker_connections  1024;
}

http {
    include mime.types;

    default_type text/plain;
    server_tokens off;

    sendfile on;
    tcp_nopush on;
    keepalive_timeout 10;

   # gzip on;
   # gzip_comp_level 2;
   # gzip_proxied any;
   # gzip_types text/plain text/css text/javascript application/json application/x-javascript text/xml application/xml application/xml+rss;

    index index.html index.php;
    include /usr/local/ngnix/conf/sites-enabled/*.link;
}

Server Config

{
    listen 80;
    server_name sandbox.local;
    root /www/sandbox;

    access_log /Users/petrogad/logs/ngnix-sites/sandbox_log.txt;
    error_log /Users/petrogad/logs/ngnix-sites/sandbox_log.txt;

    location /
    {
        # First attempt to serve request as file, then
        # as directory, then fall back to index.html
        try_files $uri $uri/ /index.html;
        autoindex on;
    }

    include /usr/local/ngnix/conf/php.conf;
}

PHP Include

fastcgi_intercept_errors on;

location ~ \.php$
{
    #fastcgi_intercept_errors on;
    fastcgi_param PATH_INFO         $fastcgi_path_info;
    fastcgi_param PATH_TRANSLATED   $document_root$fastcgi_path_info;
    fastcgi_param QUERY_STRING      $query_string;
    fastcgi_param REQUEST_METHOD    $request_method;
    fastcgi_param CONTENT_TYPE      $content_type;
    fastcgi_param CONTENT_LENGTH    $content_length;
    fastcgi_param SCRIPT_NAME       $fastcgi_script_name;
    fastcgi_param SCRIPT_FILENAME   $request_filename;
    fastcgi_param REQUEST_URI       $request_uri;
    fastcgi_param DOCUMENT_URI      $document_uri;
    fastcgi_param DOCUMENT_ROOT     $document_root;
    fastcgi_param SERVER_PROTOCOL   $server_protocol;
    fastcgi_param GATEWAY_INTERFACE CGI/1.1;
    fastcgi_param SERVER_SOFTWARE   nginx;
    fastcgi_param REMOTE_ADDR       $remote_addr;
    fastcgi_param REMOTE_PORT       $remote_port;
    fastcgi_param SERVER_ADDR       $server_addr;
    fastcgi_param SERVER_PORT       $server_port;
    fastcgi_param SERVER_NAME       $server_name;

    fastcgi_read_timeout 60; # Set fairly high for debugging

    fastcgi_pass  127.0.0.1:9001; # Non-default port
    fastcgi_index index.php;
}

Fast CGI Config

fastcgi_param  SCRIPT_FILENAME    $document_root$fastcgi_script_name;
fastcgi_param  QUERY_STRING       $query_string;
fastcgi_param  REQUEST_METHOD     $request_method;
fastcgi_param  CONTENT_TYPE       $content_type;
fastcgi_param  CONTENT_LENGTH     $content_length;

fastcgi_param  SCRIPT_NAME        $fastcgi_script_name;
fastcgi_param  REQUEST_URI        $request_uri;
fastcgi_param  DOCUMENT_URI       $document_uri;
fastcgi_param  DOCUMENT_ROOT      $document_root;
fastcgi_param  SERVER_PROTOCOL    $server_protocol;

fastcgi_param  GATEWAY_INTERFACE  CGI/1.1;
fastcgi_param  SERVER_SOFTWARE    nginx/$nginx_version;

fastcgi_param  REMOTE_ADDR        $remote_addr;
fastcgi_param  REMOTE_PORT        $remote_port;
fastcgi_param  SERVER_ADDR        $server_addr;
fastcgi_param  SERVER_PORT        $server_port;
fastcgi_param  SERVER_NAME        $server_name;

# PHP only, required if PHP was built with --enable-force-cgi-redirect
fastcgi_param  REDIRECT_STATUS    200;

PHP-FPM Config

[global]
pid = /usr/local/php-5.3.9/var/run/php-fpm.pid
daemonize = yes

[www]
listen = 127.0.0.1:9001
user = petrogad
group = staff
pm = dynamic
pm.max_children = 10
pm.start_servers = 5
pm.min_spare_servers = 5
pm.max_spare_servers = 10
pm.max_requests = 500

Attempted Simple solution with the following nginx config, same slow result as above:

user petrogad staff;
worker_processes  2;


pid        /usr/local/ngnix/var/run/nginx.pid;

events {
    worker_connections  1024;
}


http {

    include mime.types;

    default_type text/plain;
    server_tokens off;

    sendfile on;
    tcp_nopush off;
    keepalive_timeout 0;

    index index.html;

  server
  {
    listen 80;
    server_name sandbox.local;
    root /www/sandbox;

    access_log /Users/petrogad/logs/ngnix-sites/sandbox_log.txt;
    error_log /Users/petrogad/logs/ngnix-sites/sandbox_log.txt;

    location /
    {
        autoindex on;
    }

  }



}
share|improve this question
2  
Very well-composed question. –  gWaldo Jan 23 '12 at 17:38
    
Good question - the one thing that stands out is your worker_processes value - try reducing it so that it is less than or equal to the number of CPU cores you have. Also, try to run a benchmark (ab, seige, httperf, etc) directly against the nginx server (to exclude rendering issues, network, etc that a browser might experience) –  cyberx86 Jan 23 '12 at 17:39
    
does setting resolver_timeout 1s; change anything? also setting error_log /Users/petrogad/logs/ngnix-sites/sandbox_log.txt debug; might bring some insight ... –  Fox Jan 23 '12 at 17:43
    
@cyberx86 I'll run jmeter against it today to confirm; I've experimented with the worker processes and have that dropped down to 2 with the same result still. I'll report back after running jmeter against it. Cheers –  Petrogad Jan 23 '12 at 17:49
    
@Fox I added both; it didn't make a difference; however I did start seeing an errror in the log file (updated above) –  Petrogad Jan 23 '12 at 17:57

1 Answer 1

up vote 2 down vote accepted
+100

Start by stripping out all unnecessary configuration options.

Get the setup to a bare-bones 'Im only serving HTML files' default configuration. Remove optimizations.

Slowly start adding aspects back in a few at a time, restart your stack and test.

If you're feeling ambitious, you can run strace on a single server process to get timings. Have a look at this for a crash course.

share|improve this answer
    
Will give this a test tonight, I did initially comment out all the PHP, to simply try and get HTML working; however had no luck. I'll give it another go though and really strip out everything to a bare-bonesish look. Thank you for your response. –  Petrogad Jan 23 '12 at 20:54
    
Attempted this tonight with the above solution; didn't work, still slow. I'll see if I can't make my way through strace. Thank you! –  Petrogad Jan 24 '12 at 4:14
    
Little more to update; Thank you for the strace link, very informative! When using telnet to try and access my test page, I can't get any lag, every time it's instant using identical headers to that of the chrome browser. I did however see the above image in chrome.. not sure if that helps at all. Thank you for your time and help. –  Petrogad Jan 24 '12 at 4:36
    
Try using 'fetch' or 'wget' (not sure what OSX has) on the URL to confirm the speed. Do you have an alternative browser to test with? Maybe try launching chrome in in-cognito (ctrl-shift-n on windows) to disable all frills and try it. –  thinice Jan 24 '12 at 4:38
1  
Further investigation let me to add ::1 to my host file which solved the issue! Apparently there is an issue with NGINX on OSX Lion and ipv6 –  Petrogad Jan 24 '12 at 4:51

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.