Erick Patrick

Tunando o Ambiente de produção PHP no IIS

Aprenda a dominar essa monstro de sete cabeças e torná-lo seu animal de estimação

Que o habitat natural do PHP são os ambientes *nix, todos nós sabemos. Contudo, há empresas que, por possuírem seu principal produto, serviço ou aplicativo rodando num stack Microsoft, não é incomum vermos o PHP rodando em servidores IIS.

Geralmente, isso acontece por essas empresas decidirem usar a plataforma de gerenciamento de conteúdo (cms) WordPress, como base para seus sites. Essa escolha se dá pela facilidade de uso e customização, além da grande quantidade de programadores que desenvolvem para WordPress, tanto brasileiros quando estrangeiros.

Após tomarem essa decisão e colocarem o site em produção, eles percebem que ele não aparenta estar tão performático quanto poderia estar. Algumas empresas aceitam essa performance, em troca da facilidade do uso e gerenciamento proporcionados pelo sistema, porém, outras não aceitam.

Essas outras costumam ter acessos nas casa das dezenas de milhares, às vezes, centenas de milhares ou mesmo milhões de acessos. Elas precisam otimizar o ambiente e o sistema da melhor forma possível.

É por isso que esse post foi criado. Embora não seja específico para WordPress, grande parte do conhecimento presente nesse post se deve à busca de otimização de um ambiente IIS+PHP rodando WordPress. No entanto, ele deve servir para qualquer outro sistema, além do WordPress.

VM exclusivas para cada sistema

Não misture seu site com seu sistema financeiro, com seu sistema ERP, com a base de dados em um único servidor/máquina virtual.

Por mais que eles sejam bastante integrados, tentar desacopla-los é uma das melhores coisas que você pode fazer para sua sanidade e vida útil de suas aplicações e servidores.

Se, por alguma motivo, alguma das aplicações precisar atualizar alguma dependência, não precisará se preocupar se essa dependência não afetará outros sistemas. Tome, sempre, muito cuidado.

Instale o Web Platform Installer (Web PI)

A primeira coisa que você deve fazer, é usar o gerenciador do IIS e instalar o Web Platform Installer. Além de ser pequeno (apenas 2Mb), ele permite que você obtenha os aplicativos necessários para rodar suas aplicações da maneira mais fácil possível: Busca e clicar para instalar.

Com ele, é possível instalar o PHP, o IIS, o WordPress e inúmeras outros itens (inclusive, outros que estão presentes nesse post) sem suar. Não deixe de instalá-lo.

Instale o PHP em modo fast_cgi

Quando for buscar o PHP para instalar através do Web PI, a não ser que sua aplicação encontre alguma incompatibilidade, dê preferência pela versão mais recente, que, até o momento desse post, é a 5.5.8.

Geralmente, o Web PI se encarrega em instalar o PHP em modo fast_cgi e configurar o arquivo php.ini automaticamente, para que você não precise se preocupar (não disse que seria sem suar?).

Entretanto, já me deparei em 2 situações que isso não aconteceu. Então, rode o famoso phpinfo() para saber as informações da instalação e certifique-se do modo sendo usado.

Utilizar esse modo (fast_cgi) ajuda a diminuir a sobrecarga do servidor durante as requisições e processamentos em relação ao PHP.

Cuidados com o PHP

Dependendo da framework utilizada, é preciso realizar testes para que nenhum problema ocorra com as versões mais recentes. No meu caso, por exemplo, em que tenho algumas aplicações em Laravel 3, ao atualizar para a versão v5.5.x do PHP, as aplicações deixaram de funcionar.

Depois de muito bater cabeça e de muita leitura, descobri que era pelo fato do PHP 5.5.x e do LAravel estarem em choque com relação a nomenclatura de funções. Mais precisamente, a função yield, adicionada ao PHP “recentemente”.

Como o Laravel 3 não é mais suportado, tive de mexer no core do mesmo para resolver o meu problema. Então, se possível, façam testes, nem que seja usando aplicativos como WAMP, para testar suas aplicações.

USE PDO

A principal vantagem de escrever suas funções de acesso a base de dados, com PHP, usando PDO, é que você, basicamente e praticamente, fica agnóstico em relação ao banco usado, bastando alterar a linha de conexão e, talvez, uma ou outra função específica que só é suportado pelo SQL usado por um dado banco.

Dessa forma, se você está usando MySQL no IIS e quer passar a usar SQL Server, para poder integrar alguns dados do seu sistema com os dados de algum sistema de terceiros (como o WordPress), utilizar o PDO lhe poupará inúmeras horas.

Fora isso, você tem a vantagem de ser uma API mais robusta, orientada a objetos, com possibilidade de transações, parâmetros associados (bound parameters), suporte e muitos outros pontos que, para você saber, pode acessar a página do PDO.

Habilite PDO_SQLSRV.dll

É bem possível que, mesmo depois de instalar o SQL Server, você tenha de habilitar a PDO_SQLSRV.dll no php.ini.

Ao invés de mexer manualmente no arquivo para habilitá-lo, acesse o painel do IIS e procure o gerenciador do PHP (que é instalado, automaticamente, no procedimento de instalação do PHP) e procure por bibliotecas/libraries e procure pela DLL em questão e habilite-a. Depois disso, reinicie o serviço e você poderá usar PDO com o SQL Server.

Até agora, apesar de já ter a versão 5.5.8 do PHP para instalar através do Web PI, ainda não tem uma versão da DLL do SQL Server, mantida pela Miscrosoft, para instalar por lá, impedindo que você se conecte com esse banco.

Então, é possível que você precise baixar a versão da comunidade, disponível nesse tópico desse fórum. Descompacte o arquivo Rar e procure o diretório de instalação do PHP (ficará dentro do diretório de serviços do IIS). Procure pela pasta ext e cole os arquivos lá. Depois disso, torne a voltar ao gerenciador do PHP, na parte de bibliotecas e procure pela biblioteca recém colocada. Habilite-a e reinicie o serviço.

Habilite o Fileinfo.dll

Várias frameworks PHP atuais utilizam-se do módulo FileInfo para descobrir quais os tipos de arquivos e a (melhor) codificação para os mesmos. A Laravel é uma delas, por exemplo, e descreve em sua página, que o módulo FileInfo esteja ativado.

Porém, no Windows/IIS, esse módulo vem como uma DLL e desabilitada. Felizmente, ela já está presente na pasta ext do PHP e com uma versão própria para o PHP que for instalado. Só é preciso habilita-la. Mais uma vez, utilize o painel de gerenciamento do PHP para faze-lo e depois reinicie o serviço.

Instale e use WinCache.dll

O IIS permite a instalação de um sistema de cache bem interessante e que interage muito bem com o PHP, esse é o WinCache. Ele já está disponível para a versão mais recenete do PHP, inclusive.

Para você ter uma ideia, quando recém lançamos o novo site da instituição, feito em WordPress, o tempo para a primeira resposta do servidor estava muito alto, beirando os 800ms. Em dados momentos, chegava aos 1000ms (sim, 1s para a primeira resposta do servidor).

Para o dia-a-dia, esse valor já é muito alto (o recomendado é 200ms ou menos), imagine em momentos de pico, quando temos 5~10x o tráfego normal?

Resolvemos instalar o WinCache, e, após instalá-lo, sem configurá-lo, só com os valores padrões, conseguimos baixar esse valor para uma média de 400ms. Um ganho tremendo, diga-se. Contudo, não estávamos satisfeitos e fomos atrás de bater os 200ms.

Vasculhamos várias páginas em busca de maiores informações e descobrimos alguns truques. O primeiro deles, desabilite a opção wincache.fcndetect no php.ini. Essa opção, quando ativada, verifica, em todas as requisições, se houve mudanças nos arquivos para que possam ser gerados novos opcodes, gerando uma sobrecarga desnecessária. Logo após desabilita-la, verificamos tempos médios de 325ms. Outro ganho muito bom.

Também mudamos outra configuração: fizemos com que o PHP utilize um arquivo chamado reroute.ini, criado pelo WinCache, que permite que algumas funções nativas de leitura e escrita de arquivos e de memória do utilizadas pelo PHP sejam “reescritas” para utilizar códigos masi eficientes.

Quanto menor o tempo de resposta, mais difícil se torna em diminuir o tempo da primeira resposta. Mas, ao habilitar essa opção, saímos dos 325ms de tempo de resposta para uma média de 25ms!! Incrível!

Há um porém: Alguns aplicativos PHP (como algumas Wikis) utilizam-se de certos comportamentos de algumas dessas funções nativas que são “reescritas” e deixam de funcionar. Por isso, mais uma vez, sempre façam testes antes de lançar em produção.

Um outro problema que percebemos, ao utilizar o WinCache, se não mudarmos duas configurações (wincache.chkinterval e wincache.ttlmax) para valores bem próximos ao mínimo, os opcaches não se atualizam frequentemente para páginas parâmetos GET. Isso, em algumas ocasiões pode dar muito estresse e dor de cabeça.

Avalie se suas aplicações não sofrerão quaisquer consequências drásticas pelo uso do WinCache. Se você verificar que não há nada determinante afetado, utilize-o. Você só tem a ganhar.

Tudo isso posto, acredito que você terá um ambeinte de produção bastante performático. Porém, essas dicas não servirão de muita coisa se você não otimizar suas aplicações, tanto no front-end quanto no back-end.

É aquela máxima: De que serve ter pistas lisinhas, como as alemãs autobans, se você tem, no máximo, uma motoca que alcança seus 60km/h? Não dá, não é?

Até as próximas dicas.