Get best of the week

Ferro ou otimização? Badoo, Avito e Mamba - sobre desempenho em PHP

O problema de desempenho do PHP no Badoo é um dos mais importantes. A qualidade do back-end do PHP depende diretamente da quantidade de recursos que gastamos no desenvolvimento e operação, na velocidade do serviço e na impressão que ele causa nos usuários.

Portanto, o tópico da terceira reunião da comunidade de desenvolvedores de PHP em nosso escritório, fizemos o desempenho de back-end e convidamos colegas de Avito e Mamba para discutir.



Leia a transcrição da cena da discussão, na qual tive a sorte de ser um moderador: como a infraestrutura das três empresas é organizada, como medimos a produtividade e em que métricas nos concentramos, quais ferramentas usamos, como fazemos uma escolha entre hardware e otimização.

E em 15 de fevereiro, participe do próximo Meetup do Badoo PHP : discuta o Legacy.



Deciframos apenas a parte da discussão que nos pareceu mais interessante. A versão completa está disponível em vídeo.

Especialistas:

  • Semyon Kataev, Chefe da Unidade de Desenvolvimento da Core Services Avito
  • Pavel Murzakov pmurzakov, PHP Timlid no Badoo
  • Mikhail Buylov mipxtx, Diretor de TI da Mamba


Conte uma história sobre otimização a partir de sua prática: grande sucesso ou grande fracasso é algo interessante de se compartilhar.

Mikhail Mamba Buylov


Eu tenho uma parábola

Uma vez a cada seis meses, analisamos as métricas e procuramos o que diminui, não funciona bem, o que precisa ser otimizado. Uma vez notamos nosso contêiner de dependência do symfony, que cresceu para 52.000 linhas. Decidimos que ele, o canalha, era o culpado por tudo: 20 ms de sobrecarga para cada solicitação. Nós serramos. Nós reduzimos isso. De alguma forma, tentamos separá-lo, mas nada ajudou.

E então descobrimos que temos anti-spam que precisa acessar 20 bancos de dados para atender a todas as solicitações necessárias.

As soluções que vêm em primeiro lugar nem sempre são as corretas. Observe melhor os rastreamentos, logs e referências de suas solicitações e não quebre diretamente. Aqui está uma história.

Pavel Murzakov, Badoo


Como temos um ecossistema bastante grande em PHP, fazemos otimizações periodicamente. Estamos crescendo, estamos atingindo algum nível na CPU, entendemos que precisamos comprar hardware ou otimizar. Pese os argumentos a favor e contra cada opção e decida. Na maioria das vezes - a favor da otimização, porque o ferro precisa muito.

Em um desses pontos, identificamos um grupo inteiro que estava envolvido na busca de várias coisas não ideais nos scripts PHP e na otimização. Isso aconteceu literalmente “gota a gota”: aqui eles encontraram uma porcentagem, lá encontraram uma porcentagem - várias pessoas encontraram uma porcentagem dentro de um mês. Em algum momento, nosso sishnik estava próximoeinstein_man. Ele decidiu ver o que poderia fazer: saiu à noite, lançou o Perf, encontrou alguns problemas nas extensões PHP - e acelerou tudo em algumas noites em 13%!

Semyon Kataev, Avito


Eu tenho duas histórias. Um sobre o arquivo, o outro sobre o super desenvolvedor.

Sobre a falha. Temos muitos microsserviços, incluindo PHP. Todo mundo trabalha na Kubernetes. Eu trabalhei em um desses microsserviços. Houve uma utilização significativa da CPU: eles passaram uma semana otimizando e encontrando problemas. Aconteceu que um dos desenvolvedores adicionou o Xdebug às imagens base para calcular os testes de cobertura de código em seu (outro) serviço, após o qual todos os microsserviços em produção trabalhados com o Xdebug foram ativados por um quarto inteiro! Depois de um quarto, descobrimos isso, corrigimos imagens básicas - e começamos a receber presentes inesperados: relançei meu serviço e ele começou a funcionar mais rápido. Em cada implantação, nossa imagem de serviço é reconstruída e agora sem o Xdebug.

História de sucesso. Temos muitos microsserviços, e eles se tornaram cada vez mais. Nessa situação, o número de chamadas RPC se torna um problema. Por exemplo, em um cartão de anúncio - e esta é uma das páginas mais frequentes no Avito - cerca de 30 microsserviços estão envolvidos na renderização de uma página. Além disso, tudo isso não foi feito de maneira muito explícita: parece que você está chamando algum tipo de abstração e, sob ela, cinco chamadas RPC para outros serviços são executadas seqüencialmente.

Ao longo dos anos, o cartão do anúncio foi bastante degradado. Um desenvolvedor forte lutou por um quarto, otimizou e trouxe todas as chamadas de RPC. Quando ele conseguiu fazer isso, ele os paralelizou por meio da solicitação múltipla do Guzzle - e, em vez de 30 solicitações síncronas consecutivas, ele recebeu as mesmas 30 solicitações, mas paralelas, o que acelerou bastante o trabalho. Após essa refatoração, o tempo de resposta do cartão é igual ao tempo máximo de resposta de qualquer um dos serviços. Mas ele precisava de um quarto inteiro para otimizar / reescrever o código de exibição do cartão de anúncio.

Diga-nos, qual é o tamanho do seu cluster PHP, como ele está configurado - pelo menos PHP-FPM, ou talvez em algum lugar que o Apache tenha problemas?

Mikhail Mamba Buylov


Temos cerca de 15.000 RPS. Um cluster de 80 servidores FPM adquiridos há vários anos. Em cada cluster, o FPM (máximo de 50 filhos) é lançado na estática. Carregou cerca de dez no pico no horário nobre. O tempo médio de resposta é de 100 ms e tentamos mantê-lo (quando excede 100 ms, iniciamos a busca por peças de freio).

Nós temos nosso próprio sistema de monitoramento de desempenho. Distribuímos muitos contadores no código, cerca de 120 por solicitação. Monitoramos muitos eventos que ocorrem dentro do código em PHP.

Pavel Murzakov, Badoo


Tudo é padrão conosco: nginx, PHP-FPM. Aproximadamente 600 servidores com FPM. Se quisermos falar sobre PHP, provavelmente existem mais 300 servidores para vários propósitos, como script, back-office e outros.

Dos recursos de configuração, existem dois. Em primeiro lugar, temos um proxy BMA - este é um proxy para dispositivos móveis. Ou seja, antes que uma solicitação chegue ao nginx, ele chega a um proxy especial que mantém uma conexão persistente e envia solicitações ao nginx. O segundo recurso - às vezes você precisa desativar o opcache da CLI (nós o ativamos em máquinas de script). Uma vez que não o desligamos, perdemos 30% da CPU nisso. Depois que perceberam o erro, ficaram surpresos com o quanto você pode economizar com uma configuração.

Temos patches PHP, mas eles quase não estão relacionados ao desempenho.

Há um ponto no bloqueio competitivo do APCu - quando você precisa escrever muito na mesma chave. A arquitetura interna do APCu é construída de tal maneira que existe um bloqueio de chave global e, durante a gravação intensiva, os freios são iniciados. Portanto, temos uma extensão personalizada lá que resolve esse problema. Isso se refere apenas parcialmente ao desempenho, pois afeta o tempo de resposta, mas não o consumo da CPU.

Semyon Kataev, Avito


Temos cerca de 2 milhões de solicitações por minuto (~ 33 kRPS). Um aplicativo monolítico escrito em PHP é escrito há mais de 11 anos. Está em uma fase de rápido crescimento. Quando a empresa começou, havia 65 LXCs em 65 servidores físicos. Em cada contêiner com o aplicativo, o PHP-FPM, nginx e o software auxiliar para métricas e log estão em execução. Nada especial.

Ao longo dos anos, nunca adicionamos ferro para um monólito. Estamos aumentando a participação, o número de anúncios, o número de transações de usuários e estamos constantemente otimizando, melhorando o código, otimizando o software. O consumo de CPU e memória vem caindo nos últimos anos: 65 contêineres para um monólito agora são suficientes para nós.

Como você mede o desempenho? Qual ferramenta você mede o tempo de resposta do cliente?

Mikhail Mamba Buylov


Temos um sistema de coleta de logs. Ele registra dois indicadores - o tempo desde o início do FPM até a função de desligamento e até o final do script. A segunda métrica é necessária para ver o que acontece após a função de desligamento.

Nós medimos JS. Na verdade, essa é uma métrica mais ou menos: os canais de rede são frequentemente violados. Como resultado, carregar em algum lugar no interior da Rússia começa a ficar embotado. Portanto, ficamos assim: "Oh, pulou - isso significa que em algum lugar algo caiu". Além disso, a publicidade de terceiros distorce muito a métrica. E, mais importante, os spammers vêm, e isso geralmente é algum tipo de aleatoriedade.

Semyon Kataev, Avito


A propósito, costumávamos usar o Pinba do Badoo muito ativamente . Eu gosto dela agora. A maioria das métricas foram coletadas por ele, mas depois mudadas para o protocolo StatsD. Agora estamos fazendo medições de diferentes pontos: de frente, dos servidores em frente ao aplicativo, do nginx e do próprio aplicativo PHP. Temos uma equipe de desempenho dedicada. Ela começou com o desempenho da frente, mas depois mudou para o apoio. De frente, ele coleta não apenas JS, CSS e outras estáticas, mas também o tempo de resposta do servidor. Antes de tudo, nos concentramos no tempo de resposta do aplicativo.

Pavel Murzakov, Badoo


Tudo é semelhante ao que os caras nos disseram. Usando o Pinba clássico para PHP, medimos o tempo de execução de um script PHP em termos de PHP. Mas também temos, por exemplo, Pinba para o nginx, que mede o tempo de resposta do ponto de vista do nginx. Também coletamos métricas no cliente.

O que estamos olhando? Por um lado, o tempo de resposta. Não está relacionado ao planejamento de recursos. Se é ruim, precisa ser aprimorado, porque é, de fato, a qualidade do serviço. Outra coisa é que você precisa planejar o ferro de alguma forma. Nossas ITOps e equipes de monitoramento monitoram todo o hardware. Existem algumas barras na rede, no disco. Existem alguns valores após os quais o alerta ocorre - e estamos fazendo algo. Como a prática demonstrou, geralmente otimizamos a CPU: nos deparamos com ela.

Semyon Kataev, Avito


Em nós, o aplicativo PHP mede a si próprio e em register_shutdown_function () lança métricas. Cada LXC possui um servidor StatsD, que coleta essas métricas e as envia pelos coletores para o cluster Graphite (incluindo ClickHouse), onde os dados são armazenados. Este é um autodiagnóstico.

Também em cada contêiner está o nginx, ou seja, nginx + PHP-FPM. Com o nginx, coletamos métricas externas relacionadas ao tempo de execução de um aplicativo PHP. Eles também estão enfrentando servidores separados (os chamamos de avi-http) nginx, que executa roteamento básico, que também coleta métricas de nível superior, como tempo de resposta, número de 500 códigos de resposta e outros.

Quais ferramentas você possui para uma faixa de desempenho? O que você usa com mais frequência?

Mikhail Mamba Buylov


Nós escrevemos nossa própria ferramenta. Quando o Pinba acabou de ser lançado - em 2012, há muito tempo -, era um módulo para o MySQL que recebia algo assim pelo UDP. Foi difícil tirar os gráficos; não foi muito otimizado para o desempenho. E não criamos nada melhor do que escrever uma coisa chamada Better Than Pinba. É apenas um servidor de contador que os aceita de um cliente PHP.

Espalhamos muitos cronômetros no código: toda vez que queremos medir algo, definimos o início e a parada do cronômetro no código. O próprio módulo calculará o tempo de execução do contador, agregará os contadores acumulados em um pacote e os enviará para o daemon. A própria interface extrairá tudo o que você precisa e criará gráficos conectados no contador desejado.

Um dos problemas de Pinba era a falta de sua própria interface - era necessário transferir dados para o RRD (então havia tanta escuridão). Portanto, nós escrevemos nossa própria interface. Toda vez que vemos o que pulou, podemos instalar o script. No script, todos os contadores agregados são enviados para nós, que são enviados para nós. Podemos ver onde o contador aumentou, o tempo de resposta no contador aumentou ou o número de contadores aumentou.

Pode ser visto quando o desempenho cai. Estamos começando a cavar dessa maneira. Antes do PHP 7, usamos o XHProf, então ele parou de construir conosco. Portanto, mudamos para o Xdebug. Xdebug nós cutucamos apenas quando o problema é visível.

Pavel Murzakov, Badoo


É uma crença comum de que o XHProf não será construído no PHP 7. Isso é verdade, mas apenas em parte. Se você usar o XHProf no assistente, ele realmente não será. Mas se no GitHub você alternar para um ramo chamado Experimental (ou algo parecido), tudo funcionará bem para o PHP 7, pronto para produção. Verificado.

Mikhail Mamba Buylov


Não, eu troquei. Não funcionou para mim.

Pavel Murzakov, Badoo


Quero adicionar sobre Pinba. Você se tornou profeta até certo ponto. Também, em algum momento, perdemos a produtividade. Criamos o Pinba2 , que é muito rápido. Pode ser usado como um substituto para o Pinba.

Semyon Kataev, Avito


Tudo é modesto conosco. Acabamos de levar a direção do desempenho para o trabalho: coletamos métricas, como tempo de resposta. Nós usamos StatsD. Ainda não usamos perfis regularmente, mas tenho certeza de que algumas equipes os usam em seus microsserviços escritos em PHP. Na minha opinião, até alguém retransmite a New Relic. Mas, no contexto da principal aplicação monolítica, até agora estamos apenas abordando isso.

Pavel Murzakov, Badoo


A história do ferro é monitorada em Grafana, Zabbix. Quanto à parte do PHP, temos Pinba, temos um monte de temporizadores; Construímos gráficos convenientes sobre eles. Usamos o XHProf, na produção, dirigimos para uma parte das solicitações. Sempre temos novos perfis XHProf disponíveis. Temos liveprof: esta é a nossa ferramenta, você pode ler sobre isso, inclusive no meu artigo . Tudo acontece automaticamente, você só precisa assistir. Nós usamos o phpspy. Nem sempre começa conosco: quando alguém quer ver alguma coisa, entra no carro, tira o perfil. Em princípio, como é o caso do Perf.

Semyon Kataev, Avito


XHProf tem a mesma história. Nós o usamos uma vez há muito tempo: era uma iniciativa pessoal de alguns desenvolvedores e, de fato, não decolou. Ele parou de colecionar. Coletamos várias métricas de chamadas de roteadores, controladores e vários modelos. Cerca de 60 a 70% da rede interna do datacenter é ocupada por pacotes UDP com métricas. No momento, isso é suficiente para nós. Agora vamos procurar novos locais para otimização.

Desde que chegamos ao ponto do ferro: alguém está envolvido sistematicamente no planejamento da capacidade da sua empresa? Como esse processo é construído?

Semyon Kataev, Avito


Um aplicativo monolítico executa pelo menos 65 LXC por pelo menos cinco anos. Otimizamos o código, melhoramos: ele possui recursos suficientes. Nosso planejamento de capacidade principal vai para o Kubernetes, onde cerca de 400 microsserviços vivos são escritos em PHP / Go. Estamos lentamente cortando pedaços do monólito, mas ele ainda está crescendo. Não podemos detê-lo.

Em geral, o PHP é uma linguagem interessante. Ele implementa rapidamente a lógica de negócios.

Pavel Murzakov, Badoo


Primeiro, as ITOps e as equipes de monitoramento garantem a disponibilidade de recursos suficientes. Se começarmos a nos aproximar do valor limite, os colegas perceberão isso. Eles provavelmente são os principais responsáveis ​​pelo planejamento da capacidade global. A parte do PHP tem o principal recurso da CPU, por isso nós o seguimos.

Nós estabelecemos o padrão: não devemos "comer" mais de 60% do cluster. 60%, e não 95%, porque temos hypertreading, que extrai mais do processador do que você pode extrair sem ele. Por isso, pagamos pelo fato de que, após 50% de nosso consumo de CPU, podemos crescer de uma maneira imprevisível, porque os kernels com hiper-leitura não são totalmente honestos.

Mikhail Mamba Buylov


Fazemos uma implantação e vemos que algo falhou conosco - esse planejamento de capacidade. A olho! Temos uma certa margem de produtividade que nos permite fazer isso. Tentamos cumpri-lo.

Além disso, postamos otimização factum. Quando vemos que algo caiu, revertemos se tudo estiver completamente ruim. Mas isso praticamente não acontece.

Ou apenas vemos que "aqui não é o ideal, agora vamos corrigir rapidamente tudo e tudo funcionará como deveria".

Não nos preocupamos particularmente: é muito difícil e o escapamento não será muito grande.

Você está falando sobre microsserviços. Como eles interagem? É REST ou você está usando protocolos binários?

Semyon Kataev, Avito


Kafka é usado para enviar eventos entre serviços, JSON-RPC é usado para garantir a interação entre serviços, mas não completa, mas sua versão simplificada, da qual não podemos nos livrar. Existem implementações mais rápidas: o mesmo protobuf, gRPC. Isso está nos nossos planos, mas certamente não é uma prioridade. Com mais de 400 microsserviços, é difícil transportar todos eles para o novo protocolo. Existem muitos outros lugares para otimizar. Definitivamente, não estamos preparados para isso agora.

Pavel Murzakov, Badoo


Nós, como tal, não temos microsserviços. Existem serviços, também existe o Kafka, seu próprio protocolo em cima do protobuf do Google. Provavelmente, usaríamos o gRPC, porque é legal, tem suporte para todos os idiomas, a capacidade de vincular facilmente peças diferentes. Mas quando precisávamos, o gRPC ainda não estava lá. Mas havia um protobuf e nós o pegamos. Além disso, coisas diferentes foram adicionadas para que não fosse apenas serialização, mas um protocolo completo.

Mikhail Mamba Buylov


Também não temos microsserviços. Existem serviços escritos principalmente em C. Usamos JSON-RPC porque é conveniente. Você acabou de abrir o soquete ao depurar seu código e rapidamente escreveu o que queria. Algo voltou para você. Protobuf é mais difícil porque você precisa usar algumas ferramentas adicionais. Há uma pequena sobrecarga, mas acreditamos que você precisa pagar por conveniência, e esse não é um preço alto.

Você tem bancos de dados enormes. Quando você precisa mudar o circuito em um deles, como você faz isso? Algum tipo de migração? Se essas migrações demorarem vários dias, como isso afeta o desempenho?

Mikhail Mamba Buylov


Temos mesas grandes, monolíticas. Há um fragmento. O fragmento altera-se rapidamente, porque existem muitos alteradores paralelos ao mesmo tempo. Uma mesa grande com perfis alterou cerca de três horas. Usamos ferramentas Perkonovskie que não possuem leitura e gravação. Além disso, implementamos a alteração para que o código suporte os dois estados. Após a alteração, também implantamos: a implantação é mais rápida do que a aplicação de qualquer esquema.

Pavel Murzakov, Badoo


Temos o maior armazenamento (chamamos de "pontos") - este é um enorme banco de dados fragmentado. Se pegarmos a tabela "Usuário", ela terá muitos fragmentos. Não vou dizer exatamente quantas tabelas estarão em um servidor: a idéia é que existem muitas pequenas. Quando mudamos o circuito, de fato, fazemos apenas uma alteração. Em todas as mesas pequenas, isso acontece rapidamente. Existem outros repositórios - já existem outras abordagens. Se houver uma base enorme, existem ferramentas Perconian.

Em geral, usamos coisas diferentes de acordo com as necessidades. A mudança mais frequente é uma mudança nessa enorme base de pontos fragmentados, na qual já construímos um processo. Tudo funciona de maneira muito simples.

Semyon Kataev, Avito


O mesmo aplicativo monolítico que atende à maior parte do tráfego é implantado cinco a seis vezes por dia. Quase a cada duas horas.

Em termos de trabalho com o banco de dados, esse é um problema separado. Existem migrações, elas rolam automaticamente. Esta é uma revisão do DBA. Há uma opção para pular a migração e rolar manualmente. A migração passará automaticamente para a preparação ao testar o código. Mas na produção, se houver algum tipo de migração duvidosa que utilize muitos recursos, o DBA iniciará manualmente.

O código deve ser tal que funcione com as estruturas de banco de dados antigas e novas. Muitas vezes fazemos várias viagens para implantar recursos. Para duas ou três implementações, é possível obter o estado desejado. Da mesma forma, existem enormes bancos de dados, bancos de dados fragmentados. Se contarmos para todos os microsserviços, definitivamente existem 100 a 150 implantações por dia.

Gostaria de saber qual é o tempo de resposta padrão de back-end que você está seguindo? Quando você entende o que precisa otimizar ainda mais ou qual é a hora de terminar? Existe um valor de "média hospitalar"?

Pavel Murzakov, Badoo


Não. Depende do ponto final. Nós olhamos para tudo separadamente. Tentando entender como isso é crítico. Alguns pontos de extremidade geralmente são solicitados em segundo plano. Isso não afeta o usuário de forma alguma, mesmo que o tempo de resposta seja de 20 s. Isso vai acontecer em segundo plano, não há diferença. O principal é que algumas coisas importantes sejam feitas rapidamente. Talvez 200 ms ainda estejam ok, mas um pequeno aumento já é importante.

Mikhail Mamba Buylov


Estamos mudando da renderização HTML para solicitações de API. Aqui, de fato, a API responde muito mais rápido que a resposta HTML grande e pesada. Portanto, é difícil distinguir, por exemplo, um valor de 100 ms. Focamos em 200 ms. Então aconteceu o PHP 7 - e começamos a focar em 100 ms. Essa é a "média do hospital". Essa é uma métrica muito vaga, o que sugere que é hora de pelo menos olhar para lá. Por isso, focamos na implantação e aumentamos o tempo de resposta após ela.

Semyon Kataev, Avito


Fizemos um esboço de uma das equipes de desempenho. Os colegas mediram quanto mais uma empresa ganha, acelerando o carregamento de páginas em vários cenários. Calculamos quanto mais compradores, transações, chamadas, transições etc. estão acontecendo. De acordo com esses dados, pode-se entender que, em algum momento, a aceleração deixa de fazer sentido. Por exemplo, se o tempo de resposta de uma das páginas de 90 ms for acelerado para 70 ms, isso dará + 2% dos compradores. E se você acelerar de 70 ms para 60 ms, já haverá mais 0,1% de compradores, o que geralmente está incluído no erro. Assim como os caras, tudo depende muito da página com a qual estamos trabalhando. Em geral, Avito percentil 75 - cerca de 75 ms. Na minha opinião, isso é lento. Agora estamos procurando lugares para otimizar. Antes da transição para os microsserviços, tudo acontecia muito mais rápido para nós, e estamos tentando otimizar o desempenho.



E a eterna pergunta: ferro ou otimização? Como entender se vale a pena comprar hardware ou é melhor investir em otimização? Onde fica a fronteira?

Semyon Kataev, Avito


Minha opinião: um verdadeiro programador é otimização. Parece-me que em grandes empresas como o Badoo, a minha, a Yandex, existem muitos desenvolvedores de diferentes níveis. Existem desenvolvedores juniores / estagiários e desenvolvedores líderes. Parece-me que o número de locais para otimização / revisão é sempre adicionado lá. O ferro é o último passo. Para um monólito em 65 LXC, não adicionamos ferro por muito tempo. Utilização da CPU - 20%. Já estamos pensando em transferi-los para o cluster Kubernetes.

Pavel Murzakov, Badoo


Eu realmente gosto da posição de Semyon. Mas tenho um ponto de vista completamente oposto. Primeiro de tudo, eu olhava para o ferro. É possível deixar cair o ferro e será mais barato? Nesse caso, é mais fácil resolver o problema com ferro. O desenvolvedor pode fazer outra coisa útil neste momento. O tempo do desenvolvedor custa dinheiro. Ferro também custa dinheiro, então você precisa comparar.

Qual destes é mais importante não está claro. Se os dois custam o mesmo, o hardware vence, porque o desenvolvedor poderá fazer algo no momento. Especificamente, em termos de back-end do PHP, não podemos fazer isso. A otimização nos custa muito mais barato do que comprar ferro.

Prestes a parar. Em termos de planejamento, temos algum tipo de bar. Se reduzirmos o consumo da CPU abaixo dela, paramos. Por outro lado, há também a qualidade do serviço. Se percebermos que o tempo de resposta não nos convém em algum lugar, precisamos otimizar.

Mikhail Mamba Buylov


Parece-me que tudo depende do tamanho da equipe e do projeto. Quanto menor o projeto, mais fácil é comprar o hardware, porque o salário do desenvolvedor é constante e o código que funciona, os usuários que trabalham com ele, são muito diferentes. Se houver poucos usuários, será mais fácil comprar hardware e confiar ao desenvolvedor trabalho para desenvolver o projeto. Se houver muitos usuários, um desenvolvedor poderá compensar a maior parte do custo dos servidores.

Semyon Kataev, Avito


Tudo realmente depende da escala. Se você possui mil servidores e a otimização leva ao fato de não precisar de outros mil servidores, é claramente melhor otimizar. Se você tiver um servidor, poderá comprar com segurança mais dois ou três servidores e pontuar na otimização. Se o comando for pequeno, inicie os servidores adquiridos. Se a equipe for grande e você tiver dois ou três datacenters, a compra de seis datacenters já não é tão barata, nem tão rápida.

Como temos um mitap do PHP, esta frase deve soar: por que precisamos do PHP, pois temos esses problemas o tempo todo? Vamos reescrever Go, C, C #, Rust, Node.js!
Você acha que a abordagem de reescrita é geralmente justificada? Existem problemas cuja solução vale a pena fazer e investir neste momento?

Semyon Kataev, Avito


Em geral, o PHP é uma linguagem muito boa. Realmente permite que você resolva problemas de negócios. Ele é rápido o suficiente. Todos os problemas de desempenho são problemas de erros, bugs, código legado (algum tipo de código insuficiente, coisas abaixo do ideal que seriam disparadas em outro idioma da mesma maneira). Ao transportá-los brutos para Golang, Java, Python, você obtém o mesmo desempenho. O problema é que há muito legado.

A introdução de um novo idioma, na minha opinião, faz sentido para expandir a pilha e as oportunidades de emprego. Agora é difícil o suficiente encontrar bons desenvolvedores de PHP. Se introduzirmos Golang no techradar, podemos contratar esquilos. Existem poucos shniks PHP e poucos esquilos no mercado, e juntos já existem muitos deles. Por exemplo, tivemos um experimento. Adotamos desenvolvedores de C # que estão prontos para aprender novos idiomas - simplesmente expandimos a pilha de contratação. Se dissermos às pessoas que vamos ensiná-las a escrever em PHP, elas dizem que é melhor não. E se lhes oferecermos que aprendam a escrever em PHP, Go e ainda prometam a oportunidade de escrever em Python, as pessoas estarão mais dispostas a responder. Para mim, esta é uma extensão das oportunidades de emprego. Em outras linguagens, existem algumas coisas que realmente faltam no PHP. Mas, em geral, o PHP é super suficiente para resolver problemas de negócios e implementar grandes projetos.

Pavel Murzakov, Badoo


Eu provavelmente concordo completamente com Semyon. Reescrever simplesmente não faz sentido. PHP é uma linguagem bastante produtiva. Se você compará-lo com outras linguagens não-compiladas com script, provavelmente será quase o mais rápido. Reescrever em alguns idiomas como Go e outros? Estes são outros idiomas, eles têm outros problemas. Ainda é mais difícil escrever sobre eles: não tão rápido e há muitas nuances.

No entanto, existem coisas difíceis ou inconvenientes de se escrever em PHP. Algumas coisas com vários processos e com vários threads são melhores para escrever em outro idioma. Um exemplo de tarefa em que o não uso do PHP é justificado é, em princípio, qualquer armazenamento. Se este é um serviço que armazena muita memória, provavelmente o PHP não é a melhor linguagem, porque possui uma sobrecarga de memória muito grande devido à digitação dinâmica. Acontece que você salva um int de 4 bytes e 50 bytes são consumidos. Claro, eu exagerei, mas ainda assim essa sobrecarga é muito grande. Se você tiver algum tipo de armazenamento, é melhor escrevê-lo em outro idioma compilado com digitação estática. Assim como algumas coisas que exigem execução multiencadeada.

Mikhail Mamba Buylov


Por que o PHP não é considerado muito rápido? Porque é dinâmico. Ir tradução é uma solução para o problema de traduzir código de digitação dinâmica para estática. Devido a isso, tudo está acontecendo mais rápido. Especificamente para o Go, no meu plano há tarefas de um fluxo de dados específico. Por exemplo, se houver algum tipo de fluxo de dados que precise ser convertido em formatos mais convenientes, isso é ideal. Gerado por um daemon, ele recebe um fluxo de dados na entrada e emite outro. Pouca memória come. O PHP consome muita memória neste caso: você precisa garantir cuidadosamente que ele esteja limpo.

Transfer to Go é uma transferência para microsserviços, porque você não cortou todo o código. Você não aceita e reescreve na íntegra. A tradução para microsserviços é uma tarefa mais profunda que a tradução de um idioma para outro. É necessário resolvê-lo primeiro e depois pensar em qual idioma escrever. A parte mais difícil é aprender a microsserviços.

Semyon Kataev, Avito


Não é necessário usar o Go em microsserviços. Muitos serviços são escritos em PHP e têm um tempo de resposta aceitável. A equipe que os apoia decidiu por eles mesmos que eles precisavam escrever lógica de negócios muito rapidamente e introduzir recursos. Na verdade, às vezes eles são mais rápidos que os esquilos.

Temos a tendência de contratar Gopher, traduzir para Go. Mas ainda temos a maior parte do código escrito em PHP, e assim será por pelo menos mais alguns anos. Não existe uma corrida real, não decidimos que o Go é melhor ou pior. Seis lançamentos são lançados no monólito diariamente. Nosso bate-papo "Avito Deploy" possui uma lista de tarefas implantadas. Pelo menos 20 tarefas são lançadas por dia em cada release: pelo menos cinco ou seis releases por dia, aproximadamente 80 tarefas que as pessoas executaram nessas tarefas. Tudo isso é feito em PHP.

? -, ?

,


É muito difícil. Há um momento psicológico: lancei um novo recurso - você está pronto. Lançou um novo recurso gigantesco - você é super jovem! Quando um gerente ou desenvolvedor diz que removeu um recurso (desativado), ele não recebe esse reconhecimento. Seu trabalho não é visível. Por exemplo, uma equipe pode receber um bônus pela implementação bem-sucedida de novos recursos, mas eu não vi nenhum prêmio pela funcionalidade morta ou experimental. E o resultado disso pode ser realmente colossal.

Um monte de recursos herdados que ninguém já está usando realmente diminui o desenvolvimento. Existem centenas de casos em que uma nova pessoa entra em uma empresa e refatora um código morto que nunca é chamado porque ele não sabe que é um código morto.

Estamos tentando, de alguma forma, negociar com os gerentes, descobrir pela golog que tipo de recurso era, com os analistas consideramos quanto dinheiro ele traz, quem precisa dele e somente depois disso tentamos cortá-lo. Este é um processo complicado.

Mikhail Mamba Buylov


Cortamos o código morto quando chegamos a ele. E está longe de ser sempre possível cortá-lo rapidamente. Primeiro, você escreve um código, depois outro, em cima de um terceiro e, por baixo, tudo indica que esse recurso não é necessário. Ela puxa um grande número de dependências, que também precisam ser corrigidas. Isso nem sempre é possível, e os gerentes precisam denunciá-lo.

O gerente define a tarefa, você a avalia. Você diz: "Sabe, cara, vou fazer isso por seis meses. Você está pronto para tolerar meio ano? Ele diz: "Não, vamos pensar o que precisa ser cortado, o que pode ser deixado. O que é fundamentalmente necessário e o que é necessário para brincar. ” É assim que é.

Pavel Murzakov, Badoo


Quando um desenvolvedor recebe um recurso, ele avalia como é difícil em termos de desenvolvimento, como é difícil em termos de desempenho. Se ele vê que um ou outro, ele esclarece com o gerente de produto se isso é realmente necessário, se podemos remover algo em algum lugar. Às vezes acontece que as mudanças não são críticas, e os gerentes fazem concessões rapidamente quando descobrem que isso é complicado ou está consumindo recursos. Apenas acontece: você diz "Vamos removê-lo" - e é isso.

Acontece que um recurso sai e, depois disso, percebemos que ele não funcionará tão bem quanto gostaríamos. E então, novamente, você pode conversar com o gerente. Muitas vezes, tudo termina com sucesso.

Não há processo interno para remover recursos. Isso é feito esporadicamente. Vemos que há algum recurso, que surgimos e nos oferecemos para desativá-lo. Nós desligamos, observamos o que dá e cortamos. Outra coisa é código morto. Temos uma extensão especial, mesmo uma infraestrutura inteira, para detecção de código morto. Vemos esse código morto. Estamos tentando cortá-lo lentamente. Outra pergunta é se ele está realmente morto e a solicitação nunca entra, então não afeta o desempenho de nenhuma maneira. Isso afeta a capacidade de suporte. As pessoas leem constantemente, embora possam não lê-lo. Não há uma conexão específica com o desempenho.

15 Badoo PHP Meetup. , : SuperJob, ManyChat, , Badoo FunCorp .

, , YouTube-. , - .

, .

Source: https://habr.com/ru/post/undefined/

More articles:


All Articles