1 / 23

Hotmail’s Performance Tuning Best Practices

Hotmail’s Performance Tuning Best Practices. Aladdin A. Nassar Hotmail’s Performance Champion Microsoft. Lessons Learned. We cannot defy the laws of physics The truth is always out there History is bound to repeat itself if we don’t learn from it

lehmanm
Télécharger la présentation

Hotmail’s Performance Tuning Best Practices

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Hotmail’s Performance Tuning Best Practices • Aladdin A. Nassar • Hotmail’s Performance Champion • Microsoft

  2. Lessons Learned • We cannot defy the laws of physics • The truth is always out there • History is bound to repeat itself if we don’t learn from it • Newer technologies ~ bigger guns to shoot ourselves with • Performance is like beauty – it only shines from the inside • Performance effects are asymmetric • Customers do not care what we think our performance is • We will always find ways to outgrow our capacity • It is very easy to lose the forest in the trees • Some of the best performance gains are the simplest of all

  3. Laws of Physics • The more bytes you transfer, the longer they take to load • HTML is much faster & more resilient than Javascript • Web Applications are thin applications • WW performance is bound by network latency • TCP packets cannot travel faster than the speed of light • Performance Tuning is an over-constrained problem • Asymmetric bandwidths can bottleneck upstream • Fewer bigger files download faster than many small files

  4. Page Load Time (PLT) Components • Server vs. Client side Rendering • End-user’s System Config Client Rendering Network Client Rendering • Page Weight Up/Down (KB) • Bandwidth (Kbps) • Network Latency (ms) • Packet Loss (%) Client Rendering Network Network Server Rendering Server Rendering Data Center 1st Mile Midgress Backbone • SW & HW Architecture Server Rendering Last Mile Data Flow

  5. 8,000 x TCP Win (KB) Max eBW = 1.5 x Network Latency (ms) Latency Bound BW Bound Packet Loss Theoretical BW TCP Win is defined by the Receiver TCP Win (Wireless) = 8 KB TCP Win (Win XP) = 16 KB eBW Cap

  6. Performance Best Practices • Identify your performance bottlenecks & critical paths • Trim down your page weights up/downstream • Move your contents closer to your customers • Edge Caching • Edge Computing • Network Routing Optimization • Geohosting • Instrument performance across your entire network • Build a closed feedback loop – fine tune, measure, fine tune, measure, etc.

  7. Trim Page Weights (Downstream) • Trim down your features to the core minimum • Render most of your content on the server side • Trim down your image sizes by: • Minimizing their usage • Image Clustering • Reducing their color palettes • Delay load, slow down, cap and monitor ads • Use Cache Control, Expiration Dates & eTags effectively • Group your static content into fewer bigger files • Optimize between inline and stand-alone JS & CSS • Full Postbacks vs. atomic updates using Ajax

  8. Trim Page Weights (Upstream) • Down/up connection speeds ~ 5 which means your bottleneck is most likely upstream • Trim down your cookies by: • Eliminating them altogether by moving your static contents to a different domain • Optimizing their use • Moving them away from your root domain and root path “/” • Compressing them • Grouping multiple smaller files into fewer bigger ones (image clustering) • Trim down the number of requests and redirects (round trips)

  9. Bandwidth Efficiency • Identify your critical path • Spread your downloads across multiple hostnames • Hostname spreading can hurt narrowband • On Demand / JIT downloading • Control the sequencing of your downloads • Unblock & defer your Javascript • Minimize the browser’s “think time” • Use appropriate tools to analyze bandwidth efficiency

  10. The Big Picture • Outgrowing Moore’s Law • Performance Based Design (PBD) • Effect of Ads on Performance • Relative Performance Index (RPI) • Performance Consortium • PLT1 vs. PLT2 Myths • Performance vs. Capacity Planning

  11. Q&A

  12. Performance Tools • Fiddler • HTTP Watch • HTTP Analyzer • WANSim • NetMon + Add-Ons RTA / VRTA / BWA • Gomez Backbone/Last Mile • Keynote Backbone • In-House Automation Tools • JS Instrumentation

  13. Packets Packets Tahoe Fast Retransmit Fast Recovery Round Trips Reno

  14. Reference: Akamai

  15. Relative Performance Index (RPI) 100% Relative Weight 50% 0% PLT (sec) T F • RPI = the “Dow Jones” of Client Performance • It is a method not tied to any data source • T = Tolerable Level • F = Frustration Level • RPI = [0 – 100%] • RPI = G + 0.5 Y % • T/F Levels: • Defined by Usability Studies + Competitors • Defined per transaction • Function of Page Content Value G % Y % Page Views R %

  16. Ads Refresh Rates Performance Revenues Ads Refresh Rates (x Click / y Sec) Target ~ 2 clicks / 60 sec) Today = 1 click / 2 sec)

  17. Outgrowing Moore's Law

  18. Ads > Application

  19. The End

More Related