Anúncio de um mitap que se transforma suavemente em um drinkcap BeerPHP (em Moscou e on-line)

Olá, em agosto, realizaremos uma reunião em Moscou com palestrantes de outras cidades, uma reunião do BeerPHP e a transmissão da parte oficial para todos que não puderem participar.

Hoje estamos começando a apresentar palestrantes . Sergey Zhuk comparecerá à reunião de Bryansk - não há festa em sua cidade e ele tem algo a dizer sobre PHP assíncrono: ele escreveu livros sobre isso, uma série de artigos e muito mais. Abaixo está uma transcrição de um podcast recente sobre isso, links para ouvir e visualizar o lançamento, além de detalhes sobre o mitap em si.



Pyotr Myazin, também conhecido como PQR : Hoje, estou em contato com um dos principais especialistas em ReactPHP. Sergey, visitei recentemente o reactphp.org e encontrei você na página principal. Você escreve muito sobre o assunto, você ainda tem seu próprio canal com instruções em vídeo. Diga-me como você chegou a isso, o que o fisgou no ReactPHP?

De fato, você redescobre o idioma que escreve há muitos anos

Sergey aka seregazhuk : Dois anos atrás, em um trabalho anterior, era necessário escrever um script que ligasse constantemente para os clientes e trabalhasse muito rapidamente. A tarefa teve que ser concluída ontem, apenas desenvolvedores de PHP estavam na equipe - não havia tempo para uma nova pilha, você sabe. Mas aconteceu que todos ouviram algo sobre o ReactPHP. Ele se posicionou como pronto para produção, tudo foi muito fácil: acabamos de instalar a empresa através do compositor e foi possível escrever código assíncrono. Como resultado, eles escreveram uma solução, lançaram, todos ficaram satisfeitos.

Percebi que possuímos uma ferramenta - mas quase não havia artigos, exemplos práticos como "Temos um problema, resolvemos assim" - nem em russo nem em inglês. Como resultado, escrevi alguns artigos no meu blog, obtive um feedback positivo e foi tudo - de alguma forma, isso me arrastou. Estamos acostumados com o modelo de solicitação-resposta, mas vale a pena carregá-lo em código assíncrono e você imediatamente pergunta: "Como pode ser isso?"

Peter: Vamos falar novamente, que problema o código assíncrono resolve para nós e por que o ReactPHP é especialmente necessário?

Sergey: Quase todos os aplicativos têm chamadas de API ou interação com o sistema de arquivos ou consultas ao banco de dados. Quando esperamos uma resposta deles, nosso processador fica ocioso - em vez de fazer algo útil. Você não pode esperar por uma resposta, mas inicie as operações sem bloqueio e siga em frente. Surge a pergunta: “Se tivermos o ReactPHP em todos os lugares para E / S, nossos aplicativos serão muitas vezes mais rápidos?”

Infelizmente, você não pode simplesmente pegar e reescrever nossos aplicativos em aplicativos assíncronos

Sergey: Eu pensaria em usar o ReactPHP nos casos em que o desempenho é crítico e a E / S é o nosso botlock que bloqueia tudo. Além disso, eu recomendaria não transferir todo o aplicativo para trilhos assíncronos, ou seja, reescrever esse botlock específico. Normalmente, uma fatia assíncrona é muito mais fácil de inserir em um código de bloqueio tradicional do que tentar reescrever o aplicativo inteiro.

Peter: Ok, mas por que não começamos alguns processos PHP então? Este está ocioso, mas o próximo está ocupado.

Sergey: E como coordenamos os resultados? Suponha que precisamos obter dados de três fontes, fazer chamadas para três APIs, compor os resultados e entregá-los ao usuário. Se fizermos três fluxos separados, surgirá o problema de coordenar o resultado.

Com uma abordagem assíncrona, simplesmente as executávamos, por assim dizer, em paralelo, para obter o resultado e processá-lo. Com os threads, você terá que, de alguma forma, coordenar esta bola, ou seja, haverá um problema com o estado. Isso parece ser mais complicado do que uma abordagem assíncrona.

Peter: Entendi. Eu tinha esse pensamento em minha mente: se queremos aumentar o número de usuários. processado por segundo, como a pilha inteira de aplicativos do Symfony seria lançada na versão assíncrona e processaria um número maior de conexões?

Sergey: Eu não faria isso. Muitas vezes, o aplicativo não fica completamente lento. Se surgir a questão do desempenho, provavelmente haverá alguns gargalos internos, o que provavelmente resultará em E / S lenta. E agora eu traduziria esses gargalos para o ReactPHP.

Pareceria um pequeno programa assíncrono dentro do código de bloqueio usual: por exemplo, chamamos três solicitações em paralelo, processamos e enviamos uma resposta ao usuário, e o tempo total de execução seria igual ao tempo da solicitação mais lenta. Se, no caso da abordagem tradicional, esperarmos pelo primeiro pedido, o segundo e o terceiro. Mas o aplicativo não se tornou assíncrono com isso.

E se compararmos tudo com o NodeJS e outros?

Peter: E se compararmos tudo com o NodeJS, digamos, ou Go, realmente existe assincronia em todo o aplicativo. Todas as solicitações ao banco de dados, ao sistema de arquivos - todas elas são assíncronas por dentro. Isso significa, em princípio, se tudo está escrito de forma assíncrona, há algum lucro?

Sergey: Será rentável se o problema inicial for E / S. Então sim, vamos resolver isso. Nosso código será o mais eficiente possível, capaz de processar o número máximo de tarefas em vez de ficar ocioso e aguardar o processamento dessa saída. Mas se, inicialmente, o problema não está em E / S, então, escrevendo tudo de forma assíncrona, é improvável que você ganhe alguma coisa, e podemos obter um código complexo que será difícil de ler e manter.

Peter: De volta ao PHP. Então, nós temos o ReactPHP, e dos famosos análogos Swoole, Amp e Ext-async. E diga-me, em comparação, qual é a diferença entre esses projetos e qual é a qualidade do ReactPHP, é rápido e apresenta algumas desvantagens em comparação com o mesmo Swoole?

Sergey: Dos três, para ser sincero, só testei o Amp, e porque, como o ReactPHP, é suportado imediatamente. Ou seja, colocamos os componentes necessários no compositor e pronto. E aqui eu realmente não gosto de histórias com extensões. Como se ficamos sozinhos com PHP e assincronia, parece-me que é mais razoável usar a linguagem e coisas nativas - e se usarmos extensões adicionais, aqui não é particularmente PHP assíncrono, mas extensões assíncronas para PHP.

Como o ReactPHP realmente está pronto para produção?

Peter: “Suporte de longo prazo” está escrito no site deles. Ou seja, algum tipo de suporte de longo prazo, sem alterações críticas na API. É isso mesmo? Tudo está alto o suficiente?

Sergey: Sim. O projeto ReactPHP em si já é bastante antigo. Ele trabalha desde o décimo segundo ano, ele tem 7 anos. Ele já tem tempo suficiente para produção. E sim, além disso, aqui vem o suporte de longo prazo para os principais componentes por 2 anos. Ou seja, você pode estar vinculado com segurança a esses componentes, receber correções, atualizações e não se preocupar com compatibilidade com versões anteriores. Por dois anos eles se comprometem a manter suas versões, nada vai quebrar. Acho que isso é realmente muito legal, é um grande passo à frente. Tanto quanto me lembro, até recentemente, o Amp discutiu alguns de seus componentes, eles não decidiram completamente sobre a interface e sua API pública.

Peter: Onde você recomenda começar a aprender o ReactPHP? Além da documentação oficial e dos seus tutoriais em vídeo, é claro. Onde estão todas as comunidades, existem conversas por telegrama ou conversas por discórdia, fóruns?

Sergey: Infelizmente, não conheço uma comunidade tão direta. Existe uma conta no Twitter bastante ativa: você pode fazer, fazer perguntas e se interessar. E os mineiros respondem rapidamente - você pode escrever pessoalmente no Twitter. Fiz isso, pedindo algumas coisas.



Peter: Bem, obrigado por uma história tão detalhada sobre o ReactPHP - e, nesse sentido, vou anunciar o Panda Meetup , que será realizado em 22 de agosto em Moscou, no escritório de Skyeng. Você vai se apresentar lá, certo?

Sergey: Sim, está certo. Venha conversar.

Peter: Também haverá um relatório sobre o Domain Driven Design, que também é um tópico interessante no contexto do PHP [e mais alguns foram adicionados] e, como os organizadores me disseram, haverá um pós-festa.

Presentes:

• Versão completa de áudio e podcast do YouTube
• Link para transmitir mitap para quem não pode vir
• Detalhes sobre o pós-festa no telegrama BeerPHP Moscow