Web ScalabilityWeb Scalability
www.folio3.com@folio_3
Scalability
 It is the ability of a system to handle a growing amount of
traffic/data in a capable manner
 How much system can grow
 How easy it is to increase capacity
Generation Time
Delivery Time
Scalability
Solutions
 Add hardware. More CPU and RAM to machine
 Vertical Scalability
 Costly
 Higher TCO
 Add another server
 Horizontal Scalability
 More reliable
 Less costly as compared to other options
 Maintenance cost is higher
Opportunity Areas
 Database
 Application
 Web Server
 Scripting Language
 Hardware
 Hosting
Database
 Query Optimization
 Log slow queries
 Check query plan to make sure indexes are used
 Indexes
 A lot of how-to's available
 MySQL Query Cache
 Performance Schema
Database
 Review default values
 Index buffers
 Innodb Buffer Pool
 Number of open tables
 Innodb vs MyISAM
 Speed up file system
 Per-table file for Innodb
 Keep RDBMS updated
 A lot of diagnostic tools available
phpMyAdmin Advisor
Database
 Load balancing
 Route read queries to slaves
 Write queries to Master
 Multi-master Architecture
 Offload Database server
 Sphinx, Solr
 Nosql (Radis, Mongo etc)
 MySQL Cluster
 Write intensive
Application
 Identify Bottleneck
 Newrelic
 xDebug
 Framework profiling tools
Application
 Use framework DB APIs
 Avoid custom queries
 It allows the use of plug-ins / extensions / modules
 Use Framework cache APIs
 Don’t by-pass framework or CMS
 Profile your code
 Time
 Memory
 Profile/Monitor third party services
Application
 Cache output
 Full page cache
 Can be done in:
 Application (Disk, memcache, apc etc)
 Proxy server (varnish, lightspeed)
 Very effective
 Wikipedia serves 85% cached content. Only 15% is fetched from DB
 Cache static files in memory
 Query Results Cache
 Reduces number of queries
 Reduce IO
 Avoid file_exists sort of checks
 Reduce file operations
Web Server
 Explore options
 Apache
 Nginx
 Litespeed
 Load balancing
 HAProxy
 Ldirector
 Varnish (define multiple backend)
 Nginx, Apache balancer modules
 Decide balancing strategy
 Round robin, Last used, Weighted
 Do heavy lifting in crons, message queues
Web Server
 Fine-tune web server
 Don’t rely on default configurations
 Make web server use multiple cores
 E.g worker_processes for nginx
 Check your specific server configuration
 KeepAlive sort of options
 A lot can be done
Scripting Language (php)
 Enable opcache
 APC
 Opcache in 5.5
 eAccelerator
 Fine-tune settings
 Real path cache
 Buffers
 Max memory per script
 Look for best practices for that language
Hardware
 Disk is the slowest part of the system
 Go for SSD
 Reduce IO
 Offload Extensive downloads
 Cloud files
 CDN
 File system optimizations
 Number of files in folder
 RAID
Hosting
 Cloud vs. Dedicated
 Cloud makes scaling easy
 Easy to add hardware
 Easy to build
 Cloud is cheaper as compared to dedicated hardware
 Easy to separate DB & Application server
 Avoid having control panels on servers
 Cloud has slight performance disadvantage
 Does not work well when it is raining.
Resources
 http://www.slideshare.net/mkherlakian/high-performance-php-scaling-and-
getting-the-most-out-of-your-infrastructure
 http://www.slideshare.net/mohamed_almasry_lamp/lamp-applications-
scalability-lamp-web-applications
 http://20bits.com/article/10-tips-for-optimizing-mysql-queries-that-dont-
suck

Web Performance & Scalability Tools

  • 1.
  • 2.
    Scalability  It isthe ability of a system to handle a growing amount of traffic/data in a capable manner  How much system can grow  How easy it is to increase capacity
  • 3.
  • 4.
    Solutions  Add hardware.More CPU and RAM to machine  Vertical Scalability  Costly  Higher TCO  Add another server  Horizontal Scalability  More reliable  Less costly as compared to other options  Maintenance cost is higher
  • 5.
    Opportunity Areas  Database Application  Web Server  Scripting Language  Hardware  Hosting
  • 6.
    Database  Query Optimization Log slow queries  Check query plan to make sure indexes are used  Indexes  A lot of how-to's available  MySQL Query Cache  Performance Schema
  • 7.
    Database  Review defaultvalues  Index buffers  Innodb Buffer Pool  Number of open tables  Innodb vs MyISAM  Speed up file system  Per-table file for Innodb  Keep RDBMS updated  A lot of diagnostic tools available
  • 8.
  • 9.
    Database  Load balancing Route read queries to slaves  Write queries to Master  Multi-master Architecture  Offload Database server  Sphinx, Solr  Nosql (Radis, Mongo etc)  MySQL Cluster  Write intensive
  • 10.
    Application  Identify Bottleneck Newrelic  xDebug  Framework profiling tools
  • 13.
    Application  Use frameworkDB APIs  Avoid custom queries  It allows the use of plug-ins / extensions / modules  Use Framework cache APIs  Don’t by-pass framework or CMS  Profile your code  Time  Memory  Profile/Monitor third party services
  • 14.
    Application  Cache output Full page cache  Can be done in:  Application (Disk, memcache, apc etc)  Proxy server (varnish, lightspeed)  Very effective  Wikipedia serves 85% cached content. Only 15% is fetched from DB  Cache static files in memory  Query Results Cache  Reduces number of queries  Reduce IO  Avoid file_exists sort of checks  Reduce file operations
  • 15.
    Web Server  Exploreoptions  Apache  Nginx  Litespeed  Load balancing  HAProxy  Ldirector  Varnish (define multiple backend)  Nginx, Apache balancer modules  Decide balancing strategy  Round robin, Last used, Weighted  Do heavy lifting in crons, message queues
  • 17.
    Web Server  Fine-tuneweb server  Don’t rely on default configurations  Make web server use multiple cores  E.g worker_processes for nginx  Check your specific server configuration  KeepAlive sort of options  A lot can be done
  • 18.
    Scripting Language (php) Enable opcache  APC  Opcache in 5.5  eAccelerator  Fine-tune settings  Real path cache  Buffers  Max memory per script  Look for best practices for that language
  • 19.
    Hardware  Disk isthe slowest part of the system  Go for SSD  Reduce IO  Offload Extensive downloads  Cloud files  CDN  File system optimizations  Number of files in folder  RAID
  • 20.
    Hosting  Cloud vs.Dedicated  Cloud makes scaling easy  Easy to add hardware  Easy to build  Cloud is cheaper as compared to dedicated hardware  Easy to separate DB & Application server  Avoid having control panels on servers  Cloud has slight performance disadvantage  Does not work well when it is raining.
  • 21.