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

Question

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

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

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

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

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

Answer 1

Прочитано http://www.kegel.com/c10k.html. Вы также можете прочитать StackOverflow questions tagged 'c10k'. C10K - это 10 000 одновременных клиентов.

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

Answer 2

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

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

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

Answer 3

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

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

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

Answer 4

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

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

Answer 5

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

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

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

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

Answer 6

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

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

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

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

Answer 7

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

Answer 8

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

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

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

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

Answer 9

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-which-server-to-use/

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

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

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

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