Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer
 
PerlMonks  

Re: Re: Where to keep HTML templates for a web application?

by legLess (Hermit)
on Feb 10, 2004 at 04:22 UTC ( [id://327812]=note: print w/replies, xml ) Need Help??


in reply to Re: Where to keep HTML templates for a web application?
in thread Where to keep HTML templates for a web application?

By the way, the design of putting templates in the database is pretty bad for usability.

Well, it is Slash we're talking about here :) Their design isn't perhaps as bad as it seems. The templates live on the filesystem, but after editing you run a tool to compile them, as Perl, into the database. They do this for speed. I haven't benchmarked it, so can't say if it works.

What really sucks about this is that each Apache/mod_perl child process caches all the templates, so if you make a minor change to a template you have to bounce Apache, or at least kill all its children.

Replies are listed 'Best First'.
Re: Re: Re: Where to keep HTML templates for a web application?
by perrin (Chancellor) on Feb 10, 2004 at 04:59 UTC
    Reading a file on a local filesystem is faster than reading from a database. Maybe they did it that way so they could share code between machines, but that's better done with NFS or rsync in my opinion. The compile step sounds annoying, as does having to restart when changes happen.

    When templates live on the filesystem, changes can be automatically picked up by the running system just by stat'ing the file. That could be turned into a database check in their custom Provider class, but I suspect they did this to keep shared memory high. In my experience though, compiling the templates before forking didn't really decrease the amount of unshared memory.

      The ultimate point, I think, is the caching of the templates in memory. As for storage ... access from multiple servers certainly is an issue. I can think of reasons for or against it, but until I've benchmarked a few solutions in a serious environment (few million hits a day) I don't want to out-guess them.

      Either way, you don't have to sell me on the inconveniences of the system. Nearly every design decision in Slash is sacrificing something, often ease of use or development, in the name of speed or security. Not the way I would do it at all. A couple extra web server machines are a lot cheaper than developer time in the long run.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://327812]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others contemplating the Monastery: (4)
As of 2024-03-29 10:48 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found