¿Es php escalable con una encuesta larga ajax inversa?

Question

Estoy trabajando en un sitio web que muestra algunos datos de DB que cambian con frecuencia (Estado de una cola y una conversación de chat). Mi configuración actual es Apache/PHP/MySQL. Naturalmente, me gustaría evitar sondear el servidor cada x segundos ya que esto no se escala bien. Me gustaría revertir el largo sondeo ajax, sin embargo, he leído que Apache no funciona bien con esto, ya que rápidamente se queda sin hilos de trabajo. Hay muchos otros servidores web que solucionan este problema: nginx, tornado, etc. Sin embargo, mi problema es que PHP es el ÚNICO lenguaje de scripting del lado del servidor que conozco. También ya he escrito algunos scripts PHP, así que me gustaría guardarlos si puedo. Estoy de acuerdo con el cambio de servidor, siempre y cuando aún pueda usar PHP.

Pero después de investigar un poco más, he leído que la gente dice que PHP (PHP-FPM?) También crea un proceso para cada solicitud, lo que significa que si tengo cientos/miles de conexiones abiertas, habrá cientos/miles de procesos, que también serán un problema.

¿Puedo concluir que no hay buenas maneras escalables de hacer sitios web de larga duración con PHP? ¿Debo abandonar PHP y aprender otro lenguaje de scripting de servidor? Puedo continuar desarrollando encuestas largas utilizando mi configuración actual (Apache/PHP) por ahora, pero no quiero que la elección del lenguaje de scripts represente ninguna limitación en la escalabilidad de mi sistema cuando implemente. ¿Entonces qué debo hacer? No tengo mucha experiencia con la programación web, así que si algún gurú me puede dar algunos consejos, ¡te lo agradecería! ¡Gracias!

Answer 1

PHP ejecutado en modo php-fpm todavía tendrá limitaciones, especialmente si su código está consumiendo mucha memoria. No podrá ejecutar miles de procesos paralelos sin algo de memoria disponible. Pero generalmente se realiza más rápido que mod_php, y al menos el pedido HTTP que no necesita PHP es manejado por el servidor web, y si ese servidor web es nginx obtendrá muchas más solicitudes HTTP disponibles en paralelo.

Con php-fpm también tendrá una cola de solicitudes de espera, que puede ser útil en caso de un gran tráfico temporal, ya que al menos las solicitudes están en cola, no rechazadas.

Ahora las largas operaciones de sondeo están bien con nginx (u otras, eso es un ejemplo), pero no con PHP. PHP no está diseñado para ser un servidor de larga ejecución, cada solicitud es un proceso nuevo, realmente no es la elección correcta para KeepAlive. Pero "Dividir ut regnes" (dividir y regla). Sus largas tareas de sondeo podrían correr cerca de su aplicación PHP, pero sin su aplicación PHP.

Como ejemplo, mira el jappix project, este es un proyecto de PHP. Pero necesita colocar en algún lugar un servidor XMPP (como ejabberd) y un servidor BOSH con nginx como proxy en el puerto 80 para ese servidor BOSH (para tener el protocolo de chat xmpp en el puerto 80, a través de nginx y ejabberd, y nada en el lado de PHP para eso). El problema es conectar la autentificación de la aplicación, la identificación y demás, y esto tendrá que hacerse extendiendo la configuración del servidor XMPP (para que use el mismo servidor LDAP que su aplicación PHP, por ejemplo).

Su segundo problema de larga duración es el estado de una cola. Puede encontrar algunas extensiones XMPP para eso, tal vez. O puede realizar consultas ajax regulares en la cola. Una de las técnicas útiles para evitar la gran cantidad de solicitudes ajax en su aplicación PHP es reprogramar la siguiente comprobación de ajax en la devolución de llamada ajax del cheque, en función de los números de Fibonacci (es un ejemplo). Así que la primera vez que la próxima llamada ajax se programará 1 minuto después, la próxima vez 2 minutos, luego 3m, 5m, 8m, 13m, 21m, 34m, 55m, 89m, 144m, etc. La idea es que quizás sea importante verificar mensajes nuevos entrantes 1 minuto después de la carga de una página. Como el usuario sigue leyendo la misma página (o tomando un café, hablando con un amigo, yendo de vacaciones sin apagar su computadora, etc.), podemos retrasar cada vez más los próximos controles.Es una forma de asumir que el usuario no está realmente activo. Tenga en cuenta que puede detectar la actividad del usuario por otros medios y modificar la reprogramación.

Answer 2

PHP no es adecuado para encuestas largas, Comet y tecnologías reversa ajax. Debería usar Node.js