high performance web sites

23
 High Performance Web Applications Checklist - Ravi Raj Ravi Raj

Upload: ravi-raj

Post on 07-Jul-2015

8.101 views

Category:

Technology


0 download

DESCRIPTION

High Performance Web Sites

TRANSCRIPT

Page 1: High Performance Web Sites

   

High Performance Web Applications Checklist

- Ravi Raj

Ravi Raj

Page 2: High Performance Web Sites

   

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.

Page 3: High Performance Web Sites

   

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.

Page 4: High Performance Web Sites

   

APACHE :- 2

AllowOverride – It should be set to NONE to avoid additional file system lookups.

Page 5: High Performance Web Sites

   

APACHE :- 3Add 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.

Page 6: High Performance Web Sites

   

APACHE :- 4

Gzip Components - Gzipping as many file types as possible is an easy way to reduce page weight and accelerate the user experience.

Page 7: High Performance Web Sites

   

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.

Page 8: High Performance Web Sites

   

APACHE:-6Disable 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

Page 9: High Performance Web Sites

   

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.

Page 10: High Performance Web Sites

   

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.

Page 11: High Performance Web Sites

   

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.

Page 12: High Performance Web Sites

   

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.

Page 13: High Performance Web Sites

   

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.

Page 14: High Performance Web 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.

Page 15: High Performance Web 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.

Page 16: High Performance Web Sites

   

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.

Page 17: High Performance Web Sites

   

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).

Page 18: High Performance Web Sites

   

Page 19: High Performance Web Sites

   

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

Page 20: High Performance Web Sites

   

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

Page 21: High Performance Web Sites

   

Performance Tools

1.Manual Page Measurement - Firefox+Firebug+Yslow, AOL Pagetest, IBM Page Detailer, Keynote KITE2. Real User Monitoring - Coradiant Truesight + Web.I, Tealeaf, Others3. Internal Synthetic Monitoring - HP/Mercury SiteScope + BAC, Nagios, Many Others4. External Synthetic Monitoring – Keynote, Gomez, WebMetrics5. Network Analysis – Wireshark, Clearsight, ACE, NetQoS6. In Depth Metrics – Opnet Panorama, Introscope, Quest (DB), many others7. Load Testing – HP/Mercury LoadRunner, Jmeter, ab, many other

Page 22: High Performance Web Sites

   

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