Abaixo os slides da minha palestra de hoje (03/02/2012) no Codificando Night Week
Nessa palestra falarei bastante sobre IIS, mas voltado para o desenvolvedor. Vou tentar mostrar algumas coisas que aprendi depois de apanhar muito.
Abaixo os slides da minha palestra de hoje (02/02/2012) no Codificando Night Week
Nessa palestra falei bastante sobre Front-end e expliquei a motivação e o uso das bibliotecas javascript LABjs e JQuery Templates
Abaixo os slides da minha palestra de ontem (01/02/2012) no Codificando Night Week
Nessa palestra falei sobre as novidades do ASP.NET MVC 4, a galera gostou bastante.
Precisamos conhecer exatamente como as coisas acontecem por debaixo dos panos, só assim conseguiremos otimizar nossas páginas e deixar nossos usuários felizes 
.
Muitos fatores podem afetar a performance de uma página, largura de banda, distância entre o cliente e o servidor, tamanho e quantidade de elementos em uma página, como esses elementos são carregados e etc.
Devemos começar por algum lugar a procura por gargalos, existem muitas ferramentas que podem nos ajudar com isso. O que todas elas possuem em comum é o que chamamos de Waterfall chart, um gráfico em cascata que mostra como os elementos da página estão sendo carregados.
Figura 1: Aba Net do FireBug
Figura 2: Waterfall View da ferramenta WebPageTest.org
As duas figuras acima mostram o Waterfall view da página inicial do site do Google.
Cada linha da cascata representa um componente de página sendo baixado para o browser do usuário.
Perceba que primeiramente o HTML é baixado e depois todos os componentes associados a ele (Imagens, arquivos CSS, arquivos JS e etc).
No caso da visualização do WebPageTest.org cada componente (linha) tem uma barra com pedaços coloridos que representam diferentes atividades para aquela requisição HTTP, vejamos:
Figura 3: Requisição HTTP
Figura 4: Legenda
DNS (Domain Name System) Lookup é o processo de resolução de nome (de domínio) em IP, ou seja, é achar através de uma url como http://www.google.com.br o IP associado a mesma, que é o que o browser precisa para fazer a conexão com o servidor remoto.
Um ponto importantissímo é que um DNS Lookup irá acontecer para cada domínio diferente que sua página possa ter associado a ela, por exemplo: http://images.seusite.com.br , http://static1.seusite.com.br . Cada um desses subdomínios gerará um novo DNS Lookup já que diferentes subdomínios podem estar associados a difentes IP’s.
Todos as requisições HTTP que um browser faz para o servidor são trafegadas através de conexões TCP (Transmission Control Protocol), portanto toda requisição precisa de uma conexão TCP ativa para que se possa baixar os componentes da página.
Para se estabelecer uma conexão TCP um three-way handshake é feito entre o cliente e o servidor através de metadados enviados nos pacotes. Os pacotes do handshake são muito pequenos e depois de enviados e reconhecidos pelas duas pontas a conexão é estabelecida e a transferência do arquivo pode ser iniciada.
Figura 5: Handshake
Um novo header foi introduzido no HTTP 1.1 com o intuito de reaproveitar conexões TCP para difentes requisições. Quando utilizamos o header Connection: keep-alive uma conexão TCP aberta e que nao tenha dado timeout ainda será reaproveitada para trafegar outras requisições HTTP, evitando assim o overhead de se estabelecer conexões TCP (handshake).
Figura 6: Visualização de conexões
Perceba que em uma mesma linha diferentes tipos de componentes são trafegados em momentos diferentes, uma mesma conexão TCP é reaproveitada.
Time to First Byte também conhecido como TTFB é o tempo que o browser espera para receber o primeiro byte de informação da requisição, em páginas dinâmicas podemos considerar esse tempo a demora do processamento server side por exemplo. Se o TTFB de uma request esta muito alto, investigue pois pode ser um ponto importante para otimizações (índice de bancos de dados, melhorias de algoritmos na aplicação e etc).
Depois de receber o primeiro byte, o “resto” em azul é o tempo de download do componente em sí.
Perceba na figura 3 que só de bater o olho percebemos que mais da metade do tempo gasto nessa requisição foi gasto com REDE!, DNS Lookup, estabelecimento de conexão TCP e TTFB (resumidamente consideramos esse tempo como simplesmente LATÊNCIA).
Digo novamente, nós desenvolvedores web precisamos conhecer muito tudo isso, esse tipo de conhecimento esta escondido e poucas pessoas tem ou tentam aprender, mas com certeza saber isso e muito mais faz de você um melhor desenvolvedor.
Abraços
Uma CDN (Content Delivery Network) é uma rede de computadores distribuídos geograficamente com cópias de conteúdos a serem acessados.
A CDN tem dois grandes objetivos o primeiro é tornar mais próximo o conteúdo que esta sendo distribuído e solicitado (Imagens, Stylesheets, Scripts, Flashs, Músicas, PDF’s e etc) dos usuários assim diminuindo o tempo de resposta e latência destes componentes, o segundo é diminuir custos com banda/tráfego de dados (do site que esta utilizando a CDN) e por conseqüência diminuir a quantidade de requisições diretas ao servidor real do site desafogando e muito a infra “local”.
É normal um site sendo acessado de uma país ter grandes diferenças no tempo de resposta das páginas quando acessado de um país vizinho, até mesmo diferenças entre cidades ou bairros. Isto ocorre devido ao roteamento entre as requisições e os servidores que estão sendo solicitados que dependendo do link ou região que o usuário se encontra os saltos são maiores ou menores e com velocidades diferentes também.
Uma solução interessante seria entregar para cada usuário ou região o conteúdo que esteja mais próximo da requisição que esta sendo feita e é justamente ai que uma CDN faz a diferença melhorando incrivelmente a experiência do usuário e o tempo de resposta dos componentes que estão sendo solicitados pelo usuário.
Existem CDN’s comerciais ou pagas e CDN’s gratuitas abaixo listo algumas bem famosas e recomendadas pela indústria.
CDN’s Comerciais:
Akamai
EdgeCast Networks
Limelight Networks
Daniel M. Lewin um dos fundadores da Akamai estava em um dos vôos do 11 de setembro de 2001 e faleceu.
Aumente a performance do tempo de resposta dos componentes de suas páginas, faça os usuários mais felizes e ainda diminua alguns gastos com o alto tráfego que você tem hoje sem uma CDN pra te dar uma força.
A cada dia novas startups surgem com idéias inovadoras em ramos diferentes, mas o que todas elas têm em comum é que normalmente praticamente toda sua operação e infraestrutura vivem na Web, a “lojinha”, o “ganha pão” está e somente é acessível através de uma URL.
Isto requer um investimento menor já que é mais barato no começo criar um site do que montar por exemplo uma loja física (comparando a outros negócios).
Uma vez que a empresa vive através da World Wide Web é fundamental que o tal site esteja otimizado afim de garantir entre outras coisas um rápido atendimento (e a qualquer momento, afinal acho que essa é uma vantagem da Web), satisfação do cliente, um baixo (ou o mais baixo possível) custo para manter a “lojinha” aberta (o site do ar), fidelização da clientela, aumento da taxa de conversão, uma fácil descoberta de seus produtos ou serviços por potenciais interessados (SEO), etc etc etc.
WPO – Web Performance Optimization é uma recente área de estudo e otimização pra Web Sites e deve ser observada e utilizada cada dia mais por todos aqueles que pretendem trabalhar ou até viver de internet (no caso dos empreendedores). WPO é parecido com SEO do ponto de vista que também traz mais trafego para o site, mas não para por aí, de acordo com alguns cases que veremos abaixo também melhora a experiência do usuário, aumenta receita e diminui custos operacionais.
Parece ridículo, mas apenas 1 segundo a mais ou a menos no tempo de carregamento de uma página faz muita diferença dependendo de qual site estamos falando, veja alguns exemplos:
Bing – 2 segundos a mais no tempo de resposta de suas páginas é igual a 4,3% de receita a menos por usuário.
Google – 400 milisegundos de delay é equivalente a 0,59% de buscas a menos por usuário.
AOL – Atestou que usuários que carregam páginas rápidas navegam 50% mais que usuários com páginas com carregamentos mais demorados (50% de páginas a mais por usuário)
ShopZilla – Diminuiu o tempo de carregamento das páginas de 7 segundos para 2 segundos e conseguiu aumentar de 7% para 12% em receita e diminuir em 50% os custos com hardware e banda.
Fonte: Gomez Inc
Empresas sérias que tem milhares ou milhões de acessos diariamente devem sem sombra de dúvidas melhorar a performance de suas páginas, simplesmente você ganha mais e gasta menos! veja que maravilha!
Há varias formas e técnicas para aumentar a performance das páginas de nossos sites, mas isso é assunto para um outro post. (em breve postarei algumas coisas.)
Importante: Não poderia deixar de dizer que o Google já há algum tempo vem utilizando o fator “velocidade/performance” como critério para o resultado de suas buscas, ou seja, agora páginas rápidas ou performáticas são melhor indexadas pelo maior mecanismo de buscas do planeta.
Melhorar a performance de nossas páginas diminui custos de operação com hardware e banda (pois se trafega menos dados e diminui em manutenção dos servidores, por exemplo), aumenta tempo de navegação e pageview por usuário (logo da pra vender mais, aumentando a receita), fortifica a marca afinal sites rápidos são adorados pelos usuários e eles recomendarão com certeza, etc e tal!
Post rápido prometo. Piadinhas de cookie a parte 
a coisa é bem séria.
É muito comum nós Web Developers guardarmos informações em cookie(s) no(s) browser(s) do(s) usuário(s), certo? Sim certo!
As vezes até “sem querer” fazemos isso (até sem saber), por exemplo, vários frameworks web (inclusive o ASP.NET) armazena no cookie informações para fazer a autenticação dos usuários na aplicação.
Bom, e daí que não é através de mágica que nós conseguimos acessar lá no SERVER os dados do cookie que fica no BROWSER do usuário.
A toda request feita para o servidor pelo browser o cookie do usuário (sem piadinhas aqui ok? ) vai junto, é trafegado na request. Sério? Sim, sério.
A grande questão aqui é que o cookie é baseado em subdomínio, ou seja, se eu gero um cookie qualquer para www.meusite.com.br, toda request feita para o “www” levará o cookie junto (sem piadas novamente), inclusive requisições para imagens, arquivos css e javascript e tudo que estiver apontando para o subdomínio “www”.
Agora cá pra gente, por que raios a gente precisa trafegar os cookies para imagens e arquivos estáticos em geral? Não precisamos! Não serve pra nada, nem pra gente e nem para o servidor, é um grande desperdício!
Use cookie-free domains, se nós criarmos um novo subdomínio, por exemplo, static.meusite.com.br e fizermos com que todos os arquivos estáticos apontem para este subdomínio bingo! Os cookies não serão trafegados porque eles foram gerados para o “www” e não para o “static”, dessa forma conseguimos economizar alguns Kilobytes no final do mês no tráfego geral do site , chique não?
Qualquer dúvida ou sugestão, deixe-me saber nos comentários
Abraços
Olá pessoal,
Resolvi escrever este pequeno post para explicar a diferença entre dois (famosos) eventos que são disparados quando uma página é carregada, são eles:
Estes eventos são muito importantes e devemos saber a real diferença entre eles, assim usaremos cada um deles de maneira apropriada
Também conhecido em JQuery como: $(document).ready
Este evento é disparado quando o documento HTML é carregado e parseado (analisado), neste momento o DOM (Document Object Model) é construído e esta pronto para ser acessado.
Não há a necessidade de esperarmos todo o resto da página ser carregado para acessarmos a estrutura de objetos e fazermos manipulações .
Também conhecido em JQuery como: $(window).load
Este evento por sua vez é disparado quando TODOS os componentes da página são carregados: Imagens, CSSs, JavaScripts, Frames, Flashs e etc.
Devemos usar este evento somente quando quisermos fazer algo depois do carregamento COMPLETO da tal página.
Tirei a imagem acima do FireBug uma extensão do Firefox.
Perceba duas linhas verticais uma azul e outra vermelha, que representam os eventos DOMContentLoaded e load respectivamente. No tooltip ainda conseguimos ver a quantidade de tempo que se passou até que esses eventos fossem disparados, interessante não?
Quanto mais perto uma linha da outra mais rápido sua página esta sendo carregada!
Sim! Botões do Facebook, coisas do Twitter e etc, tudo que for de terceiro que estiver “pindurado” em sua página vai interferir ou postergar o evento load de sua página, portanto cuidado!
O ideal nesses casos é carregar tais componentes de modo assíncrono, mas isso é assunto para um próximo post .
Espero ter contribuído de alguma forma
Abraços!
Olá pessoal,
É muito comum (ainda) desenvolvedores Web utilizarem os verbos Http Get e Post de maneira meio que “indiscriminada” para acessarem e/ou buscarem recursos no servidor Web, e digo isso independentemente da tecnologia de servidor que esta sendo utilizada (PHP, ASP.NET, JSF, Rails, Django e etc).
A ideia desse post é simplesmente alertar os desenvolvedores de alguns “perigos” da utilização errada dos verbos para fazer “ações” no servidor.
Em geral devemos pensar nos dois verbos literalmente como nós os lemos, ou seja, GET (SOMENTE para pegar recursos, ok?) e POST (Para postar algo, levar algo ao servidor e provavelmente mudar o estado de algo).
Existem vários motivos de não utilizarmos GET para fazer alterações de estado no servidor, alguns:
Portanto muito cuidado quando for alterar estado no servidor (adicionar/atualizar/deletar) via GET, pode ser um tanto quanto “perigoso” em alguns casos.
OK então vou sempre utilizar POST para fazer alteração de estado!
Perfeito, mas nesse caso se não fizermos “nada” na resposta dessa requisição teremos um problema chato.
Quem nunca depois de um POST de formulário tentou recarregar a página e PAM! Sim! Alerta do browser dizendo que vai reenviar tudo para o server (outro POST pra ser mais exato, podendo repetir por exemplo a inserção de algo no banco), é eu sei, você assim como eu já passou por isso.
Como resolver?
Até que é fácil, nesse caso devemos utilizar o padrão Post/Redirect/Get (sim é considerado um padrão), dessa forma evitamos esse comportamento chato que sempre acontece, no ASP.NET MVC é bem tranquilo de implementar inclusive.
Bom fica a dica, espero que vocês parem de utilizar GET pra fazer alteração de estado no server =)
Críticas, dúvidas ou sugestões vamos conversar nos comentários.
Olá Pessoal,
Na última sexta-feira (30/09/2011) tive a oportunidade juntamente com o Alexandre Tarifa no TechEd 2011 de ministrar uma palestra que queríamos fazer já há algum tempo. O título da sessão foi: Técnicas e recursos para desenvolvimento Web em cenários de grande escala.
A ideia principal da apresentação era mostrar pontos/dicas/soluções que normalmente não são considerados ou lembrados em um cenário onde o volume de acesso e requisições são enormes (temas como: custo, latência, performance, escalabilidade e etc foram discutidos).
Abaixo segue o PPT e o link para o download das DEMOS que fizemos.
PS: Para informações mais detalhadas sobre a demo de Long Polling verifiquem o Post no blog do Rodolfo Fadino
Agradeço a todos que participaram da apresentação, realmente o feedback foi muito bom, espero que tenham gostado.
Resolvi escrever este post para explicar o que são os tão conhecidos porém as vezes não entendidos Http Modules e Http Handlers, estes dois players na infraestrutura do ASP.NET fazem basicamente tudo acontecer.
Todo o funcionamento do ASP.NET é baseado nestes dois conceitos que aprenderemos a partir de agora.
Todas as requisições feitas para uma aplicação ASP.NET são tratadas através de um pipeline, este pipeline possui uma série de eventos de entrada que leva a tal requisição a um manipulador, este manipulador é o que chamamos de Http Handler (os Http Handlers também são conhecidos como Endpoints – você já entenderá o porque). Depois da requisição ser tratada por um Http Handler ela será liberada ao solicitante e dessa vez passará pelos eventos de saída do pipeline.
ASP.NET Pipeline
Perceba que na imagem o processo lembra muito um túnel (pipeline) onde a requisição passa por eventos de entrada, é tratada por um http handler e depois passa por eventos de saída até ser liberada ao solicitante da requisição.
É importante lembrar que todas as requisições passam por este eventos do pipeline (definidos por HttpApplication) .
Os Http Handlers são de fato os componentes que fazem “a coisa acontecer”, são eles que processam as requisições (ProcessRequest definido por IHttpHandler). No Web Forms por exemplo o HttpHandler que processa as requisições é o PageHandlerFactory que implementa a interface IHttpHandler, já no MVC esse papel é feito pelos handlers MvcHandler e MvcHttpHandler (dependendo da situação).
É comum nós termos que criar nossos próprios Http Handlers em algumas situacões como por exemplo um handler de imagens que possui os binários no banco de dados e ainda talvez tenham que variar os tamanhos dessas imagens. Outro exemplo seria criar um handler para prover informações em formato RSS ou CSV.
Implementar um handler não é uma tarefa muito difícil só é preciso implementar a interface IHttpHandler (Basta dar uma googlada para ver 1 bilhão de exemplos =D).
Diferente dos Http Handlers que atuam como endpoints para as requisições os Http Modules atuam nos mais variados eventos do pipeline do ASP.NET, na verdade um Http Module (quando escrito) se inscreve em um ou mais eventos do pipeline onde pode fazer diferentes coisas (olhar imagem do pipeline acima e link do HttpApplication), dessa forma dizemos que os Modules atuam como “filtros” em todo esse processo (tanto nos eventos de entrada como nos eventos de saída do pipeline).
Você pode querer criar um Http Module para por exemplo minimificar arquivos estáticos, colocar alguns headers http customizados na resposta da requisição ou ainda tratar questões de segurança e logging que são tarefas que normalmente um Http Module resolve muito bem.
Assim como os Handlers os Modules não são coisas de outro mundo para serem implementados e você pode achar milhares de exemplos facilmente no Google.
Os Http Handles e os Http Modules são parte fundamental do ASP.NET entendê-los faz de você um melhor desenvolvedor sem dúvidas, e acredite quando der zica saber bem como funciona o framework com o qual você trabalha faz toda a diferença.
Espero que este post tenha ajudado de alguma forma…
Qualquer dúvida, crítica ou sugestão por favor vamos bater um papo nos comentários.
Abraços!
Quem trabalha com ASP.NET MVC sabe o quanto as rotas são importantes para o correto funcionamento das aplicações, as rotas tem um papel fundamental e são delas que o Framework extrai informações para construção de Controllers e para o acionamento de Actions.
Mas e quando temos problemas com as rotas? O sistema deveria estar caindo em uma rota e não na outra, como verificar isso? Na verdade é meio complicado mesmo uma vez que as rotas são todas configuradas na inicialização da aplicação (AKA Application_Start do nosso querido Global.asax).
Pensando nessa dificuldade de cada dia o Phil Haack criou um package chamado RouteDebugger que tem o objetivo de nos ajudar a caçar possíveis problemas em nossas rotas.
Mão na massa!
Criei um projeto chamado MvcRouteDebugger no meu Visual Studio 2010
Com o projeto recém criado abra o Package Manager Console e instale o pacote como abaixo:
PM > Install-Package routedebugger
A instalação adiciona uma referência da Dll RouteDebugger ao projeto e uma entrada no Web.Config
A entrada no Web.Config é que define se o debug esta valendo ou não, então é aqui que você pode ativar ou desativar o RouteDebugger em sua aplicação:
<add key=”RouteDebugger:Enabled” value=”true” />
Por padrão vem ativo (true).
Executando a aplicação
Com a aplicação rodando podemos ver que quando a aplicação esta com o RouteDebugger ativo são adicionadas várias informações sobre roteamento no fim das nossas páginas, dessa forma conseguiremos de uma forma melhor analisar possíveis problemas com nossas rotas.
Espero que tenham gostado da dica.
Abraços.
Hoje estive na FIAP para ministrar uma palestra que seria em conjunto com o Alexandre Tarifa, mas infelizmente ele por motivos profissionais não pode participar.
Eu quis mostrar aspectos do ASP.NET MVC que realmente são muito legais, como por exemplo a nova View Engine Razor, Validação com Data Annotations, Segurança (XSS e CSRF), Nuget, Cache e etc.
O feedback do público foi muito bom!
Abaixo o ppt
Abs
Hoje tive o prazer de participar de um grande evento organizado pela comunidade inteiramente sobre ASP.NET MVC o MVC Summit, foram duas tracks com muito MVC pra galera e dessa vez eu pude falar sobre AJAX, JSON e CACHE.
Abaixo segue o ppt e o vídeo que gravei da palestra.
Espero que gostem
Abs
MVC Summit – Como trabalhar com AJAX, JSON e Cache no MVC from Cleber Dantas on Vimeo.
Para não passar 2010 em branco sem nenhum vídeo técnico segue uma dica sobre ASP.NET MVC bem útil (eu acho ;D), espero que gostem!
Compilação de Views no ASP.NET MVC from Cleber Dantas on Vimeo.