Plone занимает много времени, чтобы ответить на запрос диапазона байтов
У нас есть два недавно обновленных экземпляра Plone 4.3.2 за балансировщиком нагрузки haproxy, который стоит за Apache.
Мы ограничиваем каждый экземпляр Plone обслуживанием двух одновременных запросов с использованием конфигурации haproxy.
Недавно мы столкнулись с проблемой, из-за которой клиент отправлял 4 последовательных запроса в байтовом диапазоне для PDF, каждый из которых занимал от 6 до 8 минут, чтобы получить ответ. Это заблокировало все доступные запросы на 6 минут, и, таким образом, haproxy заблокировал другие запросы в очереди. PDF хранит объект ATFile в Plone, который, как я считаю, должен был быть перенесен в хранилище BLOB-объектов в нашем недавнем обновлении.
Мой вопрос: какие шаги мы должны предпринять, чтобы предотвратить подобный сценарий в будущем?
Я также заинтересован в:
- как отладить, почему запросы диапазона байтов на слабо загруженном сервере должны так долго отвечать
- как plone.app.blob обрабатывает запросы в диапазоне байтов
- Можно ли настроить Apache таким образом, чтобы запросы байтового диапазона обслуживались из его кэша, а не с внутреннего сервера
Как и было запрошено, файл haproxy.cfg с лишней конфигурацией удален.
global
maxconn 450
spread-checks 3
defaults
log /dev/log local0
mode http
option http-server-close
option abortonclose
option redispatch
option httplog
timeout connect 7s
timeout client 300s
timeout queue 120s
timeout server 300s
listen cms 127.0.0.1:18181
id 3
balance leastconn
option httpchk
http-check send-state
timeout check 10s
acl cms_edit url_dom xxx.xxx.xxx.xxx
acl cms_not_ok nbsrv() lt 2
block if cms_edit cms_not_ok
server cms_instance1 app:18081 check downinter 10s maxconn 2 rise 1 slowstart 300s
server cms_instance2 app:18082 check downinter 10s maxconn 2 rise 1 slowstart 300s
2 ответа
Я решил отключить запросы диапазона байтов к внутреннему серверу Zope. Я добавил следующее в раздел прослушивания CMS в haproxy.
reqidel ^Range:.*
Вы можете установить https://pypi.python.org/pypi/Products.LongRequestLogger и проверить его файл журнала, чтобы увидеть, где застрял запрос.