Каковы теоретические ограничения производительности на веб-серверах?

Question

Каковы типичные ограничения его производительности на развернутом в данный момент веб-сервере?

Я полагаю, что значимым ответом будет один из 100, 1000, 10000, 100000 или 1000000 запросов в секунду, но что верно сегодня? Что было правдой 5 лет назад? Чего можно ожидать через 5 лет? (т. е. как тренды в пропускной способности, производительности диска, производительности процессора и т. д. влияют на ответ)

Если это материально, следует учитывать тот факт, что HTTP через TCP является протоколом доступа. ОС, язык сервера и эффекты файловой системы следует считать лучшими в своем классе.

Предположим, что диск содержит много небольших уникальных файлов, которые обслуживаются статически. Я намерен устранить влияние кешей памяти, и это время ЦП в основном используется для сбора информации о сети / протоколе. Эти предположения предназначены для смещения ответа в сторону оценки «наихудшего случая», когда для запроса требуется некоторая пропускная способность, некоторое время процессора и доступ к диску.

Я только ищу что-то точное на порядок или около того.

Answer 1

Чтение http://www.kegel.com/c10k.html. Вы также можете прочитать вопросы StackOverflow , помеченные как 'c10k' . C10K означает 10 000 одновременных клиентов.

Короче говоря - в основном, это не пропускная способность и не процессор. Это параллелизм.

Answer 2

Шесть лет назад я видел, как Windows Server 2003 с 8 процессами обслуживает 100 000 запросов в секунду для статического содержимого. В этой коробке было 8 карт Gigabit Ethernet, каждая в отдельной подсети. Ограничивающим фактором была пропускная способность сети. Невозможно представить такой большой объем контента через Интернет, даже с поистине огромной трубкой.

На практике для чисто статического контента даже скромный блок может насыщать сетевое соединение.

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

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

Answer 3

100, 1000, 10000, 100000 или 1000000 запросов в секунду, но что сегодня верно?

Этот тест был проведен на скромном ноутбуке i3, но в нем были рассмотрены Varnish, ATS (Apache Traffic Server), Nginx, Lighttpd и т. Д.

http://nbonvin.wordpress.com/2011/03/24/serving-small-static-files-which-server-to-use/

Интересным моментом является то, что использование высокопроизводительного 8-ядерного сервера дает незначительный импульс большинству из них (Apache, Cherokee, Litespeed, Lighttpd, Nginx, G-WAN):

http://www.rootusers.com/web-server-performance-benchmark/

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

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

Answer 4

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

Answer 5

Я думаю, это действительно зависит от того, что вы служите.

Если вы обслуживаете веб-приложения, которые динамически отображают html, процессор потребляет больше всего.

Если вы обслуживаете относительно небольшое количество статических элементов много и много раз, вы, вероятно, столкнетесь с проблемами пропускной способности (поскольку сами статические файлы, вероятно, окажутся в памяти)

Если вы обслуживаете большое количество статических элементов, вы можете сначала столкнуться с ограничениями диска (поиск и чтение файлов)

Answer 6

Я думаю, что здесь слишком много переменных, чтобы ответить на ваш вопрос.

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

«Это то, что я хочу сделать и достичь, что мне нужно сделать?»

Answer 7

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

индексы, оптимизация запросов и т. Д.

Для статических файлов ваше приложение кеширует их в памяти?

и т. Д. И т. Д. И т. П.

Answer 8

ОС, язык сервера и эффекты файловой системы являются переменными здесь. Если вы уберете их, то у вас останется сокет TCP без накладных расходов.

В этот момент речь идет не о производительности сервера, а о сети. С сокетом TCP без накладных расходов ваш предел, который вы достигнете, скорее всего, будет на брандмауэре или сетевых коммутаторах с количеством одновременных обработок соединений.

Answer 9

Это будет зависеть от того, какое у вас ядро ​​процессора Какова скорость ваших дисков Что такое «толстая» труба «средних» хостинговых компаний? Что такое веб-сервер?

Вопрос слишком общий

Разверните свой сервер, протестируйте его с помощью таких инструментов, как http://jmeter.apache.org/ и посмотрите, как вы попали.