André H. Ferreira

Venho hoje posta a técnica desenvolvida por mim para utilizar processo distribuído, multi-servidores, e simulação de multi-thread totalmente em PHP. Como todo desenvolvedor web sabe, o carregamento da um página é estrutural se tratando de serve layer, isso pois o conteúdo que é enviado para o usuário é todo processado no servidor primeiro, porém existe uma forma de facilitar esse processamento simulando um multi-thread com o PHP, isso é possivel e hoje é utilizando no projeto em que trabalho. Vamos analisar a ideia: 1. Inicialmente vamos pensar que o PHP nada mais é que uma linguagem que é interpretada por um aplicativo que no Windows tem o nome de php.exe, e fica localizado na pasta da instalação do PHP. 2. Quando um usuário faz uma requisição HTTP o Apache ou qualquer outro servidor web identifica qual a extensão do arquivo, sendo .php, .php4, .php5, .sphp ou coisa do tipo(definidos no htacess ou nas configurações do servidor), o servidor web então chama o php.exe, enviando o conteudo pelo parâmetro -f, e depois retornando o HTML já processado, este processo ocorre toda vez que há uma requisição por POST ou GET, estão resumindo, toda vez que enviamos um formulário, clicamos em um link ou acessamos um site e solicitamos Ajax, é feito este processo. 3. Cada vez que o servidor web passa o arquivo pelo PHP vários comandos são interpretados e executados no sistema operacional por meio de bibliotecas e comandos de baixo nível, por isso na instalação do PHP é criada a pasta 'ext', está é a pasta que contem todas as dll para funcionamento do MySql, PDO, Zip, OpenSSL, resumindo é possivel usar qualquer biblioteca juntamente com o PHP, basta sabe fazer a configuração corretamente. 4. O mais importante, o PHP pode ser executado diretamente pelo CMD(Linha de comando), para isso é necessário digitar a pasta aonde esta localizado o arquivo e -f com o nome do arquivo que desejamos executar, porem exite um problema, ao fazer isso perdemos acesso a variáveis de ambiente como $_GET, $_POST, mas ainda sim é possivel passar parâmetros para essa aplicação e resgatá-las no PHP por meio da variável $argv Primeiro etapa para consegui fazer um sistema distribuído é a classe thread, disponível no arquivo anexo no final do post, esta incrível classe tem o poder de fazer requisições para si mesmo e para outros arquivo em runtime, além disso ele consegui retorna o resultado, eu fiz alguma alterações nesta classe para atender minhas necessidade e a classe que utilizo hoje esta disponível no arquivo multi-thread simulate.zip. O arquivo que contem a classe original também tem um arquivo teste que demonstra a utilização simples da classe, um outro script importante para utilizar multi-servidores é o arquivo que criei com nome de Exec.php disponível no segunda arquivo abaixo, ele verifica qual sistema operacional está em uso no servidor e executa um comando CMD por meio da função exec e shell_exec para iniciar um 'thread' ou finalizar um, no caso é possivel também finalizar todos os processos iniciados por meio da função killallthreads. Para usuários de Windows é necessário configurar o caminho do arquivo php.exe no arquivo exec.php, caso não o script não irá funcionar. Internamente ainda tenho uma função para criação da thread(segue abaixo), no caso a variável $host seque a url do script remoto, $link é o caminho para o arquivo exec.php, $exe é o nome do arquivo php que deseja iniciar e $args são parâmetros a serem passadas para o arquivo. Exemplo de chamada open_thread("127.0.0.1", "/thread/", "/thread/processos/soma.php", "1 5");, no caso eu quero chamar um arquivo php de soma, aonde teoricamente ele recebe 2 parametros, faz a soma e retorna o resultado, o arquivo esta na minha maquina local, na pasta /thread/ deve estar o arquivo exec.php, e o arquivo soma deve esta em /thread/processos, é claro que em tarefas tão simples não é necessário utilizar multi-thread. function open_thread($host, $link, $exe, $args){ $tmp_thread = new Thread($host, 80, $link . "exec.php"); $tmp_thread->setFunc("createthread", array($exe." ".$args)); $tmp_thread->start(); } Este modelo é totalmente novo e não há nada parecido, falo isso pois fiquei mais de 2 meses procurando, e é muito útil para serviços de extrema complexabilidade que demoraria muito tempo para ser feito, a vantagem de utilizar o PHP pra isso é o tempo de resposta que é excelente, e sua mobilidade por ser uma linguagem altamente modular, fora isso ter a possibilidade de controlar tarefas pesadas por meio de uma interface WEB sem necessidade de usa Java ou Flash. Classe Thread original - PHP Classes ou Skydriver Classe thread alterada e arquivo Exec -Skydriver Espero que tenham gostado Para mais artigos relacionados a performance, programação e SEO acesse http://vivendonaweb.blogspot.com

Hoje vou falar um pouco sobre o Sphinx, ainda estou em estudo sobre mecanismos de full text search, como estou gostando do que estou vendo, venho falar sobre, neste post. Basicamente o Sphinx é um projeto de otimização de buscas do tipo texto em banco de dados com grande quantidade de conteúdos e registros, o MySQL possui um mecanismo interno de criação de índices tipo FULLTEXT, que ajudam muito em pesquisas tipo texto porém existem mecanismos como o Sphinx que trabalha de forma independente ao banco e possuem alta performance. Lendo o manual do Sphinx analisei as características e são realmente impressionantes: * Alta velocidade de indexação (Acima de 10 MB/se em CPUs modernas); * Alta velocidade de busca (Média da consulta abaixo de 0.1 segundo em 2 a 4GB de coleções de texto); * Alta escalabilidade (Acima de 100 GB de texto, acima de 100 Milhões de documentos em uma única CPU); * Suporta busca distribuída (a partir da versão 0.9.6); * Suporta MySQL nativamente (tabelas MyISAM e InnoDB são suportadas); * Suporta busca por frases; * Suporta ranking de proximidade de frases, provendo boa relevância; * Suporta Stemming em Inglês e Russo; * Suporta qualquer número de campos de documentos (pesos podem ser mudados “on the fly”); * Suporta grupos de documentos; * Suporta “stopwords”; * Suporta diferentes modos de busca (“match all”, “match phrase” and “match any” – desde a versão 0.9.5); * Interface genérica de XML com a qual é possível simplificar integrações customizadas; API cliente de busca - pure-PHP. Além disso o modo de pesquisa Full Text possui duas propriedades interessantes: Stopwords: São preposições e artigos como: a, o, para e um. Em inglês são palavra como “a, are, an, at, be, do, in, of, the e to”. Como são palavras que são muito repetidas em uma língua, os sites de busca acabam não indexando estas Stop Words. Com isto, a performance de uma página de resposta é muito melhor, pois são menos palavras no banco de pesquisa. Por isso, a inserção destas palavras no texto não faz muita diferença. (Fonte: www.marketingdebusca.com.br) Stemming: Stem: Origem. Stemming: Lingüisticamente, palavras seguem regras morfológicas que permitem a quem está falando derivar variantes da mesma idéia para evocar uma ação (verbo), um objeto ou conceito (substantivo), ou a propriedade de algo (adjetivo). Normalmente, é possível derivar palavras a partir da mesma origem e significado abstrato de ação e movimento. Stemming faz o processo reverso: ele deduz a origem (stem) a partir de uma palavra completamente sufixada de acordo com sua regra morfológica. Essas regras envolvem sufixos morfológicos e flexivos. (Fonte: http://blog.tink.com.br) Para baixar o Sphinx acesse http://sphinxsearch.com/. Bom é isso ai, Obrigado pela atenção Para mais assuntos relacionados a tecnologia, programação e SEO acesse http://vivendonaweb.blogspot.com/

Hoje venho posta sobre a maravilha dos índices em bancos de dados, e algumas dicas de performance. Coisas que não são levados em conta pelos desenvolvedores menos experientes em bancos, hoje serão comentadas neste post. Até pouco mais de 3 meses eu não sabia de coisas muito avançadas de banco de dados, visto que nunca precisei, porém com o projeto em que trabalho atualmente, nosso banco de dados trabalha com milhões de registros, tabelas gigantes e temos que agilizar a pesquisa ao máximo, mesmo tendo tantos registros, agora vou passa algumas dicas no qual tive que aprender sozinho com muita pesquisa, juntamente com meu amigo e chefe Davi Pozzi. Índices é a maravilha por trás dos bancos: Em vários testes, verifiquei que ao indexar campos com muitas requisições, o resultado apresentado em menos tempo(resultados consideráveis de redução), eu ainda não entendo o processo interno que os bancos fazem porém são eficientes. Evite usar o comando LIKE: Evite ao máximo utilização do comando LIKE pois ao pesquisar várias palavras separadas por % o SELECT pode fica muito demorado. A melhor solução para pesquisas em linguagem natural de várias palavras é utilizar Full Text Search, descrito abaixo. Nunca utilize * em consultas: Esta dica é extremamente valiosa, vou explicar por que. Os bancos de dados atuais utilizam um 'banco guias' para gerenciamento dos schemas(bancos de dados), no caso do MySQL todas as informações de databases, tabelas e campos são cadastrados em information_schema, quando você utilizar * o banco internamente precisa verificar no information quais os campos da tabela no qual deseja resultados, caso o SELECT tenha JOIN esse processo é feito para todas as tabelas, isso já diminui a performance, principalmente se o banco for compartilhar, onde deverá haver muitas informações no information_schema. Por isso fica a dica, é melhor declarar todos os campos que deseja retorna, NUNCA UTILIZE *. Conferências de strings grandes, utilize MD5: Caso haja necessidade de fazer uma comparação de string em algum momento do desenvolvimento é aconselhável criar um campo contendo o MD5 da string que deseja pesquisar, associar ao campo um índice do tipo HASH, e fazer comparação. Este processo irá diminui muito o tempo de resposta da query. É claro que este tipo de pesquisa somente é válida para valores que devem ser exatamente iguais, para pesquisa por referencia é necessário usar LIKE ou Full Text Search. Criar índices compostos em pesquisas com mais de um filtro: Caso haja verificações que utilizam mais de um parâmetro da tabela para filtro, é recomentado a criação de índices compostos pelos itens a serem filtrados, este processo melhora consideravelmente a pesquisa. Evite uso de JOIN, DISTINCT e GROUP BY: Evite ao máximo utilizar estes processos pois eles gastam muito recurso do servidor para executar em tempo razoável, principalmente o DISTINCT. Somente utilize índice UNIQUE em último caso: Os índices único são extremamente prejudiciais a performance da tabela visto que a cada INSERT o banco irá verificar todos os registros antes de inserir, por isso somente utilize-o em ultimo caso. NUNCA UTILIZE ESSE ÍNDICE EM TABELAS QUE SÃO MUITO PESQUISADAS. Abuse das FUNCTIONS e STORED PROCEDURE: Todo processo que puder ser feito pelo banco deve ser feito nele, as funções e procedimentos são bons pois: * São fáceis de alterar e não requer alteração no código fonte, que muitas vezes pode esta criptografado ou encodado. * O tempo de resposta do processamento de uma função com dados de banco são incrivelmente mais rápidos que em linguagens como PHP, ASP, Ruby e Java, visto que há necessidade de transmitir os dados para a linguagem para que haja o processamento. * Que as funções podem ser reaproveitadas em outras linguagens. Neste caso a dica é: Sempre utilize stored procedure e functions quando for possível. Tudo que exige muito tempo para processamento, utilize arquivo txt: Basicamente a dica é, tudo que requer mais de 2seg para executar, ou utilize processo distribuído, ou armazene a informações em TXT e crie Jobs para executar atualização deste arquivo, um exemplo deste tipo de abordagem é no site http://www.vigiadepreco.com.br, a quantidade de produtos cadastrados, e o total de lojas do sistema são armazenadas em arquivo texto e atualizada a cada 20min pelo Linux. Otimização da tabela: Toda tabela que possui índice, e que frequentemente altera ou deleta registros devem ser otimizadas, pelo menos um vez por semana, este processo é demorado e recomendado a ser feito durante a madrugada, no MySQL o comando para otimizar a tabela é OPTIMIZE TABLE. Full Text Search: Por ultimo a dica extraordinária do meu querido chefe(muito puxa saco não é? kkk). Basicamente este item fala sobre o índice tipo FULLTEXT do MySQL, este tipo de índice possibilita pesquisas de alto nível e alta performance em linguagem natural para campos tipo CHAR, VARCAHR ou TEXT, com isso não é necessário utilização de vários LIKE dentro do query, para mais informações acesse http://dev.mysql.com/doc/refman/4.1/pt/fulltext-search.html. Bom pessoal é isso, espero ter ajudado Para mais informações sobre tecnologia, programação e SEO acesse http://vivendonaweb.blogspot.com/ T+