У нас есть несколько клиентов в Азии и США, и мы наблюдаем это странное поведение при вызове request.data при обработке их запросов POST:
- Сингапурский клиент работает очень быстро (> 10 мс)
- Клиенты в США не такие быстрые (50 - 100 мс)
- Китайский клиент самый медленный (200+ мс)
Мы получили вышеуказанные данные с помощью cProfile, так что это должно быть точным (я думаю?). Полезная нагрузка каждого клиента варьируется от 50 до 700 байт, но, похоже, не демонстрирует каких-либо закономерностей (у сингапурского клиента полезная нагрузка POST среднего размера, а у китайского - небольшого размера)
Посмотрев на этот вопрос , я подозреваю, что мы сталкиваемся с чем-то похожим, когда запрос обрабатывается сразу после получения заголовков, поэтому вызывает request.data до получения полной полезной нагрузки POST. Я предполагаю, что китайские клиенты работают медленнее, поскольку GFW замедляет передачу полезной нагрузки POST.
У меня два вопроса:
- Имеет ли смысл анализ?
- Как я могу это исправить? Вышеупомянутое поведение кажется довольно неэффективным, поскольку мой экземпляр API блокируется на дополнительное время и тратит впустую циклы процессора. Кажется, что это будет работать лучше, если запрос будет полностью получен до отправки в экземпляр API
FWIW, я унаследовал эту кодовую базу, и в моем понимании могут быть некоторые пробелы, но наша архитектура DCOS похожа на изображение ниже. Я пытался искать параметры конфигурации во внешнем марафоне LB, чтобы увеличить буферизацию или отправлять только полностью полученные запросы, но я не нашел таких параметров.
