Re: PHP Performance and System Load

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, July 20, 2007 2:25 am, Sascha Braun, CEO @ ejackup.com wrote:
> I developed a very large Application, which has at the moment strong
> performace problems, while pages are loaded.

Look into valgrind/callgrind to get an idea of where all your time is
being spent.

Optimizing something that is not taking any significant time pointless.

> At the moment I am trying to lower the number of filesystem calls as
> much as I can. I was able allready to lower the rate of filesystem
> calls from round about 260 calls, which normaly included database
> calls
> each time as well.
>
> Now a page loads with round about 36 Filesystem and database calls, so
> a improvement could really get established.

Whoa.

I'm assuming this helped a lot.

But, really, 36 filesystem calls seems kinda high to me...

> Now, as I might have imagined, the next problem is the object model of
> the application which was very flexible in the past two years. But now
> over time, for example the content management class grew up to 400 Kb
> which is for a web application hell of a lot.

Are you only imagining that the class size is the problem, or have you
some kind of evidence?

> But it seems it is the only class at that enormous size.
>
> I am using the PHP5 autoload functionality exclusive, so no other way
> of loading classes is getting used.
>
> No I started to come in mind of, splitting the cms class into smaller
> potions. Will it really improve the page load, or will the object ini-
> tialisations of the new appearing mass of classes have the same effect
> as a class, stored in the eaccelator cache with a memory consumtion
> round about 400 Kb?

I cannot begin to imagine how splitting it into a bunch of little
classes, each with an fstat for the autoload, is going to improve
things.

Rather the opposite, really.

And splitting it up in the cache will just give you a lot of little
numbers that add up to more than 400k due to overhead, so that doesn't
seem like a "win"...

> Another question is, that I started to include my application
> framework
> over a symlink placed in every webspace directory. I've read somewhere
> that linux needs time to resolve a symlinks target.

I would DEFINITELY look very carefully at this...

If the eaccelerator is unable to properly cache because of the
symlink, your accelerator may be serving no useful purpose...

It's also possible that the accelorator handles symlink just fine, but
anything not cached requires 2 fstats instead of 1.  That's definitely
a slow-down, but how MUCH of a slowdown, and whether it's relevant, is
unknown until you profile (see valgrind/callgrind paragraph at
beginning).

> Can this be a real performance issue? All datasets as well as images,
> modules and all application relevant informations are loaded from that
> symlinked place at the moment.

If all else fails, moving the images to a separate server is a common
way of lightening the load on a busy web-server.

It's generally pretty trivial in a well-designed application.

Actually, it's even pretty trivial in a badly-designed application,
usually.

> The webserver does only contain the webspace filesystem structure as
> well as 5 line of PHP Code dummies, for every document in the content
> management system, to avoid the usage of mod_rewrite.

I'm not sure what this means, though I'm going to hazard a guess that
you've got some kind of front-controller model where a 5-line PHP
script is pounded to figure out what other content to serve up.

While this is really nifty for a lot of reasons, it *DOES* mean that
you're hitting that 5-line script for every page hit, which is an
extra fstat call, unless your cache is working properly.

If the cache is working properly, it's fine.

If not, fix the cache, or consider a different model...

> It would be really wonderfull, to be able to discuss my questions with
> you people here :))

Before you do anything else, I stress again that using
valgrind/callgrind (or any profiling tool) to find your performance
bottleneck MUST be your first step.

Anything further work or even discussion is pretty pointless without
that.

-- 
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


[Index of Archives]     [PHP Home]     [Apache Users]     [PHP on Windows]     [Kernel Newbies]     [PHP Install]     [PHP Classes]     [Pear]     [Postgresql]     [Postgresql PHP]     [PHP on Windows]     [PHP Database Programming]     [PHP SOAP]

  Powered by Linux