2015-01-12 9 views
1

В настоящее время у нас есть настройка сервера Nginx с PHP-FPM и APC для кэширования. Было настроено запустить один веб-сайт средней загрузки, где мы хотели обратить особое внимание на время загрузки сайта, так как весь их бизнес в значительной степени зависит от веб-сайта (онлайн-бронирование).Nginx + PHP-FPM + время отклика APC

Спецификации являются: 1 CPU, 1GB Ram, Ubuntu 12.04 LTS, Nginx 1.1.19, PHP-FPM 5.3.10

Она работает без каких-либо проблем довольно долго сейчас (около 1 года).

Однако нам нужно было настроить разделенную тестовую ситуацию для проверки новой версии веб-сайта. Поскольку мы не могли просто чередоваться с различными фрагментами кода (с использованием CMS и структуры базы данных также были изменения), мы решили использовать субдомен и отправлять 20% трафика в субдомен.

Для этого мы просто создали новый серверный блок и установили новый сайт полностью автономным в новой папке. Затем в исходном файле блока сервера мы использовали nginx split clients для установки cookie и перенаправления на «new», если в этом процентиле.

Мы полагали, что было бы просто сделать это на основном/старом сайте, так как все их трафик поступает от Google и вряд ли будет повторным клиентом в течение периода тестирования, поэтому вероятность того, что кто-то придет прямо к «новому», очень невелик и не повлияет на результаты.

Вначале работала нормально, и через несколько дней мы начали жаловаться на медленные нагрузки. После некоторой отладки это был только заголовок трафика в «новый» и только прерывистый. На данный момент исходный сайт не выполняется.

У нас есть медленно отключенные функции, которые пытаются тренироваться там, где проблема, но мы не можем найти, где проблема. Тестирование split было временно отключено, и оказалось, что даже если вы попытаетесь загрузить субдомен напрямую, у него иногда будет очень медленный первоначальный ответ (около 20 секунд).

Сначала я думал, что это может быть проблема с кешированием, поэтому мы полностью отключили APC, но это не решило проблему. У нас был кеш fastcgi включен в один момент, чтобы попытаться ускорить его, но это было отключено давно.

У нас есть несколько других серверов с очень похожими настройками, поэтому я изо всех сил пытаюсь найти, где проблема.

Вот файл сниппеты

nginx.conf

user www-data; 
worker_processes 1; 
pid /var/run/nginx.pid; 

events { 
     worker_connections 1024; 
     use epoll; 
     multi_accept on; 
} 

http { 

     ## 
     # Basic Settings 
     ## 

     sendfile on; 
     tcp_nopush on; 
     tcp_nodelay on; 
     keepalive_timeout 65; 
     types_hash_max_size 2048; 
     server_tokens off; 
     send_timeout 60; 

     include /etc/nginx/mime.types; 
     default_type application/octet-stream; 

     #fastcgi_cache_path /var/cache/nginx levels=1:2 keys_zone=microcache:10m max_size=100m inactive=60m; 
     #fastcgi_cache_key "$scheme$request_method$host$request_uri"; 

     ## 
     # Logging Settings 
     ## 

     access_log off; 
     error_log /var/log/nginx/error.log; 

     ## 
     # Gzip Settings 
     ## 

     gzip on; 
     gzip_disable "msie6"; 

     gzip_http_version 1.1; 
     gzip_vary on; 
     gzip_comp_level 6; 
     gzip_proxied any; 
     gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/javascript text/x-js; 
     gzip_buffers 16 8k; 

     open_file_cache   max=2000 inactive=20s; 
     open_file_cache_valid 30s; 
     open_file_cache_min_uses 5; 
     open_file_cache_errors off; 

     include /etc/nginx/conf.d/*.conf; 
     include /etc/nginx/sites-enabled/*; 
} 

сайта 1/Оригинал

split_clients "app${remote_addr}${http_user_agent}${date_gmt}" $upstream_variant { 
     20% "new"; 
     * "original"; 
} 

map $cookie_split_test_version $upstream_group { 
     default $upstream_variant; 
     "new"  "new"; 
     "original" "original"; 
} 

geo $internal_request { 
     xxx.xxx.xxx.xxx 1; 
     default 0; 
} 


server { 
     listen 80; 
     server_name domain.com otherdomain.com$ 
     return 301 $scheme://www.domain.com$request_uri; 
} 

server { 
     listen 80; 
     listen 443 ssl; 

     add_header Set-Cookie "split_test_version=$upstream_group;Path=/;Max-Age=3600;"; 

     if ($upstream_group = "new") { 
       set $test_group 1; 
     } 
     if ($test_group = 1) { 
       return 301 $scheme://new.domain.com$request_uri; 
       break; 
     } 


     ssl_certificate path/to/ssl; 
     ssl_certificate_key path/to/sslkey; 
     ssl_session_timeout 5m; 
     ssl_protocols TLSv1; 
     ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv3:+EXP; 


     root /var/www/domain.com/httpdocs; 
     index index.php index.html index.htm; 

     server_name www.domain.com 

    client_max_body_size 2M; 


     location/{ 
       try_files $uri @website; 
     } 


    location @website { 
       include fastcgi_params; 
       fastcgi_split_path_info ^(.+\.php)(/.+)$; 

       fastcgi_param SCRIPT_FILENAME $document_root/framework/main.php; 
       fastcgi_param SCRIPT_NAME /framework/main.php; 
       fastcgi_param QUERY_STRING url=$uri&$args; 

       fastcgi_param ENVIRONMENT production; 

       fastcgi_pass unix:/var/run/php5-fpm.sock; 
       fastcgi_index index.php; 
       fastcgi_buffer_size 32k; 
       fastcgi_buffers 4 32k; 
       fastcgi_busy_buffers_size 64k; 
     } 

    ///other location directives 

    expires 2w; 
} 

сайта 2/New

server { 
     listen 80; 
     listen 443 ssl; 

     root /var/www/domain.com/subdomains/new; 
     index index.php index.html index.htm; 

     server_name new.domain.com 

     ssl_certificate path/to/ssl; 
     ssl_certificate_key path/to/sslkey; 
     ssl_session_timeout 5m; 
     ssl_protocols TLSv1; 
     ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv3:+EXP; 

     client_max_body_size 2M; 


     location/{ 
       try_files $uri @website; 
     } 


    location @website { 
       include fastcgi_params; 
       fastcgi_split_path_info ^(.+\.php)(/.+)$; 

       fastcgi_param SCRIPT_FILENAME $document_root/framework/main.php; 
       fastcgi_param SCRIPT_NAME /framework/main.php; 
       fastcgi_param QUERY_STRING url=$uri&$args; 

       fastcgi_param ENVIRONMENT new; 

       fastcgi_pass unix:/var/run/php5-fpm.sock; 
       fastcgi_index index.php; 
       fastcgi_buffer_size 32k; 
       fastcgi_buffers 4 32k; 
       fastcgi_busy_buffers_size 64k; 
     } 

    ///other location directives 

    expires 2w; 
} 

Биты из пула PHP-FPM.d

user = www-data 
group = www-data 

listen = /var/run/php5-fpm.sock 

pm.max_children = 10 
pm.start_servers = 5 
pm.min_spare_servers = 4 
pm.max_spare_servers = 6 
pm.max_requests = 1000 

Я также не думаю, что его вопрос памяти (не получает никаких предупреждений памяти)

top - 10:24:51 up 54 days, 11:11, 1 user, load average: 0.16, 0.12, 0.12 
Tasks: 77 total, 1 running, 76 sleeping, 0 stopped, 0 zombie 
Cpu(s): 6.7%us, 0.7%sy, 0.0%ni, 91.6%id, 1.0%wa, 0.0%hi, 0.0%si, 0.0%st 
Mem: 1015380k total, 896120k used, 119260k free, 149888k buffers 
Swap:  0k total,  0k used,  0k free, 333820k cached 

    PID USER  PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 
28873 www-data 20 0 293m 47m 5572 S 6.0 4.8 0:41.26 php5-fpm 
25241 www-data 20 0 80176 6112 2036 S 0.3 0.6 28:57.78 nginx 
28872 www-data 20 0 293m 47m 5548 S 0.0 4.8 0:34.50 php5-fpm 
28874 www-data 20 0 290m 44m 5556 S 0.0 4.5 0:34.60 php5-fpm 
28875 www-data 20 0 286m 39m 5320 S 0.0 4.0 0:40.08 php5-fpm 
29249 www-data 20 0 281m 34m 5288 S 0.0 3.5 0:32.04 php5-fpm 
31620 www-data 20 0 280m 33m 5176 S 0.0 3.4 0:02.06 php5-fpm 

Файлы журнала, кажется, не дает мне никакой полезной информации и ISN 't вызывает что-либо для входа в php slowlog с порогом 15s.

Как уже упоминалось, это проблема только в прерывистом состоянии, и я не могу найти шаблон.

Любая помощь была бы принята с благодарностью.

Также, если есть лучший способ провести разделенное тестирование, я хотел бы услышать об этом.

+0

не может быть связано с ssl? у вас есть отдельный ключ ssl для субдомена или с помощью подстановочного сертификата? также проверьте поиск dns на самой машине - просто чтобы это исключить. включите журналы отладки nginx и php-fpm - см., что использует большую часть времени. если в php, проверьте время запроса db и т. д. ах, просто увидели, что медленный лог php-fpm пуст, поэтому я подозреваю не php-fpm проблемы. – troseman

ответ

0

У вас установлен NewRelic (или любой другой инструмент для профилирования)? Это поможет выяснить точную причину медленных транзакций, поскольку проблема может быть полностью в другом месте.

+0

У нас установлена ​​базовая версия NewRelic, но до сих пор мне не удалось отладить эту проблему. Поскольку оба сайта используют одну и ту же CMS, есть только один файл, который используется для всего сайта, и имя файла, которое ссылается на NewRelic, одинаково для обоих – Onfire

 Смежные вопросы

  • Нет связанных вопросов^_^