How many users warrants caching

[wantedSpidy]

I'm working on this real time app with gwt. Its a pretty simple app (right now). I fetch some data from a couple of db's, do some calculations and present a nice pretty overall status for the boss, and the support staff.

Right now everything is on an application level, so every instance created results in a bunch of store procs getting executed.

At what point should I start caching the data I receive from the databases? The same information is shown to all the users, so there is some merit to caching. But if only 10-20 ppl are using it I'm not sure if its worth the dev time. But what if its 50 users? 100 users? At what point should I start caching the data?

 

[WannaFly]

There's a ton of variables too take into account so every answer will be different.

Depending on how often it refreshes and your potential user max, and how time-lagged the data can be, (also how long the SPs are currently/expected to take):
I'd suggest, if you expect any time soon for there to be over 50 users, your best bet instead of "caching" is to make a multi-tier app where the server is the only one that runs the SPs and it shoots the most recent copy to the clients.

If you are running a major DBMS the queries should be able to optimize and run pretty quickly. It really depends on so many factors as to whether to cache or not.

 

[wantedSpidy]

oops sorry forgot to mention, the refresh rate is currently about 10 minutes, and the SP's take a a couple of seconds to run.

The potential number of users right now is 10-20, however it could get up to 100.

The app is currently multi-tiered ... but only for name sake. I guess I'll have to change that now!

thanks

 

[degibson]

If you're expecting growth, profile now.

 

[Cogman]

If you are planning on having any write backs (IE, the user is allowed to change the data) Don't cache, look for some other place to improve speed (as degibson said, profile).

Really, profiling should be the first thing you do when talking about optimizations.