Where's my web server bottleneck?

nathan r. hruby yellowdog-general@lists.terrasoftsolutions.com
Wed Nov 20 15:28:01 2002


On Wed, 20 Nov 2002, bronto wrote:

> YDL 2.1

- Upgrade to 2.3 or make sure you are running a *recent* 2.4 series 
  kernel.
- If you've migrated to ext3, make sure you're not doing a full journal.  
  See google for more info

> Beige G3 tower 233

- should be ok-ish

> 768 MB RAM (which I believe it the capacity)

- plenty

> Data is stored on 60 gig 7200 RPM IBM IDE drive
> Most of Linux is stored on the original 4gig IDE drive
> MacOS booted from an old 500 (or so) Mb SCSI drive

Make sure you have swap on the fasest drive (the 60GB one) if not, add it 
if possible (if you have an extra 256 MB unallocated on that drive) not 
that you're probably swapping that much, but things do swap (like swapd :) 
and that could help.. not the biggest performance things in the world, but 
it *might* help.

Also, the ATA conroller in the g3's wasn't too fast (ata33 IIRC) you may 
want to get an addtional faster ATA controller that will work with your 
drive and put the fast drive on that card as the sole and master device 
on the channel.  The bus speed is still slow on those guys, but it'll be 
better than what you got, and better than nothing.

Thirdly, I bet you have a zip drive and a cdrom in that thing as well.  
this means the logical place to put the 60Gb drive is into the slave slot 
for the onboard ATA controller, this will degrade your drive performance 
further, as the master drive (the 4gb) will always get access to the bus 
first.  you could try flipping the original drive and the 60GB and see 
what happens.  

also, do note that the original drive is probably nearing it's useful 
life, backup early, backup often :)

> original equipment network adaptor (presumably 10 megabit)

Yes, UPG to a decent 10/100 card.  3com cards work nicely in YDL.  This 
won't help a bandwidth problem, but faster is better, and a stronger card 
with better drivers can shave a little time of per request.

> connected to internet via bronze DSL (which means 256k up, 768 down) :')
> 

I'm sure you understand the implication of that statement ;)

> Web applications are Apache, MySQL, Postfix, Courier-imap, and a 
> PostNuke application (php).  The php application is at the moment 
> uncache because of a lack of cache's for the PPC architecture.  I'm 
> aware of some for PPC, but not the ones I want (zend or php 
> accelerator).
> 

jpcache babby!  PostNuke (and all the Nuke's) are not too terriblly speedy
 - you need to do something other than wait for Zend/APC.  using jpcache
will mean you need to poke at some of the files and edit them.  Also, read
up on MySQL performance tuning.  Most liekly the MySQL tables are living
on that slow original 5400RPM drive in /var.. you can move the tables
directory to your faster 60GB drive and you should see a small performance
boot.  I'm sure there are some tuing tips for postnuke out there
somewhere.. if not, Bug 'em and tell them I sent you :)  Caching the
bytecode compiled php doesn't do all that much because you still have to
tear up and down the data structures those cached objects create at every
request (which is a lot and they are big).  jpcache slurps the whole
output page as a statis entity depending on a bunch of stuff.  
SourceForge uses jpcache to make it not slow.  you could also get the Zend 
studio  or compiler and compile your source site into php bytecode.. that 
might make up for the Zend cache not being there.

Above that, there are a bunch of services running on that box, if alot of 
them are getting heavy traffic, you'll maybe want to migrate some of them 
over to something else (for instance, mail service could move to another 
slower box without a lot of hassle).

> It's the connection, right?  But when I move it to a T1, where's the 
> next bottleneck, and how soon will I hit it?
> 

The connection is a serious part of the problem.  what you;re also not 
seeing is that the DSL network you're on is not a commerically designed 
network, so there are probably some things going on that prevent optimal 
performace.  if you're DSl modem locked at 10Mb/sec?  how fast is the 
backbone your DSL service is on?  Is there a lot of traffic at their 
demarcation to the upstream provider?  Who are they (and their upstream 
provider) peered with?  

A 486 with a 10Mb/sec card can saturate a t1 (1.5Mb/sec) all day long with 
static pages / images.  t1's don;t go as far as your thing, espcially as I 
belive you;re just upping your service level, not moving to a co-lo or 
having a dedicated t1 + router installed into your home :)

> FWIW, the latest complaint I got was that the main page (about 100k 
> in size) took 15 sec. to load.
> 

100k is a little big, dontcha think?  Is that page static, dynamic, image 
heavy?  why's it 100k and what being done to generate it.

[nathan@jake www]$ ls -lh *.php
-r--rw-r--    1 apache   www          3.3k Oct 20 17:59 error.php
-rw-r--r--    1 philb    www          4.9k Oct  4 12:45 index2.php
-rw-rw-r--    1 nathan   www           937 Oct  1 11:09 index-old.php
-rw-rw-r--    1 nathan   www          1.0k Oct  1 11:06 index.php
-r--rw-r--    1 apache   www           137 Jun 16 11:14 map.php
-r--rw-r--    1 apache   www           576 Jun 16 11:14 noaccess.php
-r--rw-r--    1 apache   www          6.7k Jun 16 11:15 search.php

Note that the index.php page has two images that top out at about 10k 
together and a auto included header that's 4k for a total of about 15k.  
the index page is the palce you want to be snappy, as that's what gets hit 
the most.

-n
-- 
----------------------------------------
nathan hruby <nathan@drama.uga.edu>
computer services specialist
uga drama
http://www.drama.uga.edu/support/
----------------------------------------