RE: Application Server Caching
SAP R/3 has taken advantage of this approach for a long time now. It buffers tables based on settings in the R/3 data dictionary and can buffer single rows, groups of rows, or entire tables. Tables which are used to store configuration information are typically fully buffered, while transactional tables are buffered using either single rows or generic keys. Tables which have high concurrency arent generally buffered at all to prevent inconsistent views of the data from different application servers. All app servers in a given system synchronize their buffers (default every 60 seconds if memory serves); if a buffered row is updated, its marked dirty in the buffer, then the dirty bits are syncd to the other app servers. The first app server to request that row re-validates the buffer. They also handle sequences in a similar way; SAP uses number ranges rather than relying on vendor specific sequences. A number range is just a table of min, max, current numbers basically. For something like sales orders, it doesnt really matter if you skip a few numbers occasionally, so they allow you to buffer these as well, and control how many are buffered. For example, in a system with 2 app servers and a buffer size of 10 with a number range and current number 1000, the first application server will reset the current field in the table to 1010 and allocate 1000-1009 for itself; all requests for a sequence for that number range are answered locally on that app server. The disadvantage to this is that if the app server crashes, you can lose potentially 10 numbers from your sequence, and your sales orders (or whatever youre numbering) can get out of sequence (i.e. not monotonically increasing over time). Generally this isnt a problem, but they do allow you to disable this for each individual number range if you have contractual or legal requirements for doing so. Having directly seen the performance impact of both table and sequence buffering on the application server, I can attest that its very useful. A buffer access on the app server is a micro-second operation, whereas a database access over the network thats served from the DBs buffers is on the order of 10s of milliseconds. One that has to go clear to disk can be in the 100s of milliseconds from the applications point of view. Granted these numbers improve every year with technology, but the idea is that memory is faster than database buffers, which are in turn faster than going clear to disk for something Cheers! Rich -- Rich Holland (913) 645-1950 SAP Technical Consultant print unpack(u,92G5S\=\!A;F]T:5R(\'!EFP\@:%C:V5R\[EMAIL PROTECTED]); -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Rich Holland INET: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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).
RE: Application Server Caching
Obviously. The issue has been whether or not Oracle's data caching worked well - and was read for prime-time in earlier versions. -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of RyanSent: Wednesday, January 14, 2004 5:14 PMTo: Multiple recipients of list ORACLE-LSubject: Application Server Caching 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.
RE: Application Server Caching
Title: Message He's right, accessing the database is expensive. So is accessing from an app server if you have to support concurrency, updataing, transaction control,etc. Only if you consider the ACID properties of databases of no use for your application is this line of argument correct. The businesses that this is true of are small in number. Allan -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of RyanSent: Wednesday, January 14, 2004 4:14 PMTo: Multiple recipients of list ORACLE-LSubject: Application Server Caching 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. __ This email is intended solely for the person or entity to which it is addressed and may contain confidential and/or privileged information. Copying, forwarding or distributing this message by persons or entities other than the addressee is prohibited. If you have received this email in error, please contact the sender immediately and delete the material from any computer. This email may have been monitored for policy compliance. [021216]
RE: Application Server Caching
Ryan, He has a point. If you look at 9IAS's architecture there is a cache database at the apps server. The trick is to know when the data your looking for in cache is no longer valid. A certain children's apparel/toys site did that to me back in October. I'm still torqued at them. Dick GouletSenior Oracle DBAOracle Certified 8i DBA -Original Message-From: Ryan [mailto:[EMAIL PROTECTED]Sent: Wednesday, January 14, 2004 5:14 PMTo: Multiple recipients of list ORACLE-LSubject: Application Server Caching 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.
Re: Application Server Caching
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 [EMAIL PROTECTED]To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] .netcc: Sent by: Subject: Application Server Caching [EMAIL PROTECTED] .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: [EMAIL PROTECTED] 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
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 [EMAIL PROTECTED]To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] ban.com.au cc: Sent by: Subject: Re: Application Server Caching [EMAIL PROTECTED] .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 [EMAIL PROTECTED]To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] .netcc: Sent by: Subject: Application Server Caching [EMAIL PROTECTED] .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
