Autor Tópico: Scriptcase, banco de dados e otimização de performance. Postem suas experiências  (Lida 11152 vezes)

Kleyber

  • Expert
  • *****
  • Mensagens: 2232
    • Email
Re:Scriptcase, banco de dados e otimização de performance. Postem suas experiências
« Responder #30 Online: Março 27, 2015, 03:57:06 pm »
Alexandre,

Boas notícias então. Pelo que vi o nginx é realmente bem mais rápido do que o Apache.
Kleyber Derick

ITIL® V3 Foundation Certified
Analista de Sistemas
São Luís - Maranhão
www.tkinformidia.net

Alexandre Pereira Bühler

  • Expert
  • *****
  • Mensagens: 1637
  • Nunca estabeleça um teto para os seus rendimentos.
    • Simão & Bühler Ltda
    • Email
Re:Scriptcase, banco de dados e otimização de performance. Postem suas experiências
« Responder #31 Online: Março 27, 2015, 06:10:43 pm »
E bota mais rápido nisto.
Mas assim com o apache tem que ser bem configurado.
--
Alexandre Pereira Bühler
https://www.simaoebuhler.com.br
Hospedagem compartilhada Scriptcase desenvolvimento e produção. Temos servidores dedicados Scriptcase.
Eu RTFM todo dia e você?

gunet

  • Novato
  • *
  • Mensagens: 3
    • Email
Re:Scriptcase, banco de dados e otimização de performance. Postem suas experiências
« Responder #32 Online: Março 27, 2015, 09:19:37 pm »
Interessante.  E com o php 5.6 ou 5.4?
Marcus

Alexandre Pereira Bühler

  • Expert
  • *****
  • Mensagens: 1637
  • Nunca estabeleça um teto para os seus rendimentos.
    • Simão & Bühler Ltda
    • Email
Re:Scriptcase, banco de dados e otimização de performance. Postem suas experiências
« Responder #33 Online: Março 28, 2015, 12:02:39 am »
PHP 5.4. Procuro manter a compatibilidade com o scriptcase.
--
Alexandre Pereira Bühler
https://www.simaoebuhler.com.br
Hospedagem compartilhada Scriptcase desenvolvimento e produção. Temos servidores dedicados Scriptcase.
Eu RTFM todo dia e você?

Alexandre Pereira Bühler

  • Expert
  • *****
  • Mensagens: 1637
  • Nunca estabeleça um teto para os seus rendimentos.
    • Simão & Bühler Ltda
    • Email
Dica do dia:
Para melhorar a performance do seu servidor web:

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."


--
Alexandre Pereira Bühler
https://www.simaoebuhler.com.br
Hospedagem compartilhada Scriptcase desenvolvimento e produção. Temos servidores dedicados Scriptcase.
Eu RTFM todo dia e você?

Alexandre Pereira Bühler

  • Expert
  • *****
  • Mensagens: 1637
  • Nunca estabeleça um teto para os seus rendimentos.
    • Simão & Bühler Ltda
    • Email
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.
--
Alexandre Pereira Bühler
https://www.simaoebuhler.com.br
Hospedagem compartilhada Scriptcase desenvolvimento e produção. Temos servidores dedicados Scriptcase.
Eu RTFM todo dia e você?

Alexandre Pereira Bühler

  • Expert
  • *****
  • Mensagens: 1637
  • Nunca estabeleça um teto para os seus rendimentos.
    • Simão & Bühler Ltda
    • Email
Re:Scriptcase, banco de dados e otimização de performance. Postem suas experiências
« Responder #36 Online: Outubro 29, 2016, 01:54:33 am »
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.
« Última modificação: Outubro 29, 2016, 02:06:35 am por Alexandre Pereira Bühler »
--
Alexandre Pereira Bühler
https://www.simaoebuhler.com.br
Hospedagem compartilhada Scriptcase desenvolvimento e produção. Temos servidores dedicados Scriptcase.
Eu RTFM todo dia e você?

Kleyber

  • Expert
  • *****
  • Mensagens: 2232
    • Email
Re:Scriptcase, banco de dados e otimização de performance. Postem suas experiências
« Responder #37 Online: Outubro 29, 2016, 08:00:44 am »
Show, Alexandre. Obrigado por compartilhar.
Kleyber Derick

ITIL® V3 Foundation Certified
Analista de Sistemas
São Luís - Maranhão
www.tkinformidia.net