При запуске Apache Bench на том же сервере, что и веб-сайт, например:
ab -n 1000 -c 10 localhost:8080/
Вероятнее всего, я не получаю точных результатов при сравнении с пользователями, заходящими на сервер из разных мест.
Я пытаюсь понять, как или, вернее, почему это повлияет на производительность в реальном мире, поскольку у пользователя в Китае будут другие проблемы с задержкой по сравнению с пользователем в том же штате/стране.
Допустим, на моем веб-сервере максимальное количество потоков равно 100.
Может ли кто-нибудь подробно объяснить, как задержка конечного пользователя может/будет влиять на производительность сервера?
Я предполагаю, что каждый запрос будет обрабатываться одинаково, скажем, за 10 мс.
Чего я не понимаю, так это как внешние факторы могут влиять на общую производительность сервера, в частности на интернет-соединения (местоположение или даже устройство, например, мобильное), а также на рукопожатия http/tcp и т. д.
решение1
В целом задержка конечного пользователя не влияет на производительность сервера. Главное отличие будет в том, что при более высокой задержке конечного пользователя ваш сервер будет иметь больше подключений одновременно, поскольку каждое подключение занимает немного больше времени. Но сервер все равно выполняет примерно тот же объем работы для каждого подключения. Пока вы не упретесь в ограничения сервера, в первую очередь памяти, это не имеет значения.
Сервер не начнет выполнять тяжелую работу для соединения, пока не получит весь запрос. Так что если установка соединения и получение запроса займут больше времени, это будет означать, что сервер будет ждать немного дольше, по сути ничего не делая, прежде чем приступить к реальной обработке.
Обычно сервер обрабатывает запрос и ставит ответ в очередь за один раз. Задержка клиента и сети может означать, что потребуется немного больше времени, чтобы очистить эту очередь. Но часть сервера, которая этим занимается, сильно оптимизирована, и логика для конкретной страницы или объекта уже отработана до завершения генерации ответа. Так что, опять же, обычно это не оказывает существенного влияния на производительность сервера.
Однако клиентский опыт может быть намного хуже. Это особенно актуально, если у сервиса много случаев, когда клиент должен получить информацию с сервера, а затем снова подключиться для получения дополнительной информации. Например, если веб-страница говорит клиенту загрузить кучу кадров, а затем эти кадры говорят клиенту загрузить кучу изображений, будет много операций «туда и обратно» (каждая из которых увеличивается на задержку сети), прежде чем клиент увидит результат. Но сервер выполняет тот же объем работы.
решение2
На самом деле это не будет проблемой, если только у вас нет работающего в реальном времени многопроцессорного (скажем, 1К ЦП) суперкомпьютера с большим объемом памяти...
В многопроцессорной системе все процессы имеют временное окно, которое называется Quantum Size. Операционные системы с многопроцессорными возможностями, которые существуют примерно с 80-х по 90-е годы и по сей день, переключаются между запущенными процессами, давая каждому из них этот квантовый размер. Это временное окно составляет около 20 миллисекунд в наших современных операционных системах, и это переключение выполняется так быстро с очень низкими накладными расходами на переключение. Скажем, если у нас есть один процессор, между которыми переключаются два процесса за 1 секунду, что равно 1000 миллисекундам, мы можем запустить их в течение 900-950-980 (возможно) миллисекунд (разница уходит на переключение процессов). В любом случае, как я уже сказал, это переключение выполняется так быстро, и представьте себе 50 запущенных процессов, мы видим, что все процессы выполняются одновременно. На самом деле это не так, и это многопроцессорность, основы планирования процессов...
Когда у нас есть многопоточность в процессах, ОС сначала планирует процесс и дает ему квант, затем она планирует потоки в этом процессе. И в этом кванте потоки тоже планируют. Когда весь квант заканчивается, ОС планирует другой процесс (или то же самое в соответствии с алгоритмом планирования), и потоки в этом новом процессе также планируются.
Существует два уровня среды выполнения для потоков. Один — уровень пользователя, два — уровень ядра. Тот, о котором я упоминал выше, — уровень пользователя. Планирование процессов, планирование потоков в этом квантовом размере. Но когда вы спускаетесь на уровень ядра, планировщик может планировать разные потоки из разных процессов. Квант применяется к потокам непосредственно на уровне ядра...
После всего вышесказанного давайте начнем понимать, как задержка конечного соединения может повлиять на производительность сервера:
Ваши потоки должны быть на уровне ядра, если вы хотите максимальной производительности, и я знаю, что потоки Apache не находятся в режиме ядра. Сам Apache находится в пользовательском режиме, это пользовательское приложение, и его потоки работают в режиме уровня пользователя. Так что вы никак не получите 100% производительности от этого сервера... Допустим, потоки работают в режиме ядра, и у вас есть два процессора. Один поток для первого процессора, один поток для второго. Теперь два потока действительно работают одновременно. Рабочий поток веб-сервера на самом деле является I/O Boundedпотоком с точки зрения ОС, и когда он запрашивает какой-то файл, он будет заблокирован, пока файл не будет готов. Планировщик запланирует другой рабочий поток для запуска. Когда «этот» файл будет готов, заблокированный поток переместится в очередь готовности и будет запланирован снова. Так вот так хорошо... Что произойдет, если у вас будет 100 рабочих потоков? Этот вопрос порождает другой вопрос: когда создается рабочий поток?
Говоря о приложениях веб-сервера, рабочий поток создается, когда low-level IP connection is made. Итак, ваши фактические два потока уже запущены, новое соединение установлено оборудованием (у них есть свои собственные PU, и они прерывают основную систему для передачи данных и информации), появился новый рабочий поток, он был отправлен в очередь готовности для планирования...
Возвращаемся к основной теме, как внешний фактор влияет на производительность системы. Все дело в ограничениях системы. Количество потоков влияет на производительность, независимо от того, достаточно ли у системы единиц обработки для их обработки или нет. Простая математика: два процессора обрабатывают только два потока одновременно... Плохая пропускная способность сетевого соединения влияет на производительность на «сколько подключений оно может принять». Допустим, данные соединения составляют 10 байт, а пропускная способность — 100 байт в секунду, у вас может быть 10 подключений в секунду...
Масштабирование этих потоков зависит от вас. Вам нужно помнить только одно: ваш общий ресурс процессора уже обрабатывает потоки, которые находятся в очереди готовности... Поэтому, когда появляется новый поток, это просто не ухудшает положение текущих потоков.
Производительность может быть проблемой, когда серверное приложение запускается впервые. Он быстро достигает верхнего предела. Это своего рода ускорение автомобиля. Он сначала разгонится, а через некоторое время достигнет максимальной скорости. Вы можете ехать на максимальной скорости, пока не кончится бензин или пока не уберете ногу с педали газа.