Обработка медленных запросов

Иногда нам нужно обрабатывать медленные бизнес-процессы. Чтобы избежать влияния медленных бизнес-процессов на обработку других запросов в webman, эти бизнес-процессы могут быть обработаны различными способами в зависимости от ситуации.

Использование очереди сообщений

Смотрите redis очередь stomp очередь

Преимущества

Может обрабатывать внезапно поступающие запросы на обработку большого объема бизнес-процессов

Недостатки

Невозможно напрямую вернуть результат клиенту. Для отправки результата необходимо использовать другие службы, например, использование webman/push для отправки обработанного результата.

Добавление HTTP-порта

Примечание
Эта функция требует webman-framework>=1.4

Добавление обработки медленных запросов через новый HTTP-порт, где эти медленные запросы обрабатываются в отдельной группе процессов и возвращают результат напрямую клиенту.

Преимущества

Возможность напрямую возвращать данные клиенту

Недостатки

Невозможно обрабатывать внезапно поступающие запросы большого объема

Шаги реализации

Добавьте следующую конфигурацию в config/process.php.

return [
    // ... Здесь пропущены другие конфигурации ...

    'task' => [
        'handler' => \Webman\App::class,
        'listen' => 'http://0.0.0.0:8686',
        'count' => 8, // Количество процессов
        'user' => '',
        'group' => '',
        'reusePort' => true,
        'constructor' => [
            'request_class' => \support\Request::class, // Установка класса запроса
            'logger' => \support\Log::channel('default'), // Экземпляр журнала
            'app_path' => app_path(), // Путь к каталогу приложения
            'public_path' => public_path() // Путь к каталогу public
        ]
    ]
];

Таким образом, медленные запросы могут обрабатываться через эту группу процессов по адресу http://127.0.0.1:8686/, не влияя на обработку других процессов.

Чтобы сделать разницу в портах незаметной для фронтенда, вы можете добавить прокси для порта 8686 в nginx. Предположим, что пути медленных запросов начинаются с /tast, тогда целая конфигурация nginx будет выглядеть примерно следующим образом:

upstream webman {
    server 127.0.0.1:8787;
    keepalive 10240;
}

# Добавление новой upstream для 8686 порта
upstream task {
   server 127.0.0.1:8686;
   keepalive 10240;
}

server {
  server_name webman.com;
  listen 80;
  access_log off;
  root /path/webman/public;

  # Запросы, начинающиеся с /tast, будут направлены на порт 8686. Вам нужно изменить /tast на фактический префикс в соответствии со своими потребностями
  location /tast {
      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header Host $host;
      proxy_http_version 1.1;
      proxy_set_header Connection "";
      proxy_pass http://task;
  }

  # Остальные запросы будут отправляться на оригинальный порт 8787
  location / {
      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header Host $host;
      proxy_http_version 1.1;
      proxy_set_header Connection "";
      if (!-f $request_filename){
          proxy_pass http://webman;
      }
  }
}

Таким образом, при обращении клиента по адресу домен.com/tast/xxx запрос будет направлен на отдельный порт 8686, не влияя на обработку запросов на порту 8787.