Avaliação do serviço Amazon SES

O serviço Amazon SES cuida da entrega de mensagens, fazendo o papel de MTA.

Pelo que pesquisei, a MailChimp passou a usar este serviço para entrega.

A maior vantagem é a escala.

O serviço possui limites que são aumentados periodicamente.

No Blog Email Marketing Vodoo há o relato do aumento limite para 1 milhão por dia, em um mês de uso.

Descrição do serviço em português:

Preço:

1 dolar a cada 10 mil mensagens + o gasto de banda ( $0.12 por GB )

Testes e seus resultados

Os testes foram feitos usando a SDK da Amazon para PHP e executados a partir de uma máquina em rede simples. Naturalmente em um envio real, a rede será mais rápida, porém com envio maior de informações.

Resultado do teste de stress, texto plano:

Testes a partir de máquina local, com texto plano:

  • 40 envios
  • 30.124973058701 seconds
  • 0.75312432646751 seconds per message

Com envio a partir de uma máquina dentro do datacenter diminuiremos o tempo de rede porém aumentaremos a quantidade de informação do POST, o que deve permanecer nestes 4800 envios por hora, por processo.

Podemos abrir N processos por máquina, 115.200 envios/dia por processo.

Testes com envio simultâneo

Usando 20 processos simultâneos, 2000 envios em 1.4 minutos.

  • 1428 por minuto.
  • 85.680/hora
  • 2.056.320/dia

(Desde que exista a permissão Max Send Rate menor que 1 email/second)

Sobre os retornos de erro.

É informado se o email foi entregue com sucesso, mas não indica a qualidade da entrega. Não nos listam quais foram estes emails com sucesso.

As falhas são entregues por email, a partir de endereços específicos, como o bounce: [email protected]

Isto é ruim pois eu esperava poder recolher isso via API. Continua sendo necessário processar os retornos a partir de mensagens de email, e não a partir de uma inteligência da Amazon, semelhante ao serviço já prestado no Amazon SQS.

O relatório nos entrega apenas os números finais, o que é uma pena.

Discussões sobre esta necessidade, no Fórum

Conclusões

É um serviço muito bom, porém 3 vezes mais caro que a entrega a partir de um MTA próprio, sem grandes vantagens imediatas que justifiquem a migração, para aplicativos que já estão estáveis com o envio simples por MTA.

Se ainda não está implantando o know how sobre a entrega por MTA, aí sim é um ótima escolha, por não precisar de manutenção em um servidor de email próprio


Alternativas ao Amazon SES:


Exemplo de envio com PHP:

<?php

// Instantiate the class
$email = new AmazonSES();

$response = $email->send_email(
    '[email protected]', // Source (aka From)
    array('ToAddresses' => '[email protected]'), // Destination (aka To)
    array( // Message (short form)
        'Subject.Data' => 'Email Test ' . time(),
        'Body.Text.Data' => 'This is a simple test message ' . time()
    )
);

// Success?
var_dump($response->isOK());

Keep-Alive: Fazendo flush antes do término da execução, no controller do Symfony 2

No Symfony (1 e 2), a saída do controlador apenas é enviada após o processamento interno.

Para uma saída constante, em processos demorados, precisamos outra abordagem,

chamando o flush manualmente e seguindo o caminho Keep-Alive.

A necessidade

A CamelSpiderBundle possui um controller que executa a CamelSpider e isto pode demorar um pouco.

É necessário que exista uma saída informativa e uma negociação com o navegador para que não seja interrompida a exibição.

Solução: 

//….

    public function captureAction($id)
    {
        $response = new Response();
        $response->headers->set(‘Content-Encoding’, ‘chunked’);
        $response->headers->set(‘Transfer-Encoding’, ‘chunked’);
        $response->headers->set(‘Content-Type’, ‘text/html’);
        $response->headers->set(‘Connection’, ‘keep-alive’);
        $response->sendHeaders();
        flush();
        ob_flush();
        echo “<html><head><title>Capture</title></head><body><pre>”; 
        $this->get(‘camel_spider.launcher’)->checkUpdates($id);
         echo nnnn<b>Done</b>.”;
        echo “</pre></body></html>”;
        return $response;
    }
//…..
Você pode visualizar o arquivo completo aqui
Algumas informações relevantes:

Customizando as páginas de erro no Symfony 2

Existem várias formas de customizar as páginas de erro no Symfony 2,

mas uma maneira bem simples,

é sobrecarregar a view de erros da Twig,

criando o arquivo app/Resources/TwigBundle/views/Exception/error.html.twig:

https://gist.github.com/1402754

 

Lógico que esta sobrecarga de exibição é feita apenas no ambiente de produção,

e para testar suas alterações você precisa limpar o cache.

./app/console cache:clear –env=prod

 

 

A beleza da visualização de dados

David McCandless transforma conjuntos de dados complexos como gastos militares mundiais, media buzz, atualizações do Facebook e mais em bonitos ainda que simples diagramas. Ele propõe design de informação como a ferramenta que usamos para navegar através do excesso de informação de hoje, achando padrões únicos e conexões que podem mudar a maneira como vemos o mundo.

Inscrições abertas para o PHP’n Rio 2011

276458_160383237381004_2042319

Em sua terceira edição, o PHP’n Rio será realizado no dia 05 de Novembro de 2011 na cidade do Rio de Janeiro, RJ.

O evento é focado na linguagem PHP e seu ecossistema e será composto por duas trilhas de palestras, quatro minicursos e uma área de desconferência, onde os participantes terão a oportunidade de apresentar suas palestras relâmpago, e praticarem programação em sessões de Coding Dojo durante todo o evento.

Para mais informações acompanhe o site http://phpnrio.com.br