Назад | Перейти на главную страницу

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

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

Так что было много статей вроде вот этот недавно превозносил достоинства Django Static Generator при использовании в сочетании с легким интерфейсным веб-сервером. Для меня это имеет большой смысл.

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

Я собираюсь начать редизайн веб-сайта моей газеты. Я получил его с помощью 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% памяти. Процессор простаивает около 95 процентов.

Что я делаю не так? Мог ли я как-то неправильно настроить nginx? Мой основной файл конфигурации вставлен ниже; включение, специфичное для этого сайта, в значительной степени является точной копией образца конфигурации на Домашняя страница статического генератора. Я запускаю 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/*;
}

Вы можете увеличить производительность 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;

    }

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

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

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

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

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

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

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

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

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