производительность — Nginx + PHP-FPM + APC медленное время отклика

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

Спецификации:
1 процессор,
1 ГБ оперативной памяти,
Ubuntu 12.04 LTS,
Nginx 1.1.19,
PHP-FPM 5.3.10

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

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

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

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

Сначала все работало нормально, но через несколько дней мы начали получать жалобы на медленное время загрузки. После некоторой отладки это было только движение, направляющееся к ‘новому’ и только прерывистое. На этом этапе оригинальный сайт вообще не используется.

Мы медленно отключали функции, пытаясь определить, где проблема, но не можем найти ее. Сплит-тестирование было временно отключено, и получается, что даже если вы попытаетесь загрузить поддомен напрямую, у него иногда будет очень медленный начальный ответ (около 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 / Новый

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 pool.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

Похоже, что файлы журнала не дают мне никакой полезной информации, и это ничего не вызывает для входа в php slowlog с порогом 15 с.

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

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

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