Ищете шаблон / подход / предложения для обработки длительных операций, связанных с веб-приложением

Question

Я работаю над потребительским веб-приложением, которое должно выполнять длительный фоновый процесс, связанный с каждым запросом клиента. Под длительной работой я имею в виду от 1 до 3 минут.

Вот пример потока. Объект / виджет на самом деле не имеет значения.

1. Клиент заходит на сайт и указывает объект / виджет, который ищет.
2. Мы ищем / очищаем / фильтруем виджеты, соответствующие некоторым начальным критериям. <- длительный процесс </li>
3. Клиент дополнительно настраивает более подробную информацию о виджете, который он ищет.
4. Когда длительный процесс завершен, клиент может выполнить несколько последних шагов перед преобразованием.

Шаги 3 и 4 на самом деле не важны. Я просто упоминаю их, потому что мы можем выиграть время, пока мы выполняем длительный процесс.

Среда, в которой мы работаем, представляет собой стек LAMP - в настоящее время используется PHP. Не похоже на хороший дизайн, чтобы длительный процесс занимал поток apache в mod_php (или процесс fastcgi). Уровень Apache нашего приложения должен быть направлен на обслуживание контента, а не на обработку данных IMO.

Несколько вопросов:

1. Правильно ли наше мышление в том, что мы должны отделить эту "долго работающую" часть от уровня apache / web app?
2. Существует ли стандартный / типичный способ решить эту проблему в Linux / Apache / MySQL / PHP (мы открыты для использования другого языка для обработки, если это необходимо)?
3. Любые предложения о том, как это сделать? Например. мы создадим демона, который будет проходить через очередь FIFO?

Редактировать: Просто для пояснения, только около 1/4 длительного процесса ориентированы на базу данных. Мы работаем над оптимизацией этой части. Мы можем потенциально выполнить некоторую работу, но мы ограничены в сумме, которую можем сделать прямо сейчас.

Спасибо!

Answer 1

Как предложил Джонни, вы можете запустить дочерний процесс для выполнения фоновой обработки. Тем не менее, это должно быть сделано с некоторой осторожностью:

• Убедитесь, что все пропущенные параметры правильно экранированы
• Убедитесь, что более одной копии процесса не запускается одновременно

Если запущено несколько копий процесса, ничто не мешает (даже злонамеренному, просто нетерпеливому) пользователю выполнить перезагрузку на странице, которая его запускает, и в конечном итоге запускает так много копий, что у машины заканчивается оперативная память и она переходит остановка.

Таким образом, вы можете использовать подпроцесс, но делать это осторожно, контролируемым образом и правильно его проверять.

Другим вариантом является постоянное выполнение демона в ожидании запросов, который обрабатывает их и затем записывает результаты куда-то (возможно, в базу данных)

Answer 2

Рассмотрите возможность предоставления результатов поиска через AJAX из веб-службы вместо вашего приложения. Предположительно, вы можете перенести это на другой сервер и позволить вашему веб-приложению работать с контентом по вашему желанию.

Просто любопытно: 1-3 минуты кажется долгим поисковым запросом. Вы смотрели на индексы столбцов, которые вы запрашиваете, чтобы улучшить скорость? Или вам нужно выполнить какой-то алгоритмический процесс - возможно, вы могли бы выполнить некоторые из них в автономном режиме и заранее заполнить некоторые распространенные поиски подсказками?

Answer 3

Java-сервлеты могут выполнять фоновую обработку . Вы можете сделать что-то похожее на эту технологию в веб-технологии с поддержкой потоков. Хотя я не знаю про PHP.

Answer 4

Вот некоторые обсуждения Java-версии этой проблемы.

См. Java: как лучше всего общаться с пакетным сервером?

Две важные вещи, которые вы можете сделать:

1. Переключитесь на Java и используйте JMS.

2. Читайте в JMS, но используйте другой администратор очередей. Например, именованные каналы Unix могут быть приемлемой реализацией.

Answer 5

Не полный ответ, но я бы подумал, используя AJAX и передавая 2-й шаг чему-то более быстрому, чем PHP (C, C ++, C #), а затем функцию PHP, извлекает результаты из некоторого стека, скорее всего, просто из базы данных.

Answer 6

Это решение для бедняка:

exec ("/usr/bin/php long_running_process.php > /dev/null &");

В качестве альтернативы вы можете:

1. Вставьте в базу данных строку с подробностями фонового запроса, который демон может затем прочитать и обработать.

2. Записать сообщение в очередь сообщений, которую демон затем прочитал и обработал.