Часто задаваемые вопросы. Для различных значений «часто».

Мифы, ложь и микробенчмарки: разве x миллисекунд недостаточно быстро?

Для тех, кто не знаком с микробенчмарками, может показаться заманчивым думать, что x миллисекунд для перебора коллекции или выполнения какой-либо задачи, как видно из микробенчмарка, будет достаточно для приложения xyz. К сожалению, это игнорирует важный урок проектирования для масштабируемости: микробенчмарки вообще не измеряют абсолютную производительность, и очень опасно проектировать приложения на основе этого заблуждения.

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

Чтобы объяснить это подробнее, на этот вопрос лучше всего ответить другим вопросом:

Какова средняя задержка на запрос для очереди из 10 запросов, где каждый запрос занимает 10 мс для обработки?

Вот хорошая диаграмма:

Общая задержка на запрос — это время обработки этого запроса плюс сумма времён обработки запросов впереди него в очереди. Или общая задержка = время обработки + задержка в очереди.

Некоторые интересные факты об этом:

• Средняя задержка составляет 50 мс;
• 50% запросов занимают более 50 мс для обработки;
• 10% запросов занимает 100 мс для обработки.

Поведение, подобное очереди, и нехватка ресурсов процессора происходят в приложениях неявно, когда возникают всплески трафика.

Даже в приложениях, в которых нет явных очередей, поведение, подобное очереди, происходит за любой синхронизированной логикой, блокирующими вызовами ввода-вывода или за любым этапом обработки, который не может принимать запросы быстрее, чем они поступают. Задержка в очереди умножает задержки на порядки. Неспособность учесть задержку в очереди при проектировании приложений является основной причиной внезапной неотзывчивости приложений при большой нагрузке: очереди просто начинают расти, количество потоков взрывается, задержки стремительно растут. Иногда компоненты, обрабатывающие запросы, могут сообщать, что время обработки приемлемо, но задержка может быть высокой.

Анекдот: если вы подозреваете, что конкретный запрос к базе данных замедляет работу вашего приложения, но администратор базы данных говорит, что его время обработки составляет 10 мс, правильный ответ — «какая длина очереди?».

При проектировании приложений даже рассмотрение среднего времени отклика для различных рабочих нагрузок само по себе опасно. Из диаграммы выше должно быть ясно, что изменчивость времени отклика вероятна и проблематична. Если требования указывают, что приемлемое время отклика составляет 50 мс, то как насчёт того, что у 1 из 10 запросов задержка составит 100 мс? Рассмотрение только среднего времени ответа скроет эту проблему. Распределение задержек при различных нагрузках или при всплесках трафика важно.

Связанным виновником является нехватка ресурсов процессора, вызванная чрезмерной подпиской количества потоков на ядра процессора в рабочих нагрузках, связанных с процессором (таких как итерация). Если у вас есть 8 потоков, пытающихся перебирать коллекции параллельно, и только 4 ядра, задержка на запрос будет более чем удвоена (она усугубляется накладными расходами на переключение контекста). Связывание потоков для обработки запросов дольше дополнительно усугубляет проблему, требуя создания большего количества потоков в пулах потоков для обработки дополнительных входящих запросов.

Ответ на этот вопрос действительно таков:

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

Задержка в очереди и нехватка ресурсов процессора часто будут увеличивать задержки в реальных приложениях на порядки.

Это относится к бенчмаркам в этом проекте как для итерации, так и для CQEngine: задержка для обоих этих подходов увеличится на порядки в продакшене. Цель CQEngine — быть быстрее в первую очередь, чтобы, когда задержка действительно увеличивалась под нагрузкой, она увеличивалась с гораздо более низкой начальной точки. Какие уровни изоляции транзакций поддерживает CQEngine?

• См. TransactionIsolation.