правильная настройка nginx

Тема правильной настройки nginx очень велика, и, боюсь, в рамки одной статьи на LOR никак не помещается.

Список musthave настроек для отдачи n стат страниц на максимальной скорости приветствуется. Т.е. настроек, без которых nginx можно считать не готовым, а тестирование не репрезентативным. Ну или ссылки на соотв статьи на других ресурсах.

http://nginx.org/ru/docs/example.html

Я даже не знаю, что м ответить..

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

Тестировать собираюсь минимум на одном своём ноуте.

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

Прелесно. И при чём тут сообщающиеся сосуды? С такими понтами давать такие хреновые иллюстрации — это просто блеск.

Напиши свой сервер на сях и порви их всех.

Только вот смысла в этом мало — скорости отдачи статики у nginx достаточно для практически во всех случаях.

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

Кстати, если ещё интересно, поиграйся с open_file_cache.

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

И при чём тут сообщающиеся сосуды?

Представь устройство по типу гидравлического пресса. Клиент и сервер давят по своей стороне. В результате они будут соревноваться за процессор как на гидравлическом устройстве - сколько смогут выжать друг друга - столько и сделают.

Для качественного сравнения можно и локальные тесты сделать: более быстрому веб-серверу будет соответствовать больше запросов.

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

Что-то я не увидел у товарища точного описания его теста. Т.е. непонятно что он делал.

более быстрому веб-серверу будет соответствовать больше запросов.

Это если он херней какой-то неведомой на блокировках занят. Например сам висит на disk IO, а клиенту тестирующему disk IO не нужен. А если не занят - тогда они будут соревноваться за процессор и работа клиента будет непосредственно влиять на производительность сервера.

сам висит на disk IO

По условию задачи меряется отдача мелкой статики, всё закэшируется.

тогда они будут соревноваться за процессор и работа клиента будет непосредственно влиять на производительность сервера.

Более быстрому веб-серверу всё равно будет соответствовать больше запросов. Да и раскидать их можно по разным процам.

http://dak1n1.com/blog/10-3-million-http-cluster

http://gwan.com/en_apachebench_httperf.html

http://mew.org/~kazu/proj/mighttpd/en/config.html (а тут ничего не видно кроме отключения дебага, логов и +RTS -N).

Попробовал ghc-7.8.1_rc1, ..., mighttpd2-3.0.3 + 4 ядра сервер, 4 ядра клиент — не получается у mighty в полтора раза быстрее nginx, получается либо хуже (~2 раза по rps — wrk, weighttp), либо совсем плохо на большом количестве конкурентов (~десяток раз, если верить weighttp).

Пасиб, статьи почитаю, просто исследования казу весьма странные, у меня ни разу не воспроизводились, а полную информацию как воспроизвести он не пишет.

По первой ссылке:

I used 6 web servers, 1 LVS Router, and 7 Load Generators. The machines were SuperMicro 1U servers with dual-socket Westmere Xeon (6-core) processors, and 48G RAM. The important part here was the network. 10-gigabit ethernet allowed my cluster to distribute large amounts of http traffic among the nodes.

Generally, a properly tuned Nginx server on Linux can handle 500,000 - 600,000 requests per second. My Nginx servers consistently handle 904k req/sec, and have sustained high loads like these for the ~12 hours that I tested them.

While the original goal was 3 million requests/sec, I was able to get up to about 5 million regularly, through repeated tests. (If you count the very highest spike in traffic, it actually peaked around 8 million).

Ну 6 * 900 ~ 5Mrps, ок.

http://haskell.cs.yale.edu/wp-content/uploads/2013/08/hask035-voellmy.pdf

Hardware: We run Haskell server programs on a SuperMicro X8OBN server, with 128 GB DDR3 memory and 8 Intel Xeon E7-8850 2 GHz CPUs, each having 10 cores with a 24 MB smart cache and 32 MB L3 cache. This server has four 10 Gbps Intel NICs. In the experiments, we turn off hyper-threading to prevent the system scheduler from scheduling multiple native threads that should run in parallel to a single physical CPU core. Client and workload generator programs run on Dell PowerEdge R210 II servers, with 16 GB DDR3 memory and 8 Intel Xeon E3-1270 CPUs (with hyper-threading) running at 3.40 GHz. Each CPU core has 256 KB L2 cache and 8 MB shared L3 cache. The servers communicate over a 10 Gbps Ethernet network and are configured so that each client server has a dedicated 10 Gbps path the main server. This level of network bandwidth was required to avoid network bottlenecks.

Software: The server software includes Ubuntu 12.04, Linux kernel version 3.7.1 on the SuperMicro server and version 3.2.0 on the Dell server, and Intel ixgbe driver (version 3.15.1). We use the latest development version of GHC at the time of this writing. For comparison of the threaded RTS of GHC without Mio, we use the development version of GHC with Mio patches removed. We run weighttp 8 on the Dell servers to benchmark HTTP servers. weighttp simulates a number of clients making requests of an HTTP server, with each client making the same number of requests. Each client establishes a connection to the server and then repeatedly requests a web page and then waits for the response. In addition to recording the throughput for a given run, we extend weighttp to uniformly and randomly sample the latency for a fraction of the requests.

nginx: 50-300Krps

0_o

а с товарищами из йеля это ещё веселее, у них то что зарелизено страшный тормоз, всё новое в сокрытом коде, на предложение что-нибудь показать, говорят, что допиливать надо :/ там для openflow у них библиотека была, которая по их словам рвёт лучшие реализации в разы..