Passei as últimas semanas trabalhando com o Magento, líder do mundo dos e-commerces. Em um cenário distribuído em cloud, tentando assim obter o máximo de performance, escalabilidade e o mínimo de custos, obtive algumas experiências que vou compartilhar hoje.
Utilizando serviços da AWS como EC2 + ELB, S3 bem como algumas dicas sobre como colocar o Magento em um cenário distribuído, o resultado ficou bem bacana.
Colocando suas imagens em um CDN
Um dos primeiros desafios foi passar as imagens dos produtos em catálogo para um CDN. No meu caso era o Simple Storage Service da Amazon, o S3 com o CloudFront. Pra quem não conhece, o funcionamento do S3 é bem simples: você cria um bucket (ganhando assim uma url pública), coloca seus arquivos lá dentro e paga alguns míseros centavos de dólar por GB utilizado por mês.
No Magento, você pode até configurar a base url dos arquivos estáticos de CSS, imagens e JS utilizados no template, por exemplo, para apontar para um CDN. Entretanto, nativamente não existe nada ligar as imagens de cache dos produtos em seu catálogo ao seu CDN.
Assim, eu utilizei uma extensão bem útil chamada OnePica, a extensão funciona muito bem.
Além do S3, a extensão permite você colocar suas imagens no Coral CDN, Rackspace Cloud Files e qualquer CDN, servidor ou serviço que suporte FTP, FTPS, ou SFTP.
Problema com diretório Media
Um problema quando se distribuí o Magento em várias instâncias é com relação ao diretório media, na raíz da app. Basicamente, o Magento usa o diretório media para guardar alguns css e js gerados on the fly. Aliás, ele guarda as imagens originais dos produtos em catálogo em disco também – e neste último item encontrei um grande problema.
Mesmo utilizando o OnePica, ainda assim o Magento necessita ter as imagens dos produtos no diretório media. Aparentemente é por lá que ele sabe se a imagem existe ou se ele deve usar um placeholder. Outro seja: mesmo que a imagem esteja perfeitamente no seu bucket S3 ou qualquer outro CDN, sem a imagem original no diretório media, você terá problemas.
Levando em consideração que você tem várias instâncias do web server, não da pra saber em qual delas o Magento irá guardar a imagem do seu produto. Para isso, de cara temos duas soluções:
- Porca e barata: No administrador, indo em Sistema > Configuração > Avançado > Sistema, você terá o formulário Armazenamento de Configuração de Media. Nesta opção você poderá trocar o local de armazenamento de mídia do arquivo físico para o banco de dados. Note que fazendo isso facilmente você terá problemas de performance dependendo da quantidade de produtos x concorrência que seu e-commerce tiver.
- Minimamente aceitável: criar um diretório compartilhado via NFS (ou algo parecido) entre as instâncias e transformar o diretório media em um link simbólico para lá. Tenho usado esta última opção e o Magento tem se comportado bem até então.
Passando a sessão para Banco
Este item é moleza e não tem segredo: abra o xml app/etc/local.xml e troque o <session_save><![CDATA[files]]></session_save> para <session_save><![CDATA[db]]></session_save> .
Além de ser fácil configurar, há quem afirme que o Magento trabalha mais rápido com a sessão em banco do que em disco. Duvido, mas fica a observação.
SSL usando Load Balancer
Quem já configurou urls usando o administrador do Magento viu que é fácil habilitar a url segura: só colocar o base url na sessão HTTPS dentro de Sistema > Configuração > Web.
O pórem é que se você tiver um balanceador de carga na frente (onde você configurará o certificado SSL), o Magento pode se perder e entrar em redirect loop nas áreas onde ele precisa usar a url segura. O motivo disso é bem simples: o Magento espera que as váriaveis de ambiente $_SERVER['HTTPS‘] e $_SERVER['SERVER_PORT'] estejam devidamente preenchidas, o que não acontece quando você faz foward do load balancer para as instâncias.
Para resolver isso, eu fiz o seguinte: no arquivo index.php, na raíz do Magento, adicione as seguintes linhas antes do Mage::run :
if( isset($_SERVER['HTTP_X_FORWARDED_PROTO']) ) {
$_SERVER['HTTPS'] = 'on';
$_SERVER['SERVER_PORT'] = 443;
}Embora em alguns cenários isso seja um tiro no pé com relação a segurança da sua app, em um ambiente dedicado, fechado e seu (como acontece no AWS), não será um grande problema.
Disparo de E-mails
É bem provável que para um ambiente distribuído e balanceado, você não queira ficar enviando e-mails usando um mero sendmail local da vida – isso sem contar que como os IPs da EC2 estão queimados nos filtros de spam por conta de alguns spammers sem mãe, o que torna necessário isolar os disparos de e-mails em algo mais apropriado.
Para quem precisa disparar uma massa considerável de e-mails , serviços como o Amazon SES talvez sejam uma opção interessante. Para outros casos, é possível que um simples SMTP autenticado resolva sua situação.
No meu caso, utilizei o próprio SMTP disponibilizado pelo Google Apps/Gmail. Para isso instalei uma outra extensão no Magento chamada ASchroder SMTP Pro Email, que permite parametrizar sua forma de disparo de e-mails, além de permitir fazer log de todos os emails disparados.
Dica: uma vez instalada, você pode acessá-la indo em Sistema > Configuração > Avançado > Sistema. Configure sua forma de disparo de e-mails (Google Apps/Gmail, SMTP, Amazon SES), salve e depois sete a extensão de email para a forma que você escolheu (Choose extension option).
Performance, performance e performance.
O Magento pode não ser o open source mais amado do mundo, mas mesmo entre aqueles que não gostam tanto algo não pode ser negado: ele é o líder do mercado de e-commerces. É o que possui mais features (muitas delas gratuitas) e a maior comunidade. Porém algo assim não fica de graça: com tanta coisa, não é de hoje que ele conquistou a fama de ser lento.
Dicas
Felizmente existem várias formas que você tornar o Magento em uma plataforma extremamente rápida. Não vou entrar muito fundo nas questões de tuning por que isso merece um post per si, mas vou levantar as seguintes questões:
- Habilite o cache nativo do Magento: fácil e indolor, basta entrar no admin e ligar todos os caches dentro de Sistema > Gerenciamento de cache.
- Faça merge dos arquivos CSS e JS: diminua o numero de requisições causados por arquivos JS e CSS, indo em Sistema > Configuração > Avançado > Desenvolvedor, colocando como sim as opções de Mesclar arquivos JavaScript e Mesclar arquivos CSS
- Habilite o mod_deflate do seu Apache para a transmissão dos arquivos compactados do seu servidor web para os navegadores.
- Use um acelerador de PHP como XCache, APC, ionCube, entre muitos outros. Os mais esperançosos acreditam reduzir em até 70% o tempo de execução PHP.
- Habilite o KeepAlives do Apache. Com isso, basicamente o Apache vai permitir conexões persistentes usando TCP. Isso pode acelerar seu tempo de latência para arquivos HTML com várias imagens, css, js, etc. Existem alguns contras neste tipo de abordagem, para ver mais clique aqui.
- Melhore a performance do seu MySQL. Um dos vários métodos é aumentando seu Query Cache.
- Fique de olho nas métricas: cada ms ganho, um passo dado. Para isso use ferramentas como Browsermob para checar como anda seu load time. O objetivo é simples: seja mais rápido que a concorrência. Sempre.
