Scriptcase, banco de dados e otimização de performance. Postem suas experiências

Configuração PHP / Ambiente / Performance
#21

[size=14pt]Obs: façam backup antes dos procedimentos não me responsabilizo por perdas de dados.[/size]
[size=12pt]
Se seu scriptcase desenvolvimento estiver lento e não é mais o mesmo. Pode ser fragmentação no banco de dados em que ele foi instalado.[/size]

Para instalação no mysql ler neste post: http://www.scriptcase.com.br/forum/index.php/topic,5689.msg39937.html#msg39937
Comando disponiveis no phpmyadmin e sql.

Para instalação no sqlite use o comando vacuum nas tabelas e indexes. http://www.sqlite.org/lang_vacuum.html
No sqliteadmin use o icone limpar database.
Ou use no sql

Para o postgresql use reindexdb, vacuumdb e analyze -> http://www.postgresql.org/docs/9.3/static/app-reindexdb.html , http://www.postgresql.org/docs/9.3/static/app-vacuumdb.html e http://www.postgresql.org/docs/9.3/static/sql-analyze.html
Comandos disponíveis no phppgadmin, pgadmin ou sql

E fim.

Scriptcase lento demais
#22

[size=14pt]Para se pensar:[/size]

Windows server 2012 requisitos (http://technet.microsoft.com/pt-br/library/jj134246.aspx):

Mínimo: processador de 1,4 GHz e 64 bits
RAM: Mínimo: 512 MB
Espaço em disco: Mínimo: 32 GB
Ou seja isto é o mínimo para ele rodar bem lentium.

Ai façamos a conta:

512 MB do mínimo para ele rodar mais uma margem de 512M para processos dos sistema operacional.
Total 1gb de memória
1GB somente para o windows rodar lentium.

Apache + php + sc (fonte google e experimentações pessoais)
Vamos desprezar o consumo de memória pelo apache e considerar somente pelo php.
Cada chamada do php como php-cgi para rodar o scriptcase pode consumir até 65Mb ou mais um pouquinho.
Obs: o sc instalador instala o php como php-cgi no apache.
Então vamos usar o php como módulo que consome menos memória e supor na melhor das hipóteses que cada chamada consuma 35Mb.
Logo se coloco no apache um limite para 150 conexões temos:
150x35Mb=5250Mb que é aproximadamente 5GB.
Então na pior das hipóteses se 150 usuários acessarem seu servidor simultaneamente temos um consumo de 5Gb de memória.
Ainda bem que isto é difícil de acontecer. Será?

Banco de dados

Vamos pegar o campeão de popularidade: Mysql.

Vamos desconsiderar que campos blob requerem 3x mais memória, para que você vai querer usar campo blob não é mesmo?.
Os mais afoitos podem usar estes sites para calcular o consumo de memória do mysql com base na configuração do my.cnf ou my.ini
http://www.mysqlcalculator.com/
http://www.omh.cc/mycnf/
vamos pegar um caso leve com a pior configuração para seu mysql que tem 2gb de base de dados innodb começar a ficar lentium:
key_buffer_size 64 MB
query_cache_size 64 MB
tmp_table_size 32 MB
innodb_buffer_pool_size 8 MB
innodb_additional_mem_pool_size 1 MB
innodb_log_buffer_size 1 MB
max_connections 150

sort_buffer_size 2 MB
read_buffer_size 128 KB
read_rnd_buffer_size 256 KB
join_buffer_size 128 KB
thread_stack 196 KB
binlog_cache_size 0 MB
Total: 576.2 MB de memória consumida com 150 conexões simultâneas.

Agora vamos ver o MS SQLSERVER. fonte: http://msdn.microsoft.com/pt-br/library/ms143506.aspx

memória Mínima:
Edições Express: 512 MB
Todas as outras edições: 1 GB
Recomendado:
Edições Express: 1 GB
Todas as outras edições: pelo menos 4 GB e deve ser aumentado à medida que o banco de dados cresce para garantir um ótimo desempenho.

Logo para o windows + apache + php + mysql

sistema operacional: 1gb
apache + php 150 conexões: 5gb
mysql 150 conexões simultâneas: 576 Mb
memória mínima que o cloud deve ter: aproximadamente 6.5gb
obs: Isto para ele trabalhar lentium, arrastando e travando na pior das hipóteses.

Para windows + apache + php + ms sqlsever edition express ( a que consome menos).

sistema operacional: 1gb
apache + php 150 conexões: 5gb
Edições Express: 1GB (recomendado)
Memória mínima que o cloud deve ter: aproximadamente 7gb
obs: Isto para ele trabalhar lentium, arrastando e travando na pior das hipóteses.

Obs: quando você considerar o mínimo requerido. Lembre-se que o mínimo do windows seven ultimate para rodar (http://windows.microsoft.com/pt-br/windows7/products/system-requirements) é 1 gigabyte (GB) de RAM (32 bits) ou 2 GB de RAM (64 bits) .
Agora experimente rodar o windows seven ultimate com office, antivirus instalado e 1gb de memória!? Fica uma carroça dependendo da máquina!
E clique hoje, vá tomar um café e volte amanhã.
Logo, imagine o que os requerimentos mínimos de hardware fazem ao ms sqlserver, mysql, php, apache e windows server?

Isto pode ser aplicado ao Linux (http://www.debian.org/releases/wheezy/mipsel/ch03s04.html.pt) e outros sistemas operacionais, também a outros sgdb´s.

Ai você vem me dizer que quando contratou o cloud, montou seu servidor e etc…
E era somente você a usar. Uau!!!.. O “acesso era legal”, mais que demais!
Somente que agora não entende…!? Depois de começar a colocar seus clientes tudo começou a ficar lento.
Seu servidor com: 2Ghz e 2 cores, 2 Gb de memória e 50 Gb de espaço em disco não era para dar conta do recado?

Olha! Se você tiver muita sorte como a maioria tem! E eu sou um dos sortudos.
Os acesso não serão simultâneos e o seu servidor vai dar conta.
Mas sempre terá que fazer uma mágica na configuração. E isto a qualquer hora.
Afinal os perfis de acesso não são fixos. Mas as limitações do seu servidor sim.
Esta mágica de controlar o consumo de memória, disco, processamento tem que ser feita até que você ou eu criemos juízo e coloquemos a mão no bolso.
Espero ter contribuído com a dúvida de muita gente.

#23

Alexandre,

Parabéns pelos posts.

Na instalação default do SC 7 onde fica a base de dados?

O meu está muito lento é quero ver se resolvo utilizando uma das suas dicas.

Obrigado

#24

George obrigado
A instalação padrão fica:
pasta instalação scritpcase\devel\conf\scriptcase\nm_scriptcase.db.

Mas copie esta base para um lugar seguro antes de fazer o procedimento.

#25

Alexandre vc é o cara.

Meu SC voltou a funcionar com a velocidade normal, estava muito lento.

Obrigado

#26

de nada

#27

Olá pessoal,
Relato caso acontecido com nosso amigo aqui do fórum.

Problema relatado: lentidão no sc 7.1 com php 5.4.
Teste feito com sc IDE instalado com mysql e sqlite e ficava lento nos dois.
Executado vaccum no sqlite e ainda continuava lento.

Solução:
Nos teste desabilitamos o antivírus e o sc voltou a funcionar normal.
O firewall do antivírus estava deixando lento o SC.
Antivírus: Mcafee Live Safe 12.8 para windows 8.1

Dica
Quando o SC estiver lento e a desfragmentação ou tuning do apache + SGDB não funcionar experimente desligar o antivírus.
Ele pode ser o grande vilão no que diz respeito do desempenho do SC IDE.

#28

caraca !

Eu achava que sabia alguma coisa…

muito, muito obrigado!

#29

De nada Pessanha.
Tendo coisas para compartilhar neste post não esqueça de contribuir.

#30

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

#31

Alexandre,

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

#32

E bota mais rápido nisto.
Mas assim com o apache tem que ser bem configurado.

#33

Interessante. E com o php 5.6 ou 5.4?

#34

PHP 5.4. Procuro manter a compatibilidade com o scriptcase.

#35

[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.”

#36

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.

#37

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.

#38

Show, Alexandre. Obrigado por compartilhar.

#39

Hoje fica como dica o artigo:

45 maneiras de acelerar o FB -> Firebird
https://www.firebase.com.br/artigo.php?id=2920

#40

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.