☰

Nginx обслуживает статические файлы слишком медленно

tag-icon • tag-icon nginx
Nginx обслуживает статические файлы слишком медленно

Я задал этот вопрос на Stack Overflow, но, возможно, это больше вопрос к команде SF.

Итак, было много статей, подобныхВот этотнедавно, восхваляя достоинства Django Static Generator при использовании в сочетании с легким front-end веб-сервером. Для меня это имеет большой смысл.

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

Я готовлюсь запустить редизайн веб-сайта моей газеты. Я сейчас использую Static Generator на тестовом сервере. И когда я запускаю Apache Bench на определенной статической странице, я получаю довольно жалкие результаты:

ab -c 10 -n 1000 http://journal.streamlister.com/news/

Concurrency Level:      10
Time taken for tests:   53.011 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      21281212 bytes
HTML transferred:       21067360 bytes
Requests per second:    18.86 [#/sec] (mean)
Time per request:       530.107 [ms] (mean)
Time per request:       53.011 [ms] (mean, across all concurrent requests)
Transfer rate:          392.04 [Kbytes/sec] received

Я наблюдаю topза сервером во время осады и вижу, что он вообще не обращается к Apache или серверу базы данных. Так что он фактически обслуживает кэшированную страницу. Nginx работает, но он никогда не превышает 2% использования памяти. CPU простаивает примерно на 95%.

Что я делаю не так? Может быть, я неправильно настроил nginx? Мой основной файл конфигурации вставлен ниже; include, специфичный для этого сайта, по сути, является точной копией примера конфигурации наДомашняя страница статического генератораЯ использую Ubuntu 9.10 на Slicehost 256k.

user not_my_real_username;
worker_processes  4;
error_log  /var/log/nginx/error.log;
pid        /var/run/nginx.pid;
events {
    worker_connections  8192;
}
http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;
    access_log  /var/log/nginx/access.log;
    sendfile        on;
    #tcp_nopush     on;
    keepalive_timeout  0;
    #keepalive_timeout  65;
    tcp_nodelay        on;
    gzip  on;
    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;
}

решение1

Вы можете увеличить производительность nginx, просто добавив следующие параметры в конфигурацию:

   http {

      open_file_cache max=1000 inactive=300s;
      open_file_cache_valid 360s;
      open_file_cache_min_uses 2;
      open_file_cache_errors off;

    }

решение2

Ваш nginx на самом деле обслуживает файлы с разумной скоростью. С внешней машины мне удалось получить 371 запрос в секунду с abодним из файлов CSS на этой странице.

Вы тестируете всю страницу, что означает, что вы делаете 22 запроса на ней. Мне удалось получить около 40 запросов в секунду при бенчмаркинге http://journal.streamlister.com/news/.

Возможно, это могло бы быть быстрее, но вы используете VPS, где разделяете ресурсы ЦП и дисковый ввод-вывод с другими.

решение3

Я бы согласился с gekkz, что это может быть ваш VPS. Я только что провел ab-тест на одном из моих статических файлов и получил:

Всего передано: 11203000 байт
HTML передано: 10861000 байт
Запросов в секунду: 674.14[#/сек] (среднее)
Время на запрос: 14,834 [мс] (среднее)
Время на запрос: 1,483 [мс] (среднее, по всем одновременным запросам)
Скорость передачи: получено 7375,39 [Кбайт/сек]

это был css-файл. Я также на VPS от linode.com. Недавняя запись в их блоге показывает,некоторые тестысделано на различных VPS, которые могут представлять интерес.

Я только что посмотрел, и мой файл конфигурации немного отличается. У меня настроено 2 процесса, 1024 соединения и включен keep_alive.

решение4

Я думаю, проблема в ваших тестовых параметрах. При максимальном параллелизме 10, но при доставке каждой страницы в общей сложности ~500 мс, вы увидите максимум около 20 запросов в секунду.

Вы проводили тестирование с более высокими уровнями параллелизма, используя ab? (Обратите внимание, что ab — это действительно упрощенный инструмент для нагрузочного тестирования веб-приложений, и его можно считать только «микробенчмарком»). Конечно, вам также следует проводить бенчмаркинг с другой машины, возможно, с нескольких машин, если пропускная способность или память представляют проблему.

Связанный контент