Остановить запрос программно

Question

На работе мы время от времени запрашиваем, чтобы так долго возвращалось, что к моменту их завершения интерфейс (nginx) уже убил соединение, поэтому пользователь не увидит вывод (либо if это хорошо или плохо).

Хуже всего то, что балансиратор (haproxy) также убьет соединение, а затем предположим, что сервер может обрабатывать другой запрос, а это означает, что, хотя сервер все еще обрабатывает старый запрос, приходит новый и сражается за ресурсов.

В идеале серверы должны обрабатывать только один запрос за раз, чтобы как можно больше использовать поток соединений с базой данных ZEO, поэтому одновременное выполнение двух запросов делает сервер еще более медленным, а затем по праву считается одна из наших систем мониторинга перезапускает все вместе, потому что манекен доказывает, что он отправляет тайм-ауты.

Таким образом, содержит некоторую логику (возможно, повторное использование Products.LongRequestLogger, которое мы уже используем) есть ли способ сказать потоку, обрабатывающему запрос, прекратить его выполнение?

Answer 1

IMHO это плохая идея, чтобы отменить запрос вручную. Вы как-то вмешиваетесь в разрешение конфликта, а это ИМХО не очень хорошее поведение.

У меня запущено большое количество сайтов с 200-200 авторами, публикующими/изменяющими 1000 - 3000 объектов в день. Обычно нагрузка распределяется в течение дня, поэтому и более длительный запрос обрабатывается в разумные сроки.

Например, вечером, длительные запросы als (30s - 60s) преуспевают. нет причин прервать их.

В Plone у нас есть классические длинные запросы, такие как переименование/перемещение большого дерева, изменение прав доступа, копирование большого количества объектов. Тогда обычно конфликты происходят где-то в каталоге и прерывают транзакцию после 3 попыток.

Отменяя длинный запрос, вы просто удаляете некоторые функции от Plone. Вы можете подумать о добавлении условия к действиям переименования/перемещения/копирования, поэтому их больше нет, если у вас есть 1000 объектов в контейнере.

То, что я пытался/не сделал до сих пор:

• сделать длинные запросы короче (Ха-ха, теперь я просто сказал, но трудно достичь :-)) -> Для примера проверки это package's copy/move patch: Это делает нет более длинное выполнение каталога/каталога для переименования и перемещения, вместо этого оно обновляет только необходимые индексы. Мы многого добились с этим.

• Очереди: Я использовал, например, redis для очереди и обработки известных длинных действий. Конечно, вам нужно знать заранее, что является потенциальным длинным запросом, но, я думаю, вы уже знаете это в своей среде. Вы можете связаться с пользователем по электронной почте или каким-либо флэш-сообщением, если запрос будет выполнен.

• Keep каталог как можно делегировать все, чтобы Solr/elasticsearch (удаление SearchableText дает много ...)

• Оборудование: Я знаю, что звучит глупо, но это часто быстро победа , Попробуйте загрузить по крайней мере все объекты каталога в ОЗУ. вложите несколько $ в быстрый cpu/ssd (общий ввод-вывод). Это не так, как мне нравится, но это происходит, и в 2016 году это может дать вам некоторое время для решения проблемы длинных запросов.

Будущее:

• Вы, наверное, видели Джима Fultons "The ZODB" talk at the ploneconf 2016. Если вы можете справиться с разрешением конфликта на zeoclient, и вместо этого вы получите объект, а только государство, возможно, будет лучше реализовано разрешение конфликтов.

Эххх ... Сначала я только сделал замечание, но я превысил символы ограничения ;-)