High Performance Web Sites
Upcoming SlideShare
Loading in...5
×
 

High Performance Web Sites

on

  • 9,337 views

High Performance Web Sites

High Performance Web Sites

Statistics

Views

Total Views
9,337
Views on SlideShare
9,316
Embed Views
21

Actions

Likes
7
Downloads
118
Comments
0

5 Embeds 21

http://www.slideshare.net 12
http://www.linkedin.com 5
http://www.lmodules.com 2
http://ravirajsblog.blogspot.com 1
https://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as OpenOffice

Usage Rights

© All Rights Reserved

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

    High Performance Web Sites High Performance Web Sites Presentation Transcript

    • High Performance Web Applications Checklist - Ravi Raj Ravi Raj
    • APACHE :- 1 Tuning the Apache MaxClients parameter – It varies acc. to the application so tune it as per the process size of your application. The RSS column in "ps -ylC httpd --sort:rss" shows non-swapped physical memory usage by Apache processes in kiloBytes.
    • APACHE :- 1 MaxClients = (Total Memory - Operating System Memory - MySQL memory) / Size Per Apache process. For example, if one has 1GB of memory, and leaves 250 MB for the system and MySQL, with an Apache process of 15MB, this means 50 Apache processes can fit in the remaining 750MB.
    • APACHE :- 2 AllowOverride – It should be set to NONE to avoid additional file system lookups.
    • APACHE :- 3 Add an Expires or a Cache-Control Header - A first-time visitor to your page may have to make several HTTP requests, but by using the Expires header you make those components cacheable. This avoids unnecessary HTTP requests on subsequent page views. Expires headers are most often used with images, but they should be used on all components including scripts, stylesheets, and Flash components.
    • APACHE :- 4 Gzip Components - Gzipping as many file types as possible is an easy way to reduce page weight and accelerate the user experience.
    • APACHE :-5 Configure ETags - If you're not taking advantage of the flexible validation model that ETags provide, it's better to just remove the ETag altogether.
    • APACHE:-6 Disable folders listing on production sites. Mod_Security – It is an Apache module that shields web applications from known and unknown attacks, such as SQL injection attacks, cross-site scripting, path traversal attacks, etc. Mod_Evasive – It is an Apache module that blocks the DOS (Denial of Service) attacks and reports abuses via email and syslog facilities
    • MYSQL Indexing – Using slow query log / devel module, you can find slow queries in the page and then with help help “Explain” statement in SQL, you can find out if there are enough indexes in the database.
    • MYSQL Query Cache – It should be on and the query size cache as per the requirements of your site by monitoring the ratio of Qcache_hits (The number of cache hits) and Qcache_inserts (The number of queries added to the cache) mysql variables.
    • MYSQL max_connections - Each apache process will use one MySQL process so the MySQL max_connections should not be set to be less than the Apache MaxClients. This must be higher than "MaxClients" set in Apache.
    • MYSQL Master Slave Replication – If one db server is utilizing complete resources then add another db server using master slave replication and distribute the load.
    • PHP error_reporting - The setting (E_ALL & ~E_NOTICE & ~E_STRICT) is recommonded on production sites as we should not display notices and coding standard warnings on live site. We should use E_ALL on development system to write clean code. display_errors - Default is "on" but it should be off on production sites.
    • PHP log_errors - Default is "Off" but it should be on on production sites. error_log - Default is not set but it should be set on production sites.
    • PHP post_max_size - Default is 8MB but sometimes we may need to increase it when we allow users to upload large media files like videos etc. upload_max_filesize - Default is 2MB but sometimes we may need to increase it when we allow users to upload large media files like videos/audios etc.
    • PHP session.cookie_domain - Default is set to nothing but if we need to have single sign for sub-domains then we should give the name of main site. (e.g. .goingon.com) max_execution_time – Default is 30 seconds, but sometimes if we using lengthy / heavy php scripts (e.g. video proccessing scripts) then we may need to increase it as needed.
    • PHP memory_limit – Default is 8MB, but sometimes we may need to increase it. E.g. if we are using many modules in Drupal then we may need to increase it. Sometimes, if you see the page is coming blank without any reason then it indicates we need to increase memory limit. Application Cache – Put the complex blocks in your page or complete pages in cache (database / filesystem / memory).
    •  
    • 14 rules for faster-loading pages # Make fewer HTTP requests # Use a CDN # Add an Expires header # Gzip components # Put CSS at the top # Move JS to the bottom # Avoid CSS expressions
    • 14 rules for faster-loading pages # Make JS and CSS external # Reduce DNS lookups # Minify JS # Avoid redirects # Remove duplicate scripts # Turn off ETags # Make AJAX cacheable and small
    • Performance Tools 1.Manual Page Measurement - Firefox+Firebug+Yslow, AOL Pagetest, IBM Page Detailer, Keynote KITE 2. Real User Monitoring - Coradiant Truesight + Web.I, Tealeaf, Others 3. Internal Synthetic Monitoring - HP/Mercury SiteScope + BAC, Nagios, Many Others 4. External Synthetic Monitoring – Keynote, Gomez, WebMetrics 5. Network Analysis – Wireshark, Clearsight, ACE, NetQoS 6. In Depth Metrics – Opnet Panorama, Introscope, Quest (DB), many others 7. Load Testing – HP/Mercury LoadRunner, Jmeter, ab, many other
    • Monitoring Drawbacks * Manual Page Measurement – Different results lead to contention between stakeholder groups * Real User Monitoring – Very network setup dependent * Internal Synthetic Monitoring – Generates load, can sneak into reporting * External Synthetic Monitoring – Generates load, can sneak into reporting * Network Analysis – Information is buried and only useful in narrow scope * In Depth Metrics – Agents cause problems * Load Testing – Good load testing is an art unto itself * Javascript/Page Beacons – Our experience with Web analytic based on these indicates up to 10% unreliability
    • Thanks [email_address]