Anuncio de un mitap que se transforma sin problemas en una copa BeerPHP (en Moscú y en línea)

Hola, en agosto celebraremos una reunión en Moscú con oradores de otras ciudades, una reunión de BeerPHP y la transmisión de la parte oficial para todos los que no puedan unirse.

Hoy comenzamos a presentar oradores . Sergey Zhuk vendrá a la reunión de Bryansk: no hay fiesta en su ciudad y tiene algo que contar sobre PHP asincrónico: escribió libros sobre esto, una serie de artículos y más. A continuación se muestra una transcripción de un podcast reciente sobre esto, enlaces para escuchar y ver el lanzamiento, así como detalles sobre el propio mitap.



Pyotr Myazin, también conocido como PQR : Hoy estoy en contacto con uno de los principales expertos en ReactPHP. Sergey, recientemente visité reactphp.org y te encontré en la página principal. Escribes mucho sobre el tema, incluso tienes tu propio canal con instrucciones en video. Dime cómo llegaste a esto, ¿qué te enganchó en ReactPHP?

De hecho, redescubre el idioma que ha estado escribiendo durante muchos años.

Sergey, alias seregazhuk : Hace dos años, en un trabajo anterior, era necesario escribir un guión que constantemente llamara a los clientes y funcionara muy rápidamente. La tarea tenía que completarse "ayer", solo los desarrolladores de PHP estaban en el equipo; ya no había tiempo para una nueva pila. Pero resultó que todos escucharon algo sobre ReactPHP. Se posicionó como listo para la producción, todo fue muy fácil: acabamos de instalar la empresa a través del compositor, y fue posible escribir código asincrónico. Como resultado, escribieron una solución, la lanzaron, todos quedaron satisfechos.

Me di cuenta de que teníamos una herramienta, pero casi no había artículos, ejemplos prácticos como "Tenemos un problema así, lo resolvimos así", ni en ruso ni en inglés. Como resultado, escribí un par de artículos en mi blog, recibí comentarios positivos, y eso es todo, de alguna manera me atrajo. Estamos acostumbrados al modelo de Solicitud-Respuesta, pero vale la pena cargarlo en un código asíncrono, e inmediatamente preguntará: "¿Cómo podría ser eso?"

Peter: Hablemos de nuevo, ¿qué problema nos resuelve el código asincrónico y por qué se necesita ReactPHP en particular?

Sergey: Casi todas las aplicaciones tienen llamadas API o interacción con el sistema de archivos o consultas a la base de datos. Cuando esperamos una respuesta de ellos, nuestro procesador está inactivo, en lugar de hacer algo útil. No puede esperar una respuesta, pero inicie operaciones sin bloqueo y continúe. Surge la pregunta: "Si obtenemos ReactPHP en todas partes para E / S, ¿nuestras aplicaciones serán muchas veces más rápidas?"

Desafortunadamente, no puede simplemente tomar y reescribir nuestras aplicaciones a otras asincrónicas

Sergey: Pienso en usar ReactPHP en casos en los que el rendimiento es crítico y la E / S es nuestro bloqueo que bloquea todo. Además, recomendaría no transferir toda la aplicación a rieles asíncronos, es decir, reescribir este botlock en particular. Por lo general, una división asincrónica es mucho más fácil de insertar en un código de bloqueo tradicional que intentar reescribir toda la aplicación.

Peter: Ok, pero ¿por qué no comenzamos algunos procesos PHP entonces? Este está inactivo, pero el siguiente está ocupado.

Sergey: ¿Y cómo coordinamos los resultados? Supongamos que necesitamos obtener datos de tres fuentes, hacemos llamadas a tres API, luego compilamos los resultados y se los damos al usuario. Si hacemos tres flujos separados, surgirá el problema de coordinar el resultado.

Con un enfoque asincrónico, simplemente los ejecutamos, por así decirlo, en paralelo, luego obtenemos el resultado y lo procesamos. Con hilos, tendrá que coordinar de alguna manera esta bola, es decir, habrá un problema con el estado. Esto parece ser más complicado que un enfoque asincrónico.

Peter: lo entiendo. Tenía este pensamiento en mi cabeza: si queremos aumentar el número de usuarios. procesado por segundo, ¿cómo se lanzaría toda la pila de aplicaciones de Symfony en la versión asíncrona y procesaría una mayor cantidad de conexiones?

Sergey: Yo no haría eso. A menudo, la aplicación no se ralentiza por completo. Si surge la cuestión del rendimiento, lo más probable es que haya un par de cuellos de botella en el interior, lo que probablemente también provoque una E / S lenta. Y ahora traduciría estos cuellos de botella a ReactPHP.

Se vería como un pequeño programa asíncrono dentro del código de bloqueo habitual: por ejemplo, llamamos a tres solicitudes en paralelo, las procesamos y enviamos una respuesta al usuario, y el tiempo de ejecución total sería igual al tiempo de la solicitud más lenta. Si en el caso del enfoque tradicional, esperaríamos la primera solicitud, la segunda y la tercera. Pero la aplicación no se volvió asíncrona a partir de esto.

¿Y si lo comparamos todo con NodeJS y otros?

Peter: Y si lo comparamos todo con NodeJS, digamos, o Go, realmente existe una asincronía en toda la aplicación. Todas las solicitudes a la base de datos, al sistema de archivos, todas son asíncronas por dentro. ¿Esto significa, en principio, si todo está escrito en una forma asincrónica, hay algún beneficio?

Sergey: Será rentable si el problema inicial es E / S. Entonces sí, lo resolveremos. Nuestro código será lo más eficiente posible, capaz de procesar la cantidad máxima de tareas en lugar de estar inactivo y esperar a que se procese esta salida. Pero si inicialmente el problema no está en E / S, entonces al escribir todo de forma asíncrona, es poco probable que ganemos algo, y podemos obtener un código complejo que será difícil de leer y mantener.

Peter: De vuelta a PHP. Entonces, tenemos ReactPHP, y de los famosos análogos Swoole, Amp y Ext-async. Y dime en comparación, ¿cuál es la diferencia entre estos proyectos y qué tan bueno es ReactPHP, es rápido y tiene algún inconveniente en comparación con el mismo Swoole?

Sergey: De los tres, para ser honesto, sentí solo por Amp, y porque, como ReactPHP, es compatible de inmediato. Es decir, ponemos los componentes necesarios a través del compositor y ya está. Y aquí no me gustan las historias con extensiones. Porque si nos quedamos solos con PHP y la asincronía, entonces, me parece, es más razonable usar el lenguaje y las cosas nativas, y si usamos extensiones adicionales, aquí no hay PHP particularmente asincrónico, sino extensiones asincrónicas para PHP.

¿Cómo ReactPHP realmente listo para la producción?

Peter: "Soporte a largo plazo" está escrito en su sitio web. Es decir, algún tipo de soporte a largo plazo, sin cambios críticos en la API. Es asi? ¿Es todo lo suficientemente alto?

Sergey: si. El proyecto ReactPHP en sí ya es bastante antiguo. Ha estado trabajando desde el duodécimo año, tiene 7 años. Él ya tiene suficiente tiempo listo para la producción. Y sí, además, aquí viene el soporte a largo plazo para los componentes principales durante 2 años. Es decir, puede estar atado de forma segura a estos componentes, recibir correcciones, actualizaciones y no preocuparse por la compatibilidad con versiones anteriores. Durante dos años se comprometen a mantener sus versiones, nada se romperá. Esto, creo, es realmente genial, este es un gran paso adelante. Hasta donde recuerdo, hasta hace poco, Amp discutió algunos de sus componentes, no decidieron completamente sobre la interfaz y su API pública.

Peter: ¿Dónde recomiendas comenzar a aprender ReactPHP? Además de la documentación oficial y sus videos tutoriales, por supuesto. ¿Dónde están todas las comunidades? ¿Hay chats de telegramas o chats de discordia, foros?

Sergey: Desafortunadamente, no conozco una comunidad tan directa. Hay una cuenta de Twitter bastante activa: allí puede preguntar, hacer preguntas y estar interesado. Y los mineros responden bastante rápido: puedes escribirles personalmente en Twitter. Lo hice, pidiéndoles algunas cosas.



Peter: Bueno, gracias por una historia tan detallada sobre ReactPHP, y en este sentido anunciaré el Panda Meetup , que se llevará a cabo el 22 de agosto en Moscú en la oficina de Skyeng. Actuarás allí, ¿verdad?

Sergey: Sí, eso es correcto. Ven y chatea.

Peter: También habrá un informe sobre el diseño impulsado por dominio, que también es un tema interesante y interesante en el contexto de PHP, [y se han agregado otros dos más] y, como me dijeron los organizadores, habrá algunos después de la fiesta.

Golosinas:

• Versión completa de podcast de audio y YouTube
• Enlace para transmitir mitap para aquellos que no pueden venir
• Detalles sobre la fiesta posterior en el telegrama BeerPHP Moscú