real world performance tuning n.
Skip this Video
Download Presentation
Real World Performance Tuning

Loading in 2 Seconds...

play fullscreen
1 / 23

Real World Performance Tuning - PowerPoint PPT Presentation

  • Uploaded on

Real World Performance Tuning. Ask Bjørn Hansen OSCON 2001. Performance Tuning. Show more pages Faster With less resources Design the architecture right Optimize the code (in that order!). Memory usage. N connections = N fat mod_p erl processes

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Real World Performance Tuning' - hedy-anthony

Download Now 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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
real world performance tuning
Real WorldPerformance Tuning

Ask Bjørn Hansen

OSCON 2001

performance tuning
Performance Tuning
  • Show more pages
  • Faster
  • With less resources
  • Design the architecture right
  • Optimize the code
  • (in that order!)
memory usage
Memory usage
  • N connections = N fat mod_p erl processes
  • Fat processes doing little other than buffering to slow clients
memory usage1
Memory usage

20 connections per second

+ Each request takes 3 seconds to write to the network

= 60 active mod_perl processes

+ 15 spare processes for peaks

= 75 active mod_perl processes

* 20MB-12MB shared = 8MB memory

= 600MB memory

reverse proxy
Reverse proxy
  • Offload the buffering to a reverse proxy
  • Can
    • Do caching
    • Serve static content
    • Distribute requests to different backend processes
  • All in a “slim” process
reverse proxies
Reverse proxies
  • squid
    • best caching
    • not as flexible for a "reverse proxy" as mod_proxy
  • apache/mod_proxy
    • simple to configure
    • known environment
    • can cache
    • mod_rewrite
apache mod proxy
  • Specify what to pass through

RewriteRule ^/(foo/.*) http://localhost:8001/$1 [P]

  • Specify what NOT to pass through

RewriteCond %{REQUEST_URI} !^/images/

RewriteRule /(.*) http://localhost:8002/$1 [P]

  • Allow fix up of $r->connection->remote_ip

LoadModule proxy_add_forward_module modules/

memory usage with apache mod proxy
Memory Usage with apache/mod_proxy
  • mod_proxy

20 connections per second

+ Each request takes 3 seconds

to write to the network

= 60 active mod_proxy processes + 15 spare

= 75 running mod_proxy processes

75 mod_proxy processes (300KB each)

= ~25MB memory

memory usage with apache mod proxy1
Memory Usage with apache/mod_proxy
  • mod_perl

20 connections per second

+ Each request takes <.05 seconds

to write to the proxy

= 1-2 active mod_perl processes + 3 spare

= 5 running mod_perl processes

5 mod_perl processes (8MB non-shared each)

= 40MB memory

memory usage with apache mod proxy2
Memory Usage with apache/mod_proxy


= 65MB total memory usage

  • >500MB less than the mod_perl alone!
basic httpd conf tuning
Basic httpd.conf tuning
  • mod_proxy

MaxClients 512

StartServers 50

MinSpareServers 20

MaxSpareServers 100

  • mod_perl

MaxClients 5

StartServers 3

MinSpareServers 1

MaxSpareServers 5

Port 80

Listen 8001

mod status

ExtendedStatus on

<Location /server-status>

SetHandler server-status

Order deny,allow

Deny from all

Allow from


virtualhost configuration
<VirtualHost> configuration





RewriteCond %{REQUEST_URI} !.*\.(gif|png|jpg)$

RewriteRule /(.*) http://localhost:8010/$1 [P]






RewriteRule /(.*) http://localhost:8020/$1 [P]


uri configuration
URI configuration

RewriteRule /(bar/.*) http://localhost:8030/$1 [P]

RewriteRule /(foo/.*) http://otherhost:8040/$1 [P]

  • Each backend process can run as a different user
    • A process per developer
    • A process per customer
    • A process per site
  • Backends can run on different machines
focus on code quality
Focus on code quality
  • The mod_perl guide recommends not using the IO:: modules or use vars qw(%foo);
  • I say use them if you would like to
    • far fewer mod_perl processes
  • use Exporter to export your function names as needed
  • Of course, don't go crazy and use POSIX and everywhere
load balancing
Load balancing
  • mod_rewrite can do simple load balancing
  • the mod_perl processes can be behind a load balancer,

RewriteRule /(foo/.*)$1 [P]

  • mod_backhand
  • Browsers/end user proxies can cache from servers
    • set the right headers, content-length, last-modified
  • Reverse proxies
    • you set the rules, if complete documents can be cached
  • Application can cache from other parts of the system (eg database)
    • even the database can cache some of what it has done
http headers
HTTP headers
  • Expires:
  • Content-Length:
  • Cache-Control:
  • Pragma: (old "Cache-Control")
  • When the complete documents can be cached.
  • If-Modified-Since:
    • 304 response
application caching
Application caching
  • Generate static content every N minutes
    • for small set of files
  • Save results from the SQL database
    • in a local BerkeleyDB or similar
  • Generate a Storable or BerkeleyDB file centrally and rsync it to each mod_perl server
  • Create summary tables in the database
    • to lighten the load of heavy queries
  • Mix and match for fragments
caching summary
Caching summary
  • Decide for how long data can be considered "fresh enough"
  • Cache fragments of pages where possible
  • Make each part of the system cache and aggregate as much as possibly
  • Make SQL queries as simple and fast as possibly
  • Databases are hard(er) to scale
  • Reverse proxy minimizes the need for many concurrent database connections
  • Apache::DBI minimizes the number of new connections made
  • Caching minimizes the number of lookups
  • Summary tables can make the lookups faster
  • Architecture more important than code
  • Use many proxies
    • Allowing fewer heavy backends
  • Caching is fundamental
  • The mod_perl guide's performance section
    • lot's of nitty gritty details
  • DBI and mod_perl
  • Database performance
    • Tim’s Advanced DBI Tutorial
  • These slides