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/d...ide/html/cpconcachingportionsofaspnetpage.asp

 

[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/d...ide/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

 

[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.

 

[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.