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

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

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

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

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

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


performance c10k
person John McAleely    schedule 11.03.2009    source источник
comment
Обычно первой исчерпывается память. Затем вы исправляете свое приложение. Тогда ЦП исчерпан. Затем вы исправляете свое приложение. Затем пропускная способность сети исчерпана. Затем вы исправляете свое приложение. Потом память иссякла...   -  person S.Lott    schedule 11.03.2009
comment
Многопоточный сервер, обслуживающий в основном статические файлы, не будет исчерпать оперативную память.   -  person vartec    schedule 11.03.2009
comment
Вопрос не имеет смысла. Теоретические ограничения производительности достигаются кэшем ОЗУ, разгрузкой TCP и т. д. Установка искусственных ограничений дает вам такое же искусственное ограничение производительности. И на практике все используют хоть какое-то кэширование ОЗУ, хотя бы в самих дисках.   -  person MSalters    schedule 02.04.2009

Ответы (9)


arrow_upward
14
arrow_downward

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

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

person vartec    schedule 11.03.2009
comment
Я предполагаю, что C10K означает десять тысяч клиентов, что неясно на странице Кегеля. Я изначально думал это как в схеме i18n/L10n - person Sam Hasler; 02.04.2009
comment
Итак, первая строка страницы Кегеля: пора веб-серверам одновременно обслуживать десять тысяч клиентов, не так ли? - person vartec; 02.04.2009

arrow_upward
4
arrow_downward

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

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

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

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

person George V. Reilly    schedule 16.03.2009

arrow_upward
2
arrow_downward

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

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

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

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

person efalcao    schedule 11.03.2009

arrow_upward
2
arrow_downward

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

person cmeerw    schedule 11.03.2009

arrow_upward
2
arrow_downward

100, 1 000, 10 000, 100 000 или 1 000 000 запросов в секунду, но что актуально сегодня?

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

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

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

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

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

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

person Nerd    schedule 04.08.2011

arrow_upward
1
arrow_downward

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

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

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

person Lazarus    schedule 11.03.2009
comment
Что еще более важно, скорость браузера и отклик кеша имеют такое же значение, как и все остальное. - person S.Lott; 11.03.2009

arrow_upward
0
arrow_downward

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

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

person Brandon    schedule 11.03.2009
comment
Когда я говорил об устранении эффектов ОС, языка и файловой системы, я имел в виду их нормализацию или допущение «наилучшего из доступных» для каждого из них. - person John McAleely; 11.03.2009

arrow_upward
0
arrow_downward

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

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

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

и т.д, и т.д, и т.д.

person Community    schedule 11.03.2009

arrow_upward
0
arrow_downward

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

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

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

person Paul Whelan    schedule 11.03.2009