All pages are currently static, but built from data. Sorry, perhaps I should have linked directly to my baby rather than assume you'd find it on my home node.

So, maintenance isn't a problem, I was just looking at general speed.

Thanks for your comments so far :)

cLive ;-)

If the number of user groups in your application is low, and the main performance hit you're worried about is the cost of data manipulation and page generation rather than the overhead of spawning a new perl process for each request, you'd probably do allright with some kind of caching scheme:

1. A request for a customized page arrives.
2. Your script checks the cache (on disk) if that page has already been generated for this user group. If so, it is read from file and served to the client.
3. Otherwise, a new page is generated from scratch, saved to the cache, and served to the client.

Cheers,
-- moodster

Ummm... if you're not going to use SSI because of these security or dynamic issues,then you might as well forego just about any dynamic technology. SSI can be extremely useful for page creation and makes for a fast, easy-to-maintain website. Particularly if non-coders are going to maintain it, since the basic idea is easy to understand.

Chris
M-x auto-bs-mode

At one point, the web designer altered the way he generated the pages and used SSI to include the side-bar into the table, to move away from frames. The result of this was that every single page served was painfully slower than before.

I used SSI once more at a web hosting company for their main page, and again I found SSI to slow page serving quite noticeably. I ended up using a simple perl CGI script (which ended up being around 15 lines) to do the same task, and the page serving was faster to my senses.

The eCom Apache server (1.3.19 w/mod_perl + SSL) was running on a Sun ULTRA 1 with 196MB of memory (172mHz uSPARC if my memory serves) if anyone wants to make fun out of it.

JP,
-- Alexander Widdlemouse undid his bellybutton and his bum dropped off --

mod_perl is also a dynamic page technology. It is also fast, and the Apache::SSI module which implements SSI in perl for mod_perl is just as fast as mod_include.

CGI is another dynamic page technology. It's slow. It has to fork perl and compile your code every time the page is run. It is much slower than SSI.

I don't see how you can do customized pages for each group using SSI, unless you can somehow get the name of the group into an environment variable, maybe using mod_rewrite. You aleady said you can't use mod_perl. That means you're stuck with CGI.

To combat the slowness of CGI, you can pre-generate most of the page. Have the main page and the different prices all generated ahead of time. In your CGI, just look at the user information (you'll need to use cookies or URLs with persistent data in them) and decide which price to show them. Use a simple templating tool like CGI::FastTemplate to stitch the main page HTML together with the appropriate price.

Perrin wrote:
I don't see how you can do customized pages for each group using SSI, unless you can somehow get the name of the group into an environment variable

If members of the "group" log in, then it is not too difficult. For example:

<!--#if expr="${REMOTE_USER} = fancygroup"-->

We LOVE you!

<!--#elif expr="${REMOTE_USER} = blahgroup"-->

Well, okay...

<!--#else-->

Go away, loser

<!--#endif-->
[download]

Any "CGI" environment variable is available like REMOTE_USER. So I think you can get away with using SSI in a lot of cases (though I'd prefer HTML::Mason ;)

If all you're doing is including new fragments at page assembly time, mod_perl and SSI should be equivalent. A lot of systems rely on "dynamically" assemblying from static content that is periodically regenerated. Things get tricker when the content has be assembled on the spot.

If you would be using SSI #exec to prepare dynamic content at page assembly time, then mod_perl is going to be faster (by virtue of not having to start a new processes).

If you're not able to use mod_perl, then you need to start counting process starts to predict whether SSI or CGI will be faster. In the case of including static content, SSI is going to win, since #include doesn't involve starting any new processes. Beyond that, and all other factors being equal^*, then it comes down to counting process starts. A CGI that can assemble content without having to fork subprocesses is liable to beat out an SSI that assembles content using 2 or more #exec's.

^* Other factors include maintainability of separate scripts, separation of static and dynamic content, ability of a designer to edit HTML (vs. forcing them to become programmers), etc.

drfrog - i don't think there would be many more issues than existing situation - ie, clients have no reason to piss around (it wouldn't be to their advantage)

joealba - thanks, great input - technically, I will be the only one in *most* cases. I think, for now, static page sets will make more sense, but as certain features get added, I'll need to rethink this.

moodster - I was thinking of using SSI to call scripts, so no real limitations on content. Perhaps the question should have been amended to "...build multiple static page sets or use CGI..'

mischief - It's perl in the sense that I'm using Perl to generate the pages,whatever method's used. I could have built 3 sets of scripts to test each of the three scenarios and benchmarked them, but since I know there are a lot of e-commerce/developer types here, I thought I'd ask around first. A bit like asking, "What's the best way to send an e-mail?" That's not a Perl question, but if you've ever done it in Perl, you'll understand what the question is asking :)

JPaul - Thank You! Just the sort of feedback I was looking for. Very useful.

perrin - sorry, should have expanded - SSI calls perl scripts, state maintained using a cookie.

--

I think for now, continuing to create template based static pages will be the way to go (also means less work for me), but for the long term, I'll need to probably go the whole hog to a dynamic template driven system that benchmarks a page when designed so the shop owner can be warned if it contains too much custom content.

Oh joy, how I love the SME^* market :)

Thanks again all for your comments.

cLive ;-)

^* - Small/Medium sized Enterprises