Where's my web server bottleneck?

bronto yellowdog-general@lists.terrasoftsolutions.com
Wed Nov 20 16:47: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.

Is Apt reliable for this?  I could never get it working in 2.0.  Will 
it hose any of my existing self compiled applications?

>- If you've migrated to ext3, make sure you're not doing a full journal. 
>   See google for more info

No, still ext2.

>  > Beige G3 tower 233
>
>- should be ok-ish
>
>>  768 MB RAM (which I believe it the capacity)
>
>- plenty

Great news.

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

Swap is on the 4gb.  No unallocated space on the 60gb.  Its been two 
weeks since my last reboot, today was my heaviest day since then, I 
have X running, and no swap space is being used.

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

Good suggestion.

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

CD & (scsi)CD-ROM.  No zip.  You're right, I just used an available 
slot, must have been a slave but I'll check.  I remember having to 
change some cables around to some of them to reach.

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

Noted.

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

Good tip.

>  > connected to internet via bronze DSL (which means 256k up, 768 down) :')
>>
>
>I'm sure you understand the implication of that statement ;)

Yes, but what I don't know is the relative effects of different 
upgrades.  I have a net traffic monitor running often and I NEVER see 
it come close to saturating the network.  I presume it's reading the 
cards capability and has no clue that the connection's limit is.

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

The 60gig drive is partitioned to contain both the /home and /var 
directories in separate partitions.
Are there any docs for jpcaching PostNuke anywhere?  I looked at 
jpcache and it seemed to me like it wouldn't be that effective if the 
page was changing all the time.  Curious: what's your pn username, 
I'd probably recognize it.  I'm bronto.

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

I had planned on migrating the postnuke services to a speedier box 
when I outgrew this one, and leaving the other services on this one.

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

Oh, I know all about the DSL quality of my connection.  For web 
surfing it's OK, but I frequently experience latencies in responses 
that I can't blame on the server.  No, I am negotiating a deal with 
someone I know to get on to their dedicated, genuine T1 running other 
servers.  No browsers there :').

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

It's data.  No individually heavy images but lots of light ones over 
and over.  And a banner ad or two.

thanks for your detailed responses.

Rob