Melhor Performance com PHP-FPM

O PHP-FPM (ou Fast Process Manager) oferece várias vantagens sobre o mod_php, por ser mais flexível e por ser uma implementação alternativa de PHP FastCGI amplamente usada e de alto desempenho. No entanto, se você estiver usando as configurações padrão do gerenciador de pacotes, provavelmente não aproveitará ao máximo.

Apresentaremos aqui uma breve visão geral sobre como melhorar o desempenho do PHP-FPM, discutindo os três tipos de gerenciadores de processos do PHP-FPM e qual é o melhor para usar em qual circunstância.
O PHP-FPM pode usar um dos três tipos de gerenciamento de processos :

  • estático
  • dinâmico
  • sob demanda

Vamos ver o que cada um é em um pouco de detalhe.

Estático ( static )

Estático garante que um número fixo de processos filho esteja sempre disponível para lidar com as solicitações do usuário. Isso é definido com pm.max_children. Nesse modo, as solicitações não precisam esperar pela inicialização de novos processos, o que a torna a abordagem mais rápida.

Supondo que você queira usar a configuração estática com 10 processos filhos sempre disponíveis, você a configuraria /etc/php/8.1/fpm/pool.d/www.conf (assumindo que você está usando o arquivo de configuração padrão do PHP-FPM do Debian/Ubuntu) da seguinte forma:

pm = static
pm.max_children = 10

Para ver se a mudança de configuração foi efetivada, após reiniciar o PHP-FPM, execute pstree -c -H <PHP-FPM process id> -S <PHP-FPM process id>. Isso mostrará que existem dez processos disponíveis, como no exemplo abaixo.

php-fpm8.1-+-php-fpm8.1 |-php-fpm8.1 |-php-fpm8.1 |-php-fpm8.1 |-php-fpm8.1 |-php-fpm8.1 |-php-fpm8.1 |-php-fpm8.1 |-php-fpm8.1 |-php-fpm8.1

Dinâmico (Dynamic)

Nesse modo, o PHP-FPM gerencia dinamicamente o número de processos filho disponíveis e garante que pelo menos um processo filho esteja sempre disponível.

Esta configuração usa cinco opções de configuração que são:

  • pm.max_children: O número máximo de processos filho que podem ser gerados.
  • pm.start_servers: O número de processos filhos a serem iniciados quando o PHP-FPM for iniciado.
  • pm.min_spare_servers: O número mínimo de processos filho inativos que o PHP-FPM criará. Mais são criados se menos do que esse número estiver disponível.
  • pm.max_spare_servers: O número máximo de processos filho inativos que o PHP-FPM criará. Se houver mais processos filho disponíveis do que esse valor, alguns serão eliminados.
  • pm.process_idle_timeout: O tempo ocioso, em segundos, após o qual um processo filho será eliminado.

E como você calcula os valores para cada configuração? O artigo de Sebastian Buckpesch, oferece a seguinte fórmula:

Contexto

Valor

max_children

(Total RAM – Memória usada para Linux, DB, etc.) / tamanho do processo

start_servers

Número de núcleos de CPU x 4

min_spare_servers

Número de núcleos de CPU x 2

max_spare_servers

Igual a start_servers

Também precisamos definir pm.process_idle_timeout, que é o número de segundos após o qual um processo ocioso será eliminado.

Digamos que nosso servidor tenha quatro núcleos (4 vCPU) e 8 GB de RAM. Se assumirmos que o Linux e daemons relacionados estão usando cerca de 2 GB (use free -hl para obter um valor mais específico), isso nos deixa em torno de 6192 MB.

Agora, quanta memória cada processo está usando? Para calcular isso, existe um script Python chamado ps_mem.py. Crie uma arquivo com ele na sua maquina com mesmo nome e depois de executá-lo, usando sudo python ps_mem.py | grep php-fpm, você obterá uma saída semelhante à seguinte:

# 28.4 MiB + 33.8 MiB = 62.2 MiB php-fpm8.1 (11)
A primeira coluna é a memória privada. A segunda coluna é a memória compartilhada. A terceira coluna é a RAM total usada. A quarta coluna é o nome do processo.

De todo modo, você pode ver que o tamanho do processo é de 62,2 MiB. Então, alimentando todas essas informações em nossa fórmula, chegamos ao seguinte:

# Round the result up. (8192 – 2000) / 62.2
Com base nisso, chegamos aos seguintes valores de configuração:

Contexto

Valor

max_children

100

start_servers

32

min_spare_servers

16

max_spare_servers

32

Vamos deixar pm.process_idle_timeout o padrão de10s. Supondo que estejamos satisfeitos com essas configurações, configuraríamos da seguinte forma:

pm = dynamic

pm.max_children = 100

pm.start_servers = 32

pm.min_spare_servers = 16

pm.max_spare_servers = 32

pm.max_requests = 200

Você também pode usar ferramentas de monitoramento de memória regularmente para monitorar quanta memória seu aplicativo está usando. Existem várias opções disponíveis para PHP, incluindo php-memprof

Sob demanda (ondemand)

Ondemand tem processos de fork PHP-FPM quando os pedidos são recebidos. Para configurar o PHP-FPM para usá-lo, precisamos definir pm como ondemand e fornecer valores para:

  • max_children
  • process_idle_timeout
  • max_requests

max_requests define o número de solicitações que cada processo filho deve executar antes de reaparecer. A documentação sugere que essa configuração é útil para contornar vazamentos de memória.

O gerenciador de processos mais ideal para a maioria das aplicações é o esquema ondemand, em que nenhum processo filho é criado na inicialização, mas sim gerado sob demanda. Os processos filhos são bifurcados apenas quando novas solicitações se conectarão com base em pm.max_children e pm.process_idle_timeout,
que define o número de segundos após os quais um processo inativo será eliminado .

Supondo que tenha as mesmas configurações de hardware que usou para configurar o modo dynamic
acima, nós o configuraríamos da seguinte forma com base nos cálculos:

pm = ondemand

pm.max_children = 100

pm.process_idle_timeout = 10s

pm.max_requests = 200

Qual configuração é ideal para você?

A resposta é: “depende”, pois sempre depende do tipo de aplicativo que você está executando. No entanto, aqui estão algumas sugestões sobre qual configuração escolher.

Aplicações de Baixo tráfego ou poucas requisições.

Se você tiver um site ou aplicativo de baixo tráfego/requisições, como um que hospeda um painel de controle de back-end, como cPanel, use ondemand. A memória será salva, pois os processos filhos só serão gerados quando forem necessários e eliminados quando não forem mais necessários. Como é um back-end, os usuários podem esperar um momento ou dois a mais enquanto um thread é gerado para lidar com sua solicitação.

Aplicações de Alto tráfego ou muitas requisições

Se você tiver um site de alto tráfego, use estático e ajuste as configurações com base em suas necessidades ao longo do tempo e nos recursos de hardware disponíveis. Pode parecer um exagero ter um grande número de processos filhos sempre prontos para receber solicitações.

No entanto, sites de alto tráfego precisam responder o mais rápido possível. Portanto, é essencial usar static para que um número suficiente de processos filho esteja pronto para isso.

Ao usar o ondemand, os processos filhos provavelmente consumirão muita memória sendo gerados e eliminados, e o atraso de inicialização terá um impacto no desempenho.

Usar dinâmico provavelmente não será tão ruim, dependendo da configuração. No entanto, você pode acabar com uma configuração que espelha efetivamente a estática.

Recomendações

Essa foi uma rápida introdução ao ajuste do PHP-FPM para melhor desempenho. Examinamos as três configurações diferentes do gerenciador de processos, suas configurações relacionadas e discutimos quando cada configuração faz sentido.

Recomendamos que cada administrador avalie a melhor configuração do e memória RAM para uso no seu servidor, e portanto, realize as configurações mais adequadas pra atender as necessidades de seus usuários.

Como dica deixo aqui um link interessante para melhorar o desempenho configurando pools para o seu php-fpm: https://www.nginx.com/blog/thread-pools-boost-performance-9x/

Como usar o Composer em um cloud linux na Absam

O Composer é uma ferramenta popular de gerenciamento de
dependências para PHP, criada principalmente para facilitar a instalação e
atualizações das dependências do projeto. O Composer funciona verificando de
quais outros pacotes um projeto específico depende e os instala para você
usando as versões apropriadas de acordo com os requisitos do projeto. O
Composer também é comumente usado para inicializar novos projetos baseados em
frameworks PHP populares, como Symfony e Laravel .

Além das dependências que já podem estar incluídas em seu
sistema linux ( nesse exemplo usando o Debian 11), o Composer requer php-clia
execução de scripts PHP na linha de comando e unzipa extração de arquivos
compactados.

Atualize os pacotes com o comando: sudo apt update

Em seguida, instale as dependências. Você precisará baixar o
Composer, php-mbstring e o php-cli instalá-lo e executá-lo com o comando: sudo
apt install curl php-cli php-mbstring git unzip

Em seguida, baixe o instalador do composer usando curl:

curl -sS https://getcomposer.org/installer
-o composer-setup.php

Em seguida, verifique se o instalador corresponde ao hash
SHA-384 para o instalador mais recente encontrado na página chaves públicas/assinaturas do
compositor
. Para facilitar a etapa de verificação, você pode usar o
seguinte comando para obter programaticamente o hash mais recente da página do
compositor e armazená-lo em uma variável de shell:

HASH=`curl -sS https://composer.github.io/installer.sig`

Para gerar o valor obtido, execute:

echo $HASH

Agora execute o seguinte código PHP, conforme fornecido na
página de download do Composer , para verificar se o script de instalação é
seguro para ser executado

php -r “if (hash_file(‘SHA384’, ‘composer-setup.php’)
=== ‘$HASH’) { echo ‘Installer verified’; } else { echo ‘Installer corrupt’;
unlink(‘composer-setup.php’); } echo PHP_EOL;”

Para instalar composerglobalmente, use o seguinte comando
para baixar e instalar o Composer como um comando de todo o sistema chamado
composerem /usr/local/bin:

sudo php composer-setup.php –install-dir=/usr/local/bin
–filename=composer

E pronto esta com o composer instalado e usável em seu cloud.

Teste sua instalação executando este comando:  $ composer

Projetos PHP geralmente dependem de bibliotecas externas, e
gerenciar essas dependências e suas versões pode ser complicado. O Composer
resolve esse problema rastreando suas dependências e tornando mais acessível
para outras pessoas instalá-las.

Para usar o Composer em seu projeto, você precisará de um
arquivo composer.json. O arquivo composer.json informa ao Composer as
dependências que ele precisa baixar para o seu projeto e as versões de cada
pacote que podem ser instaladas. Isso é extremamente importante para manter seu
projeto consistente e evitar a instalação de versões instáveis que podem
causar problemas de compatibilidade com versões anteriores.

Você não precisa criar esse arquivo manualmente, pois isso é
propenso a erros e pode causar erros de sintaxe. O Composer gera
automaticamente o arquivo composer.json quando você adiciona uma dependência ao
seu projeto usando o comando: composer require

Você pode adicionar dependências adicionais da mesma forma,
sem a necessidade de editar manualmente este arquivo.

Agora você sabe como instalar e atualizar dependências para
o seu projeto em um cloud Linux.

Tenha seu negócio online na Absam

A tecnologia tem proporcionado experiencias inovadoras para os como procedemos com os negócios, e você que é varejista, já está inserido ou pensando em inserir seu negócio em um servidor virtual. 

Para que sua venda chegue com qualidade no seu consumidor final e você tenha sucesso no comércio digital, todas as etapas de experiência do cliente devem ser consideradas. A praticidade, segurança e disponibilidade são indispensáveis para o seu negócio online.

Contar com o apoio profissional de um(a) TI auxilia na implementação de soluções e viabiliza a trajetória do usuário, seja colaborador ou cliente, e em parceria com um Data Center os gestores de TI podem implementar medidas de proteção a dados e ataques on-line, criptografia ponta a ponta, agilidade e segurança no acesso a sites e autonomia para gerenciar ativos de TI. 

 

Ao migrar para um Servidor Cloud Virtual, o varejista prioriza a evolução do seu negócio ao contar com uma infraestrutura estável de um serviço virtual e acessível feito sob medida para as suas necessidades e pagando apenas os recursos que utilizar.

Somado a esses fatores e pensando na experiência do consumidor, os Servidores Clouds na Absam é uma ótima escolha para o varejo, pois para ter uma plataforma de e-commerce com alto desempenho e disponibilidade que agrega credibilidade e reputação do empreendimento com o usuário os servidores dedicados da Absam são sua melhor opção para esse tipo de negócio.

Utilizando tecnologia de ponta te levamos a um outro patamar de resiliência da informação, assim você pode replicar os seus ativos em rede numa infraestrutura privada dedicada e redundante. Além de ferramentas de backup disponível diretamente no painel sem custos para replicações semanais. Disponibilizamos outros modelos de backups que você pode analisar e decidir o melhor para o seu negócio tudo diretamente no painel do seu Cloud.

Absam oferece Servidores Virtuais Privados e Clouds Dedicados com  benefício de você subir todas as definições de segurança, load balance, flexibilidade de expansão computacional e de storage abstraindo completamente toda camada física que seu negócio possua com a agilidade que uma infraestrutura nativamente de alta disponibilidade oferece sem burocracia, totalmente acessível e gerenciada pelo painel de controle da Absam.

Você também poderá contar com um suporte 24 horas por dia x 7 dias da semana x 365 dias do ano, mensalidades que não sofrem as oscilações do valor do dólar e a certeza de uma estrutura eficiente e segura.

Quer inovar no seu negócio e entrar de vez na transformação digital? Então, vem conhecer de perto nossas soluções ou até mesmo contratar nossos serviços, entrando em contato conosco através de uma mensagem. Será uma satisfação atendê-lo!

Ambiente de integração contínua com Jenkins

Em um ambiente de produção de software, a prática da Integração Contínua(CI) é uma ótima opção da métodologia ágil para o processo como parte da rotina, para alterações de código na ramificação principal de um repositório, e testes nas alterações com o máximo de antecedência e frequência possível, onde os desenvolvedores integrem os códigos todos os dias, passado ao cliente a ideia de continuidade.

A vantegem de um ambiente com Integração Contínua é a disponibilidade de manter um fluxo minimamente controlado e chance de falhas quase inexistentes, controle de branches dos ambientes de desenvolvimento, homologação e produção separados com geração de versão disparada e disponibilizada automaticamente ou manualmente pelo servidor de automação, sem interrupção. 

Com ferramentas como o Jenkins, essa métodologia pode ser aplicada com maior facilidade. Baseado em Java, o Jenkins ajuda a automatizar o processo de desenvolvimento de software por integração contínua e facilita certos aspectos da entrega contínua. 

Vamos montar um servidor de CI com jenkis na Absam para o desemvolvimento de um projeto simples como exemplo.

Para isso iremos instalar o jenkis a partir de um docker, caso não tenha um docker instalado no seu servidor Cloud Server na Absam, você pode instalar seguindo esse tutorial: https://absam.io/faq/content/1/62/pt-br/como-instalar-docker-no-cloud-server-com-ubuntu.html

Utilize o comando para instalar o jenkis: 

> docker pull jenkins/jenkins:lts

Referência: https://hub.docker.com/r/jenkins/jenkins/

Em seguida para rodar: > docker run -p 8080:8080 -p 50000:50000 jenkins/jenkins:lts Pronto! jenkins esta instalado e rodando na porta 8080 do seu servidor Cloud Server, para acessar vá ao navegador e acesse pelo endereço ip do seu servidor dessa forma: http://<endereco_ip>:8080  Ao acessar a primeira vez o endereço ele ira solicitar uma chave para password do administrador, a qual você poderá adquirir no local indicado na tela por ele.

Na tela seguinte recomendo que você siga instalando os plugins sugeridos, depois você pode reavaliar e deixar só o que for usar:

Na próxima etapa você cria o seu usuário ou continua como admin e em seguida define as configurações da instancia do seu servidor de automação.

Navegue por Gerenciar Jenkins > Gerenciar Plugins > Acesse a aba disponíveis

Você deverá instalar e configurar:

Build Monitor View — Será possível acompanhar os builds dos jobs que você criar

Periodic Backup — Vai ajudar você a manter as configurações de todo o seu jenkins (configurações gerais, de jobs, plugins)

Publish Over SSH — Vai possibilitar comunicação SSH com servidores locais ou na nuvem

Role-based Authorization Strategy — Gestão mínima de credenciais ao Jenkins

xUnit — Vai possibilitar gravar seus reports de testes

E um plugin de notificação, existes no link https://plugins.jenkins.io/ui/search?query=notification a depender do seu gosto e do tipo de ferramenta que usa para sua equipe.

Com essas ferramentas instaladas você pode montar uma gama variada de testes e pipelines para seu projeto. 

Você pode montar incialmente um job “construir um projeto de software free-style”, primeira opção da lista de jobs, que pode montar um jenkis para seu projeto do git.

Selecione para isso nessa tela a opção git e adicione o endereço do repositório git do seu projeto com as credenciais para o mesmo adicionando no botão add em credentials. e a branch é dev que ira utilizar para o desemvolvimento.

Selecione nessa configuração por exemplo o consultar periodicamente, que definirá o tempo que o Jenkins verificará se existe algum código novo na branch especificada, a expressão que especifiquei não é recomendada pois a verificação acontece a todo segundo, na interrogação ao lado deste campo existem exemplos de como combinar uma expressão mais adequada.

Com estas configurações iniciais quaisquer alterações que forem feitas já estarão sendo capturadas pelo seu job, e você poderá acompanhar a entrega de seus artefatos, acompanhamento de builds, notificações, backup e relatório de testes com as configurões utilizando os plugins citados anteriormente.

Existem diversas possibilidades com Jenkins, algumas utilizam estratégias de pipelines, Jenkinsfile que são muito interessantes para serém implemetas no projeto de sua equipe. 

A documentação para o Pipeline do Jenkins pode ser acessada aqui: https://www.jenkins.io/doc/book/pipeline/ 

Esperamos que com essa pequena pratica lhe dê uma experiencia do poder que a Integração Contínua pode fazer para ajudar a equipe como um todo no desenvolvimento de boas praticas ágeis.

Sair da versão mobile