Performance engineering
Upcoming SlideShare
Loading in...5
×
 

Performance engineering

on

  • 2,178 views

 

Statistics

Views

Total Views
2,178
Views on SlideShare
2,169
Embed Views
9

Actions

Likes
1
Downloads
76
Comments
0

2 Embeds 9

http://www.linkedin.com 8
https://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

CC Attribution License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Eden Space: The pool from which memory is initially allocated for most objects. Survivor Space: The pool containing objects that have survived the garbage collection of the Eden space. Tenured Generation: The pool containing objects that have existed for some time in the survivor space. Permanent Generation: The pool containing all the reflective data of the virtual machine itself, such as class and method objects. With Java VMs that use class data sharing, this generation is divided into read-only and read-write areas. Code Cache: The HotSpot Java VM also includes a code cache, containing memory that is used for compilation and storage of native code. Survivor Space: The pool containing objects that have survived the garbage collection of the Eden space.

Performance engineering Performance engineering Presentation Transcript

  • Performance Engineering by Franz See (DevCon Java Roadshow) (ValueCommerce) [email_address] http://twitter.com/franz_see
  • UI Performance Page Loading Optimization
  • Best Practices
    • Optimizing caching — keeping your application's data and logic off the network altogether
    • Minimizing round-trip times — reducing the number of serial request-response cycles
    • Minimizing request size — reducing upload size
    • Minimizing payload size — reducing the size of responses, downloads, and cached pages
    • Optimizing browser rendering — improving the browser's layout of a page
    View slide
  • Optimize caching HTTP caching allows these resources to be saved, or cached, by a browser or proxy. Once a resource is cached, a browser or proxy can refer to the locally cached copy instead of having to download it again on subsequent visits to the web page. Thus caching is a double win: you reduce round-trip time by eliminating numerous HTTP requests for the required resources, and you substantially reduce the total payload size of the responses. Besides leading to a dramatic reduction in page load time for subsequent user visits, enabling caching can also significantly reduce the bandwidth and hosting costs for your site. View slide
  • Optimize caching
    • Leverage browser caching - Setting an expiry date or a maximum age in the HTTP headers for static resources allows the browser to load previously downloaded resources from local disk rather than over the network.
    • Leverage proxy caching - Enabling public caching in the HTTP headers for static resources allows the browser to download resources from a nearby proxy server rather than from a remoter origin server.
  • Minimize round-trip times Round-trip time (RTT) is the time it takes for a client to send a request and the server to send a response over the network, not including the time required for data transfer. That is, it includes the back-and-forth time on the wire, but excludes the time to fully download the transferred bytes (and is therefore unrelated to bandwidth). For example, for a browser to initiate a first-time connection with a web server, it must incur a minimum of 3 RTTs: 1 RTT for DNS name resolution; 1 RTT for TCP connection setup; and 1 RTT for the HTTP request and first byte of the HTTP response. Many web pages require dozens of RTTs.
  • Minimize round-trip times
    • Minimize DNS lookups - Reducing the number of unique hostnames from which resources are served cuts down on the number of DNS resolutions that the browser has to make, and therefore, RTT delays.
    • Minimize redirects - Minimizing HTTP redirects from one URL to another cuts out additional RTTs and wait time for users.
    • Combine external JavaScript - Combining external scripts into as few files as possible cuts down on RTTs and delays in downloading other resources.
  • Minimize request size Every time a client sends an HTTP request, it has to send all associated cookies that have been set for that domain and path along with it. Most users have asymmetric Internet connections: upload-to-download bandwidth ratios are commonly in the range of 1:4 to 1:20. This means that a 500-byte HTTP header request could take the equivalent time to upload as 10 KB of HTTP response data takes to download. The factor is actually even higher because HTTP request headers are sent uncompressed. In other words, for requests for small objects (say, less than 10 KB, the typical size of a compressed image), the data sent in a request header can account for the majority of the response time.
  • Minimize request size
    • Minimize cookie size - Keeping cookies as small as possible ensures that an HTTP request can fit into a single packet.
    • Serve static content from a cookieless domain - Serving static resources from a cookieless domain reduces the total size of requests made for a page.
  • Minimize payload size The amount of data sent in each server response can add significant latency to your application, especially in areas where bandwidth is constrained. In addition to the network cost of the actual bytes transmitted, there is also a penalty incurred for crossing an IP packet boundary. (The maximum packet size, or Maximum Transmission Unit (MTU), is 1500 bytes on an Ethernet network, but varies on other types of networks.) Unfortunately, since it's difficult to know which bytes will cross a packet boundary, the best practice is to simply reduce the number of packets your server transmits, and strive to keep them under 1500 bytes wherever possible.
  • Minimize payload size
    • Enable gzip compression - Compressing resources with gzip can reduce the number of bytes sent over the network.
    • Remove unused CSS - Removing or deferring style rules that are not used by a document avoid downloads unnecessary bytes and allow the browser to start rendering sooner.
    • Minify JavaScript - Compacting JavaScript code can save many bytes of data and speed up downloading, parsing, and execution time.
  • Minimize payload size
    • Defer loading of JavaScript - Deferring loading of JavaScript functions that are not called at startup reduces the initial download size, allowing other resources to be downloaded in parallel, and speeding up execution and rendering time.
    • Optimize images - Properly formatting, sizing, and losslessly compressing images can save many bytes of data.
    • Serve resources from a consistent URL - It's important to serve a resource from a unique URL, to eliminate duplicate download bytes and additional RTTs.
  • Optimize browser rendering Once resources have been downloaded to the client, the browser still needs to load, interpret, and render HTML, CSS, and Javascript code. By simply formatting your code and pages in ways that exploit the characteristics of current browsers, you can enhance performance on the client side.
  • Optimize browser rendering
    • Use efficient CSS selectors - Avoiding inefficient key selectors that match large numbers of elements can speed up page rendering.
    • Avoid CSS expressions - CSS expressions degrade rendering performance; replacing them with alternatives will improve browser rendering for IE users. This best practices in this section apply only to Internet Explorer 5 through 7, which support CSS expressions.
    • Put CSS in the document head - Moving inline style blocks and <link> elements from the document body to the document head improves rendering performance.
    • Specify image dimensions - Specifying a width and height for all images allows for faster rendering by eliminating the need for unnecessary reflows and repaints.
  • Tips and Tricks
    • Remove all 404 resources.
      • Access logs to check 404 resources.
      • grep 'HTTP/1.1&quot; 404' access.log
    • Put CSS at the top, and CSS first before JS
      • Put JS at the end of the page
    • Set a reasonable buffer size for JSP for eager loading if possible divisible by 1500 bytes. <%@ page buffer=&quot;36kb&quot; %>
  • Tips and Tricks
    • Enable GZIP using GZIP filter for text content types
      • Pre GZIP Text static resources (Custom ant task)
      • Compress images
      • Page speed provides you with the compressed image
      • https://developer.yahoo.com/yslow/smushit/
    • Minify JavaScript, CSS or even dynamic (JSP) contents
      • YUI compressor from Yahoo!
      • Closure Tools from Google
      • Combining of external JavaScript and CSS resources
      • Custom ant tasks
      • CSS sprites
      • http://csssprites.com/
  • Tips and Tricks
    • Browser caching using http header
      • Cache-Control response header with at least one month expiration
      • Ideally for static resources, and can be done also on get Ajax calls
      • Caching of asynchronous call results (page scope)
    • Progressive loading using Ajax
    • Deferred loading
  • Tips and Tricks
    • Use performance analyzer tools
      • Yslow! from Yahoo!
      • Page speed from Google
  • Possible UI Performance Drawback
    • Maintainability
      • Support for JavaScript debugging is now impossible
        • Minify JavaScript and CSS resources
        • Combining of external JavaScript and CSS resources
  • References
    • http://code.google.com/speed/page-speed/docs/rules_intro.html
    • https://developer.yahoo.com/yslow/
    • https://developer.yahoo.com/yslow/smushit/
    • http://csssprites.com/
    • http://developer.yahoo.com/yui/compressor/
    • http://code.google.com/closure/
  • Back End Performance Engineering
  • Problems? Slow down Out of Memory
  • What are they? Profiler A form of Dynamic Program Analysis for Improving performance Heap Analysis Tool Tool for analyzing heap dumps
  • Example
  • Example
  • Example
  • Popular Profiling Tools
    • Paid
      • JProfiler
      • YourKit
    • Free
      • Eclipse TPTP
      • Netbeans Profiler
      • Visual VM (comes with java 6u7)
  • Popular Heap Analysis Tools
    • Jhat
    • Eclipse Memory Analyzer Tool
    • <Profiling tools>
  • Common Profiling Views Self Tree Telemetry CPU Duration Per Method Call Tree CPU Load Memory Size per object of type Dominator Tree Memory Load Thread Duration per thread (---) (---)
  • Heap Analysis
    • Quick recap of the Java Memory Model
    • Learning to generate heap dumps (hprof)
    • Setting up the Eclipse Memory Analyzer Tool
    • The 3 basic reports – Overview, Leak Suspects, and Top Components
    • The 'other' features
  • Java Memory Model
    • Heap
      • Young GEn
        • Par Eden Space
        • Par Survivor Space
      • CMS Old Gen
    • Non-Heap
      • Code Cache
      • CMS Perm Gen
    More info: http://download.oracle.com/javase/6/docs/ ... ...technotes/guides/management/jconsole.html
  • Generate HPROF
    • -XX:+HeapDumpOnOutOfMemoryError
    • jmap -heap:format=b <pid>
    • jmap.exe -dump:format=b,file=HeapDump.hprof <pid>
    More info : http://wiki.eclipse.org/index.php/MemoryAnalyzer#Getting_a_Heap_Dump
  • Setup Eclipse MAT
    • Home Page : http://www.eclipse.org/mat/
    • Download Page : http://www.eclipse.org/mat/downloads.php
    • Quick Start: http://wiki.eclipse.org/index.php/MemoryAnalyzer
  • 3 Basic Reports
    • Overview
    • Leak Suspects
    • Top Components
    • The 'other' features.
    • Histogram
    • Dominator Tree
    • OQL
  • OQL
  • Histogram
  •  
  • Last Tips & Tricks 1.) Premature Optmization is the source of all evil 2.) Validate Assumptions 3.) Avoid blind fixes as much as possible 4.) Differentiate between CPU & IO 5.) Work Together
  • Thank You Questions? [email_address] http://devworks.devcon.ph http://devcon.ph http://facebook.com/DevConPH http://twitter.com/DevConPH http://twitter.com/franz_see