Caching design question

[Griff]

I need to implement caching in a web application and have come up against a
design issue which I would like some advice on. Am using CLASSIC ASP...

The web application is a "business to business" application. So the users
who log on belong to many different companies.

There are system wide settings, for example financial exchange rates etc.

There are "business" settings, so for example colours. So all users that
belong to Business A will see a blue background, and those in Business B
will see a green background.

There are "user" settings, so for example font size.

As far as caching is concerned, the system wide settings should go in the
Application() cache. These will be the same for ALL users.

The "user" settings should presumably go in the Session() cache; they're
peculiar that an individual and you don't want them hanging around in RAM
for too long, so they can expire when the session expires.

But, the problem I have is knowing where to put the Business settings. If I
put them in the Session() cache then there will be X number of copies of the
same data and I can see this soon consuming a lot of memory. The
alternative is to put them in the Application() cache so that there is a
single copy, but the problem here is that it will be stored in memory and
there can be an awful lot of businesses...

Is there an alternative that I've not considered? I guess ideally I'd like
to put things in the Application() cache with a Time To Live value (rather
like a cookie or a DNS record has), but I don't think that this is
possible..

Any advice/suggestions would be most appreciated.

Thanks

Griff

 

[Anthony Jones]

I need to implement caching in a web application and have come up against a
design issue which I would like some advice on. Am using CLASSIC ASP...

The web application is a "business to business" application. So the users
who log on belong to many different companies.

There are system wide settings, for example financial exchange rates etc.

There are "business" settings, so for example colours. So all users that
belong to Business A will see a blue background, and those in Business B
will see a green background.

There are "user" settings, so for example font size.

As far as caching is concerned, the system wide settings should go in the
Application() cache. These will be the same for ALL users.

The "user" settings should presumably go in the Session() cache; they're
peculiar that an individual and you don't want them hanging around in RAM
for too long, so they can expire when the session expires.

But, the problem I have is knowing where to put the Business settings. If I
put them in the Session() cache then there will be X number of copies of the
same data and I can see this soon consuming a lot of memory. The
alternative is to put them in the Application() cache so that there is a
single copy, but the problem here is that it will be stored in memory and
there can be an awful lot of businesses...

Is there an alternative that I've not considered? I guess ideally I'd like
to put things in the Application() cache with a Time To Live value (rather
like a cookie or a DNS record has), but I don't think that this is
possible..

Any advice/suggestions would be most appreciated.

Thanks

Griff

How many users do you expect to have at any one time?
The reason you're not doing all this stuff with a database is?
How many settings specific to a business are there?
Is this a piece of software you intend to sell or is it your (or your
client's) business that will be offering the service?

 

[Mike Brind]

How many users do you expect to have at any one time?
The reason you're not doing all this stuff with a database is?
How many settings specific to a business are there?

Also, are they all style related?

 

[Griff]

To answer Anthony's question (and hopefully expand upon it):
--------------------------------------------------------------

There are up to 1000 businesses and ~ 100,000 registered users. We have
upwards of 150 users on the system at any one time.

All the data is of course held as durable data in the database. This
database is on it's separate server. Caching the this soft of data would
cut down on unnecessary slow network round trips to the database server and
allow the DB to concentrate on working on the queries that can't be cached.

As to how many settings - something like 30 settings that can be held in a
string. There are of other more data-set style bits of data that can be
cached (e.g. allowable cost centres etc) which could go into select boxes
etc.

This is an existing application that we host.

To answer Mike Brind's questin
--------------------------------

Many of them are style related and are used to programatically generate a
CSS style sheet. Others are to do with functionality access - business A
can run reports, business B can't etc. Also (as mentioned above) some of
this information is array-type information, for example a list of cost
centres for a business, or a list of delivery addresses etc.

Griff

 

[Anthony Jones]

To answer Anthony's question (and hopefully expand upon it):
--------------------------------------------------------------

There are up to 1000 businesses and ~ 100,000 registered users. We have
upwards of 150 users on the system at any one time.

All the data is of course held as durable data in the database. This
database is on it's separate server. Caching the this soft of data would
cut down on unnecessary slow network round trips to the database server and
allow the DB to concentrate on working on the queries that can't be cached.

As to how many settings - something like 30 settings that can be held in a
string. There are of other more data-set style bits of data that can be
cached (e.g. allowable cost centres etc) which could go into select boxes
etc.

This is an existing application that we host.

To answer Mike Brind's questin
--------------------------------

Many of them are style related and are used to programatically generate a
CSS style sheet. Others are to do with functionality access - business A
can run reports, business B can't etc. Also (as mentioned above) some of
this information is array-type information, for example a list of cost
centres for a business, or a list of delivery addresses etc.

Griff

The chances are then there are few concurrent users actually from the same
business.

Stick the business settings in the session for the user. Shove more memory
in the server if necessary but I doubt 150 users would trouble a reasonable
well specified server.


Anthony.

 

[Griff]

Okay - thanks for your time.

 

[Griff]

One quick question

What number would have made you suggest using the application rather than
the session object?

Griff

 

[Anthony Jones]

One quick question

What number would have made you suggest using the application rather than
the session object?

Griff

How long is a piece of string, there are too many variables.

The fact that it is your server imeadiately means by far the most cost
effective way to maintain performance is beef up the hardware.

It's also the ratio of concurrent users to the business they are from which
reduces the likely hood of caching business settings separately in the
application object would really have much benefit.

At a very rough guess if you had like 600 concurrent users with a 10:1
business ratio then perhaps the additional complexity of managing separate
business settings might be warranted.

In this case I would consider a Free Threaded XML DOM as a cache for each
business stored in the Application object. Have an attribute on the
document element specify the expiry. Use a VB Script class in an ASP
include to wrap the accessing of values and the refreshing of the content.

Perhaps the first thing I would do is confirm that accessing all this from
the DB is really a problem. Again adding hardware may help, if the DB
server is physically near enough perhaps a couple of dedicated 1Gb network
cards, cost peanuts but has massive impact on server round trip performance.


Anthony.