O documento discute as ações tomadas por uma grande varejista para modernizar sua plataforma WebForms legada e manter a compatibilidade, enquanto garante o negócio. Eles migraram parcialmente para uma nova plataforma, mas tiveram problemas de desempenho que exigiram rollbacks. Análises posteriores identificaram problemas de arquitetura e código, como uso inadequado de recursos e paralelismo. Estratégias como Redis e cache melhoraram o desempenho após correções.
4. O Grande Desafio...
Inovar o ecommerce, mantendo
conversão de clientes e vendas
Aumentar performance, sem aumentar o
consume de vCPUs, Memória e I/O de
disco e Rede
Reutilizar o checkout? Usaram Api, Não?
Não!!! Aumento da curva de aprendizado
do time !!!
Backoffice, onde fica nisso tudo?
Inovar aplicando os conceitos web de
SEO, WPO (Web Presentation Optimized)
Estratégia da Convivência
5. Como estava o cenário?
Cenário caótico e com várias definições
de negócio divergentes
Aplicação com várias falhas de
desenvolvimento e lógica
Descrédito sobre a utilização do REDIS.
Porquê? Qual foi a outra solução?
Não havia servidores de Testes
integrados e Staging (Pré-Produção)
Tudo baseado no AspNet Cache, serviço
windows, entreypoint único para
atualização do cache, tudo num único
Application Pool
NGINX desatualizado e mal configurado
Sem Rumo = CAOS
6. Ações planejadas
TDD + MTM
DDD ? Sim, para alguns casos!
Entityframework? Sim, usamos !
Implementação de técnicas de WPO
Implementação de carregamento assincrono dos Assets: Javascript e
CSS
Implementação de recomendações de SEO
Continuar com AspNet Cache? Porquê? Quais ganhos? Quais
perdas?
Grande inclinação para utilizar o REDIS
Servidores de Testes e Staging
Teste de Carga
Atualização do Nginx e Revisão de suas configurações
Refatoração e adequação do Backoffice
Colocando cada coisa em seu lugar…
7. Migrar 100% não seria o caminho?
Esse seria o caminho…
Não daria para entregar o
projeto completo, em tempo
hábil. (4 meses)
Morte do Projeto e Desgaste dos Desenvolvedores
10. O que aconteceu ao subir as novidades da
Nova Plataforma?
ROLLBACK por 3X
Porquê?
Consumo altíssimo das vCPUs
Consumo altíssimo de Memória
Alto indice de I/O nos Web Servers
Mas onde estavam os problemas? Ação HARD...
E…
Só tinhamos mais uma chance, final de
Setembro/2015! E fizemos um novo Deploy
11. Nem tudo são flores…
Lock de objetos implementados inadequadamente
Implementação LINQ utilizando vários .Includes
Stored Procedures mal implementadas Lockando registros
Paralelismo utilizado inadequadamente
Problemas de performance na aplicação REDIS, pagando o
preço por estrégias inadequadas
Tivemos que abrir mão dos testes de unidade já iniciados
(Diante de alguns rollbacks, não tinhamos tempo para
“desperdiçar” com TDD – Doce ilusão)
Retorno do filho pródigo: AspNet Cache !!!
12. O que houve com o Redis?
Armazenamento mal planejado
Estratégia das chaves-valor sem lógica e fora
dos padrões recomendados
Throughput muito alto de rede (Tráfego de
um grande volume de objetos em
requisições simples)
Mas o REDIS não resolve cenários de alta
performance?
Retorna, assim, o AspNet Cache!!!
Vejo sinais de Code Smell
14. Como ficou ao de subir as novas
implementações da Nova Plataforma?
15. Overload de CPU?
107% em algumas CPUs
O que levou a esse cenário?
Utilização de recursos de programação de forma inadequada
Paralelismo em consultas LINQ
Lock em blocos de código, segurando outras requests a executarem o código
Pagamento da dívida de ter removido os Testes de Unidade
Várias requests e consultas sendo executadas pela aplicação, para a mesma informação
Iterações em 10k+ registros aplicando operações com strings com Regex
16. O que tivemos que analisar?
Dump de memória de Produção e Homologação
Aplicação de filtros e indicadores para análise de performance através do PerfMon
Aplicação do Dump de memória ao Debug Diagnostic Tools
21. Estratégias utilizadas
Análise do fluxo do negócio
Análise sobre a utilização das informações e grau de mudança das informações no site
Levantamento sobre qual navegabilidade o usuário esperava do portal
Chaveamento das informações por departamento, dentro do portal
Aplicação do conceito Get-Fetch (Buscar e Carregar)
Aplicação de filtros de dados dentro nas estruturas de dados no Redis
Implementação dos servidores do Redis no mesmo barramento de Rede dos WebServers
28. Conclusão
1. Realize SEMPRE uma Análise sobre as expectativas do seu cliente.
Frustra-las será seu pior fracasso.
2. Busque SEMPRE inovar, com MODERAÇÃO.
NÃO utilize tudo de novo que o Mercado oferece, nem tudo se encaixa com suas necessidades.
3. Entenda o perfil do seu time.
Você será o principal fator para seu time performar
4. Mesmo tomando todos os cuidados, tenha ferramentas, estratégias e conhecimento para sanar os problemas.
Caso contrário, um pequeno ponto no código poderá levar seu projeto ao fracasso.
5. Fique sempre antenado no Mercado e busque aplicar as melhores práticas.
Elas normalmente te encaminharam para o sucesso do seu projeto, motivação do seu time e garantia de um cenário mais
controlado.
6. Trabalhem bem sua arquitetura, NUNCA a Negligencie.
O preço dela é ALTÍSSIMO, a conta chega e o pagamento, as na maioria das vezes não é tão trivial. Gerando cenários
nocivos ao seu negócio.
Um site com mais de 10 anos, usando AspNet 2.0
WebForms
JS sendo servido e montado no lado servidor
CSS fora dos novos padrões web
Baixa responsividade no site principal
Todo o Sistema dependia de Stored Procedure (Baixa escalabilidade)
Migrar o front-end do ecommerce, mantendo conversão de clientes e vendas
Melhorar a performance do site anterior sem consumir muitos recursos de servidor
Integrar com o checkout legado? Podemos colocar API? Depende, a curva de aprendizado seria grande para o time que tinhamos!!!
Backoffice como fica nesse emaranhado de código legado?
Como inovar a arquitetura da aplicação sem "engessar" o negócio que está em operação há mais de 15 anos? (WPO, SEO, Cache e outros ingredientes)
- Turnover muito alto no time
- Pouco tempo para grandes melhorias
- Cenário CAÓTICO com grandes divergências de definições
- Equipe desmotivada após 3 rollbacks
- Descrença sobre o funcionamento do Redis
- Porque descrença? E o que apontaram como solução?
- Sem Test Stage
- Tudo baseado em AspNet Cache, um serviço windows para atualizar os caches, um entrypoint em cada web server para atualizar o cache do Application Pool- NGINX mal configurado
TDD, Utilização de ferramentas para mapear e aplicar roteiros de teste
DDD ???
Entityframework? Sim, Usamos!
Utilização técnicas de WPO
Implementação de recomendações para aplicação do SEO
Continuar com AspNet Cache? Porque? Quais ganhos? Quais Perdas?
Adquirir servidores para Test Stages
Criação de ambientes pre-produção
Medições e métricas aplicadas através do Newrelic
Teste de Carga
Revisão sobre as configurações do NGINX (Log storage in separated partition, Cache Lock (Serve stale), Cache Purge, Assets rentantion timeout, Reverse Proxy)
Refatoração e adequação do Backoffice (Agendamento, Monitoramento, Log de erros melhorados, Separação dos serviços, SEQ + Quartz)
Consumo absurdo das vCPUs e Memória (claro tudo estava com base no AspNet Cache)
Dentre outros problemas que tiveram que ser analisado em modo HARD (Deep Diagnostic)
Paralelismos sendo usado de forma inadequada
Problemas de performance nos primeiros testes de carga (Redis mal dimensionado e com várias falhas de estratégia de chave e armazenamento)
O que tivemos que abdicar no meio das implementações de correção e melhoria? Testes de unidade , sim mais uma vez o argumento de que o tempo era curto e precisavamos entregar a nova plataforma antes da blackfriday (High Level Pressure)
Retorno do AspNet Cache (Bad signal…)
Sim, usamos tudo isso em uma estrutura da Locaweb
Mal planejamento da estratégia de armazenamento
Estratégia de chaves completamente fora de lógica e padronização recomendada pela Redis
Alto throughput de rede (volume de dados altíssimo trafegando na rede)
Mas espera um pouco: O Redis não é para ambientes de alta performance? Sim, mas se não for bem dimensionados os dados, quem paga é o meio físico - Rede!!!
E volta o cão arependido… AspNet Cache
Consumo absurdo das vCPUs e Memória (claro tudo estava com base no AspNet Cache)
Dentre outros problemas que tiveram que ser analisado em modo HARD (Deep Diagnostic)
Consumo absurdo das vCPUs e Memória (claro tudo estava com base no AspNet Cache)
Dentre outros problemas que tiveram que ser analisado em modo HARD (Deep Diagnostic)
- Não tem como comprovar em gráfico, mas pode-se mostrar o trecho de código que ocasionou tudo isso- Apresentar que nem tudo que há de mais modern em código, tecnologia pode ser aplicado sem ter a noção do quão nocivo pode ser para uma aplicação com acessos simultaneos
- Dump de memória do servidor de homologação + Debug Diagnostic Tools
- PerfMon e algumas métricas
- Para maiores detalhes, meu post no meu blog: http://www.jrobertoaraujo.net/2015/11/16/como-otimizar-a-performance-das-vcpus-de-um-e-commerce/
- Várias chamadas de métodos equivocadamente
- Aplicação de Regex em loops que recebiam várias chamadas simultaneas
- Parceiros bombardeando a aplicação
- Dump de memória do servidor de homologação + Debug Diagnostic Tools
- PerfMon e algumas métricas
- Para maiores detalhes, meu post no meu blog: http://www.jrobertoaraujo.net/2015/11/16/como-otimizar-a-performance-das-vcpus-de-um-e-commerce/
- Várias chamadas de métodos equivocadamente
- Aplicação de Regex em loops que recebiam várias chamadas simultaneas
- Parceiros bombardeando a aplicação
- Dump de memória do servidor de homologação + Debug Diagnostic Tools
- PerfMon e algumas métricas
- Para maiores detalhes, meu post no meu blog: http://www.jrobertoaraujo.net/2015/11/16/como-otimizar-a-performance-das-vcpus-de-um-e-commerce/
- Várias chamadas de métodos equivocadamente
- Aplicação de Regex em loops que recebiam várias chamadas simultaneas
- Parceiros bombardeando a aplicação