A question about efficiency

[Stephen Oakes]

I am developing a site which will be very dynamic. Most of the displayed
content will come from a database (MySql) via PHP.

Some types of pages will change frequently (something like a forum page
which is always having new content added to it) and others will only change
once a day (a new news item gets added, etc.).

Although I can optimise my queries and my PHP scripts, there is still the
potential for the site to get congested, once a large number of people start
accessing it.

The question is how do I make sure it performs well? There are several
options I might consider, such as:
- don't do anything, but rely on server caching. Is PHP / Apache caching
any good?
- Periodically "publish" my PHP-generated pages to flat HTML pages and serve
them up instead of the PHP.
- Other things?

Any thoughts?

--
Stephen Oakes

[Erwin Moller]

Stephen Oakes wrote:

I am developing a site which will be very dynamic. Most of the displayed
content will come from a database (MySql) via PHP.

Some types of pages will change frequently (something like a forum page
which is always having new content added to it) and others will only
change once a day (a new news item gets added, etc.).

Although I can optimise my queries and my PHP scripts, there is still the
potential for the site to get congested, once a large number of people
start accessing it.

The question is how do I make sure it performs well? There are several
options I might consider, such as:
- don't do anything, but rely on server caching. Is PHP / Apache caching
any good?
- Periodically "publish" my PHP-generated pages to flat HTML pages and
serve them up instead of the PHP.
- Other things?

Any thoughts?

--
Stephen Oakes

Hi Stephen,

I am unsure what you expect from the first solution.
Is there any way Apache/PHP can cache requests that depend on
databasecontent that changes all the time?
I don't think so, but maybe I am wrong. (Happens daily. :P)

You second approach is easy to implement, and easy to understand.
I did it before, and it works realy easy.

The approach I choosed was a little different from the one you describe, but
similar:
1) I identified a bunch of pieces in pages that seldom change but need a lot
of Database-querying.
2) All those pieces were made include-files. Nothing fancy, just a plain
include.
3) I programmed on relevant 'triggers' (Not database-triggers) on places
where the includefiles were modified (mostly by an admin that changed
something in the database). These triggers simply called a routine that
rebuilded the included files.
In this way you:
- do not need a cronjob or anything like that.
- And all your includefiles are always up to date. Immediately.

Of course, it is up to you to decide which pieces on your site are suitable
for this approach.

Just my 2 cents.

Regards,
Erwin Moller

[Stephen Oakes]

"Erwin Moller" <si*****************************@spa.com> wrote...

- don't do anything, but rely on server caching. Is PHP / Apache caching
any good? - Periodically "publish" my PHP-generated pages to flat HTML pages and
serve them up instead of the PHP. - Other things?

I am unsure what you expect from the first solution.
Me too, that's why I asked. I don't really know enough about how
server/mysql caching works to know whether I need do anything extra.
You second approach is easy to implement, and easy to understand.
I did it before, and it works realy easy.

The approach I choosed was a little different from the one you describe,
but
similar:
...
Yes, that's the basic approach I had in mind, although more on a per-page
basis than part-page. That idea might help in some places.
Of course, it is up to you to decide which pieces on your site are
suitable
for this approach.

Did you notice any improvements in speed?

--
Stephen Oakes

[Erwin Moller]

Stephen Oakes wrote:

"Erwin Moller" <si*****************************@spa.com> wrote...

- don't do anything, but rely on server caching. Is PHP / Apache
caching any good? - Periodically "publish" my PHP-generated pages to flat HTML pages and
serve them up instead of the PHP. - Other things?

I am unsure what you expect from the first solution.
Me too, that's why I asked. I don't really know enough about how
server/mysql caching works to know whether I need do anything extra.

So maybe there are great solutions out there that work great, we both don't
know about.
:-)
You second approach is easy to implement, and easy to understand.
I did it before, and it works realy easy.

The approach I choosed was a little different from the one you describe,
but
similar:
...

Yes, that's the basic approach I had in mind, although more on a per-page
basis than part-page. That idea might help in some places.

In my case I had a few lists (top10 like stuff) that appeared on several
pages. So a small piece of HTML in an include made the most sense in my
situation.
Of course your situation might differ, and you need complete pages: but
principle is the same, I expect.

Of course, it is up to you to decide which pieces on your site are
suitable
for this approach.
Did you notice any improvements in speed?

Yes.
Some of the queries I needed took up a lot of time (because of quite complex
calculations needed to produce the top10 lists).

I would like to add that the above solution is really easy to implement.
Instead of writing the html to output, you just put it into the appropriate
file.

Of course the user PHP/WWW-data/nobody/whatever needs writepermission in the
directory where you store these files. That is why I made a special
directory for it, because I didn't want that that user had writepermission
on all my files, so in case of a securitybreach, the damage would be
limitted to those includefiles.

Hope this helps you a bit.

Regards,
Erwin Moller

--
Stephen Oakes

[Chung Leong]

My advise is to wait till you have a congestion problem before dealing
with it. Unless the success of a site is somehow guaranteed, your focus
should be on making it a success, instead of worrying about it becoming
too successful.

[NC]

Stephen Oakes wrote:

I am developing a site which will be very dynamic. Most of the displayed
content will come from a database (MySql) via PHP.

Some types of pages will change frequently (something like a forum page
which is always having new content added to it) and others will only change
once a day (a new news item gets added, etc.).

Although I can optimise my queries and my PHP scripts, there is still the
potential for the site to get congested, once a large number of people start
accessing it.

The question is how do I make sure it performs well? There are several
options I might consider, such as:
- don't do anything, but rely on server caching. Is PHP / Apache caching
any good?
- Periodically "publish" my PHP-generated pages to flat HTML pages and serve
them up instead of the PHP.
- Other things?

Consider MySQL query caching...

Cheers,
NC

[Scott Auge]

In article <11*********************@g14g2000cwa.googlegroups. com>,
"Chung Leong" <ch***********@hotmail.com> wrote:

My advise is to wait till you have a congestion problem before dealing
with it. Unless the success of a site is somehow guaranteed, your focus
should be on making it a success, instead of worrying about it becoming
too successful.

This is the best advice I have read in a long long time!

So many people focus on problems that aren't even there...

And this kind of problem is a "good problem" to have. Hopefully when it
happens, you will be making some money to buy the resources to fix it.

[Good Man]

"NC" <[e-mail]> wrote in
news:11**********************@g44g2000cwa.googlegr oups.com:

Consider MySQL query caching...

this will make a HUGE difference for the type of application you are
proposing.... it is not enabled out of the box, but it's easy to set up.

http://www.databasejournal.com/featu...le.php/3110171

[Stephen Oakes]

"Scott Auge" <sc********@yahoo.com> wrote...

My advise is to wait till you have a congestion problem before dealing
with it. Unless the success of a site is somehow guaranteed, your focus
should be on making it a success, instead of worrying about it becoming
too successful.

This is the best advice I have read in a long long time!

hmm...yeah, but not if the subsequent "dealing with it" involves an entire
architectural redesign.

Frankly I'd rather at least know what my options are before I build the
system.

Thanks to those who've replied; there've been some helpful ideas.

--
Stephen Oakes

[Alexey Kulentsov]

Stephen Oakes wrote:

I am developing a site which will be very dynamic. Most of the displayed
content will come from a database (MySql) via PHP. .... The question is how do I make sure it performs well?

1. All pages are generated by 404 script. First time page is generated,
second time it's just a static page.

2. When you change your data, engine must delete from disk generated
pages which depends on this data. For each class you need method
returned list of URL to delete if this object is changed.

3. When you develop design have in mind this approach. Separately
changed objects in database must be presented by separately cached
objects in URL space. For example in you make shop don't insert HTML
code with current basket info right to page with product info. It must
be _separate_ object: iframe, frame, included javascript file, etc... In
this case you can make product info page static. And it will be
regenerated only when product is changed.

Lazy way.

[R. Rajesh Jeba Anbiah]

Stephen Oakes wrote:
<snip>

Although I can optimise my queries and my PHP scripts, there is still the
potential for the site to get congested, once a large number of people start
accessing it.

<snip>

FWIW, <news:11*********************@z14g2000cwz.googlegr oups.com> (
http://groups-beta.google.com/group/...63108151657c33
)

--
<?php echo 'Just another PHP saint'; ?>
Email: rrjanbiah-at-Y!com Blog: http://rajeshanbiah.blogspot.com