caraca !
Eu achava que sabia alguma coisa…
muito, muito obrigado!
De nada Pessanha.
Tendo coisas para compartilhar neste post não esqueça de contribuir.
Bom dia,
Estava um cliente sofrendo com lentidão no sistema com o servidor apache.
tinha mais de 300 conexões simultâneas por dia.
Arrisquei e troquei o apache por nginx com php-fpm.
O sistema está satisfatório. A melhora foi visível.
A única dificuldade foi ao gerar pdfs.
Isto foi resolvido tirando o cache dos scripts .php, ou seja, faz cache de tudo menos dos scripts php.
Penso quando for mudar de servidor e migrar os domínios hospedados aqui já mudar também de apache para nginx.
Fica ai meu relato
Alexandre,
Boas notícias então. Pelo que vi o nginx é realmente bem mais rápido do que o Apache.
E bota mais rápido nisto.
Mas assim com o apache tem que ser bem configurado.
Interessante. E com o php 5.6 ou 5.4?
PHP 5.4. Procuro manter a compatibilidade com o scriptcase.
[size=14pt]Dica do dia:
Para melhorar a performance do seu servidor web:[/size]
1) Desabilite os módulos do servidor web que não irá usar.
2) Desabilite os módulos php que não irá usar.
3) Faça uso do mencached para guardar dados. Ele é um cache próprio para isto.
“Em computação, memcached é um sistema de cache em memória distribuído de propósitos gerais que foi originalmente desenvolvido pela Danga Interactive para o LiveJournal, mas é usado agora para muitos outros sites. É frequentemente usado para acelerar sites dinâmicos database-driven cacheando dados e Objetos na RAM para reduzir o número de vezes que uma fonte de dados externa (como um banco de dados ou uma API) deva ser acessada. O Memcached roda em Unix, Linux, Windows and Mac OS X e é distribuido sobre um permissive free software license.2”
4) Faça uso do xcache para guardar os scritps php compilados. Ele é um cache próprio para isto.
“É um gerenciador de cache, que armazena os scripts php em opcode para uso futuro, é extremamente rápido e muito usado no mundo em servidores com alta demanda.”
somente para complementar:
O xcache é bom para o php até 5.4
o php 5.5 e acima já tem seu próprio cache opcode.
Que até onde li é mais rápido que o xcache.
http://massivescale.blogspot.com.br/2013/06/php-55-zend-optimiser-opcache-vs-xcache.html.
Bom dia,
Hoje quero compartilhar configurações do php-fpm que pode agilizar o tempo de resposta ou aumentar a capacidade de carga do servidor.
Para php-fpm temos as três configurações (modos): static, dynamic ou ondemand (complementado com http://fatorbinario.com/comunidade/topico/php5-fpm-nginx-modos-static-x-dynamic-x-on-demand/)
A escolha de um destes modos pode ser vital para o desempenho do seu projeto.
1) static é melhor para um único pool correndo um único projeto ou grupo de aplicativos.
Pode ser configurado para rodar um número fixo de requisições de páginas impondo um limite, quando este limite é ultrapassado o NginX/Apache responde com erros 502 ou 504. A opção Static tem a vantagem de ser a mais rápida pois a memória é pré-alocada para “N” requisições, porém para sites com muitos acessos isso pode ser um problema pois demandaria muita memória RAM reservada, que nem sempre é usada.
2) dynamic é melhor para vários pools sendo a maioria de deles com ordem de 10.000 requisições por dia.
Neste modo um número limite de requisições é configurado, e quando este limite é atingido o processador procura por processos inativos servindo as páginas a partir deles (respawning). Essa opção é intermediária e configurada por padrão na maioria dos servidores que usam PHP-FPM. As páginas serão servidas com demora de alguns milissegundos em comparação ao modo Static, mas o uso da memória RAM é menor uma vez que os processos são recicláveis pois podemos configurar com um número bem mais reduzido de “requests”.
3) ondemand é o melhor para grande número de pools, muitos dos quais lidam com baixa carga (algumas centenas de requisições por dia ou menos) - A típica hospedagem compartilhada configurada com centenas de sites de baixo tráfego por servidor.
Este modo pode ser ativado a partir da versão 5.3.9 do PHP sendo a melhor opção para servidores que servem alta demanda de páginas. Após ativado e configurado para “N” requisições ele criará novos processos quando necessário e destruirá os mesmos quando não estiverem mais em uso. A velocidade em que as páginas serão servidas é ainda mais lenta que no modo Dynamic por causa da reciclagem constante, porém nota-se que estamos falando em milisegundos aqui. O uso de memória RAM é bem reduzido mesmo com muitos acessos.
Entre as configurações que estes três modos podem usar é bom ficar de olho e sempre que necessário reconfigurar (https://secure.php.net/manual/pt_BR/install.fpm.configuration.php):
a) pm.max_children O número de processos filhos que podem ser criados quando pm está configurado como static e o número máximo de processos filhos podem ser criados quando pm está configurado como dynamic. Essa opção é obrigatória.
Pode ser calculado com a fórmula; pm.max_children = Total RAM dedicada ao servidor web (apache ou nginx) / tamanhod do Max child process
No linux Max child process pode ser determinado pela média que se obtém com o comando:
ps --no-headers -o “rss,cmd” -C php-fpm | awk ‘{ sum+=$1 } END { printf ("%d%s\n", sum/NR/1024,“M”) }’
ou
ps --no-headers -o “rss,cmd” -C php5-fpm | awk ‘{ sum+=$1 } END { printf ("%d%s\n", sum/NR/1024,“M”) }’
Observação: use as formulas acima quando for horário de pico de uso no seu projeto
b) pm.start_servers O número de processos filhos criados na inicialização. Usado apenas quando pm é configurado em dynamic. Valor padrão: min_spare_servers + (max_spare_servers - min_spare_servers) / 2.
c) pm.min_spare_servers O número mínimo desejado de processos servidores inativos. Usado apenas quando pm está configurado como dynamic.
d) pm.max_spare_servers O número máximo desejado de processos servidores inativos. Usado apenas quando pm está configurado como dynamic.
e) pm.max_requests O número de solicitações de cada processo filho deve ser executado antes do respawning. Isto pode ser útil para contornar falhas de memória de bibliotecas de terceiro quebradas. Para o processamento de pedido interminável especificar '0 '. equivalente a PHP_FCGI_MAX_REQUESTS. Valor padrão: 0
f) pm.process_idle_timeout O número de segundos, após o quais processos ociosos serão mortos. Usado quando pm está configurado para ondemand.
Show, Alexandre. Obrigado por compartilhar.
Hoje fica como dica o artigo:
45 maneiras de acelerar o FB -> Firebird
https://www.firebase.com.br/artigo.php?id=2920
Se os seus servidores são fora do Brasil ou se mesmo dentro do Brasil ocorre lentidão (latência alta) no acesso ao sistema, considere usar um CDN.
CDN — sigla em inglês para Content Delivery Network ou Rede de Distribuição de Conteúdo
Mais informações sobre CDN em:
https://www.tecmundo.com.br/internet/54073-o-que-e-uma-cdn-e-como-ela-controla-a-internet-que-voce-usa-.htm
Um bom CDN com plano gratuito e pago é o Cloudflare.
Agora com servidores no RJ e SP.
Alguns membros do Fórum já testaram com o Scriptcase produção e houve melhora significativa.
Não aconselho uso com Scriptcase desenvolvimento pois o cache de um CDN irá atrapalhar.
Mas antes teste bem com sua aplicação. Não me culpe depois se colcoar direto sem testar e gerar resultado imprevisivéis.
Não sabe mais onde otimizar seus apps para que entrega de conteúdo seja rápida?
O google tem uma proposta para você:
https://developers.google.com/speed/pagespeed/module/
https://www.modpagespeed.com/
https://developers.google.com/speed/
The PageSpeed modules are open-source server modules that optimize your site automatically.
É um módulo para os servidores web Apache e Nginx que tem como objetivo melhorar a velocidade de carregamento das páginas.
Resumidamente o mod_pagespeed lê os arquivos que o servidor envia para o navegador do cliente e aplica uma série de boas práticas para agilizar o processo. Mais uma vez aconselho colocar somente no Scriptcase produção.
Mas antes teste bem com sua aplicação. Não me culpe depois se colcoar direto sem testar e gerar resultado imprevisivéis.
Dica do dia:
PHP-FPM seja em conjunto com Apache ou Nginx deixará seus projetos com acesso melhor .
Mas leve em consideração que Nginx + php-fpm podem requerer mais núcleos de CPU do que o conjunto Apache + php-fpm, quando o acesso simultâneo for alto.
Também observe que a conexão php-fpm via SOCKET é muito mais rápida que via TCP/IP.
O detalhe é que para muitos acessos simultâneos começará a dar problema.
Logo, se o acesso for alto opte diretamente por php-fpm via TCP/IP.
Bom dia.
O primeiro link está quebrado. Alguém sabe como posso encontrar ele? Meu scriptcase está lento, e quero fazer o procedimento para desfragmentação.
O arquivo de banco de dados está em:
C:\Program Files (x86)\NetMake\v9\wwwroot\scriptcase\devel\conf\scriptcase
Att,
André.
Se o banco for sqlite faça um cópia dele para um lugar seguro.
Ninguém pode estar acessando o scriptcase durante a cópia.
Depois instale o https://sqlitestudio.pl/index.rvt
A base é esta: nm_scriptcase.db
Então use o vacuum
Se deu certo e for isto o seu scriptcase ficará mais rápido.
Se der algum erro volte a cópia da sua base.
PS: não me responsabilizo por perdas, principalmente se não fez backup antes do procedimento.
@HenriqueB
A não resolução dos links no fórum trás este incoveniente. Ter que descobrir todas as soluções de novo. Se pelo menos pudessemos editar os links antigos.
1 Curtida
Obrigado Alexandre, estou usando MySQL. Existe ferramenta nele que faça o mesmo?
Att.
André.
Sim.
Neste mesmo post:
Hoje resolvei fazer um benchmark com uma máquina velha para ver em que banco gratuito terei melhor performance com o Scriptcase.
Instalei o Debian 9 com Postgresql 11, MariaDB 10.3 e Fireird 3.0.
Não fiz otimização nenhuma nos SGDB´s. Estão com a instalação padrão.
Com o gerador de dados do Dbeaver me conectei aos três SGDB e fiz um insert de 50000 registros.
Segue resultado:
Mariadb myisam
Old data isn’t removed.Inserting mock data into the “teste”.
Rows updated: 50000
Duration: 4220ms -> 4,22 segundos
Postgresql
Old data isn’t removed.Inserting mock data into the “teste”.
Rows updated: 50000
Duration: 16965ms -> 16,965 segundos
Firebird
Old data isn’t removed.Inserting mock data into the “TESTE”.
Rows updated: 50000
Duration: 94374ms -> 1,5729 minutos
Mariadb innodb
Old data isn’t removed.Inserting mock data into the “teste”.
Rows updated: 50000
Duration: 2918181ms -> 48,63635 minutos
Mais tarde irei ver o tempo gasto para select, update e delete dos 50000 registros.
PS: Este teste prova que MariaDB/MySQL com InnoDB somente é bom para Select.
2 Curtidas