Superlman has asked for the wisdom of the Perl Monks concerning the following question:
Hello!
I have a question about efficiency. Is it faster to make up pages on the fly, or to generate an html file and serve that, updating the file whenever changes are made? The pages in question won't be changed more than once a day, but will be accessed often.
I thought it might be faster to just have a perl script refresh the HTML files once a day, or specific files whenever a change is made, than to make them fresh each hit since the output will be the same the vast majority of the time. (If I needed to change the site design, I would just modify the script and run it again)
Will this offer any performance gains? Are there any other concerns I should know about?
Thanks!
Re: Dynamic Web Content- Efficiency
by Chmrr (Vicar) on Sep 08, 2001 at 22:34 UTC
|
Static HTML is several orders of magnitude faster, in general. Some folks did some fairly simple benchmarks of a bunch of dynamic content generation systems. Now, I'd include all of the standard disclaimers about benchmarks and their validity, but it's clear that there's an order of magnitude difference between the mod_cgi results (9.2 hits / second with CGI.pm) and the static HTML (1148.1 hits / second!).
All in all, static pages are your friends if you can get away with them. Be wary, however, of the increased maintenance and tweaking cost as tilly points out.
perl -e 'print "I love $^X$\"$]!$/"#$&V"+@( NO CARRIER'
| [reply] [Watch: Dir/Any] |
Re: Dynamic Web Content- Efficiency
by jepri (Parson) on Sep 08, 2001 at 22:24 UTC
|
There aren't any other concerns, and generating static HTML pages is by far faster. It's a known technique (was used at my last workplace, and they aren't very up to date).
Static HTML is far better because you can unleash things like the kernel web server, which has been clocked at more then 2 times faster than Apache (the kernel server only serves static pages). Then there are the benefits of caching, etc. ____________________
Jeremy
I didn't believe in evil until I dated it. | [reply] [Watch: Dir/Any] |
|
Actually there are other concerns. A lot of them.
The first and simplest is that having a batch process
update pages is less maintainable. Someone can
accidentally remove or break the process, not knowing
what it does, and 6 weeks later you find out that there
is a problem with the page, but have no clue how it was
supposed to work, and there is no obvious trail back to
how it was supposed to be generated. As the mantra
goes, premature optimization is usually wrong.
A closely related second issue is the ease of testing and
storage. It is inherently a faster and more accurate
development cycle to edit a script and see feedback than
it is to edit a batch process, have to run it, and then
get feedback. Much experience indicates that developing
with rapid feedback leads to faster and better development
than developing without it. (All else being equal of
course.)
Third we have the issue of amount of storage. Often to
replace a single dynamic page you have to create multiple
static pages. This can quickly result in a combinatorial
explosion of pages, eventually leading to problems with
storage that make it much saner just to have a dynamic
page in the first place.
And closely related to the ease of storage is the ease of
adding further customizations. If you have a dynamic
page and want to add another customization, it is easily
done, just add it. If you have a batch process you have
to consider whether or not to rewrite it to be a dynamic
script to avoid the pain, or whether you will add more
pages.
In short there are a lot of issues. But there are partial
solutions out there. And several of the more advanced
templating systems (eg Template::Toolkit and HTML::Mason)
have put a fair amount of work into figuring out how to
reasonably trade off static caching, dynamic
caching, and on the fly pages.
| [reply] [Watch: Dir/Any] |
|
Hmmm. I assumed that the questioner was worried that he could be caught by some technicality if he went static or dynamic, and answered to reassure him that the technology was good for both, but static was faster.
I tend to focus on the technical issues in my answers and assume that the procedural problems have already been thought about - I guess I should start paying more attention to the other parts of implementation beyond "Can it be done".
Some of your points rely on assumptions you have made about the situation the petitioner is in - for instance the method used to create static pages. They are valid points, but you are raising issues for a problem that hasn't been defined yet. He hasn't told us what build process he is considering, or what devel cycles he wants to follow.
When we did our static pages site, we actually wrote the site dynamically, and used it for a bit. When we were happy with it, we ran wget over it to create the static site. To us, this seemed to be the best way to get more performance out of the hardware that we had, and it worked.
I know this particular strategy won't work in every case, but it was excellent for us because we got the best of both worlds - instant feedback and debugging, and the performance boost from static pages.
As to the storage issue - well, I assumed that the questioner could do the sums. If the static website is bigger than the disk (or than the memory buffers) then clearly dynamic is better.
Please excuse this 5am post, I just wanted to get it out before retiring for the morning.
____________________
Jeremy
I didn't believe in evil until I dated it.
| [reply] [Watch: Dir/Any] |
Re: Dynamic Web Content- Efficiency
by jlongino (Parson) on Sep 09, 2001 at 02:36 UTC
|
One aspect to consider the nature of access to your
data. Is your access dynamic or static? From your
description I gather that it is static.
If your data is dynamic, then I can see dynamically
generating pages as they are requested. Give the most
up-to-date data possible and reduce maintenance costs. If
a change from static to dynamic data is possible, go
with dynamic.
OTOH, if you data is static (manually updated at scheduled
intervals), I don't see the need to dynamically generate
the pages on request. Instead, as you suggest, it would
probably be better to generate static pages as a batch job
when you update the data files. When using static data you
can be assured of queries from anxious users wanting to know
why their data doesn't appear on the pages. You can try to
head some of them off by documenting the update intervals
up front.
I don't know if is true for you, but if you have to make
manual adjustments to your files (as a stop gap measure
between updates) the ease/difficulty/feasibility of that
process should be considered as well.
I believe that your most significant gains here are
probably not going to be in terms of performance.
Especially if the pages (static or dynamic) are basically
the same in size although content may vary slightly.
Rather, they will come from ease of maintenance.
@a=split??,'just lose the ego and get involved!';
for(split??,'afqtw{|~'){print $a[ord($_)-97]} | [reply] [Watch: Dir/Any] |
|
|