Eu tenho um site com uma quantidade relativamente baixa de tráfego que normalmente é veiculado felizmente por 3 ou 4 instâncias de passageiros.
No entanto, às vezes, ele é prejudicado por um grande número de solicitações automáticas que podem levar de 15 a 20 segundos para serem concluídas. Isso resulta na fila global de backup e o servidor não responde aos usuários comuns:
----------- General information ------
max = 18
count = 18
active = 17
inactive = 1
Waiting on global queue: 115
Quinze minutos depois, depois de reiniciar o apache para limpar a fila, tudo volta ao normal:
----------- General information -----------
max = 18
count = 4
active = 0
inactive = 4
Waiting on global queue: 0
----------- Application groups -----------
/apps/mailapp/current:
App root: /apps/mailapp/current
* PID: 31044 Sessions: 0 Processed: 275 Uptime: 14m 21s
* PID: 31047 Sessions: 0 Processed: 314 Uptime: 14m 21s
* PID: 31060 Sessions: 0 Processed: 284 Uptime: 14m 17s
Aumentei o número máximo de instâncias para 18 (cerca de quantas podem concorrer no VPS), o que ajudou um pouco, mas não muito. Otimizei o pedido o máximo que pude (de 30 segundos para 15 a 20 segundos).
Como as solicitações que estão fazendo o backup são automatizadas, não há necessidade de atendê-las de maneira particularmente oportuna. Existe alguma maneira que eu possa separar um número de instâncias de passageiros que apenas servem a este pedido em particular? (com base no caminho do URL, talvez).
Eu meio que consertei isso.
Eu criei um novo host virtual com o apache com limites no número máximo de instâncias.
Isso foi linkado no sistema operacional para apontar para o aplicativo original. Isso me permite executar o aplicativo principal com quantas instâncias eu precisar, mas com restrições sobre quantas instâncias o host virtual com links simbólicos pode executar.
Isso levantou um problema relacionado ao uso de cpu no host com link simbólico: Apache / Passenger e cpulimit