{"id":83188,"date":"2020-05-29T07:43:02","date_gmt":"2020-05-29T05:43:02","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/kak-my-perezhili-rezkij-rost-nagruzki-x10-na-udalenke-i-kakie-vyvody-sdelali"},"modified":"2020-05-29T07:43:02","modified_gmt":"2020-05-29T05:43:02","slug":"kak-my-perezhili-rezkij-rost-nagruzki-x10-na-udalenke-i-kakie-vyvody-sdelali","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/kak-my-perezhili-rezkij-rost-nagruzki-x10-na-udalenke-i-kakie-vyvody-sdelali","title":{"rendered":"Como enfrentamos um aumento repentino da carga de x10 no trabalho remoto e quais li\u00e7\u00f5es aprendemos","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ol\u00e1, Habr! Nos \u00faltimos dois meses, vivemos uma situa\u00e7\u00e3o muito interessante e gostaria de compartilhar nossa hist\u00f3ria sobre a escalabilidade da infraestrutura. Durante esse tempo, o SberMarket cresceu quatro vezes em pedidos e lan\u00e7ou o servi\u00e7o em 17 novas cidades. O crescimento explosivo na demanda por entrega de produtos exigiu que escal\u00e1ssemos nossa infraestrutura. Leia mais sobre as conclus\u00f5es mais interessantes e \u00fateis abaixo.<\/p>\n

\"Como
\n<\/a><\/noindex>
\nMeu nome \u00e9 Dima Bobylev, sou o diretor t\u00e9cnico do SberMarket. Como este \u00e9 o primeiro post em nosso blog, vou dizer algumas palavras sobre mim e sobre a empresa. No outono passado, participei do concurso de jovens l\u00edderes da Runet. Para a competi\u00e7\u00e3o, eu escrevi uma pequena hist\u00f3ria<\/a><\/noindex> sobre como vemos a cultura interna e a abordagem ao desenvolvimento do servi\u00e7o no SberMarket. E embora n\u00e3o tenha conseguido ganhar o concurso, pude formular os princ\u00edpios fundamentais para o desenvolvimento do ecossistema de TI. <\/p>\n

Ao gerenciar uma equipe, \u00e9 importante entender e encontrar um equil\u00edbrio entre o que o neg\u00f3cio precisa e as necessidades de cada desenvolvedor espec\u00edfico. Neste momento, o SberMarket est\u00e1 crescendo 13 vezes ano a ano, e isso impacta o produto, exigindo um aumento constante nos volumes e ritmos de desenvolvimento. Apesar disso, dedicamos tempo suficiente aos desenvolvedores para an\u00e1lise pr\u00e9via e escrita de c\u00f3digo de qualidade. A abordagem estabelecida ajuda n\u00e3o apenas na cria\u00e7\u00e3o de um produto funcional, mas tamb\u00e9m em sua escalabilidade e desenvolvimento futuros. Como resultado desse crescimento, o SberMarket j\u00e1 se tornou l\u00edder entre os servi\u00e7os de entrega de produtos: entregamos cerca de 18 mil pedidos por dia, embora no in\u00edcio de fevereiro estiv\u00e9ssemos na casa de 3.500.<\/p>\n

\"Como
\nCerta vez, um cliente pediu ao entregador do SberMarket que entregasse os produtos de forma sem contato \u2014 diretamente na varanda.<\/i><\/p>\n

Mas vamos aos detalhes. Nos \u00faltimos meses, temos trabalhado ativamente na escalabilidade da infraestrutura da nossa empresa. Essa necessidade foi explicada por fatores internos e externos. Ao mesmo tempo em que a base de clientes cresceu, o n\u00famero de lojas conectadas aumentou de 90 no in\u00edcio do ano para mais de 200 em meados de maio. Claro, est\u00e1vamos preparados, reservamos a infraestrutura principal e planejamos a possibilidade de escalabilidade vertical e horizontal de todas as m\u00e1quinas virtuais hospedadas na nuvem do Yandex. No entanto, a pr\u00e1tica mostrou: \"Tudo o que pode dar errado, dar\u00e1 errado\". E hoje quero compartilhar as situa\u00e7\u00f5es mais curiosas que ocorreram nessas semanas. Espero que nossa experi\u00eancia seja \u00fatil para voc\u00ea.<\/p>\n

Slave em plena prontid\u00e3o de combate<\/h3>\n

\nJ\u00e1 antes do in\u00edcio da pandemia, enfrentamos um aumento no n\u00famero de solicita\u00e7\u00f5es para nossos servidores de backend. A tend\u00eancia de solicitar produtos com entrega em casa come\u00e7ou a ganhar for\u00e7a, e com a implementa\u00e7\u00e3o das primeiras medidas de isolamento social devido ao COVID-19, a carga aumentava dramaticamente ao longo do dia. Surgiu a necessidade de descarregar rapidamente os servidores master do banco de dados principal e mover parte das solicita\u00e7\u00f5es de leitura para servidores-replica (slave).<\/p>\n

Nos preparamos para essa etapa, e para essa manobra j\u00e1 tinhamos 2 servidores slave em funcionamento. Neles, principalmente, eram executadas tarefas em lotes para a gera\u00e7\u00e3o de feeds de informa\u00e7\u00e3o para troca de dados com os parceiros. Esses processos criavam uma carga extra e, de maneira justa, foram exclu\u00eddos \"da conta\" alguns meses antes.\u00a0<\/p>\n

Como a replica\u00e7\u00e3o ocorria no Slave, seguimos a ideia de que os aplicativos poderiam operar com eles apenas em modo somente leitura. O plano de recupera\u00e7\u00e3o de desastres previa que, em caso de cat\u00e1strofe, poder\u00edamos simplesmente montar o Slave no lugar do Master e redirecionar todas as solicita\u00e7\u00f5es de grava\u00e7\u00e3o e leitura para o Slave. No entanto, tamb\u00e9m quer\u00edamos usar as r\u00e9plicas para as necessidades do departamento de an\u00e1lise, ent\u00e3o os servidores n\u00e3o foram totalmente transformados em status somente leitura, e cada host teve seu pr\u00f3prio conjunto de usu\u00e1rios, alguns com permiss\u00f5es de grava\u00e7\u00e3o para salvar resultados intermedi\u00e1rios dos c\u00e1lculos.<\/p>\n

At\u00e9 um certo n\u00edvel de carga, consegu\u00edamos usar o mestre tanto para grava\u00e7\u00e3o quanto para leitura ao processar solicita\u00e7\u00f5es http. Em meados de mar\u00e7o, exatamente quando o Sbermarket decidiu passar completamente para o remoto, come\u00e7amos a ter um crescimento exponencial de RPS. Cada vez mais clientes estavam se isolando ou trabalhando de casa, o que afetou os \u00edndices de carga.<\/p>\n

A performance do \u2018mestre\u2019 n\u00e3o foi mais suficiente, ent\u00e3o come\u00e7amos a transferir parte das consultas de leitura mais pesadas para a r\u00e9plica. Para direcionar as solicita\u00e7\u00f5es de grava\u00e7\u00e3o para o mestre e as de leitura para o slave, usamos a gem ruby \u201cOctopus<\/a><\/noindex>\u201d. Criamos um usu\u00e1rio especial com o sufixo _readonly, sem permiss\u00f5es de grava\u00e7\u00e3o. Por\u00e9m, devido a um erro na configura\u00e7\u00e3o de um dos hosts, parte das solicita\u00e7\u00f5es de grava\u00e7\u00e3o foi para o slave sob o nome de um usu\u00e1rio que tinha as permiss\u00f5es adequadas.<\/p>\n

O problema n\u00e3o se manifestou imediatamente, pois a carga aumentada fez com que os slaves ficassem atrasados. A inconsist\u00eancia de dados foi descoberta pela manh\u00e3, quando, ap\u00f3s as importa\u00e7\u00f5es noturnas, os slaves n\u00e3o \u201calcancaram\u201d o mestre. Atribu\u00edmos isso \u00e0 alta carga no pr\u00f3prio servi\u00e7o e \u00e0s importa\u00e7\u00f5es associadas ao in\u00edcio de novas lojas. No entanto, entregar dados com horas de atraso era inaceit\u00e1vel, ent\u00e3o mudamos os processos para o segundo slave anal\u00edtico, pois ele tinha mais recursos e n\u00e3o estava sobrecarregado com solicita\u00e7\u00f5es de leitura (o que explicamos a n\u00f3s mesmos como a aus\u00eancia de lat\u00eancia na replica\u00e7\u00e3o).maior<\/strong>Quando entendemos as raz\u00f5es do \u201cdesvio\u201d do slave principal, o anal\u00edtico j\u00e1 estava fora de servi\u00e7o pela mesma raz\u00e3o. Apesar de termos dois servidores adicionais, para os quais planejamos transferir a carga em caso de falha do mestre, devido a um erro lament\u00e1vel, no momento cr\u00edtico n\u00e3o havia nenhum deles.<\/p>\n

Mas, como est\u00e1vamos fazendo n\u00e3o apenas o dump do banco de dados (o restauro naquele momento levava cerca de 5 horas), mas tamb\u00e9m o snapshot do servidor mestre, conseguimos iniciar a r\u00e9plica em um prazo de 2 horas. No entanto, ap\u00f3s isso, ter\u00edamos que lidar com a aplica\u00e7\u00e3o do log de replica\u00e7\u00e3o por um longo per\u00edodo (porque o processo ocorre em modo de thread \u00fanica, mas isso j\u00e1 \u00e9 outra hist\u00f3ria).<\/p>\n

Mas, como n\u00e3o fizemos apenas o dump do banco de dados (a restaura\u00e7\u00e3o na \u00e9poca levava cerca de 5 horas), mas tamb\u00e9m um snapshot do servidor master, conseguimos iniciar a r\u00e9plica em 2 horas. Contudo, depois disso, enfrentamos o processo de aplica\u00e7\u00e3o do log de replica\u00e7\u00e3o durante um longo per\u00edodo (porque o processo ocorre em modo de thread \u00fanica, mas isso j\u00e1 \u00e9 uma hist\u00f3ria completamente diferente).<\/p>\n

Conclus\u00e3o:<\/strong> Ap\u00f3s esse incidente, ficou claro que precisar\u00edamos abandonar a pr\u00e1tica de restringir a grava\u00e7\u00e3o para os usu\u00e1rios e declarar todo o servidor como somente leitura. Com essa abordagem, n\u00e3o h\u00e1 d\u00favida de que as r\u00e9plicas estar\u00e3o dispon\u00edveis no momento cr\u00edtico.<\/p><\/blockquote>\n

<\/p>\n

A otimiza\u00e7\u00e3o at\u00e9 mesmo de uma \u00fanica consulta pesada pode \"reviver\" o banco de dados.<\/h3>\n

\nEmbora atualizemos constantemente o cat\u00e1logo do site, as consultas que realiz\u00e1vamos nos servidores Slave apresentavam um pequeno atraso em rela\u00e7\u00e3o ao Master. O tempo que levamos para identificar e resolver o problema dos \"slaves\" que \"deixaram a corrida\" foi maior do que o \"barreira psicol\u00f3gica\" (durante esse tempo, a atualiza\u00e7\u00e3o de pre\u00e7os poderia ter ocorrido, deixando os clientes vendo dados desatualizados), e fomos for\u00e7ados a redirecionar todas as consultas para o servidor principal do banco de dados. Como resultado, o site funcionou lentamente... mas pelo menos estava funcionando. E enquanto os Slaves se recuperavam, n\u00e3o tivemos escolha a n\u00e3o ser otimizar.\u00a0<\/p>\n

Enquanto os servidores Slave se recuperavam, os minutos se arrastavam lentamente, o Master permanecia sobrecarregado, e dedicamos todos os esfor\u00e7os para otimizar as tarefas ativas de acordo com a \"Regra de Pareto\": escolhemos as principais consultas que geravam a maior parte da carga e come\u00e7amos o ajuste. Isso foi feito em tempo real.<\/p>\n

Um efeito interessante foi que o MySQL, completamente carregado, respondia a mesmo a uma leve melhoria nos processos. A otimiza\u00e7\u00e3o de algumas consultas que representavam apenas 5% da carga total j\u00e1 mostrava uma redu\u00e7\u00e3o significativa na CPU. Como resultado, conseguimos garantir uma margem de recursos aceit\u00e1vel para o funcionamento do Master com o banco de dados e obter o tempo necess\u00e1rio para a recupera\u00e7\u00e3o das r\u00e9plicas.\u00a0<\/p>\n

Conclus\u00e3o:<\/strong> Mesmo uma pequena otimiza\u00e7\u00e3o permite que \"sobrevivamos\" \u00e0 sobrecarga por v\u00e1rias horas. Isso foi exatamente o que precisamos durante o tempo de recupera\u00e7\u00e3o dos servidores com r\u00e9plicas. A prop\u00f3sito, discutiremos o aspecto t\u00e9cnico da otimiza\u00e7\u00e3o das consultas em um dos pr\u00f3ximos posts. Portanto, assine nosso blog se isso lhe for \u00fatil.<\/p><\/blockquote>\n

<\/p>\n

Organize a monitoriza\u00e7\u00e3o da operabilidade dos servi\u00e7os parceiros.<\/h3>\n

\nN\u00f3s tratamos de pedidos de clientes e, por isso, nossos servi\u00e7os interagem constantemente com APIs de terceiros \u2014 que s\u00e3o gateways para envio de SMS, plataformas de pagamento, sistemas de roteamento, geocodificadores, servi\u00e7os da Receita Federal e muitas outras sistemas. E quando a carga come\u00e7ou a aumentar rapidamente, come\u00e7amos a enfrentar as limita\u00e7\u00f5es das APIs dos nossos servi\u00e7os parceiros, sobre as quais antes nem pens\u00e1vamos.<\/p>\n

Um excesso inesperado das quotas dos servi\u00e7os parceiros pode levar \u00e0 inatividade do seu pr\u00f3prio. Muitas APIs bloqueiam clientes que excedem os limites, e em alguns casos, o excesso de requisi\u00e7\u00f5es pode sobrecarregar a produ\u00e7\u00e3o do parceiro.\u00a0<\/p>\n

Por exemplo, em um momento de aumento no n\u00famero de entregas, os servi\u00e7os de apoio n\u00e3o conseguiam lidar com as tarefas de distribui\u00e7\u00e3o e defini\u00e7\u00e3o de rotas. Como resultado, t\u00ednhamos pedidos feitos, mas o servi\u00e7o que cria a rota n\u00e3o estava funcionando. \u00c9 preciso dizer que nossos logistas fizeram praticamente o imposs\u00edvel nessas condi\u00e7\u00f5es, e a intera\u00e7\u00e3o clara da equipe ajudou a compensar as falhas tempor\u00e1rias dos servi\u00e7os. Por\u00e9m, tal volume de pedidos n\u00e3o pode ser tratado manualmente de forma constante, e em algum momento estar\u00edamos enfrentando uma ruptura inaceit\u00e1vel entre os pedidos e sua execu\u00e7\u00e3o.\u00a0<\/p>\n

Uma s\u00e9rie de medidas organizacionais foi adotada, e o trabalho em equipe ajudou a ganhar tempo enquanto negoci\u00e1vamos novas condi\u00e7\u00f5es e aguard\u00e1vamos a moderniza\u00e7\u00e3o dos servi\u00e7os de alguns parceiros. Existem outras APIs que oferecem alta resist\u00eancia e tarifas exorbitantes em caso de alto tr\u00e1fego. Por exemplo, inicialmente us\u00e1vamos uma API de mapeamento conhecida para determinar o endere\u00e7o do ponto de entrega. Mas no final do m\u00eas, recebemos uma conta bastante elevada, quase 2 milh\u00f5es de rublos. Depois disso, decidimos rapidamente substitu\u00ed-la. N\u00e3o vou fazer propaganda, mas posso dizer que nossas despesas diminu\u00edram significativamente.
\n\"Como<\/p>\n

Conclus\u00e3o: <\/strong>\u00c9 absolutamente necess\u00e1rio monitorar as condi\u00e7\u00f5es de opera\u00e7\u00e3o de todos os servi\u00e7os parceiros e t\u00ea-las em mente. Mesmo que hoje pare\u00e7a que eles t\u00eam 'um grande espa\u00e7o', isso n\u00e3o significa que amanh\u00e3 n\u00e3o se tornem um obst\u00e1culo para o crescimento. E, claro, \u00e9 melhor negociar as condi\u00e7\u00f5es financeiras para aumento das demandas ao servi\u00e7o com anteced\u00eancia.\u00a0<\/p><\/blockquote>\n

<\/p>\n

\u00c0s vezes, acaba sendo que \"precisamos de mais ouro<\/a><\/noindex>\" (c) n\u00e3o ajuda<\/h3>\n

\nEstamos acostumados a \"gargalos\" no banco de dados principal ou nos servidores de aplicativos, mas ao escalar, problemas podem surgir onde menos se espera. Para a busca de texto completo no site, usamos o motor Apache Solr. Com o aumento da carga, notamos uma diminui\u00e7\u00e3o no tempo de resposta, e a carga do processador do servidor chegou a 100%. O que pode ser mais simples \u2014 vamos fornecer mais recursos ao cont\u00eainer com Solr.<\/p>\n

Em vez do ganho de desempenho esperado, o servidor simplesmente \"morreu\". Ele imediatamente carregou a 100% e respondeu ainda mais lentamente. Inicialmente, t\u00ednhamos 2 n\u00facleos e 2 GB de RAM. Decidimos fazer o que geralmente ajuda \u2014 proporcionamos ao servidor 8 n\u00facleos e 32 GB. Tudo ficou muito pior (como exatamente e por que \u2014 contaremos em um post separado).\u00a0<\/p>\n

Em poucos dias, descobrimos as sutilezas dessa quest\u00e3o e conseguimos um desempenho otimizado com 8 n\u00facleos e 32 GB de RAM. Essa configura\u00e7\u00e3o permite, at\u00e9 hoje, continuar aumentando a carga, o que \u00e9 muito importante, pois o crescimento n\u00e3o vem apenas pelo n\u00famero de clientes, mas tamb\u00e9m pela quantidade de lojas conectadas \u2014 em 2 meses, seu n\u00famero dobrou.\u00a0<\/p>\n

Conclus\u00e3o: <\/strong>M\u00e9todos padr\u00e3o como \"adicionar mais hardware\" nem sempre funcionam. Portanto, ao escalar qualquer servi\u00e7o, \u00e9 necess\u00e1rio entender bem como ele utiliza recursos e testar seu funcionamento antecipadamente em novas condi\u00e7\u00f5es.\u00a0\n<\/p><\/blockquote>\n

<\/p>\n

Stateless \u2014 a chave para escalabilidade horizontal simples.<\/h3>\n

\nNo geral, nossa equipe adota a abordagem conhecida: os servi\u00e7os n\u00e3o devem ter estado interno (stateless) e devem ser independentes do ambiente de execu\u00e7\u00e3o. Isso nos permitiu suportar o aumento da carga com uma simples escalabilidade horizontal. Mas t\u00ednhamos um servi\u00e7o exce\u00e7\u00e3o \u2013 um processador de longas tarefas em segundo plano. Ele lidava com envio de email e sms, processamento de eventos, gera\u00e7\u00e3o de feeds, importa\u00e7\u00e3o de pre\u00e7os e estoques, processamento de imagens. Ocorreu que ele dependia do armazenamento de arquivos local e estava em uma \u00fanica inst\u00e2ncia.\u00a0<\/p>\n

Quando o n\u00famero de tarefas na fila do processador cresceu (o que aconteceu naturalmente com o aumento do volume de pedidos), a performance do host que hospedava o processador e o armazenamento de arquivos se tornou um fator limitante. Como resultado, a atualiza\u00e7\u00e3o do sortimento e dos pre\u00e7os, o envio de notifica\u00e7\u00f5es para os usu\u00e1rios e muitas outras fun\u00e7\u00f5es cr\u00edticas ficaram paradas na fila. A equipe de opera\u00e7\u00f5es migrou rapidamente o armazenamento de arquivos para um armazenamento em rede semelhante ao S3, o que nos permitiu implantar v\u00e1rias m\u00e1quinas poderosas para escalar o processador de tarefas em segundo plano.<\/p>\n

Conclus\u00e3o: <\/strong>A regra Stateless deve ser seguida por todos os componentes sem exce\u00e7\u00e3o, mesmo que pare\u00e7a \"que aqui n\u00e3o teremos problemas\". \u00c9 melhor gastar um pouco de tempo organizando corretamente o funcionamento de todos os sistemas do que depois, na pressa, reescrever o c\u00f3digo e consertar o servi\u00e7o que est\u00e1 enfrentando sobrecarga.<\/p><\/blockquote>\n

<\/p>\n

7 princ\u00edpios para crescimento intenso<\/h2>\n

\nApesar da disponibilidade de recursos adicionais, durante o crescimento encontramos v\u00e1rios obst\u00e1culos. Nesse per\u00edodo, o n\u00famero de pedidos aumentou mais de 4 vezes. Atualmente, j\u00e1 estamos entregando mais de 17.000 pedidos por dia em 62 cidades e planejamos expandir ainda mais a geografia \u2014 no primeiro semestre de 2020, esperamos lan\u00e7ar o servi\u00e7o em toda a R\u00fassia. Para lidar com a crescente carga, levando em conta os erros que j\u00e1 cometemos, estabelecemos 7 princ\u00edpios fundamentais de funcionamento em condi\u00e7\u00f5es de crescimento constante:<\/p>\n

    \n
  1. Gerenciamento de Incidentes<\/strong>. Criamos um quadro no Jira, onde cada incidente \u00e9 refletido na forma de um ticket. Isso ajudar\u00e1 a priorizar efetivamente e a realizar tarefas relacionadas ao incidente. Afinal, a ess\u00eancia do problema n\u00e3o \u00e9 errar \u2014 \u00e9 errar duas vezes pela mesma raz\u00e3o. Para os casos em que os incidentes se repetem antes que a causa possa ser corrigida, deve haver um guia de a\u00e7\u00f5es preparado, pois durante uma alta carga \u00e9 importante reagir rapidamente.<\/li>\n
  2. Monitoramento <\/strong>\u00e9 necess\u00e1rio para todos os elementos da infraestrutura, sem exce\u00e7\u00e3o. Gra\u00e7as a ele, conseguimos prever o aumento da carga e escolher corretamente os \"gargalos\" para priorizar a resolu\u00e7\u00e3o. \u00c9 muito prov\u00e1vel que, em alta carga, tudo o que voc\u00ea nem pensou que poderia falhar ou come\u00e7ar a apresentar lentid\u00e3o. Portanto, \u00e9 melhor criar novos alertas logo ap\u00f3s os primeiros incidentes, para monitor\u00e1-los e antecip\u00e1-los.<\/li>\n
  3. Alertas corretos<\/strong> s\u00e3o simplesmente necess\u00e1rios em caso de aumento repentino da carga. Em primeiro lugar, eles devem informar exatamente o que quebrou. Em segundo lugar, n\u00e3o deve haver muitos alertas, pois a abund\u00e2ncia de alertas n\u00e3o cr\u00edticos leva \u00e0 ignor\u00e2ncia de todas as notifica\u00e7\u00f5es.<\/li>\n
  4. As aplica\u00e7\u00f5es devem ser stateless. <\/strong>N\u00f3s confirmamos que essa regra n\u00e3o deve ter exce\u00e7\u00f5es. \u00c9 necess\u00e1ria total independ\u00eancia do ambiente de execu\u00e7\u00e3o. Para isso, voc\u00ea pode armazenar dados compartilhados em um banco de dados ou, por exemplo, diretamente no S3. E ainda melhor \u00e9 seguir as regras https:\/\/12factor.net<\/a><\/noindex>. Durante um aumento repentino, n\u00e3o h\u00e1 tempo para otimizar o c\u00f3digo, e voc\u00ea ter\u00e1 que lidar com a carga aumentando diretamente os recursos de computa\u00e7\u00e3o e escalonamento horizontal.<\/li>\n
  5. Cotas e desempenho de servi\u00e7os externos. <\/strong>Com o crescimento r\u00e1pido, o problema pode surgir n\u00e3o apenas na sua infraestrutura, mas tamb\u00e9m no servi\u00e7o externo. O mais frustrante \u00e9 quando isso ocorre n\u00e3o por falha, mas devido ao alcance de cotas ou limites. Portanto, os servi\u00e7os externos devem escalar t\u00e3o bem quanto voc\u00ea.\u00a0<\/li>\n
  6. Separe os processos e filas. <\/strong>Isso ajuda muito quando ocorre um congestionamento em um dos gateways. N\u00e3o ter\u00edamos atrasos na transmiss\u00e3o de dados se as filas de envio de SMS cheias n\u00e3o interferissem na troca de notifica\u00e7\u00f5es entre os sistemas de informa\u00e7\u00e3o. E o n\u00famero de trabalhadores seria mais f\u00e1cil de aumentar se eles trabalhassem separadamente.<\/li>\n
  7. Realidades financeiras.<\/strong> Quando h\u00e1 um crescimento explosivo dos fluxos de dados, n\u00e3o h\u00e1 tempo para pensar em tarifas e assinaturas. Mas \u00e9 preciso lembrar deles, especialmente se voc\u00ea for uma pequena empresa. Uma grande conta pode ser cobrada por qualquer propriet\u00e1rio de API, assim como pelo seu provedor de hospedagem. Portanto, \u00e9 importante ler os contratos com aten\u00e7\u00e3o.<\/li>\n<\/ol>\n

    <\/p>\n

    Conclus\u00e3o<\/h2>\n

    \nSem grandes perdas, superamos essa fase e hoje nos esfor\u00e7amos para seguir todos os princ\u00edpios encontrados, com cada m\u00e1quina tendo a capacidade de aumentar seu desempenho em at\u00e9 4 vezes, para lidar com algumas surpresas inesperadas.\u00a0<\/p>\n

    Nos pr\u00f3ximos posts, compartilharemos nossa experi\u00eancia em investigar a queda de desempenho no Apache Solr, al\u00e9m de falarmos sobre a otimiza\u00e7\u00e3o de consultas e como a intera\u00e7\u00e3o com a FNS ajuda a empresa a economizar dinheiro. Siga nosso blog para n\u00e3o perder nada e nos conte nos coment\u00e1rios se voc\u00ea j\u00e1 enfrentou problemas semelhantes durante o aumento de tr\u00e1fego.<\/p>\n

    \"Como<\/p>\n

    Apenas usu\u00e1rios registrados podem participar da pesquisa. Entre<\/a><\/noindex>, por favor.<\/p>\n

    Voc\u00ea j\u00e1 experimentou lentid\u00e3o\/queda de servi\u00e7o devido a um aumento repentino de carga por causa de:<\/h2>\n