Тест производительности VPS сервера

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

По сути, у меня был SSH-доступ к двум серверам, один в Америке (шаред-хостинг) и другой в Англии (VPS). на обоих серверах был установлен apache, поэтому было решено использовать утилиту ab для создания стресс-нагрузки.

Использовались следующие параметры:

ab -n 500 -c 20 http://domain.ru/index.php

Тест в 500 запросов, с организацией 20 одновременных соединений.

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

Изначально проводил тестирование VPS-сервера, на котором был установлен WordPress. К тому времени уже была установлена и находилась в рабочем состоянии система кэширования XCache, WP-Super-Cache был отключен.

Concurrency Level:      20
Time taken for tests:   66.173179 seconds
Complete requests:      500
Failed requests:        0
Write errors:           0
Non-2xx responses:      500
Total transferred:      139500 bytes
HTML transferred:       0 bytes
Requests per second:    7.56 [#/sec] (mean)
Time per request:       2646.927 [ms] (mean)
Time per request:       132.346 [ms] (mean, across all concurrent requests)
Transfer rate:          2.06 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:       88   88   1.0     88      95
Processing:   676 2506 382.5   2470    4119
Waiting:      675 2506 382.5   2470    4118
Total:        766 2595 382.5   2558    4207

Довольно не плохо, 7.56 запроса в секунду. Единственно, сразу стала сказываться проблема нехватки памяти. Была израсходована вся оперативная память, под завязку, не оставляя места для буферов и кэша. И был заполнен полностью своп. То есть потребовалось более гигабайта оперативной памяти.

Загрузка процессора так же была довольно стрессовой. Все 4 ядра процессора были нагружены от 40 до 80%.

После этого включил расширение WP-Super-Cache, прописал редиректы в nginx для данного расширения. Перезапустил php5-fpm и сам nginx для высвобождения памяти. И повторил тест с теми же параметрами.

Concurrency Level:      20
Time taken for tests:   35.336727 seconds
Complete requests:      500
Failed requests:        0
Write errors:           0
Non-2xx responses:      500
Total transferred:      141500 bytes
HTML transferred:       0 bytes
Requests per second:    14.15 [#/sec] (mean)
Time per request:       1413.469 [ms] (mean)
Time per request:       70.673 [ms] (mean, across all concurrent requests)
Transfer rate:          3.91 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:       88   88   1.2     88      94
Processing:  1045 1299 238.7   1252    2976
Waiting:     1044 1298 238.7   1252    2976
Total:       1133 1387 238.8   1340    3066

Итого, тест опять пройден, но скорость отдачи уже достигает 14.15 запросов в секунду. При этом загрузка памяти и процессора была аналогична предыдущему тесту.

Чуть позже наткнулся на статью php-fpm + cache = Nginx on Steroids, в которой описывалось про технологию fastcgi_cache. Решил проверить в деле.

В файл /etc/nginx/nginx.conf в раздел http добавил строку:

fastcgi_cache_path /var/cache/nginx levels=1:2 keys_zone=testone:20m inactive=1d max_size=200m;

И затем в настройках тестируемого домена добавил:

         location ~ \.php$ {
                try_files $uri @wordpress;
                fastcgi_pass   unix:/var/run/php5-fpm.sock;
                fastcgi_index index.php;
                fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
                fastcgi_cache testone;
                fastcgi_cache_key $request_uri;
                fastcgi_cache_valid any 10m;
                include fastcgi_params;
        }

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

Concurrency Level:      20
Time taken for tests:   0.100 seconds
Complete requests:      500
Failed requests:        0
Write errors:           0
Non-2xx responses:      507
Total transferred:      141453 bytes
HTML transferred:       0 bytes
Requests per second:    4986.83 [#/sec] (mean)
Time per request:       4.011 [ms] (mean)
Time per request:       0.201 [ms] (mean, across all concurrent requests)
Transfer rate:          1377.74 [Kbytes/sec] received

Потрясающие 4986,83 запроса в секунду! Но что больше всего меня поразило, так это то, что потребление памяти и нагрузка на процессор оставались без изменений. То есть это далеко не предел. Скорость отдачи страниц с блога на WordPress стала сопоставима со скорость отдачи обычного статичного сайта!

Но, естественно, не обошлось и без проблем. Как оказалось, при включении fastcgi_cache практически не возможно стало работать с комментариями. После того, как пользователь оставляет комментарий, он добавляется в базу, исправно высылается уведомление на электронную почту, но сам комментарий не отображается на странице. Что очень не удобно. и в дальнейшем, по мере обновления кеша, информация о комментариях появляется не сразу везде, на всех страницах, а частично. то есть есть вероятность того, что информация о полученном комментарии будет показана на главной странице, но не будет показываться на самой странице, где этот комментарий был оставлен.

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

Для корректной работы админки блога приходиться прописывать отдельные правила nginx, которые отключают данную систему кэширования на определенных страницах.

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

Ну и напоследок, решил протестировать производительно хостера justhost.com, на котором в последнее время размещался мой сайт. На всякий случай не стал отключать WP-Super-Cache, использовал те же параметры команды.

Concurrency Level:      20
Time taken for tests:   27.180 seconds
Complete requests:      500
Failed requests:        0
Write errors:           0
Non-2xx responses:      502
Total transferred:      7472564 bytes
HTML transferred:       7282306 bytes
Requests per second:    18.40 [#/sec] (mean)
Time per request:       1087.190 [ms] (mean)
Time per request:       54.359 [ms] (mean, across all concurrent requests)
Transfer rate:          268.49 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:       88   89   0.4     89      92
Processing:   744  983 165.5    939    2278
Waiting:      566  805 165.6    761    2100
Total:        833 1072 165.6   1028    2367

Вполне сопоставимые результаты! Показатель в 18.4 запроса в секунду, при включенном использовании кэша для apache является довольно не плохим результатом. Правда и сервер используется с 12 гигабайтами оперативной памяти. Понятно, что все это делиться на всевозможных клиентов. Но для apache это не мало!

И к тому же, в данном случае apache лишь незначительно обошел по производительности nginx+php-fpm, установленном на менее мощном сервере.

Осталось разобраться, как будет вести себя VPS с данными настройками при долгих нагрузках, и как ограничить память выделяемые на процессы php5-fpm. Но это уже темы других статей.