У нас есть собственная стойка в Амстердаме, Leaseweb.
Мы делаем балансировку нагрузки HTTP (через Cloudflare) с 3 серверами IIS Windows 2019:
- Сервер 1: супермикросервер без операционной системы. Запускает IIS, MySQL8 и Redis.
- Сервер 2: виртуальная машина на сервере Dell. Запускает ИИС.
- Сервер 3: ВМ на сервере Dell (точная копия server2). Запускает ИИС.
Файлы обслуживаются локально во всех случаях (через репликацию)
Теперь проблема в том, что TTFB, как измеряется локально на сервере выше на сервере 2 и сервере 3 (виртуальные машины).
Запуск (несколько) тестов ЛОКАЛЬНО с хромом:
Сервер 1:
- Ожидание (TTFB): 269 мс
- Ожидание (TTFB): 255 мс
- Ожидание (TTFB): 253 мс
Сервер 2:
- Ожидание (TTFB): 379 мс
- Ожидание (TTFB): 376 мс
- Ожидание (TTFB): 369 мс
Сервер 3:
- Ожидание (TTFB): 374 мс
- Ожидание (TTFB): 381 мс
- Ожидание (TTFB): 378 мс
Как видите, у первого сервера TTFB значительно ниже.
С точки зрения процессора серверы 2 и 3 на самом деле быстрее:
СЦЕНАРИЙ БЕНЧМАРА PHP
Сервер1
Общее время: : 4,022 сек.
Сервер2
Общее время: : 2,866 сек.
Сервер3
Общее время: : 2,936 сек.
Ввод-вывод примерно одинаков для всех серверов. Все они имеют новые SSD с аппаратными рейд-контроллерами.
Я проверил перенос Redis на одну из виртуальных машин, чтобы выяснить, связана ли дополнительная задержка с Redis, но это не имеет большого значения.
Я предполагаю, что дополнительная задержка в TTFB исходит от MySQL, который работает на сервере 1? Запуск MySQL на том же сервере дает значительно меньший TTFB, даже если процессор работает медленнее.
Есть ли обходной путь для этого?
На самом деле, правильный вопрос заключается в том, как я могу определить причину дополнительной задержки?
