with texto strip_tags remove limpiar from eliminar allow all php comet

texto - ¿Usar el cometa con PHP?



string strip_tags (11)

Estaba pensando en implementar el chat en tiempo real usando un backend de PHP, pero encontré este comentario en un sitio que habla sobre el cometa:

Tengo entendido que PHP es un lenguaje terrible para Comet, porque Comet requiere que mantenga una conexión persistente abierta para cada cliente del navegador. Usar mod_php significa vincular a un niño Apache a tiempo completo para cada cliente que no se escale en absoluto. La gente que conozco haciendo cosas de Comet usa Twisted Python que está diseñado para manejar cientos o miles de conexiones simultáneas.

¿Es esto cierto? ¿O es algo que se puede configurar?


PHP

Encontré este pequeño screencasts divertido que explica el cometa simple. Como nota al margen, realmente creo que esto va a matar a su servidor en cualquier carga real. Cuando solo tengo un par de usuarios, diría que solo busque esta solución. Esta solución es realmente simple de implementar (las capturas de pantalla solo toman 5 minutos de su tiempo :)). Pero como les decía anteriormente, no creo que sea bueno para muchos usuarios simultáneos (supongo que deberían compararlo;)) porque:

  1. Utiliza archivos de E / S que es mucho más lento que solo obtener datos de la memoria. Como por ejemplo las funciones filemtime() ,
  2. En segundo lugar, pero no creo que PHP tenga un modelo de hilo decente. PHP no fue diseñado para esto de todos modos debido al modelo de compartir nada . Al igual que las diapositivas, dice "Los datos compartidos se transfieren a la capa de almacenamiento de datos" como, por ejemplo, MySQL.

Alternativas

Realmente creo que deberías probar las alternativas si quieres hacer cualquier cometa / larga encuesta. Puede usar muchos idiomas, como por ejemplo:

  • Java / JVM: continuations Jetty.
  • Python: Dustin''s slosh .
  • Erlang: lenguaje popular para cometa / etc.
  • Lua, Ruby, C, Perl solo por nombrar algunos.

El simple hecho de realizar una simple búsqueda en Google, le mostrará muchas alternativas, además de PHP (que creo que en cualquier carga grande matará a su servidor).



Actualmente estoy implementando un servidor escalable PHP Comet usando funciones de socket. Se llama ''phet'' ([ph] p com [et])

Página del proyecto: http://github.com/Tim-Smart/phet

Libre gratis para unirse al desarrollo. En la actualidad, he logrado hacer la mayor parte de la lógica del servidor, solo necesito terminar con las cosas del lado del cliente.

EDITAR: Recientemente se agregaron capacidades ''Multi-threading'' usando el método pcntl_fork :)


Creo que esto es más un problema que tener un montón de subprocesos de apache ejecutándose todo el tiempo es un problema. Eso existirá con cualquier idioma si funciona a través de apache de la misma manera que lo hace PHP (generalmente).


Deberá crear su propio servidor en PHP. Usar Apache / mod_php o incluso fastcgi no se escalará en absoluto. Algunos años, pero puede comenzar:

PHP-Comet-Server: http://sourceforge.net/projects/comet/


Estoy de acuerdo / ampliando lo que ya se ha dicho, no creo que FastCGI resuelva el problema.

apache

Cada solicitud en Apache usará un hilo de trabajo hasta que la solicitud finalice, lo que puede ser un largo tiempo para las solicitudes COMET.

Este artículo sobre Ajaxian menciona el uso de COMET en Apache, y que es difícil. El problema no es específico de PHP y se aplica a cualquier módulo CGI de fondo que desee utilizar en Apache.

La solución sugerida fue utilizar el módulo MPM ''evento'' que cambia la forma en que se envían las solicitudes a los hilos de trabajo.

Este MPM intenta solucionar el "problema de mantener vivo" en HTTP. Después de que un cliente completa la primera solicitud, el cliente puede mantener la conexión abierta y enviar más solicitudes usando el mismo socket. Esto puede ahorrar una sobrecarga significativa en la creación de conexiones TCP. Sin embargo, Apache tradicionalmente mantiene todo un proceso / subproceso esperando datos del cliente, lo que trae sus propias desventajas. Para resolver este problema, este MPM usa un subproceso dedicado para manejar los sockets de escucha y todos los sockets que están en un estado Keep Alive.

Desafortunadamente, eso tampoco funciona, porque solo se ''pospondrá'' una vez que se complete una solicitud, esperando una nueva solicitud del cliente.

PHP

Ahora, teniendo en cuenta el otro lado del problema, incluso si resuelve el problema con la retención de un hilo por solicitud de cometa, aún necesitará un hilo PHP por solicitud: esta es la razón por la cual FastCGI no ayudará.

Necesitas algo así como Continuations que permita reanudar las solicitudes de cometas cuando se observe el evento por el que se desencadenaron. AFAIK, esto no es algo posible en PHP. Solo lo he visto en Java: mira el servidor Apache Tomcat .

Editar:

Aquí hay un artículo sobre el uso de un equilibrador de carga ( HAProxy ) que le permite ejecutar tanto un servidor apache como un servidor habilitado para cometas (por ejemplo, embarcadero, tomcat para Java) en el puerto 80 del mismo servidor.


Estoy teniendo un problema similar. Una opción que me parece interesante es usar un servidor Comet existente, como cometd-java o cometd-python, como el núcleo central de mensajes. Su código PHP es simplemente un cliente del servidor Comet: puede publicar o leer mensajes de canales, al igual que otros clientes.

Hay un fragmento de código interesante vinculado aquí: http://morglog.org/?p=22=1 que implementa parte de este método (aunque también hay fragmentos de código de depuración distribuidos).


Podría usar Nginx y JavaScript para implementar un sistema de chat basado en Comet que sea muy escalable con poca memoria o uso de la CPU.

Aquí tengo un ejemplo muy simple que puede ayudarlo a comenzar. Cubre la compilación de Nginx con el módulo NHPM e incluye código para roles simples de editor / suscriptor en jQuery, PHP y Bash.

http://blog.jamieisaacs.com/2010/08/27/comet-with-nginx-and-jquery/


También puedes probar https://github.com/reactphp/react

React es una biblioteca de bajo nivel para programación dirigida por eventos en PHP. En su núcleo se encuentra un bucle de eventos, además de los cuales proporciona utilidades de bajo nivel, tales como: abstracción de flujos, resolución dns asincrónica, cliente / servidor de red, cliente / servidor http, interacción con procesos. Las bibliotecas de terceros pueden usar estos componentes para crear clientes / servidores de red asíncronos y más.

El ciclo de eventos se basa en el patrón del reactor (de ahí el nombre) y está fuertemente inspirado en bibliotecas como EventMachine (Ruby), Twisted (Python) y Node.js (V8).

El ejemplo introductorio muestra un servidor HTTP simple que escucha en el puerto 1337:

<?php $i = 0; $app = function ($request, $response) use (&$i) { $i++; $text = "This is request number $i./n"; $headers = array(''Content-Type'' => ''text/plain''); $response->writeHead(200, $headers); $response->end($text); }; $loop = React/EventLoop/Factory::create(); $socket = new React/Socket/Server($loop); $http = new React/Http/Server($socket); $http->on(''request'', $app); $socket->listen(1337); $loop->run();


Tendrá dificultades para implementar el cometa en PHP, solo porque es un hilo único inherente.

Eche un vistazo a Websync On-Demand : el servicio le permite integrar PHP a través de la publicación en el servidor, descargando las pesadas conexiones simultáneas y le permitirá crear una aplicación de chat en tiempo real en muy poco tiempo.