SSI vs. reading in a file vs. caching a DB entry?

[darrel]

I have bits of content on a site that's running of a basic CMS system I've
built.

The main content on each page is pulled in from the DB, so there's at least
one call to the DB on each page load.

But then there's content like the page footer, which is rarely updated, and
is the same on every page.

Since this is rarely updated, but initial thought was to store it in the DB,
but whenever it is edited, spit it out as a text file. Then I could use SSI
and just include it on all of the pages. The problem with the include is
that I want to include it on a usercontrol, and IIRC, the controls are
executed prior to includes, so instead, I can use a objStreamReader to read
in the file.

My first question is if reading a file via objStreamReader is any different
performance-wise than using server side includes?

My second question is if I should instead consider using an actual DB call
to grab the data, but then setting it in a session state. That way it is
only called once per user per session, and then stored in memory from page
to page. Or does that matter?

-Darrel

[Scott Allen]

Darrell:

Turn the footer into a user control and use 'fragment caching', which is
simply adding a Cache directive to the user control. This is easier than
using the file system.

See: http://msdn.microsoft.com/library/de...aspnetpage.asp
--
Scott
http://www.OdeToCode.com/blogs/scott/

I have bits of content on a site that's running of a basic CMS system
I've built.

The main content on each page is pulled in from the DB, so there's at
least one call to the DB on each page load.

But then there's content like the page footer, which is rarely
updated, and is the same on every page.

Since this is rarely updated, but initial thought was to store it in
the DB, but whenever it is edited, spit it out as a text file. Then I
could use SSI and just include it on all of the pages. The problem
with the include is that I want to include it on a usercontrol, and
IIRC, the controls are executed prior to includes, so instead, I can
use a objStreamReader to read in the file.

My first question is if reading a file via objStreamReader is any
different performance-wise than using server side includes?

My second question is if I should instead consider using an actual DB
call to grab the data, but then setting it in a session state. That
way it is only called once per user per session, and then stored in
memory from page to page. Or does that matter?

-Darrel

[darrel]

> Turn the footer into a user control and use 'fragment caching', which is

simply adding a Cache directive to the user control. This is easier than
using the file system.
See:

http://msdn.microsoft.com/library/de...aspnetpage.asp

Actually, the filesystem method seemed pretty easy. ;o)

I see a few catches with using the regular Cache settings for this type of
thing, though. One, if the person wants to update this content, they have to
wait for the cache to expire to see the change. If the cache is only a few
seconds, no big deal, but if if it's 5 minutes, that gets to be a bit
impractical. And, if it's only a few seconds, it doesn't really seem worth
it, as I'll still be hitting the database later on.

The other issue is that I'm loading the footer control dynamically and it
will load different content based on what ASPX page i'm looking at. So I
don't think I want to cache a control that will behave different from aspx
page to aspx page, do I?

-Darrel

[Scott Allen]

Yes, with those additional requirements you might want to look at the Cache
object (to cache the file's contents) and the CacheDependency class (which
can invalidate a cache entry when the file changes). This would give you
flexibility, the most up to date content, and still avoid reprocessing the
file on each request.

--
Scott
http://www.OdeToCode.com/blogs/scott/

Turn the footer into a user control and use 'fragment caching', which
is
simply adding a Cache directive to the user control. This is easier
than
using the file system.
See:

http://msdn.microsoft.com/library/de...ry/en-us/cpgui
de/html/cpconcachingportionsofaspnetpage.asp

Actually, the filesystem method seemed pretty easy. ;o)

I see a few catches with using the regular Cache settings for this
type of thing, though. One, if the person wants to update this
content, they have to wait for the cache to expire to see the change.
If the cache is only a few seconds, no big deal, but if if it's 5
minutes, that gets to be a bit impractical. And, if it's only a few
seconds, it doesn't really seem worth it, as I'll still be hitting the
database later on.

The other issue is that I'm loading the footer control dynamically and
it will load different content based on what ASPX page i'm looking at.
So I don't think I want to cache a control that will behave different
from aspx page to aspx page, do I?

-Darrel

[darrel]

> Yes, with those additional requirements you might want to look at the
Cache

object (to cache the file's contents) and the CacheDependency class (which
can invalidate a cache entry when the file changes). This would give you
flexibility, the most up to date content, and still avoid reprocessing the
file on each request.

Will do.

That said, am I overthinking all of this? Is reading in a text file really
any different performance wise than a plain-ol' SSI? We've used tons of SSIs
in the past without servers crashing so perhaps I'm worrying about a
miniscule amount of processing time.

-Darrel

[Scott Allen]

The problem I had with SSI was maintainability - which is ironic since SSI
was touted for it's ability to make ASP more maintainable (but those were
the ASP days).

With abstractions like user controls you can approach the design in an object
oriented fashion, hide additional complexity, and have a more flexible design.
I know this is a very vague, sky-high, hand waving assertion, but to give
you a bit of a concrete example, look at Karl's article:
http://openmymind.net/communication/index.html

In terms of processing time - it might not be a big win either way.

--
Scott
http://www.OdeToCode.com/blogs/scott/

Yes, with those additional requirements you might want to look at the

Cache

object (to cache the file's contents) and the CacheDependency class
(which can invalidate a cache entry when the file changes). This
would give you flexibility, the most up to date content, and still
avoid reprocessing the file on each request.

Will do.

That said, am I overthinking all of this? Is reading in a text file
really any different performance wise than a plain-ol' SSI? We've used
tons of SSIs in the past without servers crashing so perhaps I'm
worrying about a miniscule amount of processing time.

-Darrel