Как я могу найти горлышко бутылки?
У меня есть EC2 m1.large Ubuntu 13.04
Запуск экземпляра PHP 5.5
, PHP-FPM
а также NGINX
, Кеш обрабатывается Elastic Cache
с помощью Redis
и база данных подключается к отдельному m1.large
MongoDB
сервер. Содержимое может быть довольно динамичным, так как лента новостей может быть динамичной, а мой сервер используется приложением iOS.
Я делаю тесты на осаду siege -d5 -c150
если я делаю только 1 осаду, я вижу время отклика менее 1 секунды. Если я добавлю другой сервер, чтобы сделать другой siege -d5 -c150
мое время отклика поднимается до 9-15 сек
Я очень новичок в настройке серверов, но кое-что говорит мне, что если мой сервер всегда имеет среднюю нагрузку на процессор 40-50% и потребляет менее 1 ГБ оперативной памяти. Я не должен видеть задержку 10++ сек, имея столько свободных ресурсов?
Что может быть моей горлышком от бутылки или, что еще лучше, как я могу ее найти?
/etc/sysctl.conf являются
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_tw_reuse = 0
net.ipv4.ip_local_port_range = 2000 65000
net.ipv4.tcp_no_metrics_save = 1
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_max_syn_backlog = 3240000
net.core.somaxconn = 3240000
net.ipv4.tcp_max_tw_buckets = 1440000
kernel.shmmax = 1073741824
net.ipv4.tcp_rmem = 4096 25165824 25165824
net.core.rmem_max = 25165824
net.core.rmem_default = 25165824
net.ipv4.tcp_wmem = 4096 65536 25165824
net.core.wmem_max = 25165824
net.core.wmem_default = 65536
net.core.optmem_max = 25165824
net.ipv4.tcp_mem = 1474560 1966080 2949120
/etc/php5/fpm/pool.d/www.conf
pm = dynamic
pm.max_children = 32
pm.start_servers = 3
pm.min_spare_servers = 2
pm.max_spare_servers = 5
pm.max_requests = 150
/etc/nginx/nginx.conf
user www-data;
worker_processes 4;
pid /run/nginx.pid;
events {
worker_connections 32768;
multi_accept on;
use epoll;
}
http {
include /etc/nginx/mime.types;
default_type application/octet-stream;
sendfile on;
tcp_nopush on;
tcp_nodelay on;
keepalive_timeout 15;
server_tokens off;
# allow the server to close the connection after a client stops responding. Frees up socket-associated memory.
reset_timedout_connection on;
# send the client a "request timed out" if the body is not loaded by this time. Default 60.
client_body_timeout 10;
# If the client stops reading data, free up the stale client connection after this much time. Default 60.
send_timeout 10;
##
# Logging Settings
##
access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log;
##
# Gzip Settings
##
gzip on;
gzip_disable "MSIE [1-6]";
##
# Virtual Host Configs
##
include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;
server {
listen 80 default;
root /var/www/;
index index.php index.htm index.html;
# php-fpm bridge
# execute all .php files with php-fpm
location ~ .php$ {
fastcgi_pass unix:/var/run/php5-fpm.sock;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_buffer_size 128k;
fastcgi_buffers 256 16k;
fastcgi_busy_buffers_size 256k;
fastcgi_temp_file_write_size 256k;
include fastcgi_params;
}
}
}
результаты осады
ransactions: 1265 hits
Availability: 99.68 %
Elapsed time: 1196.10 secs
Data transferred: 21.30 MB
Response time: 11.48 secs
Transaction rate: 1.06 trans/sec
Throughput: 0.02 MB/sec
Concurrency: 12.14
Successful transactions: 1265
Failed transactions: 4
Longest transaction: 26.88
Shortest transaction: 0.00
1 ответ
- проверить каждый компонент в отдельности, а затем все вместе.
для каждого отдельного теста убедитесь, что вы просто тестируете чистую производительность, например, в nginx do
location /perftest/ { return 200; }
когда вы уверены, что каждый компонент настроен хорошо, начните комбинировать их и протестируйте снова
Кстати, вы используете правильные индиз на монго?