Desempenho do banco de dados 50% melhor e mudança para o Mailgun.com

Após algumas semanas lançando novos recursos relacionados a webhooks muito solicitados, trabalhamos em algumas coisas menos visíveis para manter o Mailgun sempre atualizado para você. Especificamente, reduzimos o número de consultas por segundo em nossa instância principal do MongoDB em 50%, aumentando o desempenho do Mailgun e facilitando o dimensionamento conforme crescemos. Agora estamos operando com apenas 10% da nossa capacidade máxima e conseguimos lidar tranquilamente com picos gigantescos de tráfego, que estamos vendo cada vez mais à medida que crescemos, sem um aumento perceptível na latência. Também redirecionamos todos os vestígios do mailgun.net em nossa documentação e painel de controle para o mailgun.com, acelerando futuros esforços de desenvolvimento.

Nesta semana, trabalhamos para tornar os bancos de dados principais do nosso aplicativo mais eficientes. Quando os clientes enviam e recebem e-mails pelo Mailgun, nosso MongoDB principal é consultado constantemente. No entanto, os bancos de dados não são dimensionados infinitamente, por isso, estamos sempre buscando melhorar o desempenho e fazer mais com menos.

Ao examinar as consultas recebidas no MongoDB, percebemos que se usássemos o Redis para armazenar um valor específico em cache (o Redis é excelente para cache), conseguiríamos reduzir drasticamente o número de consultas. Dê uma olhada neste gráfico de um período imediatamente antes e depois da implementação do cache. Conseguimos reduzir o número médio de consultas por segundo de 13.000 a 15.000 (com picos de 20.000 ou mais) para 4.000 a 6.000. Isso significa que podemos lidar de modo mais fácil com os enormes picos de e-mails enviados por nossos queridos clientes.

É um fato pouco conhecido (principalmente porque nunca nos perguntaram!) que, quando o Mailgun foi lançado, o mailgun.com não estava disponível. Assim, começamos com o mailgun.net como nosso domínio principal, comprando o TLD .com apenas posteriormente. Operar dois domínios diferentes — mailgun.com para nosso site principal e mailgun.net para nossa documentação e painel de controle, além da API — tem sido um grande incômodo e era confuso para os clientes. Tarefas simples, como implementar o Google Analytics para rastrear o uso do produto, tornaram-se excessivamente complicadas, exigindo código extra para rastrear as ações mais básicas sobre nosso produto. Isso torna difícil entender o que os clientes gostam no Mailgun e o que não gostam. E, o mais importante, tira o tempo de engenharia de todas as coisas que os clientes pedem. Que isso sirva de lição para todas as startups por aí: escolha um domínio e continue com ele! Caso contrário, você vai batalhar constantemente para entender o que seus usuários estão fazendo em seu aplicativo. O rastreamento de vários domínios nunca é tão fácil quanto fazem você acreditar.

Quando começamos a analisar essa migração, era assim que queríamos que o código do redirecionamento 301 de todas as páginas .net para a página .com equivalente ficasse (precisávamos fazer um redirecionamento 301 para que o Google e outros mecanismos de pesquisa repassassem o valor do link acumulado ao longo dos anos — é uma questão de SEO):

                                

                                    server {  
    listen       80;
    server_name  ~^.*$;

    charset utf-8;

    location / {
        rewrite ^ http://mailgun.com$request_uri? permanent;
    }
}
                                
                            

No entanto, devido à forma como o Mailgun foi estruturado, havia vários casos extremos a serem tratados e as coisas ficaram complicadas. Em vez de fazer uma gambiarra e passar para a próxima tarefa, decidimos reestruturar a forma como os usuários interagem com o Mailgun pelo nosso site e API, reduzindo o número de partes móveis e diminuindo a probabilidade de introduzir algum erro no qual não havíamos pensado. Mas não queríamos que os usuários tivessem que fazer nada, nem mesmo alterar seus favoritos, muito menos seu código

Desde que nos juntamos à Rackspace em agosto de 2012, recebemos vários brinquedos muito legais para brincar, incluindo os Dell R720s que executam nossos principais processos de API & SMTP (esta fera de servidor merece um post inteiro no blog e esperamos escrever isso em breve). Também testamos o Rackspace Cloud e decidimos dividir o Mailgun em duas partes como parte de nossa refatoração.

• Os processos de front-end, como o site, o painel de controle e a documentação, são executados no Rackspace Cloud Servers, por trás de um Rackspace Cloud Load Balancer, para facilitar muito o dimensionamento. A adição de novos nós requer apenas algumas chamadas simples de API.
• Os principais processos de back-end, como API e SMTP, são executados em Dell R720s atrás de um balanceador de carga F5 (esperamos visitar o data center da Rackspace no meio do ano, onde essas máquinas estão, para nos rendermos ao seu poder absoluto).

Estruturar o Mailgun dessa forma nos permitiu reduzir as configurações do nginx de 393 para 261 linhas de código. Não é uma melhoria nada má. Sentiremos sua falta, mailgun.net, mas ainda nos veremos ao usar a API, que permanecerá em

https://api.mailgun.net/v2

Por esta semana é só, pessoal.

Fique de olho na próxima semana, quando falaremos sobre mais algumas das coisas em que estivemos trabalhando.

Bons envios de e-mail.

Os Mailgunners

Autor: The Sinch Mailgun team The Sinch Mailgun team shares news, best practices, and strategies to take your products and apps to the next level using email. Subscribe to our newsletter to get all the articles in your inbox!