Hi
One of the ways to raise performance for PHP apps is to
separate static contents from dynamic contents, so that the former can
be compiled once into cache.
Can someone give me a simple example of how this kind of thing is done
when making calls to MySQL?
Thank you.
Gilles Ganault wrote:
> Hi
>
> One of the ways to raise performance for PHP apps is to
> separate static contents from dynamic contents, so that the former can
> be compiled once into cache.
>
> Can someone give me a simple example of how this kind of thing is done
> when making calls to MySQL?
>
> Thank you.
>
Gilles,
Displaying static output from a PHP page isn't that much overhead. I
doubt you'll even begin to notice the difference until you're running
hundreds of hits per second.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
Post removed (X-No-Archive: yes)
Gary L. Burnore wrote:
> On Sun, 06 Jan 2008 14:26:32 -0500, Jerry Stuckle
>
>
>>Gilles Ganault wrote:
>>> Hi
>>>
>>> One of the ways to raise performance for PHP apps is to
>>> separate static contents from dynamic contents, so that the former
>>> can be compiled once into cache.
>>>
>>> Can someone give me a simple example of how this kind of thing is
>>> done when making calls to MySQL?
>>>
>>> Thank you.
>>>
>>
>>Gilles,
>>
>>Displaying static output from a PHP page isn't that much overhead. I
>>doubt you'll even begin to notice the difference until you're running
>>hundreds of hits per second.
>
> While YOUR sites may only get a hundred hits per seconds but REAL
> websites can get much more.
I don't recall Jerry stating anything about how many hits per second his
sites get?
Also, SOME people can actually string a sentence together using the correct
words.
Seems reading posts and writing them are not amongst your strong points!
Gary L. Burnore wrote:
> On Sun, 06 Jan 2008 14:26:32 -0500, Jerry Stuckle
>
>
>> Gilles Ganault wrote:
>>> Hi
>>>
>>> One of the ways to raise performance for PHP apps is to
>>> separate static contents from dynamic contents, so that the former can
>>> be compiled once into cache.
>>>
>>> Can someone give me a simple example of how this kind of thing is done
>>> when making calls to MySQL?
>>>
>>> Thank you.
>>>
>> Gilles,
>>
>> Displaying static output from a PHP page isn't that much overhead. I
>> doubt you'll even begin to notice the difference until you're running
>> hundreds of hits per second.
>
> While YOUR sites may only get a hundred hits per seconds but REAL
> websites can get much more.
I OWN YOU, Gary! ROFLMAO!
I said NOTHING about my sites!
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
On Sun, 06 Jan 2008 14:26:32 -0500, Jerry Stuckle
>Displaying static output from a PHP page isn't that much overhead.
Good to know. But if PHP pages contain connections to MySQL, their
contents is dynamic, so their opcode cannot be compiled once and kept
in cache? How do real life apps handle this?
Gilles Ganault wrote:
> On Sun, 06 Jan 2008 14:26:32 -0500, Jerry Stuckle
>
>> Displaying static output from a PHP page isn't that much overhead.
>
> Good to know. But if PHP pages contain connections to MySQL, their
> contents is dynamic, so their opcode cannot be compiled once and kept
> in cache? How do real life apps handle this?
>
The PHP code can still be compiled and cached. The results from MySQL
is data, not operations.
And unless you are running an accelerator, the code isn't cached anyway.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
On Jan 6, 10:58 am, Gilles Ganault
>
> One of the ways to raise performance for PHP apps is to separate
> static contents from dynamic contents, so that the former can be
> compiled once into cache.
>
> Can someone give me a simple example of how this kind of thing is
> done when making calls to MySQL?
It's not; you are confusing caching content with caching database
queries.
If you cache content, you put a caching proxy server between your
application and the Internet; the proxy server receives a request from
the Internet and either serves a cached copy of the page being
requested, if it's available, or gets the page from your application,
serves it out and stores a copy in the cache for future use.
If you cache queries, you simply turn on query caching in the MySQL
server; no specific calls from the application are necessary. If you
have queries that are executed often, query caching ensures they are
not executed each time, but rather, their results are retrieved from
cache.
Cheers,
NC
On Sun, 06 Jan 2008 20:48:55 -0500, Jerry Stuckle
>The PHP code can still be compiled and cached. The results from MySQL
>is data, not operations.
So for an accelerator like APC or eaccelerator, I must pay attention
to separating code and display, or those tools won't be able to keep
the op-code in cache.
On Sun, 6 Jan 2008 18:41:32 -0800 (PST), NC
>It's not; you are confusing caching content with caching database
>queries.
Thanks for the clarification.
>If you cache queries, you simply turn on query caching in the MySQL
>server; no specific calls from the application are necessary.
Am I right in saying that MySQL doesn't care from which web user the
query is coming: As long as it's in the DB cache, ie. it's a query
that is often made from web user, regardless of who they are, it will
be sent to the PHP process, significantly improving performance since
MySQL won't actually have to compute it and access the hard disk?
On 7 Jan, 07:04, Gilles Ganault
> On Sun, 6 Jan 2008 18:41:32 -0800 (PST), NC
> >It's not; you are confusing caching content with caching database
> >queries.
>
> Thanks for the clarification.
>
> >If you cache queries, you simply turn on query caching in the MySQL
> >server; no specific calls from the application are necessary.
>
> Am I right in saying that MySQL doesn't care from which web user the
> query is coming: As long as it's in the DB cache, ie. it's a query
> that is often made from web user, regardless of who they are, it will
> be sent to the PHP process, significantly improving performance since
> MySQL won't actually have to compute it and access the hard disk?
If it's in the MySQL cache, yes.
If your pages don't change particularly quickly, you should be looking
at setting caching information via the header() function and using a
caching reverse proxy.
C.
Gilles Ganault wrote:
> On Sun, 06 Jan 2008 20:48:55 -0500, Jerry Stuckle
>
>> The PHP code can still be compiled and cached. The results from MySQL
>> is data, not operations.
>
> So for an accelerator like APC or eaccelerator, I must pay attention
> to separating code and display, or those tools won't be able to keep
> the op-code in cache.
>
No, I didn't say that. You're confusing the code, which can be compiled
and cached, with the data, which is not.
Code for maintainability. Performance wise, you won't notice a
difference until you're running hundreds of hits per second. And if
you're getting that many hits, you'll see other performance problems first.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
Gilles Ganault wrote:
> On Sun, 6 Jan 2008 18:41:32 -0800 (PST), NC
>> It's not; you are confusing caching content with caching database
>> queries.
>
> Thanks for the clarification.
>
>> If you cache queries, you simply turn on query caching in the MySQL
>> server; no specific calls from the application are necessary.
>
> Am I right in saying that MySQL doesn't care from which web user the
> query is coming: As long as it's in the DB cache, ie. it's a query
> that is often made from web user, regardless of who they are, it will
> be sent to the PHP process, significantly improving performance since
> MySQL won't actually have to compute it and access the hard disk?
>
That is true. The same query will just return data from cache. Just
like if two processes read the same file, the OS will return the data
from cache on the second request.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
On Mon, 07 Jan 2008 07:50:55 -0500, Jerry Stuckle
>No, I didn't say that. You're confusing the code, which can be compiled
>and cached, with the data, which is not.
Got it. Thanks.
On Mon, 7 Jan 2008 04:42:08 -0800 (PST), "C.
(http://symcbean.blogspot.com/)"
>If your pages don't change particularly quickly, you should be looking
>at setting caching information via the header() function and using a
>caching reverse proxy.
I'll read up on what those things are. Thanks.
On Jan 6, 11:04 pm, Gilles Ganault
> On Sun, 6 Jan 2008 18:41:32 -0800 (PST), NC
>
> > If you cache queries, you simply turn on query caching in the MySQL
> > server; no specific calls from the application are necessary.
>
> Am I right in saying that MySQL doesn't care from which web user the
> query is coming: As long as it's in the DB cache, ie. it's a query
> that is often made from web user, regardless of who they are, it will
> be sent to the PHP process, significantly improving performance since
> MySQL won't actually have to compute it and access the hard disk?
Yes, as long as the repeating queries are identical, byte for byte.
Cheers,
NC