Re: Improving performance by generating a static html file?

Much thanks for the replies. As for static vs dynamic, what i have would be a list of replies to a topic, so the content of that file would be the same untill someone replies/edits/what not. I dont think there would be that much overhead, just a bunch of print FILE;'s

I looked into the cache::cache module, and im a little unsure of exactly how i would use it to 'cache' a html page?

And as for optimizing my mysql queries, can you point me to a good reference or give me some tips?

Comment on Re: Improving performance by generating a static html file?

Replies are listed 'Best First'.
Re: Re: Improving performance by generating a static html file? by shambright (Beadle) on Apr 12, 2002 at 18:11 UTC
And as for optimizing my mysql queries, can you point me to a good reference or give me some tips? First, joealba had mentioned to make sure that your database tables have good indexes and keys - and he is right. From experience (of not doing this the first time around) I would add to make certain that your database is properly normalized BEFORE it gets large and painfully slow to query. There are plenty of good places to look for info on this. Go to Google and search for 'MySQL database normalization' -- for that matter, look at mysql.org for hints. You know that you are in good shape if you can get whatever you are looking for with an absolute minimum number of query statements using table joins. One query is obviously ideal. If the query is slow, you may want to rethink your keys/indexes. The performance benefits of a persistent database connection has already been addressed. If you can, I would suggest using it. my $.02	[reply]

Replies are listed 'Best First'.

Re: Re: Improving performance by generating a static html file?
by shambright (Beadle) on Apr 12, 2002 at 18:11 UTC

And as for optimizing my mysql queries, can you point me to a good reference or give me some tips?

First, joealba had mentioned to make sure that your database tables have good indexes and keys - and he is right.

From experience (of not doing this the first time around) I would add to make certain that your database is properly normalized BEFORE it gets large and painfully slow to query.

There are plenty of good places to look for info on this. Go to Google and search for 'MySQL database normalization' -- for that matter, look at mysql.org for hints.

You know that you are in good shape if you can get whatever you are looking for with an absolute minimum number of query statements using table joins. One query is obviously ideal. If the query is slow, you may want to rethink your keys/indexes.

The performance benefits of a persistent database connection has already been addressed. If you can, I would suggest using it.

my $.02

[reply]