Where's my web server bottleneck?

[bronto]

>  >
>>  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.
>>
>
>Err.. X has no place on a server :)

I'll get into the habit of killing it when I'm not using it now that 
I have real people coming to me server.

>You never see it use more than 256k up or you never see your internal
>network saturated?  Is the machine plugged into the DSl modem or are we
>talking though a cable/dsl router thingy?

That's the main reason I had X running - to see the server activity 
monitors.  I have the Network Load applet showing in the toolbar, 
among other things.  It doesn't display numbers, but the graph 
showing activity is rarely more than a pixel or two high.  Maybe 
there's a better monitor I should be looking at?

 From the wall, the DSL connection goes to my LAN hub, from there to 
the server.  Other pc's are connected to the hub too, but they 
weren't doing any activity while I was testing performance.

>[snip]
>
>>
>>  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.
>>
>
>Don't have one.  I know several of the PostNuke developers from a
>different project :) 
>
>jpcache *will* save a ton of processing time, what you give up is the fact
>that the page is auto generated every time.  I doubt that your pages will
>be changin on a minute by minute basis, so if you jpcached the PN front
>page, with a TTL 5 minutes, that means the machine would only have to run
>php to generate that page, once every five minutes - big savings. 
>jpcache can also look at $_POST, $_GET and $_COOKIE to determin of it
>should feed the user a cached page or live one.  Really it should be a
>simple as at the top of every page you want jpache enabled doing a

I'll remove the time stamp from the top of the site and just leave the date.

>$ttl =360;
>include('/path/to/jpcache');
>
>php is fast, but as someone mentioned it's easy to make slow apps, nuke
>is one of them.  Someone mentioned mod_perl+slashcode as a faster
>alternative - I would caution aginst that.  mod_perl really reqires a lot
>of processing power.  yes it can be fast if it has the hardware behind it,
>and it's super powerful, but it's also a complicated and difficult beast
>to master.

That sounds easy; I'll ask the postnuke/xaraya people if there's any 
gotcha's I should be aware of.  I know they are working on building 
some sort of caching system into it, and it's apparently a difficult 
problem because of the different permission levels each user may/may 
not have.  Did you see the test times I sent last night?  Loading the 
pure html version isn't much different time-wise than loading it 
"live".  Isn't that am indication of how much (little) jpcache will 
help?

>One thing I forgot to mention was to poke at apache's config.  The default
>YDL/Redhat rpm's load every module under the sun and it does help to go in
>and prune mod_perl if you're not using it and other things.  Also make
>sure that hostnakelookups is off, or you have a dedicated caching dns
>server running on that machine.  If you're using lots of .htaccess files
>in your site, stop and move them into your httpd.conf file (.htaccess can
>slow things down a lot)  There are a bunch of speed-tuning tips at
>apache's site as well, you may want to look at them.

Doh!  hostnamelookups are on!

>Images repeated are fine, they'll be pulled fromt he browsers cache on
>successive loads.  Is the "data" generated on the fly by php or not.

There's very little static text in a postnuke site.  I have browser 
caching completely turned off, for accuracy purposes during 
development, but that doesn't explain my visitor's experiences.

>Maybe if you posted a link to your site we could look at what's going on
>we could give you some better tips.

OK.  Since there's a lot of Mac people here they might get a kick out 
of it anyway.  I'm killing X here right now.

http://www.maccounting.net

Rob