| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> Re: Application Server Caching
Just to elaborate - I did a poor job of explaining the sequence trick.
If the sequence returns a value of 12345 then the application knows it has a range from 12345000 to 12345999 to use. The next process will get the sequence value 12346, providing a range from 12346000 to 12346999. The long numbers are used in the database to be unique but having the application do a multiplication by 1000 certainly reduced load on the sequence.
Mark Richard
<mrichard_at_transur To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>
ban.com.au> cc:
Sent by: Subject: Re: Application Server Caching
ml-errors_at_fatcity
.com
15/01/2004 10:49
Please respond to
ORACLE-L
Ryan,
Our application does a certain amount of application server caching, and
infact has a pretty advanced cache mechanism to deal with out of date
objects, etc.
On a more simple level - Common reference records are loaded at start up
and cached, error messages are cached, etc. In a similar fashion we a a
sequence providing GUID values (global across our application at least) -
Obviously the application chews through these very fast (millions per day).
So, to reduce load each time the application gets a new value from the
sequence it treats it as a range of 1000 values. If the app crashes we
only loose a few thousand sequence numbers (several processes each have
their own store of 1000 values) but access to the sequence is reduced by a
factor of 1000. After three years of running the sequence is around
10,000,000 instead of 10,000,000,000!
It's all a matter of knowing what to cache and how to ensure it's still current. If you were populating a list of State Codes for a drop down list then I would cache that result but something like a StockOnHandQuantity figure probably changes so often that caching is of little use.
If you have the same query (ficticious eg: select statename, statecode from states) constantly firing in your database then I guess it's a sign that caching would help. Even sub-second queries can quickly add up in a busy system.
Cheers,
Mark.
"Ryan"
<ryan.gaffuri_at_cox To: Multiple
recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>
.net> cc:
Sent by: Subject: Application Server
Caching
ml-errors_at_fatcity
.com
15/01/2004 09:14
Please respond to
ORACLE-L
I heard a presentation from a front end performance analyst last night from www.tangasol.com (im not associated with them at all). He was pretty impressive.
He argued that accessing the database is expensive. He also argued in favor of caching data at the application server level. Have any of you worked with this? What are your opinions? His opinion was that people go back to the database to ask the same question way too often and cause a botteneck, if you can cache these frequently asked questions at the front end, it will significantly scale better.
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<---->>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Privileged/Confidential information may be contained in this message.
If you are not the addressee indicated in this message (or responsible for
delivery of the message to such person), you may not copy or deliver this
message to anyone.
In such a case, you should destroy this message and kindly notify the
sender by reply e-mail or by telephone on (03) 9612-6999 or (61) 3
9612-6999.
Please advise immediately if you or your employer does not consent to
Internet e-mail for messages of this kind.
Opinions, conclusions and other information in this message that do not
relate to the official business of Transurban Infrastructure Developments
Limited and CityLink Melbourne Limited shall be understood as neither given
nor endorsed by them.
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<---->>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
-- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Mark Richard INET: mrichard_at_transurban.com.au Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).Received on Wed Jan 14 2004 - 18:19:24 CST
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<---->>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Privileged/Confidential information may be contained in this message. If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not copy or deliver this message to anyone. In such a case, you should destroy this message and kindly notify the sender by reply e-mail or by telephone on (03) 9612-6999 or (61) 3 9612-6999. Please advise immediately if you or your employer does not consent to Internet e-mail for messages of this kind. Opinions, conclusions and other information in this message that do not relate to the official business of Transurban Infrastructure Developments Limited and CityLink Melbourne Limited shall be understood as neither given nor endorsed by them.
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<---->>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
-- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Mark Richard INET: mrichard_at_transurban.com.au Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
 |
 |