Правильно ли я понимаю теорию нагрузки на сервер с 100 мбитным каналом?

Question

[webman2004]

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

Допустим, сервер только принимает запросы, но не отдает ответы. Железо сервера и исполняемый код на нем выдерживают обработку 10 тыс./сек. запросов.
Отправляемый объем данных на сервер постоянен и равняется 300 байт в одном запросе, получается что канал может выдержать 100 мбит/300 байт = 43690 запросов/сек.
Поскольку железо и ПО способно обработать только 10 тыс./сек., то канал используется неэффективно? В данном случае хватило бы канала около 25 мбит?

Теперь, сервер только отсылает ответы и способен обработать 10 тыс./сек.
Отправляемый объем данных постоянен и равняется 50 кбайт в одном ответе, получается что канал может выдержать 100 мбит/50 кбайт = 256 ответов/сек.
Поскольку канал способен обработать только 256 ответов/сек., то железо используется неэффективно? В данном случае хватило бы железа способного обработать 256 запросов/сек?

Спасибо!

Answer 1

[Клёвый Админ]

В ваших рассуждениях есть логика.
Но не забывайте:
1. Учитывать накладные расходы (это и служебный трафик и системный трафик и подтверждения доставки и все хендшейки и тд.), которые могут составлять большой % от целевого трафика
2. Не забывайте про latency. На толстых каналах, чаще всего, этот показатель ниже, так как, опять же чаще всего, он растёт экспоненциально нагрузке на канал, так для нагрузки 80 мегабит для сто мегабитного канала, задержки уже могут проявляться, для гигабита - точно нет.
3. Всегда используйте ваши мощности не на 100%. Даже на не 80%. Хорошей практикой будет использовать в пике 60% от мощностей.
4. Лучше иметь одно контролируемое бутылочное горлышко, параметры которого заранее известны (например ширина канала), чем иметь 5-ть не контролируемых, каждое из которых срабатывает в разные моменты времени (то CPU в полку, то памяти мало, то дисковая очередь, то канал).

Answer 2

[Сергей]

Когда ты принимаешь трафик, то примерно 1\10 от его объева уходит абоненту обратно в виде подтверждения доставки. Т.о. вы должны это учитывать также.

Answer 3

[index0h]

Так то оно так, но в реальности - нет. rps на разном железе у вас будет отличаться. Что касается трафика - важна еще скорость поступления / отдачи его из вне. Например клиент будет отправлять запрос на 300b со скоростью 8bit/sec, такой запрос проживет 37.5sec. Так же есть еще сетевые издержки.
Железо не стоит брать с расчетом в 100% нагрузку, это путь в никуда.

Comments

[123459]

https://en.wikipedia.org/wiki/Bandwidth-delay_product

https://news.ycombinator.com/item?id=13136536

можете для начала считать что 1/3ресурсов сервера вам недоступна напрямую - из-за неполной настройки, неоптимальности работы по, задержках при обмене данными с клиентами(они могут тоже тормозить и скачивать данные медленно. несмотря на низкий пинг и быстрый канал).
также есть проблемы масштабирования, которые проявляются при больших очередях, например статистически 10 серверов с производительностью 1 не равны одному серверу с производительностью 10 - почти всегда загрузка будет неравномерной, некоторы вообе могут быть перегружены.
но даже 1 быстрый сервер может блокироваться на каких-то конкретных тяжелых операциях определенного пользователя, и из-за этого время обслуживания всех пользователей будет меняться - https://www.elastic.co/blog/averages-can-dangerous...

bravenewgeek.com/everything-you-know-about-latency...

[webman2004]

Если 300 по 8 бит/сек., то получается канал будет забит каждую секунду на 8 бит, пока не придут все 300 бит?

[index0h]

webman2004 Нет, канал не забьется, это атака другого характера. У вас 300 соединений будут ждать данных. В таких темпах вы скорее упретесь по памяти, возможно по cpu.

Answer 4

[Пума Тайланд]

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

Comments

[webman2004]

Я поэтому и говорю, что "допустим" в одну сторону.