Сегодня про закон Литтла.

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

Как теория очередей связана с нагрузкой? Закон Литтла, один из самых простых и легко понимаемых результатов теории очередей, гласит, что среднее количество клиентов в системе равно средней скорости прибытия, умноженной на среднее время пребывания в системе. В этом случае клиенты — это запросы в обработке, скорость прибытия — это объем трафика, представленного серверу, а время пребывания — это количество времени, необходимое для обработки каждого запроса. Закон доказывается не самым простым, но вполне понимаемым для студента образом. На удивление в курсах по компьютерным наукам эта тема практически не затрагивается, а вот в на курсах по физике, не так мало информации можно найти!

И о сколько интересных результатов вы можете получить с этим законом. Например, когда вы читаете с HDD диска, то вы сначала перемещайте головку диска где-то за 10ms, а потом читаете со 100 MB/s скоростью. Если вы хотите тратить меньше половины времени на seek, чем на чтение данных, то вам нужно иметь более (20 - 10) ms * 100 MB/s = 1 MB на чтение за раз. За пределами единичных множителей поверх этого числа вы получаете убывающую отдачу с точки зрения амортизации времени 10/(10 + X MB), потраченного в пустую на seek для чтения всех данных. Это полезно знать, потому что большие блоки не дают читать другим процессам, которым тоже нужны данные, а вот откуда и получаются примерные размеры блоков, какие мы должны или хотим читать за раз. Пару раз от людей из пространства слышал что-то в духе как "не заseekать диск до смерти", когда они обсуждали закон Литтла.

И то же самое можно применить в условии фикса багов/тикетов в команде. Количество текущих багов примерно равно среднему времени фикса помножить на скорость их пребывания.

В какой-то степени все этот закон понимают интуитивно в простых случаях -- скажем, у вас seek HDD диска занимает 10ms, то значит вы можете всего 100 IOPS сделать на нём (всего на HDD может быть 1 in-flight request), но теряются когда надо ответить на тот же вопрос про SSD.

Например, если SSD/NVME обрабатывает запросы в среднем за 20 микросекунд и делает это с 10M IOPS, то одновременно в среднем обрабатывается 200 запросов. Если подумать, выше этого немного тяжело уйти, надо уметь 200 запросов очень быстро класть в очередь (из разных потоков в идеале, так как переключение контекстов уже 1-2 микросекунды) для обработки и отправлять устройству. Поэтому любые оптимизации в драйверах, firmware, ядре и так далее сильно увеличивают цифры IOPS, особенно на больших квантилях. Ну и показывает, что скорее всего лимиты вашей системы ещё ой как недоутилизированы.