1.

Apache server performance Apache server performance can be improved by adding additional hardware resources such as RAM, faster CPU etc. But, most of the time, the same result can be achieved by custom configuration of the server. his article loo!s into getting ma"imum performance out of Apache with the e"isting hardware resources, specifically on the #inu" systems. $f course, it is assumed that there is enough hardware resources, especially enough RAM that the server isn%t swapping fre&uently. 'irst two sections loo! into various Compile( ime and Run( ime configuration options. Run( ime section assumes that Apache is compiled with prefor! MPM. ) P compression and caching is discussed ne"t. 'inally, using separate servers for serving static and dynamic contents are being discussed. Basic !nowledge of compiling and configuring Apache, and #inu" are assumed. 2 Compile-Time Configuration Options 2.1 Load only the required modules: he Apache ) P *erver is a modular program where the administrator can choose the functionality to include in the server by selecting a set of modules +,-. he modules can be either statically compiled to the httpd binary or else can be compiled as .ynamic *hared $b/ects 0.*$s1. .*$ modules can be either compiled when the server is built or else can use the ap"s utility to compile and add at a later date. he module mod2so must be statically compiled into the Apache core to enable .*$ support.

Run apache with only the re&uired modules. his reduces the memory footprint and hence the server performance. *tatically compiling modules will save RAM that%s used for supporting dynamically loaded modules, but one has to recompile Apache whenever a module is to be added or dropped. his is where the .*$ mechanism comes handy. $nce the mod2so module is statically compiled, any other module can be added or dropped using the #oadModule command in httpd.conf file ( of course, you will have to compile the modules using ap"s if it wasn%t compiled when the server was built. 2.2 Choose appropriate ! : Apache server ships with a selection of Multi(Processing Modules 0MPMs1 which are responsible for binding to networ! ports on the machine, accepting re&uests, and dispatching children to handle the re&uests +3-. $nly one MPM can be loaded into the server at any time. Choosing an MPM depends on various factors such as whether the $* supports threads, how much memory is available, scalability versus stability, whether non(thread(safe third(party modules are used, etc.. #inu" systems can choose to use a threaded MPM li!e wor!er or a non(threaded MPM li!e prefor!4 5or!er MPM uses multiple child processes. 6t%s multi(threaded within each child and each thread handles a single connection. 5or!er is fast and highly scalable and the memory footprint is comparatively low. 6t%s well suited for multiple processors. $n the other hand, wor!er is less tolerant to faulty modules and faulty threads can affect all the threads in a child process. Prefor! MPM uses multiple child processes, each child handles one connection at a time. Prefor! is well suited for single or double CPU systems, speed is comparable to that of wor!er and it%s highly tolerant to faulty modules and crashing children. But the memory usage is high, more traffic leads to

more memory usage. " #un-Time Configuration Options ".1 $%& loo' up: he )ostname#oo!ups directive enables .7* loo!up so that hostnames can be logged instead of the 6P address. his adds latency to every re&uest since the .7* loo!up has to be completed before the re&uest is finished. )ostname#oo!ups is $ff by default in Apache 8.3 and above. #eave it $ff and use post(processing program such aslogresolve to resolve 6P addresses in Apache%s access logfiles. #ogresolve ships with Apache. 5hen using Allow from or .eny from directives, use 6P address instead of a domain name or a hostname. $therwise a double .7* loo!up is performed to ma!e sure that the domain name or the hostname is not being spoofed. ".2 Allo(Override: 6f Allow$verride is not set to %7one%, then Apache will attempt to open .htaccess file 0as specified by Access'ile7ame directive1 in each directory that it visits. 'or e"ample4 .ocumentRoot 9var9www9html :.irectory 9; Allow$verride all :9.irectory; 6f a re&uest is made for UR6 9inde".html, then Apache will attempt to open 9.htaccess, 9var9.htaccess, 9var9www9.htaccess, and 9var9www9html9.htaccess. hese additional file system loo!ups add to the latency. 6f .htaccess is re&uired for a particular directory, then enable it for that directory alone. "." )ollo(&ymLin's and &ymLin's*fO(ner atch: 6f 'ollow*ym#in!s option is set, then the server will follow symbolic lin!s in this directory. 6f *ym#in!s6f$wnerMatch is set, then the server will follow symbolic lin!s only if the target file or directory is owned by the same user as the lin!. 6f *ym#in!s6f$wnerMatch is set, then Apache will have to issue additional system calls to verify whether the ownership of the lin! and the target file match. Additional system calls are also needed when 'ollow*ym#in!s is 7$ set. 'or e"ample4 .ocumentRoot 9vaw9www9html :.irectory 9; $ptions *ym#in!s6f$wnerMatch :9.irectory; 'or a re&uest made for UR6 9inde".html, Apache will perform lstat01 on 9var, 9var9www, 9var9www9html, and 9var9www9html9inde".html. hese additional system calls will add to the latency. he lstat results are not cached, so they will occur on every re&uest. 'or ma"imum performance, set 'ollow*ym#in!s everywhere and never set *ym#in!s6f$wnerMatch. $r else, if *ym#in!s6f$wnerMatch is re&uired for a directory, then set it for that directory alone.

".+ Content %egotiation: Avoid content negotiation for fast response. 6f content negotiation is re&uired for the site, use type( map files rather than $ptions Multi<iews directive. 5ith Multi<iews, Apache has to scan the directory for files, which add to the latency. "., a-Clients: he Ma"Clients sets the limit on ma"imum simultaneous re&uests that can be supported by the server. 7o more than this much number of child processes are spawned. 6t shouldn%t be set too low such that new connections are put in &ueue, which eventually time(out and the server resources are left unused. *etting this too high will cause the server to start swapping and the response time will degrade drastically. Appropriate value for Ma"Clients can be calculated as4 Ma"Clients = otal RAM dedicated to the web server 9 Ma" child process si>e (((( +?- Child process si>e for serving static file is about ,(3M. 'or dynamic content such as P)P, it may be around 8@M. he R** column in Aps (ylC httpd ((sort4rssA shows non(swapped physical memory usage by Apache processes in !ilo Bytes. 6f there are more concurrent users than Ma"Clients, the re&uests will be &ueued up to a number based on #istenBac!log directive. 6ncrease *erver#imit to set Ma"Clients above ,@B. ".. in&pare&ervers/ a-&pare&ervers/ and &tart&ervers:

Ma"*pare*ervers and Min*pare*ervers determine how many child processes to !eep while waiting for re&uests. 6f the Min*pare*ervers is too low and a bunch of re&uests come in, then Apache will have to spawn additional child processes to serve the re&uests. Creating child processes is relatively e"pensive. 6f the server is busy creating child processes, it won%t be able to serve the client re&uests immediately. Ma"*pare*ervers shouldn%t be set too high, it can cause resource problems since the child processes consume resources. une Min*pare*ervers and Ma"*pare*ervers such that Apache need not fre&uently spwan more than ? child processes per second 0Apache can spwan a ma"imum of 3, child processes per second1. 5hen more than ? children are spawned per second, a message will be logged in the Crror#og. he *tart*ervers directive sets the number of child server processes created on startup. Apache will continue creating child process until the Min*pare*ervers setting is reached. .oesn%t have much effect on performance if the server isn%t restarted fre&uently. 6f there are lot of re&uests and Apache is restarted fre&uently, set this to a relatively high value. ".0 a-#equests!erChild: he Ma"Re&uestsPerChild directive sets the limit on the number of re&uests that an individual child server process will handle. After Ma"Re&uestsPerChild re&uests, the child process will die. 6t%s set to D by default, that means the child process will never e"pire. 6t is appropriate to set this to a value of few thousands. his can help prevent memory lea!age since the process dies after serving a certain number of re&uests. .o not set this too low, since creating new processes does have overhead. ".1 2eepAlive and 2eepAliveTimeout:

he EeepAlive directive allows multiple re&uests to be sent over the same CP connection. his is particularly useful while serving ) M# pages with lot of images. 6f EeepAlive is set to $ff, then for each images, a separate CP connection has to be made. $verhead due to establishing CP connection can be eliminated by turning $n EeepAlive. EeepAlive imeout determines how long to wait for the ne"t re&uest. *et this to a low value, perhaps between two to five seconds. 6f it is set too high, child processed are tied up waiting for the client when they could be used for serving new clients. + 3TT! Compression 4 Caching ) P compression is completely specified in ) P98.8. he server uses g>ip or deflate encoding method to the response payload before it is sent to the client. Client then decompresses the payload. here is no need to install any additional software at the client side since all ma/or browsers support this. Using compression will save bandwidth and improve response time, studies have found a mean compression gain of F@., G +@-. ) P Compression can be enabled in Apache using mod2deflate module. Payload is compressed only if the browser re&uests compression, otherwise uncompressed content is served. A compression aware browser inform the server that it prefers compressed content through the ) P re&uest header ( AAccept(Cncoding4 g>ip,deflateA. hen the server responds with compressed payload and the response header set to A Content(Cncoding4 g>ip 'ollowing e"ample uses telnet to view re&uest and response headers4 5ash-".667 telnet www.webperformance.org HD rying ,?.BD.,3?.,F... Connected to www.webperformance.org 0,?.BD.,3?.,F1. Cscape character is %I-%. )CA. 9 ) P98.8 )ost4 www.webperformance.org Accept(Cncoding4 g>ip,deflate ) P98.8 ,DD $E .ate4 *at, 38 .ec ,DD@ D,4,J4,, KM *erver4 Apache9,.D L(Powered(By4 P)P9@.8.8 Cache(Control4 ma"(age=D C"pires4 *at, 38 .ec ,DD@ D,4,J4,, KM <ary4 Accept(Cncoding Content(Cncoding4 g>ip

Content(#ength4 ,D Content( ype4 te"t9htmlM charset=6*$(HH@J(8 6n caching, a copy of the data is stored at the client or in a pro"y server so that it need not be retrieved fre&uently from the server. his will save bandwidth, decrease load on the server and reduce latency. Cache control is done through ) P headers. 6n Apache, this can be accomplished through mod2e"pires and mod2headers modules. Also there is server side caching, in which the fre&uently accessed contents are stored in memory so that it can be served fast. he module mod2cache can be used for server side caching, it is production stable in Apache version ,.,. , &eparate server for static and dynamic content Apache processes serving dynamic content ta!es about 3M to ,DM of RAM. 6t grows to accommodate the content it%s serving and never decreases until the process dies. *ay an Apache process grows to ,DM to serve a dynamic content. After completing the re&uest, it is free to serve any other re&uest. 6f a re&uest for an image comes in, then this ,DM process is serving a static content which could as well be served by a 8M process. Memory is used inefficiently. Use a tiny Apache 0with minimum modules statically compiled1 as the front(end server to serve static contents. Re&uest for dynamic contents are forwarded to the heavy Apache 0compiled with all re&uired modules1. Using a light front(end server has the advantage that the static contents are served fast without much memory usage and only the dynamic contents are passed over to the heavy server. Re&uest forwarding can be achieved by using mod2pro"y and rewrite2module modules. *uppose there is a lightweight Apache server listening to port HD and the heavyweight Apache listening on port HDHH. hen the following configuration in the lightweight Apache can be used to forward all re&uest e"cept re&uest for images to the heavyweight server. Pro"yPassReverse 9 http499GN) P2)$* O4HDHH9 RewriteCngine on (((( +JRewriteCond GNRCPUC* 2UR6O Q.RS.0gifTpngT/pg1U RewriteRule I90.R1 http499GN) P2)$* O4HDHH9U8 +PAll re&uests, e"cept for images, are pro"ied to the bac!end server. Response is received by the frontend server and then supplied to the client. As far as client is concerned, all the response seem to come from a single server. . Conclusion Configuring Apache for ma"imum performance is tric!y, there are no hard and fast rules. Understand the web server re&uirements and e"periment with various available options. Use tools li!e ab and httperf to measure the web server performance. #ight weight servers such as tu" , thttpd can also be used as the front(end server. 6f a database server is used, ma!e sure it is optimi>ed so that it won%t create any bottlenec!. 6n case of My*P#, mtop can be used to monitor slow &ueries. Performance of P)P scripts can be improved by using a P)P caching product such as urc! MMCache. 6t eliminates overhead due to compiling by caching the P)P scripts in compiled state. http499www.howtoforge.com9configuring2apache2for2ma"imum2performance