For us the most significant part of the pre-fetch is that the form is translated. It is translated to Java code and cached. This cache of Java code is available for any request for the form. We found that the translation takes significant server processing resources that impacts the performance of requests. Pre-fetching reduces these impacts for most of the dominant forms.
************************************* Lee Marsh Remedy Administrator BAE Systems Office Automation Systems Team Antitrust Division, U.S. Department of Justice Phone: 202-305-9725 Cell: 202-528-1749 Email: lee.ma...@usdoj.gov ************************************* From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Rick Cook Sent: Wednesday, April 14, 2010 10:04 AM To: arslist@ARSLIST.ORG Subject: Re: Benefit of Prefetch Remedy midtier 7.1 ** If the 7.1 prefetch pushes files to the client, I, too, would be surprised. What I understand is similar to what you do - it pre-caches the file definitions to the Mid-Tier server, so that if the client has to re-cache, it doesn't have to wait for that first step of caching from the AR server to the Mid-Tier servert to happen. You can configure how often it checks for that, and force a re-cache on demand if you wish, but you can also leave the client files alone if you wish, which would give the appearance that the re-cache also improved performance down to the client level, even if technically all it did was remove the requirement of a client re-cache with a MT configuration setting that I think has been there since v6. The pre-cache in v7 simply gave more power to that option by precaching to the MT server as well. Perhaps that is what the sales people are saying. So, pre-7.1, the Client (Browser) opens a Remedy form. Browser checks MT server to see if the hash on the client's cached copy of that form is equal to that which is on the MT server. Under the pre 7.1 MT config, the MT server may or may not have a locally cached copy of that form, only getting that copy on demand (i.e. the first person to request it forces the re-cache). So the MT server has to wait for the AR Server to at least check, and possibly re-cache the form, and the client has to wait for the MT server to do that so that it can go through the same process. In 7.1, if the form is pre-cached to the MT server, the MT --> AR Server wait time is removed (unless the form has been changed since the last pre-cache). The only check that has to be made is from the client to the MT server. If the client's cached copy is identical to that of the MT server, no re-cache is necessary. Rick On Wed, Apr 14, 2010 at 6:44 AM, remedy lee <haeyoon....@gmail.com> wrote: Hi, I'm confused on this prefetch 'feature' in midtier. The way I read it is that only when a server is restarted will the forms (on the web server) reload in order to save time when the first user logs in. So instead of loading HPD:Help Desk when a user first hits it, it will load by itself when restarted. Benefit is that the first user logging in won't get that 1-2 mins loading wait. Now sales people and certain consultants say that prefetch does more than that. It actually loads the forms into the clients computer and therefore speeds up the whole midtier itself. So they say that prefetch helps overall everyday midtier use such as the 50th person using HPD:Help Desk will notice better speeds with prefetch than without. They say it loads the forms to the clients computers preemptively and therefore improves performance. To me that doesn't make sense, how can the server know where to load the files. Does it work by loading all the web forms when the person logs in? I really see no benefit to using prefetch if our server hardly restarts ________________________________________________________________________ _______ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org <http://www.arslist.org/> attend wwrug10 www.wwrug.com <http://www.wwrug.com/> ARSlist: "Where the Answers Are" _attend WWRUG10 www.wwrug.com ARSlist: "Where the Answers Are"_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"
