Hello
I was wondering: Are template engines like CakePHP and Smarty, or
caches like APC etc. worth it, even if the contents of the SELECT from
MySQL differs from user to user?
Thank you.
On Thu, 17 Jan 2008 20:10:44 +0100, Gilles Ganault
wrote:
> I was wondering: Are template engines like CakePHP and Smarty, or
> caches like APC etc. worth it, even if the contents of the SELECT from
> MySQL differs from user to user?
Efficiency wise (using or resources) in my experience hardly, but that may
have to do with the nature of my projects. They are however usefull for
multi-developer teams, where some may be less PHP literate of plainly
HTML/CSS designers, in which case a good templating system let's them do
what they want without to need to disturb the other developers.
--
Rik Wasmus
On Thu, 17 Jan 2008 20:21:03 +0100, "Rik Wasmus"
>Efficiency wise (using or resources) in my experience hardly, but that may
>have to do with the nature of my projects.
Thanks for the input. The reason was really about performance, not
about how to deal with a whole team working on the same PHP
application.
I'll rephrase it this way: What are the requirements for a PHP page to
be cached?
Do I need to move all the MySQL calls to other pages, and just pass
the contents as eg. $stuff_to_display to PHP pages acting as views?
Gilles Ganault wrote:
> On Thu, 17 Jan 2008 20:21:03 +0100, "Rik Wasmus"
>
>> Efficiency wise (using or resources) in my experience hardly, but that may
>> have to do with the nature of my projects.
>
> Thanks for the input. The reason was really about performance, not
> about how to deal with a whole team working on the same PHP
> application.
>
> I'll rephrase it this way: What are the requirements for a PHP page to
> be cached?
>
> Do I need to move all the MySQL calls to other pages, and just pass
> the contents as eg. $stuff_to_display to PHP pages acting as views?
>
I agree with Rik. I don't find them overly useful for my projects,
either. But others seem to think they're the greatest thing since
sliced bread. YMMV.
The PHP code itself isn't cached unless you install an accelerator. The
source may still be in a system cache, for instance. But not the
completed page.
The HTML output my be cached by the client or any server between your
site and the clients, based on things you can recommend but not control.
The real question here is though - are you observing performance
problems? Or are you prematurely optimizing?
And if you are having performance problems, what is the source of your
problems? Unless you're getting 1K hits per second on your PHP pages, I
very much doubt it is the PHP interpreter.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
On Thu, 17 Jan 2008 20:30:10 -0500, Jerry Stuckle
>The real question here is though - are you observing performance
>problems? Or are you prematurely optimizing?
I'm going step by step so as to understand where performance can be a
problem. It makes sense that we should avoid having the PHP
interpreter needlessly reparsing pages it already parsed into opcode
before, but I'm clear as to what I _shouldn't_ include in a PHP page
so that it's kept in the cache by the accelerator.
>And if you are having performance problems, what is the source of your
>problems?
Without experience in this sort of thing, it's difficult to tell. A
big "load average" as reporter by top (60 instead of below 1) is
apparently a big sign of overload, but we're having a difficult time
tracking down where the problem lies. Maybe 400 sleeping processes and
15MB Apache processes are a sign of bad I/O (hard-disk, network, or
MySQL waiting to service queries).
It's just an opportunity for me to really get down to how LAMP
applications should be built so they can scale beyond a few ten's of
users.
Gilles Ganault wrote:
> On Thu, 17 Jan 2008 20:30:10 -0500, Jerry Stuckle
>
>> The real question here is though - are you observing performance
>> problems? Or are you prematurely optimizing?
>
> I'm going step by step so as to understand where performance can be a
> problem. It makes sense that we should avoid having the PHP
> interpreter needlessly reparsing pages it already parsed into opcode
> before, but I'm clear as to what I _shouldn't_ include in a PHP page
> so that it's kept in the cache by the accelerator.
>
Don't. Find your performance problem. 99%+ have absolutely nothing to
do with the interpreter, and an accelerator will make no noticeable
difference.
>> And if you are having performance problems, what is the source of your
>> problems?
>
> Without experience in this sort of thing, it's difficult to tell. A
> big "load average" as reporter by top (60 instead of below 1) is
> apparently a big sign of overload, but we're having a difficult time
> tracking down where the problem lies. Maybe 400 sleeping processes and
> 15MB Apache processes are a sign of bad I/O (hard-disk, network, or
> MySQL waiting to service queries).
>
Then get a sysadmin who is experienced in it. Otherwise you're shooting
in the dark. You can eventually find it. It may take you a few months,
though.
> It's just an opportunity for me to really get down to how LAMP
> applications should be built so they can scale beyond a few ten's of
> users.
>
This most probably has nothing ti do with "how LAMP applications should
be built". More likely it's lack of resources on the server.
Get a good Linux sysadmin. You can find consultants. It will be worth
the money.
And go to a Linux support group to find out what's going on with your
system.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
On Jan 18, 3:47 am, Gilles Ganault
> On Thu, 17 Jan 2008 20:30:10 -0500, Jerry Stuckle
>
>
> >The real question here is though - are you observing performance
> >problems? Or are you prematurely optimizing?
>
> I'm going step by step so as to understand where performance can be a
> problem. It makes sense that we should avoid having the PHP
> interpreter needlessly reparsing pages it already parsed into opcode
> before, but I'm clear as to what I _shouldn't_ include in a PHP page
> so that it's kept in the cache by the accelerator.
>
The only real problem is the sizer of the cache - it needs to be large
enough to give a good hit ratio while not stealing resources from
apache et al. Guesswork and experimentation are the only way to solve
this.
Note - template systems will typically slow performance compared to
code written without them - but for team development they save a lot
of hassles - unless you're Google, adding hardware is cheaper than
programmer time.
> Without experience in this sort of thing, it's difficult to tell. A
> big "load average" as reporter by top (60 instead of below 1) is
> apparently a big sign of overload, but we're having a difficult time
> tracking down where the problem lies. Maybe 400 sleeping processes and
> 15MB Apache processes are a sign of bad I/O (hard-disk, network, or
> MySQL waiting to service queries).
>
Make sure you've got mod_gzip configured and you're compressing output
from PHP (getting the request off the server quicker typically
outweighs the processing overhead by a huge factor).
Next - make sure you're returning good caching information from every
script and bit of static content on your server. Watch out for 304
responses - if you've got the caching right you may still get a
benefit by eliminating the conditional part of a if-modified-since /
if-none-match request.
> It's just an opportunity for me to really get down to how LAMP
> applications should be built so they can scale beyond a few ten's of
> users.
? You've got load problems with tens of users??????!!!
Then the above are not likely to help.
You should probably focus your efforts on the database - switch on
mysql_slow_query logging and fix all the problems - start with the
database schema - once you've exhausted everything there, try adding
hardware.
C.
On Fri, 18 Jan 2008 05:16:38 -0800 (PST), "C.
(http://symcbean.blogspot.com/)"
>? You've got load problems with tens of users??????!!!
>
>Then the above are not likely to help.
>
>You should probably focus your efforts on the database - switch on
>mysql_slow_query logging and fix all the problems - start with the
>database schema - once you've exhausted everything there, try adding
>hardware.
Yup, judging from the answers here, I got the feeling PHP wasn't the
most likely suspect. We'll check queries, and if mysql_slow_query
doesn't return anything suspicious, we'll upgrade the hardware (CPU,
HD, RAM).
Thanks guys.