Olá amigos do Fórum,
Não estou fazendo propaganda de meus serviços.
Crio este tópico para que cada um coloque suas experiências ao otimizar suas aplicações Scriptase e SGDB
Como hospedo para várias pessoas já passei por muita coisa, então posto aqui as experiências mais comuns que tenho.
Seguem meu relato mas espero que vocês também contribuam.
Tenho um provedor de hospedagem compartilhada para scriptcase e quero dizer que sofro com a performance das aplicações scritpcase e SGDB.
Mas de quem será a culpa? hardware? SGDB? Scritpcase?
Cheguei a perder clientes por causa da performance.
Então comecei a verificação geral.
Usei o comando top e etc para ver o que acontecia com meu hardware.
Comentários sobre comando top do GNU/Linux --> https://www.4site.com.br/blog/explicando-o-load-average/
O I/O do disco está ótimo.
O consumo de memória mais alto que tive no mysql foi de 11%, apache 25% e etc. Nada que ultrapasse os 50% durante o dia.
Fiz uma manutenção geral preventiva no hardware de madrugada
Mas meu consumo de CPU, este era drástico no mysql. Chegava a 100%
Dentre as possíveís causas estão:
a) I/O em disco, problemas gerais no hardware
b) configuração errada do mysql
c) querys (select, insert, updates e etc) mal construídas;
d) joins mal estruturados;
e) querys e joins que não fazem uso de indexes corretamente.
f) e etc
Como a causa “a” já foi descartada fui para causa “b” mesmo sabendo que cpu alto geralmente são as causas “c, d, e”.
Usei os arquivos tuning-primer.sh e mysqltuner.pl para verificar o que podia ser melhorado em minha configuração do mysql.
Também olhei o status do mysql.
Enfim, mysql otimizado.
Era para tudo ocorrer normal.
No outro dia clientes me falaram que havia selects demorando mais de 15 minutos para serem concluídos.
Como a causa “a Hardware” e “b configuração do mysql” foram eliminadas somente restou o mais comum: query e joins.
Ativei o log “mysql slow querys” do msyql para acompanhar as querys lentas.
Descobri dados interessantes e porque meu serivdor está “abrindo o bico”.
E aqui vai o que aprendi com meus erros e dos erros de alguns clientes ao “programar e criar suas databases”
-
Há coisas que o servidor da aplicação não faz sozinhos por vocês. Nem mesmo a empresa onde vocês contrataram a hospedagem, cloud e etc.
Aprenda o que é optimizar, desfragmentar e reparar tabelas no mysql.
Não espere as tabelas ficarem com mais de 1Gb ou terem mais de 100000 registro para fazerem uso destes recursos.
No Firebird e postgresql há comando semelhantes como o vacum do postgresql e etc
Se não fizerem uso destes recursos pode se ter o melhor link do mundo, mas o servidor será um carroça para suas aplicações.
No phpmyadmin ao clicar na tabela vá em operações, lá poderá usar este recursos. -
Aprenda a fazer uso de indexes corretamente. Eles estão ai para ajudar.
Primary key nem sempre é o index que você irá usar.
Vejam: crio um tabela “teste” campos “codigo”, “nome” e etc
crio minha primary key no campo “codigo”. Beleza index criado.
Mas na hora de fazer uma query: select bla, bla, bla “where nome” = bla, bla
Vocês acham que para “where nome =” o select irá fazer uso do index ou do primary key?
O index do campo nome nem foi criado somente o primary key para o campo código
É apropriado criar um index para o campo nome.
Deixe suas tabelas ficarem grandes que saberão que falo a verdade.
Para mais detalhes vejam o manual em inglês:
http://dev.mysql.com/doc/refman/5.5/en/optimization.html
http://dev.mysql.com/doc/refman/5.5/en/optimization-indexes.html
Se você não sabe inglês pode consultar este manual do mysql em português:
http://xoops.net.br/docs/mysql/manual/ch05s04.php
E olha que já vi muita gente fazer isto, inclusive eu. Achar que a query/join esta indexada e não está. Lentidão na certa.
- Querys e joins com cláusulas mal estruturadas
leiam este site:
http://www.intellinews.com.br/blog/pt/optimizacoes-simples-e-eficazes-no-mysql/
Não temos controle em como o Scriptcase faz suas cláusulas (filtros) sql.
Mas deduzimos que filtros como o “qualquer parte” fazem uso da claúsula like %palavraprocurada%
Se sua base tiver muitos registros ao liberar para seu cliente o filtro “qualquer parte” não reclame se ele dizer que esta demorando muito para achar o registro.
Agora tiremos o scriptcase fora da jogada e vamos para claúsulas montadas por vocês dentro do Scriptcase.
No mysql se usar tabelas mysam ao invés de “like” use os indexes como text e a claúsula “match against” a diferença de tempo é brutal.
Vi um like demorar 20 segundos e o no mesmo select o match against demorar menos de 1 segundo.
Leiam mais uma vez o site: http://www.intellinews.com.br/blog/pt/optimizacoes-simples-e-eficazes-no-mysql/
E veja que onde ele diz lento e lentooooooooooooooooooo mesmo quando a quantidade de registro é grande.
Use ferramentas que monitorem suas querys, o tempo de execução e se usaram indexes.
Houve casos no meu servidor de tabelas bem indexadas mas cujos joins não faziam uso correto dos indexes e toda uma tabela de 430000 registros era lida para satisfazer o join.
Quem não observa estas coisas terá:
“Resultado cliente liga para você. E ai?
Mudar de servidor? faço upgrade de servidor? Compro outro hardware mais potente para servidor?
Mudei ficou tudo rápido. A base cresce e a lentidão volta. E ai? muda de servidor de novo? Já viu o transtorno que é mudar de servidor?
Não é mais fácil otimizar sua aplicação no SC e sua database no SGDB do que ficar pulando de servidor em servidor?”
Se você possui vários sistemas num servidor lembre-se que geralmente, há execções é claro, mas a próxima query no mysql so entra em ação quando ele finalizar a que esta presa na frente. Então vamos otimizar ai gente!