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