Re: [PHP-DEV] Speed/Performance From: szii <email protected>
Date: 12/15/00

For anyone interested, we're seeing a HUGE differential by using include()
or
require() calls. Seems that not only is it slowing down the actual
connections,
but is also causing a considerable amount of swapping.
The test was an include() of a file which contained only <?php ?> and
watched
with top and vmstat.

We're going to check on the bware stuff, and possibly look into moving the
files onto a RAM drive to try and avoid kernel mode. Does linux view
RAM drives as "hardware" and still swap into kernel mode to access it? If
nothing else it'll drop the amount of raw disk hits.
There's been talk of a PHP function cache...has anyone looked into an
include/require file cache? Lose, maybe 10M of RAM and gain a sizeable
increase in performance.

-Szii

----- Original Message -----
From: szii <email protected> <szii <email protected>>
To: <php-dev <email protected>>
Cc: Stig S. Bakken <ssb <email protected>>
Sent: Friday, December 15, 2000 1:43 AM
Subject: Re: [PHP-DEV] Speed/Performance

> Most correct...however, we're trying to hammer it. We WANT it to thrash.
> We WANT it to choke. Until it does, we can't see where our performance
> bottlenecks are. Adding more RAM would simply hide possible chokepoints.
> Again, it's a dev machine that's not running production stuff. But if we
> can
> get some numbers on this little K6, we can be assured that when we move
> it to the REAL servers that it'll run well, and has already been tweaked
> against a lower-profile machine.
>
> -Szii
>
>
> ----- Original Message -----
> From: Stig S. Bakken <ssb <email protected>>
> To: <szii <email protected>>
> Cc: <php-dev <email protected>>
> Sent: Friday, December 15, 2000 5:04 AM
> Subject: Re: [PHP-DEV] Speed/Performance
>
>
> > szii <email protected> wrote:
> > >
> > > We're running some speed trials right now, and seeing that .php files
> > > are taking considerably longer even if they have NO <?php ?> tags.
> > > They're static pages, but by having the extension they're running
slower
> > > do to the parser running through them.
> > >
> > > Does anyone have any "performance" tips for PHP files? Caches that
> > > aren't turned on by default?
> > >
> > > Here are the ones I know:
> > > Compile into Apache, not as a DSO
> > > Lots O RAM
> > > Don't use "known php extensions" for non-php files.
> > >
> > > We're taking a single-CPU client running a multithreaded app.
> > > It spawns X threads each of which open a socket, requests a
> > > file, and shuts down the socket.
> > >
> > > At 100 threads we're choking the server (K6 233) and not
> > > even touching the client's CPU usage. We're also deep
> > > into VM/swap space, even at 192 MB RAM. This is quite
> > > obviously not our production server (cringe at the thought).
> > > We're just "playing" with this one.
> > >
> > > Any one have more ideas? 2.4 kernel with khttpd? Won't affect
> > > PHP, but could make static pages faster...
> >
> > It seems to me like you have a memory problem. With Apache/PHP you are
> > in deep trouble if you run out of physical memory, and when you say that
> > your server is choking, it sounds to me like it's "trashing" (spends
> > most of its time paging memory in and out). 192MB RAM is not exactly a
> > lot these days, even my laptop has more. :-)
> >
> > try {
> > while (server_trashes) {
> > add_more_ram();
> > }
> > } catch (OutOfMemorySlotsException) {
> > rewrite_code();
> > }
> >
> > I wouldn't consider running a system like the one you are outlining with
> > less than 512MB.
> >
> > - Stig
>
>
> --
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, e-mail: php-dev-unsubscribe <email protected>
> For additional commands, e-mail: php-dev-help <email protected>
> To contact the list administrators, e-mail: php-list-admin <email protected> 

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: php-dev-unsubscribe <email protected>
For additional commands, e-mail: php-dev-help <email protected>
To contact the list administrators, e-mail: php-list-admin <email protected>