with application and server variables, sessions would be totally madness
with the amount of visitors I serve with the system. Maybe I should give
you some more background info:
The system is a content management solution and we sell it on a ASP
basis, this is the 4th edition. Everybody using the system uses the same
files, in a shared file root, and has the ability to override those
files when files with the same name are found in their own custom
directories. Currently on the 4th edition, +/- 150 customers are using
this system. A change in the administration interface, or in the
framework is instantly available for all customers (unless the files are
overridden for a customer).
This means that queries executed in the framework are very dynamic,
because all customers use the same templates. Every customer has its own
application name defined in sessionmanagement, so It is an option to
cache the recordsets on a application.recordset basis, but not on a
server basis. You don't want the chance to mix up recordsets between
customers on the same system (for example WHERE pageid=1).
The templates in the system (homepage.cfm, subpage.cfm , etc) consist
out of pre-specified stored procedures, all the same for all customers.
The stored procedures are like "get child pages", "get articles", etc. A
basic page consists out of 2 stored procedures, one to draw the page
navigation (get childnodes with objecttype page) and one to get the
content elements (get childnodes with objecttype
article/poll/snippet/etc on placeholder X).
But there are pages which have their content based on the childnodes
from another page, like showing a list of recent press articles. When
all combined, you would fire up an amount of about 10 stored procedures
(and the system currently handles +/- 250 req/sec). This is why I am
trying to minimize the delays to a minimum. One or two stored procedures
with a delay who cares, but .... When the amount of stored procedures
rise, you also see a rise in the total delay, which seems unnecessary. I
could ofcourse return all stored procedures encapsulated in one stored
procedure and then use cfstoredproc icw resultset to pick one of the
many resultsets returned (and so minimize database round trips) but
those are last resorts. :-)
Caching recordsets could be an option, but that would be done in the
application scope. This is however very difficult, because the queries
are most of the time to dynamic. If you have a query which always
returns the same records based on a vast call, that would be very easy,
but I also must make the application variable name, variable
corresponding the sql code to determine what application variable
corresponds to what recordset. :-)
.. ok... coffee now.. :-)
Micha Schopman
Software Engineer
Modern Media, Databankweg 12 M, 3821 AL Amersfoort
Tel 033-4535377, Fax 033-4535388
KvK Amersfoort 39081679, Rabo 39.48.05.380
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings] [Donations and Support]
