Re: Mid Tier - Long Applet Load Time - pre-cache
He actually did that. =( He tried levels 1 - 5 (again, neither of us know what levels were valid). No more details. The script looks like it returns '- Error:' when if ($res->is_error). But it's supposed to return: print " - Error:\n" We aren't getting the '\n'. Of course, it's 'unsupported', so no help from Remedy. -Jamie -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] Behalf Of Kyle Whitley Sent: Thursday, October 19, 2006 3:45 PM To: arslist@ARSLIST.ORG Subject: Re: Mid Tier - Long Applet Load Time - pre-cache Turn on debugging for the script and see what is causing the error. I believe this would be option -d 1. I can't remember all the levels 1-4 they may be more I am not sure. This will help you determine what the issue is. Kyle Blodgett, Jamie wrote: > Thanks for everyone's input on this. Unfortunately, our admins can't get > this to work. We just get back the Error: with no additional text. So, I'm > stuck ensuring I've accessed all the forms before I sign off. > > Anyone else written another script? > > -Original Message- > From: Action Request System discussion list(ARSList) > [mailto:[EMAIL PROTECTED] Behalf Of Kyle Whitley > Sent: Wednesday, October 18, 2006 8:24 AM > To: arslist@ARSLIST.ORG > Subject: Re: Mid Tier - Long Applet Load Time - pre-cache > > > Has anyone gotten this script to work with https? It seems to work fine > on > web server without https, but not with one that is. > > Kyle > > Grooms, Frederick W wrote: > >> When Remedy sent me the perl script it was in a zip file that included a >> sample urls.txt file. >> >> Here is what was in it (between the cut here lines): >> - - - - - cut here - - - - - >> forms/jsayers-d600/RESOURCE/Default+Admin+ViewLOCAL >> forms/jsayers-d600/RESOURCE_Home/standard >> - - - - - cut here - - - - - >> >> Fred >> CONFIDENTIALITY: The information contained in this transmission may contain privileged and confidential information. It is intended only for the use of the person(s) named above. If you are not the intended recipient, you are hereby notified that any review, dissemination, distribution or duplication of this communication, and the information contained in it, is strictly prohibited. If you are not the intended recipient, please contact the sender and immediately destroy all copies of the original message. ___ UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org
Re: Mid Tier - Long Applet Load Time - pre-cache
Turn on debugging for the script and see what is causing the error. I believe this would be option -d 1. I can't remember all the levels 1-4 they may be more I am not sure. This will help you determine what the issue is. Kyle Blodgett, Jamie wrote: Thanks for everyone's input on this. Unfortunately, our admins can't get this to work. We just get back the Error: with no additional text. So, I'm stuck ensuring I've accessed all the forms before I sign off. Anyone else written another script? -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] Behalf Of Kyle Whitley Sent: Wednesday, October 18, 2006 8:24 AM To: arslist@ARSLIST.ORG Subject: Re: Mid Tier - Long Applet Load Time - pre-cache Has anyone gotten this script to work with https? It seems to work fine on web server without https, but not with one that is. Kyle Grooms, Frederick W wrote: When Remedy sent me the perl script it was in a zip file that included a sample urls.txt file. Here is what was in it (between the cut here lines): - - - - - cut here - - - - - forms/jsayers-d600/RESOURCE/Default+Admin+ViewLOCAL forms/jsayers-d600/RESOURCE_Home/standard - - - - - cut here - - - - - Fred -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Blodgett, Jamie Sent: Tuesday, October 17, 2006 4:40 PM To: arslist@ARSLIST.ORG Subject: Re: Mid Tier - Long Applet Load Time - pre-cache Does anyone have a sample of the urls.txt file so I can manually create it for my lan admin team? Thanks, Jamie -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] Behalf Of Michiel Beijen Sent: Tuesday, October 17, 2006 3:33 PM To: arslist@ARSLIST.ORG Subject: Re: Mid Tier - Long Applet Load Time - pre-cache If I remember correctly the perl script was supposed to be called from a batch (cron or a windows equivalent like at) You can schedule it at non-peak times such as every day 4 am. Be sure not to let it clash with any scheduled downtime of your remedy server for backup or other purposes. Kind regards, Michiel. On 10/17/06, Blodgett, Jamie <[EMAIL PROTECTED]> wrote: ** As suspected, Remedy states that the cache process works as designed. They did provide the 'unsupported' Perl script. I'm going to have our server team run through the process this weekend to see if we can get it working. However, my question is this, now that I have the Perl script, how do I have it run everytime I need to flush the cache? I can have the server support run it for me this once, but I'm thinking maybe it needs to be scheduled? Sorry, I'm clueless about the scripting side. This will be a great learning experience. Thanks everyone! Jamie CONFIDENTIALITY: The information contained in this transmission may contain privileged and confidential information. It is intended only for the use of the person(s) named above. If you are not the intended recipient, you are hereby notified that any review, dissemination, distribution or duplication of this communication, and the information contained in it, is strictly prohibited. If you are not the intended recipient, please contact the sender and immediately destroy all copies of the original message. ___ UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org -- Kyle Whitley IT System Support Professional Office of Information and Instructional Technology (OIIT) Board of Regents of the University System of Georgia ___ UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org
Re: Mid Tier - Long Applet Load Time - pre-cache
Thanks for everyone's input on this. Unfortunately, our admins can't get this to work. We just get back the Error: with no additional text. So, I'm stuck ensuring I've accessed all the forms before I sign off. Anyone else written another script? -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] Behalf Of Kyle Whitley Sent: Wednesday, October 18, 2006 8:24 AM To: arslist@ARSLIST.ORG Subject: Re: Mid Tier - Long Applet Load Time - pre-cache Has anyone gotten this script to work with https? It seems to work fine on web server without https, but not with one that is. Kyle Grooms, Frederick W wrote: > When Remedy sent me the perl script it was in a zip file that included a > sample urls.txt file. > > Here is what was in it (between the cut here lines): > - - - - - cut here - - - - - > forms/jsayers-d600/RESOURCE/Default+Admin+ViewLOCAL > forms/jsayers-d600/RESOURCE_Home/standard > - - - - - cut here - - - - - > > Fred > > > -Original Message- > From: Action Request System discussion list(ARSList) > [mailto:[EMAIL PROTECTED] On Behalf Of Blodgett, Jamie > Sent: Tuesday, October 17, 2006 4:40 PM > To: arslist@ARSLIST.ORG > Subject: Re: Mid Tier - Long Applet Load Time - pre-cache > > Does anyone have a sample of the urls.txt file so I can manually create > it for my lan admin team? > > Thanks, > Jamie > > -Original Message- > From: Action Request System discussion list(ARSList) > [mailto:[EMAIL PROTECTED] Behalf Of Michiel Beijen > Sent: Tuesday, October 17, 2006 3:33 PM > To: arslist@ARSLIST.ORG > Subject: Re: Mid Tier - Long Applet Load Time - pre-cache > > > If I remember correctly the perl script was supposed to be called from a > batch (cron or a windows equivalent like at) You can schedule it at > non-peak times such as every day 4 am. Be sure not to let it clash with > any scheduled downtime of your remedy server for backup or other > purposes. > > Kind regards, > Michiel. > > On 10/17/06, Blodgett, Jamie <[EMAIL PROTECTED]> wrote: > >> ** >> >> As suspected, Remedy states that the cache process works as designed. >> They did provide the 'unsupported' Perl script. I'm going to have our >> server team run through the process this weekend to see if we can get > it working. > >> However, my question is this, now that I have the Perl script, how do >> I have it run everytime I need to flush the cache? I can have the >> server support run it for me this once, but I'm thinking maybe it >> > needs to be scheduled? > >> Sorry, I'm clueless about the scripting side. This will be a great >> learning experience. >> >> Thanks everyone! >> Jamie CONFIDENTIALITY: The information contained in this transmission may contain privileged and confidential information. It is intended only for the use of the person(s) named above. If you are not the intended recipient, you are hereby notified that any review, dissemination, distribution or duplication of this communication, and the information contained in it, is strictly prohibited. If you are not the intended recipient, please contact the sender and immediately destroy all copies of the original message. ___ UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org
Re: Mid Tier - Long Applet Load Time - pre-cache
Ok, I've generated the urls.txt file (even did it the long way running the script to ensure I wasn't missing something). All we get back from the script is: - Error: - Error: - Error: - Error: This error message doesn't help me in determining what is causing the error. Any ideas?? Or has anyone written a vb script or something else to load the cache. From my looking over the script, it appears to just be logging onto Remedy via midtier and accessing the forms, thus it gets loaded into cache. Thanks! Jamie -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] Behalf Of Kyle Whitley Sent: Wednesday, October 18, 2006 8:24 AM To: arslist@ARSLIST.ORG Subject: Re: Mid Tier - Long Applet Load Time - pre-cache Has anyone gotten this script to work with https? It seems to work fine on web server without https, but not with one that is. Kyle Grooms, Frederick W wrote: > When Remedy sent me the perl script it was in a zip file that included a > sample urls.txt file. > > Here is what was in it (between the cut here lines): > - - - - - cut here - - - - - > forms/jsayers-d600/RESOURCE/Default+Admin+ViewLOCAL > forms/jsayers-d600/RESOURCE_Home/standard > - - - - - cut here - - - - - > > Fred > > > -Original Message- > From: Action Request System discussion list(ARSList) > [mailto:[EMAIL PROTECTED] On Behalf Of Blodgett, Jamie > Sent: Tuesday, October 17, 2006 4:40 PM > To: arslist@ARSLIST.ORG > Subject: Re: Mid Tier - Long Applet Load Time - pre-cache > > Does anyone have a sample of the urls.txt file so I can manually create > it for my lan admin team? > > Thanks, > Jamie > > -Original Message- > From: Action Request System discussion list(ARSList) > [mailto:[EMAIL PROTECTED] Behalf Of Michiel Beijen > Sent: Tuesday, October 17, 2006 3:33 PM > To: arslist@ARSLIST.ORG > Subject: Re: Mid Tier - Long Applet Load Time - pre-cache > > > If I remember correctly the perl script was supposed to be called from a > batch (cron or a windows equivalent like at) You can schedule it at > non-peak times such as every day 4 am. Be sure not to let it clash with > any scheduled downtime of your remedy server for backup or other > purposes. > > Kind regards, > Michiel. > > On 10/17/06, Blodgett, Jamie <[EMAIL PROTECTED]> wrote: > >> ** >> >> As suspected, Remedy states that the cache process works as designed. >> > > >> They did provide the 'unsupported' Perl script. I'm going to have our >> > > >> server team run through the process this weekend to see if we can get >> > it working. > >> However, my question is this, now that I have the Perl script, how do >> I have it run everytime I need to flush the cache? I can have the >> server support run it for me this once, but I'm thinking maybe it >> > needs to be scheduled? > >> Sorry, I'm clueless about the scripting side. This will be a great >> learning experience. >> >> Thanks everyone! >> Jamie >> >> CONFIDENTIALITY: The information contained in this transmission may >> contain privileged and confidential information. It is intended only >> for the use of the person(s) named above. If you are not the intended >> recipient, you are hereby notified that any review, dissemination, >> distribution or duplication of this communication, and the information >> > > >> contained in it, is strictly prohibited. If you are not the intended >> recipient, please contact the sender and immediately destroy all >> > copies of the original message. > >> __20060125___This posting was submitted with HTML >> > > >> in it___ >> > > > ___ > UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org > > > ___ > UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org > > ___ > UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org > -- Kyle Whitley IT System Support Professional Office of Information and Instructional Technology (OIIT) Board of Regents of the University System of Georgia ___ UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org ___ UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org
Re: Mid Tier - Long Applet Load Time - pre-cache
Has anyone gotten this script to work with https? It seems to work fine on web server without https, but not with one that is. Kyle Grooms, Frederick W wrote: When Remedy sent me the perl script it was in a zip file that included a sample urls.txt file. Here is what was in it (between the cut here lines): - - - - - cut here - - - - - forms/jsayers-d600/RESOURCE/Default+Admin+ViewLOCAL forms/jsayers-d600/RESOURCE_Home/standard - - - - - cut here - - - - - Fred -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Blodgett, Jamie Sent: Tuesday, October 17, 2006 4:40 PM To: arslist@ARSLIST.ORG Subject: Re: Mid Tier - Long Applet Load Time - pre-cache Does anyone have a sample of the urls.txt file so I can manually create it for my lan admin team? Thanks, Jamie -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] Behalf Of Michiel Beijen Sent: Tuesday, October 17, 2006 3:33 PM To: arslist@ARSLIST.ORG Subject: Re: Mid Tier - Long Applet Load Time - pre-cache If I remember correctly the perl script was supposed to be called from a batch (cron or a windows equivalent like at) You can schedule it at non-peak times such as every day 4 am. Be sure not to let it clash with any scheduled downtime of your remedy server for backup or other purposes. Kind regards, Michiel. On 10/17/06, Blodgett, Jamie <[EMAIL PROTECTED]> wrote: ** As suspected, Remedy states that the cache process works as designed. They did provide the 'unsupported' Perl script. I'm going to have our server team run through the process this weekend to see if we can get it working. However, my question is this, now that I have the Perl script, how do I have it run everytime I need to flush the cache? I can have the server support run it for me this once, but I'm thinking maybe it needs to be scheduled? Sorry, I'm clueless about the scripting side. This will be a great learning experience. Thanks everyone! Jamie CONFIDENTIALITY: The information contained in this transmission may contain privileged and confidential information. It is intended only for the use of the person(s) named above. If you are not the intended recipient, you are hereby notified that any review, dissemination, distribution or duplication of this communication, and the information contained in it, is strictly prohibited. If you are not the intended recipient, please contact the sender and immediately destroy all copies of the original message. __20060125___This posting was submitted with HTML in it___ ___ UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org ___ UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org ___ UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org -- Kyle Whitley IT System Support Professional Office of Information and Instructional Technology (OIIT) Board of Regents of the University System of Georgia ___ UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org
Re: Mid Tier - Long Applet Load Time - pre-cache
When Remedy sent me the perl script it was in a zip file that included a sample urls.txt file. Here is what was in it (between the cut here lines): - - - - - cut here - - - - - forms/jsayers-d600/RESOURCE/Default+Admin+ViewLOCAL forms/jsayers-d600/RESOURCE_Home/standard - - - - - cut here - - - - - Fred -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Blodgett, Jamie Sent: Tuesday, October 17, 2006 4:40 PM To: arslist@ARSLIST.ORG Subject: Re: Mid Tier - Long Applet Load Time - pre-cache Does anyone have a sample of the urls.txt file so I can manually create it for my lan admin team? Thanks, Jamie -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] Behalf Of Michiel Beijen Sent: Tuesday, October 17, 2006 3:33 PM To: arslist@ARSLIST.ORG Subject: Re: Mid Tier - Long Applet Load Time - pre-cache If I remember correctly the perl script was supposed to be called from a batch (cron or a windows equivalent like at) You can schedule it at non-peak times such as every day 4 am. Be sure not to let it clash with any scheduled downtime of your remedy server for backup or other purposes. Kind regards, Michiel. On 10/17/06, Blodgett, Jamie <[EMAIL PROTECTED]> wrote: > ** > > As suspected, Remedy states that the cache process works as designed. > They did provide the 'unsupported' Perl script. I'm going to have our > server team run through the process this weekend to see if we can get it working. > However, my question is this, now that I have the Perl script, how do > I have it run everytime I need to flush the cache? I can have the > server support run it for me this once, but I'm thinking maybe it needs to be scheduled? > Sorry, I'm clueless about the scripting side. This will be a great > learning experience. > > Thanks everyone! > Jamie > > CONFIDENTIALITY: The information contained in this transmission may > contain privileged and confidential information. It is intended only > for the use of the person(s) named above. If you are not the intended > recipient, you are hereby notified that any review, dissemination, > distribution or duplication of this communication, and the information > contained in it, is strictly prohibited. If you are not the intended > recipient, please contact the sender and immediately destroy all copies of the original message. > __20060125___This posting was submitted with HTML > in it___ ___ UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org ___ UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org ___ UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org
Re: Mid Tier - Long Applet Load Time - pre-cache
Does anyone have a sample of the urls.txt file so I can manually create it for my lan admin team? Thanks, Jamie -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] Behalf Of Michiel Beijen Sent: Tuesday, October 17, 2006 3:33 PM To: arslist@ARSLIST.ORG Subject: Re: Mid Tier - Long Applet Load Time - pre-cache If I remember correctly the perl script was supposed to be called from a batch (cron or a windows equivalent like at) You can schedule it at non-peak times such as every day 4 am. Be sure not to let it clash with any scheduled downtime of your remedy server for backup or other purposes. Kind regards, Michiel. On 10/17/06, Blodgett, Jamie <[EMAIL PROTECTED]> wrote: > ** > > As suspected, Remedy states that the cache process works as designed. They > did provide the 'unsupported' Perl script. I'm going to have our server > team run through the process this weekend to see if we can get it working. > However, my question is this, now that I have the Perl script, how do I have > it run everytime I need to flush the cache? I can have the server support > run it for me this once, but I'm thinking maybe it needs to be scheduled? > Sorry, I'm clueless about the scripting side. This will be a great learning > experience. > > Thanks everyone! > Jamie > > CONFIDENTIALITY: The information contained in this transmission may contain > privileged and confidential information. It is intended only for the use of > the person(s) named above. If you are not the intended recipient, you are > hereby notified that any review, dissemination, distribution or duplication > of this communication, and the information contained in it, is strictly > prohibited. If you are not the intended recipient, please contact the sender > and immediately destroy all copies of the original message. > __20060125___This posting was > submitted with HTML in it___ ___ UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org ___ UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org
Re: Mid Tier - Long Applet Load Time
Title: RE: Mid Tier - Long Applet Load Time ** I just wrote my own. I have it scheduled to run each night to ensure that the forms are cached and ready each morning. Now, how to programmatically flush the mid tier cache. I searched the ARS List archives and the only method I found was to run IISReset on the web server. For now this will work because I will run it at night just before I rebuild the cache files. Has anyone figured out how to trigger a cache flush through workflow or a URL? I searched the pdf manuals for ARS 6.3 and 7.0. Stephen From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Heider, StephenSent: Tuesday, October 17, 2006 10:57 AMTo: arslist@ARSLIST.ORGSubject: Re: Mid Tier - Long Applet Load Time ** Does anyone on ARS List have this script for Mid Tier 6.3? Stephen From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of McKenzie, James J C-E LCMC HQISEC/L3Sent: Tuesday, October 17, 2006 10:52 AMTo: arslist@ARSLIST.ORGSubject: Re: Mid Tier - Long Applet Load Time ** Rick: I think the problem is due to the method used to move information from the ARS server to the MT server for forms and workflow. This is not so obvious when the two are located on the same network segment but can become very visible when the ARS server and MT server are separated by a great distance. This slows down form loading to a crawl. Of course there is a script or program that can force the MT server to 'pre-cache' once the cache is flushed. This may or may not solve Jamie's problem... James McKenzie L-3 GSI From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Rick Cook Sent: Tuesday, October 17, 2006 7:49 AM To: arslist@ARSLIST.ORG Subject: Re: Mid Tier - Long Applet Load Time ** Jamie, the issue is different between the two versions in part because the Mid-Tier architecture is completely different between v5 and v6.3 - with the more modern versions being MUCH better. One thing I have seen that is helpful from a user experience perspective with both 6.3 and 7.0 MT is to have someone (i.e. you) open each of the forms, via the MT, that the user will likely access. This pre-caches the copies of the forms to the MT server, which speeds up the initial load time to the user. Rick On 10/17/06, Blodgett, Jamie <[EMAIL PROTECTED]> wrote: ** I'm having the same issue and have opened a ticket with Remedy. We'll see what they say. My issue is that for the midtier to see the changes to workflow, I have to flush the cache. After flushing the cache, it takes up to 2 minutes for users to access the pages for the first time. After that everything moves very fast. This is a midtier in AUS connecting to ARS in US. This was working fine pre-upgrade ( 5.0). Midtier 6.3 p 18 ARS 6.3 p18 IIS ServletExce 5 p6 Win 2000 Java 1.5.01 I'll update on what Remedy suggests. Thanks, Jamie Blodgett __20060125___This posting was submitted with HTML in it___ __20060125___This posting was submitted with HTML in it___ __20060125___This posting was submitted with HTML in it___
Re: Mid Tier - Long Applet Load Time - pre-cache
If I remember correctly the perl script was supposed to be called from a batch (cron or a windows equivalent like at) You can schedule it at non-peak times such as every day 4 am. Be sure not to let it clash with any scheduled downtime of your remedy server for backup or other purposes. Kind regards, Michiel. On 10/17/06, Blodgett, Jamie <[EMAIL PROTECTED]> wrote: ** As suspected, Remedy states that the cache process works as designed. They did provide the 'unsupported' Perl script. I'm going to have our server team run through the process this weekend to see if we can get it working. However, my question is this, now that I have the Perl script, how do I have it run everytime I need to flush the cache? I can have the server support run it for me this once, but I'm thinking maybe it needs to be scheduled? Sorry, I'm clueless about the scripting side. This will be a great learning experience. Thanks everyone! Jamie CONFIDENTIALITY: The information contained in this transmission may contain privileged and confidential information. It is intended only for the use of the person(s) named above. If you are not the intended recipient, you are hereby notified that any review, dissemination, distribution or duplication of this communication, and the information contained in it, is strictly prohibited. If you are not the intended recipient, please contact the sender and immediately destroy all copies of the original message. __20060125___This posting was submitted with HTML in it___ ___ UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org
Re: Mid Tier - Long Applet Load Time - pre-cache
Title: RE: Mid Tier - Long Applet Load Time - pre-cache ** Jamie: You can setup a process where the cache program is run on a scheduled basis or you can set it up as a button which will run the script from a form that can be accessed only by admins. Use a button to run a run process filter James McKenzie L-3 GSI From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Blodgett, Jamie Sent: Tuesday, October 17, 2006 12:13 PM To: arslist@ARSLIST.ORG Subject: Re: Mid Tier - Long Applet Load Time - pre-cache ** As suspected, Remedy states that the cache process works as designed. They did provide the 'unsupported' Perl script. I'm going to have our server team run through the process this weekend to see if we can get it working. However, my question is this, now that I have the Perl script, how do I have it run everytime I need to flush the cache? I can have the server support run it for me this once, but I'm thinking maybe it needs to be scheduled? Sorry, I'm clueless about the scripting side. This will be a great learning experience. Thanks everyone! Jamie __20060125___This posting was submitted with HTML in it___
Re: Mid Tier - Long Applet Load Time - pre-cache
** As suspected, Remedy states that the cache process works as designed. They did provide the 'unsupported' Perl script. I'm going to have our server team run through the process this weekend to see if we can get it working. However, my question is this, now that I have the Perl script, how do I have it run everytime I need to flush the cache? I can have the server support run it for me this once, but I'm thinking maybe it needs to be scheduled? Sorry, I'm clueless about the scripting side. This will be a great learning experience. Thanks everyone! Jamie CONFIDENTIALITY: The information contained in this transmission may contain privileged and confidential information. It is intended only for the use of the person(s) named above. If you are not the intended recipient, you are hereby notified that any review, dissemination, distribution or duplication of this communication, and the information contained in it, is strictly prohibited. If you are not the intended recipient, please contact the sender and immediately destroy all copies of the original message. __20060125___This posting was submitted with HTML in it___
Re: Mid Tier - Long Applet Load Time
Title: RE: Mid Tier - Long Applet Load Time ** Don: I agree that the flush requirement needs to be removed. However, I would not want to be the first user to access MT after a major form update! It takes a long time to load the form the first time. And my MT and ARS are on the same system... James McKenzie From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Don McClure Sent: Tuesday, October 17, 2006 8:19 AM To: arslist@ARSLIST.ORG Subject: Re: Mid Tier - Long Applet Load Time ** James: The RPC-situation certainly adds to all these transport delays. My main input was confirming experiences of some other users; specifically, the flush is necessary to guarantee that next form request does get the new form--and that the java vs _javascript_ change places additional load on the MT server (load previously borne by the web browser/plugins at the client--not overwhelming, but not inconsiderable). In at least our experience in this University setting: the demands on server hardware certainly has not decreased the workload for the MT platform, in moving from MT 5.1.2 to 6.3 to 7.0--- and that is even for users on campus only a few hops removed from MT! Don W. McClure, P.E. Systems Engineer University of North Texas [EMAIL PROTECTED] 940.565.3287 >>> "McKenzie, James J C-E LCMC HQISEC/L3" <[EMAIL PROTECTED]> 17-Oct-06 10:05 AM >>> Don: Jamie's problem is well known for long distance RPC traffic. I attended a briefing on the Riverbed traffic shaping device and RPC is very 'chatty' and the longer the connection, the longer it takes to transfer information. The ultimate solution is to not use RPC, but that is not available right now. The second solution is to force the MT server to 'pre-cache' information AFTER the cache is flushed. The way that BMC does updates is to wait until a form is requested and then send over form data from the ARS server to the MT server. This is very slow the first time a form is called for. Add a long and slow connection and this makes things much, much worse. And I agree that the method used by MT 6.3 + needs work so that the system will update whenever a form is changed, not wait for a user to call for the form. James McKenzie L-3 GSI From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Don McClure Sent: Tuesday, October 17, 2006 7:58 AM To: arslist@ARSLIST.ORG Subject: Re: Mid Tier - Long Applet Load Time ** Hi Jamie, Rick Cook mentions complete new architecture; subject re-work includes a change in use of java. Specifically, MT 5.1.2 and earlier relied on client-side java, with some JRE version-specific issues. Example: MT 5.1.2 would not work with Java 1.5.01 mentioned in your architecture, at least in our environment. Last information I had on MT 6.3: MT is server-side _javascript_ only, not relying on any java at the client at all, so the server dataflow and memory-management concerns are quite different. Also, the 'freshness' indicator in MT is not that reliable, so MT cannot necessarily discern an ARS-side change without that cache-flush action (fo rcing a retrieve of current form constructions). HTH... dwm Don W. McClure, P.E. Systems Engineer University of North Texas [EMAIL PROTECTED] 940.565.3287 __20060125___This posting was submitted with HTML in it___
Re: Mid Tier - Long Applet Load Time
** James: The RPC-situation certainly adds to all these transport delays. My main input was confirming experiences of some other users; specifically, the flush is necessary to guarantee that next form request does get the new form--and that the java vs _javascript_ change places additional load on the MT server (load previously borne by the web browser/plugins at the client--not overwhelming, but not inconsiderable). In at least our experience in this University setting: the demands on server hardware certainly has not decreased the workload for the MT platform, in moving from MT 5.1.2 to 6.3 to 7.0--- and that is even for users on campus only a few hops removed from MT! Don W. McClure, P.E.Systems EngineerUniversity of North Texas[EMAIL PROTECTED] 940.565.3287>>> "McKenzie, James J C-E LCMC HQISEC/L3" <[EMAIL PROTECTED]> 17-Oct-06 10:05 AM >>> Don: Jamie's problem is well known for long distance RPC traffic. I attended a briefing on the Riverbed traffic shaping device and RPC is very 'chatty' and the longer the connection, the longer it takes to transfer information. The ultimate solution is to not use RPC, but that is not available right now. The second solution is to force the MT server to 'pre-cache' information AFTER the cache is flushed. The way that BMC does updates is to wait until a form is requested and then send over form data from the ARS server to the MT server. This is very slow the first time a form is called for. Add a long and slow connection and this makes things much, much worse. And I agree that the method used by MT 6.3 + needs work so that the system will update whenever a form is changed, not wait for a user to call for the form. James McKenzie L-3 GSI From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Don McClure Sent: Tuesday, October 17, 2006 7:58 AM To: arslist@ARSLIST.ORG Subject: Re: Mid Tier - Long Applet Load Time ** Hi Jamie, Rick Cook mentions complete new architecture; subject re-work includes a change in use of java. Specifically, MT 5.1.2 and earlier relied on client-side java, with some JRE version-specific issues. Example: MT 5.1.2 would not work with Java 1.5.01 mentioned in your architecture, at least in our environment. Last information I had on MT 6.3: MT is server-side _javascript_ only, not relying on any java at the client at all, so the server dataflow and memory-management concerns are quite different. Also, the 'freshness' indicator in MT is not that reliable, so MT cannot necessarily discern an ARS-side change without that cache-flush action (fo rcing a retrieve of current form constructions). HTH... dwm Don W. McClure, P.E. Systems Engineer University of North Texas [EMAIL PROTECTED] 940.565.3287 __20060125___This posting was submitted with HTML in it___ __20060125___This posting was submitted with HTML in it___
Re: Mid Tier - Long Applet Load Time
Title: RE: Mid Tier - Long Applet Load Time ** Don: Jamie's problem is well known for long distance RPC traffic. I attended a briefing on the Riverbed traffic shaping device and RPC is very 'chatty' and the longer the connection, the longer it takes to transfer information. The ultimate solution is to not use RPC, but that is not available right now. The second solution is to force the MT server to 'pre-cache' information AFTER the cache is flushed. The way that BMC does updates is to wait until a form is requested and then send over form data from the ARS server to the MT server. This is very slow the first time a form is called for. Add a long and slow connection and this makes things much, much worse. And I agree that the method used by MT 6.3 + needs work so that the system will update whenever a form is changed, not wait for a user to call for the form. James McKenzie L-3 GSI From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Don McClure Sent: Tuesday, October 17, 2006 7:58 AM To: arslist@ARSLIST.ORG Subject: Re: Mid Tier - Long Applet Load Time ** Hi Jamie, Rick Cook mentions complete new architecture; subject re-work includes a change in use of java. Specifically, MT 5.1.2 and earlier relied on client-side java, with some JRE version-specific issues. Example: MT 5.1.2 would not work with Java 1.5.01 mentioned in your architecture, at least in our environment. Last information I had on MT 6.3: MT is server-side _javascript_ only, not relying on any java at the client at all, so the server dataflow and memory-management concerns are quite different. Also, the 'freshness' indicator in MT is not that reliable, so MT cannot necessarily discern an ARS-side change without that cache-flush action (forcing a retrieve of current form constructions). HTH... dwm Don W. McClure, P.E. Systems Engineer University of North Texas [EMAIL PROTECTED] 940.565.3287 __20060125___This posting was submitted with HTML in it___
Re: Mid Tier - Long Applet Load Time
Title: RE: Mid Tier - Long Applet Load Time ** I don't see why not since all it is doing is being a client and calling a URL. The only mod would be the differnet URL (5.x used /arsys/apps/... while 6.3 does not use the apps anymore) From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Heider, StephenSent: Tuesday, October 17, 2006 7:50 AMTo: arslist@ARSLIST.ORGSubject: Re: Mid Tier - Long Applet Load Time ** Fred, Does this script work with Mid Tier 6.3? I recall several discussions last year regarding this and I was left with the impression that it would not work with 6.3. From the June 6, 2005 thread entitled "Mid Tier 6.3 Performance on IIS" [On May 10th, I asked Remedy Support about a 6.3 version of the "Auto-load Mid Tier Cache" program and received the following response: "It is unknown at this time if a modification to the program you mentioned will be made so that it can be used with Mid Tier 6.3"] Stephen Mid Tier 6.3 p17 ARS 6.3 p16 ServletExec 5 Windows Server 2003 IIS 6 From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Grooms, Frederick WSent: Monday, October 16, 2006 10:21 AMTo: arslist@ARSLIST.ORGSubject: Re: Mid Tier - Long Applet Load Time ** Mid-Tier "compiles" to the Java heap memory (this is for 6.3, I don't know about 7 yet). Remedy has a script you can request that basically just does a request on each of the forms you use to have the Mid-Tier load them into memory. Fred From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Heider, StephenSent: Monday, October 16, 2006 9:09 AMTo: arslist@ARSLIST.ORGSubject: Re: Mid Tier - Long Applet Load Time ** A question about first load caching... Does Mid Tier simply download one or more files to the local client OR does Mid Tier first "compile" or "assemble" one or more files and then download to the client? If it's the later then is there a way to force Mid Tier to pre-compile or pre-assemble the files? ARS and Mid-Tier 7.0.1 Stephen From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of McKenzie, James J C-E LCMC HQISEC/L3Sent: Monday, October 16, 2006 9:52 AMTo: arslist@ARSLIST.ORGSubject: Re: Mid Tier - Long Applet Load Time ** Lori: Looks about right. The system has to generate the Java Server Pages code for the form and that definitely takes time. Second and later loads of the page should be < one second. James McKenzie L-3 GSI From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Lori Gumbiner Sent: Monday, October 16, 2006 6:23 AM To: arslist@ARSLIST.ORG Subject: Mid Tier - Long Applet Load Time ** Hi, All - We are developing our first true Mid Tier application, and are finding that anytime we perform an Admin cache of the mid tier server, the first time an end user then loads the applet, it is taking 15 - 30 seconds. This seems long to us. Can we please get input from others about load times? TIA... *Lori System Specs: ARS & Mid Tier 6.3, p17 HelpDesk 5.6 Oracle 9.2 Sun Solaris 9 * Lori Gumbiner IT Systems Architecture - Process Automation Initiatives Walgreens Co. __20060125___This posting was submitted with HTML in it___ __20060125___This posting was submitted with HTML in it___ __20060125___This posting was submitted with HTML in it___
Re: Mid Tier - Long Applet Load Time
** Actually, this is to the second webserver. The users are in AUS. We setup that server last year to address the latency concerns under 5.0. It helped tremendously. Now the cache issue with 6.3 is killing us. I agree that the pre-caching should help. I'm hoping Remedy will provide that (unless someone else has a copy?). Thanks! Jamie -Original Message-From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED]On Behalf Of Rick CookSent: Tuesday, October 17, 2006 10:57 AMTo: arslist@ARSLIST.ORGSubject: Re: Mid Tier - Long Applet Load Time** I agree that her network is a concern, but the pre-caching should at least isolate that as the source of any remaining lag time. Perhaps if they added a second web server closer to the clients, and pre-cached to that, it would take care of the problem either way. Rick On 10/17/06, McKenzie, James J C-E LCMC HQISEC/L3 <[EMAIL PROTECTED]> wrote: ** Rick: I think the problem is due to the method used to move information from the ARS server to the MT server for forms and workflow. This is not so obvious when the two are located on the same network segment but can become very visible when the ARS server and MT server are separated by a great distance. This slows down form loading to a crawl. Of course there is a script or program that can force the MT server to 'pre-cache' once the cache is flushed. This may or may not solve Jamie's problem... James McKenzie L-3 GSI From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Rick Cook Sent: Tuesday, October 17, 2006 7:49 AM To: arslist@ARSLIST.ORG Subject: Re: Mid Tier - Long Applet Load Time ** Jamie, the issue is different between the two versions in part because the Mid-Tier architecture is completely different between v5 and v6.3 - with the more modern versions being MUCH better. One thing I have seen that is helpful from a user experience perspective with both 6.3 and 7.0 MT is to have someone (i.e. you) open each of the forms, via the MT, that the user will likely access. This pre-caches the copies of the forms to the MT server, which speeds up the initial load time to the user. Rick On 10/17/06, Blodgett, Jamie < [EMAIL PROTECTED]> wrote: ** I'm having the same issue and have opened a ticket with Remedy. We'll see what they say. My issue is that for the midtier to see the changes to workflow, I have to flush the cache. After flushing the cache, it takes up to 2 minutes for users to access the pages for the first time. After that everything moves very fast. This is a midtier in AUS connecting to ARS in US. This was working fine pre-upgrade ( 5.0). Midtier 6.3 p 18 ARS 6.3 p18 IIS ServletExce 5 p6 Win 2000 Java 1.5.01 I'll update on what Remedy suggests. Thanks, Jamie Blodgett __20060125___This posting was submitted with HTML in it___ -- Rick CookCook Enterprises253-278-4112 __20060125___This posting was submitted with HTML in it___ CONFIDENTIALITY: The information contained in this transmission may contain privileged and confidential information. It is intended only for the use of the person(s) named above. If you are not the intended recipient, you are hereby notified that any review, dissemination, distribution or duplication of this communication, and the information contained in it, is strictly prohibited. If you are not the intended recipient, please contact the sender and immediately destroy all copies of the original message. __20060125___This posting was submitted with HTML in it___
Re: Mid Tier - Long Applet Load Time
Title: RE: Mid Tier - Long Applet Load Time ** Rick: I agree. However, the MT server is on a different continent. This is why I think the fat-long problem associated with RPC traffic happens. (If you need more information on this, look for the Riverbed traffic shaping device, they have a real good explanation on this problem.) This is made worse by the methods used by MT 6.3 + to transfer traffic from the ARS server to the MT server. James McKenzie L-3 GSI From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Rick Cook Sent: Tuesday, October 17, 2006 7:57 AM To: arslist@ARSLIST.ORG Subject: Re: Mid Tier - Long Applet Load Time ** I agree that her network is a concern, but the pre-caching should at least isolate that as the source of any remaining lag time. Perhaps if they added a second web server closer to the clients, and pre-cached to that, it would take care of the problem either way. Rick On 10/17/06, McKenzie, James J C-E LCMC HQISEC/L3 <[EMAIL PROTECTED]> wrote: ** Rick: I think the problem is due to the method used to move information from the ARS server to the MT server for forms and workflow. This is not so obvious when the two are located on the same network segment but can become very visible when the ARS server and MT server are separated by a great distance. This slows down form loading to a crawl. Of course there is a script or program that can force the MT server to 'pre-cache' once the cache is flushed. This may or may not solve Jamie's problem... James McKenzie L-3 GSI __20060125___This posting was submitted with HTML in it___
Re: Mid Tier - Long Applet Load Time
** Hi Jamie, Rick Cook mentions complete new architecture; subject re-work includes a change in use of java. Specifically, MT 5.1.2 and earlier relied on client-side java, with some JRE version-specific issues. Example: MT 5.1.2 would not work with Java 1.5.01 mentioned in your architecture, at least in our environment. Last information I had on MT 6.3: MT is server-side _javascript_ only, not relying on any java at the client at all, so the server dataflow and memory-management concerns are quite different. Also, the 'freshness' indicator in MT is not that reliable, so MT cannot necessarily discern an ARS-side change without that cache-flush action (forcing a retrieve of current form constructions). HTH... dwm Don W. McClure, P.E.Systems EngineerUniversity of North Texas[EMAIL PROTECTED] 940.565.3287 >>> "Blodgett, Jamie" <[EMAIL PROTECTED]> 17-Oct-06 9:36 AM >>> I'm having the same issue and have opened a ticket with Remedy. We'll see what they say. My issue is that for the midtier to see the changes to workflow, I have to flush the cache. After flushing the cache, it takes up to 2 minutes for users to access the pages for the first time. After that everything moves very fast. This is a midtier in AUS connecting to ARS in US. This was working fine pre-upgrade (5.0). Midtier 6.3 p 18 ARS 6.3 p18 IIS ServletExce 5 p6 Win 2000 Java 1.5.01 I'll update on what Remedy suggests. Thanks, Jamie Blodgett -Original Message-From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED]On Behalf Of Heider, StephenSent: Tuesday, October 17, 2006 8:50 AMTo: arslist@ARSLIST.ORGSubject: Re: Mid Tier - Long Applet Load Time** Fred, Does this script work with Mid Tier 6.3? I recall several discussions last year regarding this and I was left with the impression that it would not work with 6.3. From the June 6, 2005 thread entitled "Mid Tier 6.3 Performance on IIS" [On May 10th, I asked Remedy Support about a 6.3 version of the "Auto-load Mid Tier Cache" program and received the following response: "It is unknown at this time if a modification to the program you mentioned will be made so that it can be used with Mid Tier 6.3"] Stephen Mid Tier 6.3 p17 ARS 6.3 p16 ServletExec 5 Windows Server 2003 IIS 6 From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Grooms, Frederick WSent: Monday, October 16, 2006 10:21 AMTo: arslist@ARSLIST.ORGSubject: Re: Mid Tier - Long Applet Load Time ** Mid-Tier "compiles" to the Java heap memory (this is for 6.3, I don't know about 7 yet). Remedy has a script you can request that basically just does a request on each of the forms you use to have the Mid-Tier load them into memory. Fred From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Heider, StephenSent: Monday, October 16, 2006 9:09 AMTo: arslist@ARSLIST.ORGSubject: Re: Mid Tier - Long Applet Load Time ** A question about first load caching... Does Mid Tier simply download one or more files to the local client OR does Mid Tier first "compile" or "assemble" one or more files and then download to the client? If it's the later then is there a way to force Mid Tier to pre-compile or pre-assemble the files? ARS and Mid-Tier 7.0.1 Stephen From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of McKenzie, James J C-E LCMC HQISEC/L3Sent: Monday, October 16, 2006 9:52 AMTo: arslist@ARSLIST.ORGSubject: Re: Mid Tier - Long Applet Load Time ** Lori: Looks about right. The system has to generate the Java Server Pages code for the form and that definitely takes time. Second and later loads of the page should be < one second. James McKenzie L-3 GSI From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Lori Gumbiner Sent: Monday, October 16, 2006 6:23 AM To: arslist@ARSLIST.ORG Subject: Mid Tier - Long Applet Load Time ** Hi, All - We are developing our first true Mid Tier application, and are finding that anytime we perform an Admin cache of the mid tier server, the first time an end user then loads the applet, it is taking 15 - 30 seconds. This seems long to us. Can we please get input from others about load times? TIA... *Lori System Specs: ARS & Mid Tier 6.3, p17 HelpDesk 5.6 Oracle 9.2 Sun Solaris 9 * Lori Gumbiner IT Systems Architecture - Process Automation Initiatives Walgreens Co. __20060125___This posting was submitted with HTML in it___ __20060125___This posting was submitted with HTML in it___ CONFIDENTIALITY: The information contained in this transmission may contain privileged and confidential information. It is intended only
Re: Mid Tier - Long Applet Load Time
** I agree that her network is a concern, but the pre-caching should at least isolate that as the source of any remaining lag time. Perhaps if they added a second web server closer to the clients, and pre-cached to that, it would take care of the problem either way. Rick On 10/17/06, McKenzie, James J C-E LCMC HQISEC/L3 <[EMAIL PROTECTED]> wrote: ** Rick: I think the problem is due to the method used to move information from the ARS server to the MT server for forms and workflow. This is not so obvious when the two are located on the same network segment but can become very visible when the ARS server and MT server are separated by a great distance. This slows down form loading to a crawl. Of course there is a script or program that can force the MT server to 'pre-cache' once the cache is flushed. This may or may not solve Jamie's problem... James McKenzie L-3 GSI From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Rick Cook Sent: Tuesday, October 17, 2006 7:49 AM To: arslist@ARSLIST.ORG Subject: Re: Mid Tier - Long Applet Load Time ** Jamie, the issue is different between the two versions in part because the Mid-Tier architecture is completely different between v5 and v6.3 - with the more modern versions being MUCH better. One thing I have seen that is helpful from a user experience perspective with both 6.3 and 7.0 MT is to have someone (i.e. you) open each of the forms, via the MT, that the user will likely access. This pre-caches the copies of the forms to the MT server, which speeds up the initial load time to the user. Rick On 10/17/06, Blodgett, Jamie < [EMAIL PROTECTED]> wrote: ** I'm having the same issue and have opened a ticket with Remedy. We'll see what they say. My issue is that for the midtier to see the changes to workflow, I have to flush the cache. After flushing the cache, it takes up to 2 minutes for users to access the pages for the first time. After that everything moves very fast. This is a midtier in AUS connecting to ARS in US. This was working fine pre-upgrade ( 5.0). Midtier 6.3 p 18 ARS 6.3 p18 IIS ServletExce 5 p6 Win 2000 Java 1.5.01 I'll update on what Remedy suggests. Thanks, Jamie Blodgett __20060125___This posting was submitted with HTML in it___ -- Rick CookCook Enterprises253-278-4112 __20060125___This posting was submitted with HTML in it___
Re: Mid Tier - Long Applet Load Time
Title: RE: Mid Tier - Long Applet Load Time ** Does anyone on ARS List have this script for Mid Tier 6.3? Stephen From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of McKenzie, James J C-E LCMC HQISEC/L3Sent: Tuesday, October 17, 2006 10:52 AMTo: arslist@ARSLIST.ORGSubject: Re: Mid Tier - Long Applet Load Time ** Rick: I think the problem is due to the method used to move information from the ARS server to the MT server for forms and workflow. This is not so obvious when the two are located on the same network segment but can become very visible when the ARS server and MT server are separated by a great distance. This slows down form loading to a crawl. Of course there is a script or program that can force the MT server to 'pre-cache' once the cache is flushed. This may or may not solve Jamie's problem... James McKenzie L-3 GSI From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Rick Cook Sent: Tuesday, October 17, 2006 7:49 AM To: arslist@ARSLIST.ORG Subject: Re: Mid Tier - Long Applet Load Time ** Jamie, the issue is different between the two versions in part because the Mid-Tier architecture is completely different between v5 and v6.3 - with the more modern versions being MUCH better. One thing I have seen that is helpful from a user experience perspective with both 6.3 and 7.0 MT is to have someone (i.e. you) open each of the forms, via the MT, that the user will likely access. This pre-caches the copies of the forms to the MT server, which speeds up the initial load time to the user. Rick On 10/17/06, Blodgett, Jamie <[EMAIL PROTECTED]> wrote: ** I'm having the same issue and have opened a ticket with Remedy. We'll see what they say. My issue is that for the midtier to see the changes to workflow, I have to flush the cache. After flushing the cache, it takes up to 2 minutes for users to access the pages for the first time. After that everything moves very fast. This is a midtier in AUS connecting to ARS in US. This was working fine pre-upgrade ( 5.0). Midtier 6.3 p 18 ARS 6.3 p18 IIS ServletExce 5 p6 Win 2000 Java 1.5.01 I'll update on what Remedy suggests. Thanks, Jamie Blodgett __20060125___This posting was submitted with HTML in it___ __20060125___This posting was submitted with HTML in it___
Re: Mid Tier - Long Applet Load Time
Title: RE: Mid Tier - Long Applet Load Time ** Rick: I think the problem is due to the method used to move information from the ARS server to the MT server for forms and workflow. This is not so obvious when the two are located on the same network segment but can become very visible when the ARS server and MT server are separated by a great distance. This slows down form loading to a crawl. Of course there is a script or program that can force the MT server to 'pre-cache' once the cache is flushed. This may or may not solve Jamie's problem... James McKenzie L-3 GSI From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Rick Cook Sent: Tuesday, October 17, 2006 7:49 AM To: arslist@ARSLIST.ORG Subject: Re: Mid Tier - Long Applet Load Time ** Jamie, the issue is different between the two versions in part because the Mid-Tier architecture is completely different between v5 and v6.3 - with the more modern versions being MUCH better. One thing I have seen that is helpful from a user experience perspective with both 6.3 and 7.0 MT is to have someone (i.e. you) open each of the forms, via the MT, that the user will likely access. This pre-caches the copies of the forms to the MT server, which speeds up the initial load time to the user. Rick On 10/17/06, Blodgett, Jamie <[EMAIL PROTECTED]> wrote: ** I'm having the same issue and have opened a ticket with Remedy. We'll see what they say. My issue is that for the midtier to see the changes to workflow, I have to flush the cache. After flushing the cache, it takes up to 2 minutes for users to access the pages for the first time. After that everything moves very fast. This is a midtier in AUS connecting to ARS in US. This was working fine pre-upgrade ( 5.0). Midtier 6.3 p 18 ARS 6.3 p18 IIS ServletExce 5 p6 Win 2000 Java 1.5.01 I'll update on what Remedy suggests. Thanks, Jamie Blodgett __20060125___This posting was submitted with HTML in it___
Re: Mid Tier - Long Applet Load Time
** Jamie, the issue is different between the two versions in part because the Mid-Tier architecture is completely different between v5 and v6.3 - with the more modern versions being MUCH better. One thing I have seen that is helpful from a user experience perspective with both 6.3 and 7.0 MT is to have someone (i.e. you) open each of the forms, via the MT, that the user will likely access. This pre-caches the copies of the forms to the MT server, which speeds up the initial load time to the user. Rick On 10/17/06, Blodgett, Jamie <[EMAIL PROTECTED]> wrote: ** I'm having the same issue and have opened a ticket with Remedy. We'll see what they say. My issue is that for the midtier to see the changes to workflow, I have to flush the cache. After flushing the cache, it takes up to 2 minutes for users to access the pages for the first time. After that everything moves very fast. This is a midtier in AUS connecting to ARS in US. This was working fine pre-upgrade ( 5.0). Midtier 6.3 p 18 ARS 6.3 p18 IIS ServletExce 5 p6 Win 2000 Java 1.5.01 I'll update on what Remedy suggests. Thanks, Jamie Blodgett -Original Message-From: Action Request System discussion list(ARSList) [mailto: arslist@ARSLIST.ORG]On Behalf Of Heider, Stephen Sent: Tuesday, October 17, 2006 8:50 AMTo: arslist@ARSLIST.ORG Subject: Re: Mid Tier - Long Applet Load Time ** Fred, Does this script work with Mid Tier 6.3? I recall several discussions last year regarding this and I was left with the impression that it would not work with 6.3. From the June 6, 2005 thread entitled "Mid Tier 6.3 Performance on IIS" [On May 10th, I asked Remedy Support about a 6.3 version of the "Auto-load Mid Tier Cache" program and received the following response: "It is unknown at this time if a modification to the program you mentioned will be made so that it can be used with Mid Tier 6.3"] Stephen Mid Tier 6.3 p17 ARS 6.3 p16 ServletExec 5 Windows Server 2003 IIS 6 From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG ] On Behalf Of Grooms, Frederick WSent: Monday, October 16, 2006 10:21 AMTo: arslist@ARSLIST.ORG Subject: Re: Mid Tier - Long Applet Load Time ** Mid-Tier "compiles" to the Java heap memory (this is for 6.3, I don't know about 7 yet). Remedy has a script you can request that basically just does a request on each of the forms you use to have the Mid-Tier load them into memory. Fred From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG ] On Behalf Of Heider, StephenSent: Monday, October 16, 2006 9:09 AMTo: arslist@ARSLIST.ORG Subject: Re: Mid Tier - Long Applet Load Time ** A question about first load caching... Does Mid Tier simply download one or more files to the local client OR does Mid Tier first "compile" or "assemble" one or more files and then download to the client? If it's the later then is there a way to force Mid Tier to pre-compile or pre-assemble the files? ARS and Mid-Tier 7.0.1 Stephen From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG ] On Behalf Of McKenzie, James J C-E LCMC HQISEC/L3Sent: Monday, October 16, 2006 9:52 AMTo: arslist@ARSLIST.ORGSubject: Re: Mid Tier - Long Applet Load Time ** Lori: Looks about right. The system has to generate the Java Server Pages code for the form and that definitely takes time. Second and later loads of the page should be < one second. James McKenzie L-3 GSI From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Lori Gumbiner Sent: Monday, October 16, 2006 6:23 AM To: arslist@ARSLIST.ORG Subject: Mid Tier - Long Applet Load Time ** Hi, All - We are developing our first true Mid Tier application, and are finding that anytime we perform an Admin cache of the mid tier server, the first time an end user then loads the applet, it is taking 15 - 30 seconds. This seems long to us. Can we please get input from others about load times? TIA... *Lori System Specs: ARS & Mid Tier 6.3, p17 HelpDesk 5.6 Oracle 9.2 Sun Solaris 9 * Lori Gumbiner IT Systems Architecture - Process Automation Initiatives Walgreens Co. __20060125___This posting was submitted with HTML in it___ __20060125___This posting was submitted with HTML in it___ CONFIDENTIALITY: The information contained in this transmission may contain privileged and confidential information. It is intended only for the use of the person(s) named above. If you are not the intended recipient, you are hereby notified that any review, dissemination, distribution or duplication of this communication, and the information contained in it, is strictly prohibited. If you are not the intended recipient, please contact the sender and immediat
Re: Mid Tier - Long Applet Load Time
Title: RE: Mid Tier - Long Applet Load Time ** Jamie: Looks like a long-fat connection (network latency) problem between the Mid-Tier server and your ARS server. I know that there is a program available that will 'pre-load' the cache and you might want to utilize it. James McKenzie From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Blodgett, Jamie Sent: Tuesday, October 17, 2006 7:36 AM To: arslist@ARSLIST.ORG Subject: Re: Mid Tier - Long Applet Load Time ** I'm having the same issue and have opened a ticket with Remedy. We'll see what they say. My issue is that for the midtier to see the changes to workflow, I have to flush the cache. After flushing the cache, it takes up to 2 minutes for users to access the pages for the first time. After that everything moves very fast. This is a midtier in AUS connecting to ARS in US. This was working fine pre-upgrade (5.0). Midtier 6.3 p 18 ARS 6.3 p18 IIS ServletExce 5 p6 Win 2000 Java 1.5.01 I'll update on what Remedy suggests. Thanks, Jamie Blodgett __20060125___This posting was submitted with HTML in it___
Re: Mid Tier - Long Applet Load Time
Title: RE: Mid Tier - Long Applet Load Time ** I'm having the same issue and have opened a ticket with Remedy. We'll see what they say. My issue is that for the midtier to see the changes to workflow, I have to flush the cache. After flushing the cache, it takes up to 2 minutes for users to access the pages for the first time. After that everything moves very fast. This is a midtier in AUS connecting to ARS in US. This was working fine pre-upgrade (5.0). Midtier 6.3 p 18 ARS 6.3 p18 IIS ServletExce 5 p6 Win 2000 Java 1.5.01 I'll update on what Remedy suggests. Thanks, Jamie Blodgett -Original Message-From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED]On Behalf Of Heider, StephenSent: Tuesday, October 17, 2006 8:50 AMTo: arslist@ARSLIST.ORGSubject: Re: Mid Tier - Long Applet Load Time** Fred, Does this script work with Mid Tier 6.3? I recall several discussions last year regarding this and I was left with the impression that it would not work with 6.3. From the June 6, 2005 thread entitled "Mid Tier 6.3 Performance on IIS" [On May 10th, I asked Remedy Support about a 6.3 version of the "Auto-load Mid Tier Cache" program and received the following response: "It is unknown at this time if a modification to the program you mentioned will be made so that it can be used with Mid Tier 6.3"] Stephen Mid Tier 6.3 p17 ARS 6.3 p16 ServletExec 5 Windows Server 2003 IIS 6 From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Grooms, Frederick WSent: Monday, October 16, 2006 10:21 AMTo: arslist@ARSLIST.ORGSubject: Re: Mid Tier - Long Applet Load Time ** Mid-Tier "compiles" to the Java heap memory (this is for 6.3, I don't know about 7 yet). Remedy has a script you can request that basically just does a request on each of the forms you use to have the Mid-Tier load them into memory. Fred From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Heider, StephenSent: Monday, October 16, 2006 9:09 AMTo: arslist@ARSLIST.ORGSubject: Re: Mid Tier - Long Applet Load Time ** A question about first load caching... Does Mid Tier simply download one or more files to the local client OR does Mid Tier first "compile" or "assemble" one or more files and then download to the client? If it's the later then is there a way to force Mid Tier to pre-compile or pre-assemble the files? ARS and Mid-Tier 7.0.1 Stephen From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of McKenzie, James J C-E LCMC HQISEC/L3Sent: Monday, October 16, 2006 9:52 AMTo: arslist@ARSLIST.ORGSubject: Re: Mid Tier - Long Applet Load Time ** Lori: Looks about right. The system has to generate the Java Server Pages code for the form and that definitely takes time. Second and later loads of the page should be < one second. James McKenzie L-3 GSI From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Lori Gumbiner Sent: Monday, October 16, 2006 6:23 AM To: arslist@ARSLIST.ORG Subject: Mid Tier - Long Applet Load Time ** Hi, All - We are developing our first true Mid Tier application, and are finding that anytime we perform an Admin cache of the mid tier server, the first time an end user then loads the applet, it is taking 15 - 30 seconds. This seems long to us. Can we please get input from others about load times? TIA... *Lori System Specs: ARS & Mid Tier 6.3, p17 HelpDesk 5.6 Oracle 9.2 Sun Solaris 9 * Lori Gumbiner IT Systems Architecture - Process Automation Initiatives Walgreens Co. __20060125___This posting was submitted with HTML in it___ __20060125___This posting was submitted with HTML in it___ CONFIDENTIALITY: The information contained in this transmission may contain privileged and confidential information. It is intended only for the use of the person(s) named above. If you are not the intended recipient, you are hereby notified that any review, dissemination, distribution or duplication of this communication, and the information contained in it, is strictly prohibited. If you are not the intended recipient, please contact the sender and immediately destroy all copies of the original message. __20060125___This posting was submitted with HTML in it___
Re: Mid Tier - Long Applet Load Time
Title: RE: Mid Tier - Long Applet Load Time ** Fred, Does this script work with Mid Tier 6.3? I recall several discussions last year regarding this and I was left with the impression that it would not work with 6.3. From the June 6, 2005 thread entitled "Mid Tier 6.3 Performance on IIS" [On May 10th, I asked Remedy Support about a 6.3 version of the "Auto-load Mid Tier Cache" program and received the following response: "It is unknown at this time if a modification to the program you mentioned will be made so that it can be used with Mid Tier 6.3"] Stephen Mid Tier 6.3 p17 ARS 6.3 p16 ServletExec 5 Windows Server 2003 IIS 6 From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Grooms, Frederick WSent: Monday, October 16, 2006 10:21 AMTo: arslist@ARSLIST.ORGSubject: Re: Mid Tier - Long Applet Load Time ** Mid-Tier "compiles" to the Java heap memory (this is for 6.3, I don't know about 7 yet). Remedy has a script you can request that basically just does a request on each of the forms you use to have the Mid-Tier load them into memory. Fred From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Heider, StephenSent: Monday, October 16, 2006 9:09 AMTo: arslist@ARSLIST.ORGSubject: Re: Mid Tier - Long Applet Load Time ** A question about first load caching... Does Mid Tier simply download one or more files to the local client OR does Mid Tier first "compile" or "assemble" one or more files and then download to the client? If it's the later then is there a way to force Mid Tier to pre-compile or pre-assemble the files? ARS and Mid-Tier 7.0.1 Stephen From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of McKenzie, James J C-E LCMC HQISEC/L3Sent: Monday, October 16, 2006 9:52 AMTo: arslist@ARSLIST.ORGSubject: Re: Mid Tier - Long Applet Load Time ** Lori: Looks about right. The system has to generate the Java Server Pages code for the form and that definitely takes time. Second and later loads of the page should be < one second. James McKenzie L-3 GSI From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Lori Gumbiner Sent: Monday, October 16, 2006 6:23 AM To: arslist@ARSLIST.ORG Subject: Mid Tier - Long Applet Load Time ** Hi, All - We are developing our first true Mid Tier application, and are finding that anytime we perform an Admin cache of the mid tier server, the first time an end user then loads the applet, it is taking 15 - 30 seconds. This seems long to us. Can we please get input from others about load times? TIA... *Lori System Specs: ARS & Mid Tier 6.3, p17 HelpDesk 5.6 Oracle 9.2 Sun Solaris 9 * Lori Gumbiner IT Systems Architecture - Process Automation Initiatives Walgreens Co. __20060125___This posting was submitted with HTML in it___ __20060125___This posting was submitted with HTML in it___
Re: Mid Tier - Long Applet Load Time
Title: RE: Mid Tier - Long Applet Load Time ** Mid-Tier "compiles" to the Java heap memory (this is for 6.3, I don't know about 7 yet). Remedy has a script you can request that basically just does a request on each of the forms you use to have the Mid-Tier load them into memory. Fred From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Heider, StephenSent: Monday, October 16, 2006 9:09 AMTo: arslist@ARSLIST.ORGSubject: Re: Mid Tier - Long Applet Load Time ** A question about first load caching... Does Mid Tier simply download one or more files to the local client OR does Mid Tier first "compile" or "assemble" one or more files and then download to the client? If it's the later then is there a way to force Mid Tier to pre-compile or pre-assemble the files? ARS and Mid-Tier 7.0.1 Stephen From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of McKenzie, James J C-E LCMC HQISEC/L3Sent: Monday, October 16, 2006 9:52 AMTo: arslist@ARSLIST.ORGSubject: Re: Mid Tier - Long Applet Load Time ** Lori: Looks about right. The system has to generate the Java Server Pages code for the form and that definitely takes time. Second and later loads of the page should be < one second. James McKenzie L-3 GSI From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Lori Gumbiner Sent: Monday, October 16, 2006 6:23 AM To: arslist@ARSLIST.ORG Subject: Mid Tier - Long Applet Load Time ** Hi, All - We are developing our first true Mid Tier application, and are finding that anytime we perform an Admin cache of the mid tier server, the first time an end user then loads the applet, it is taking 15 - 30 seconds. This seems long to us. Can we please get input from others about load times? TIA... *Lori System Specs: ARS & Mid Tier 6.3, p17 HelpDesk 5.6 Oracle 9.2 Sun Solaris 9 * Lori Gumbiner IT Systems Architecture - Process Automation Initiatives Walgreens Co. __20060125___This posting was submitted with HTML in it___
Re: Mid Tier - Long Applet Load Time
Title: RE: Mid Tier - Long Applet Load Time ** A question about first load caching... Does Mid Tier simply download one or more files to the local client OR does Mid Tier first "compile" or "assemble" one or more files and then download to the client? If it's the later then is there a way to force Mid Tier to pre-compile or pre-assemble the files? ARS and Mid-Tier 7.0.1 Stephen From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of McKenzie, James J C-E LCMC HQISEC/L3Sent: Monday, October 16, 2006 9:52 AMTo: arslist@ARSLIST.ORGSubject: Re: Mid Tier - Long Applet Load Time ** Lori: Looks about right. The system has to generate the Java Server Pages code for the form and that definitely takes time. Second and later loads of the page should be < one second. James McKenzie L-3 GSI From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Lori Gumbiner Sent: Monday, October 16, 2006 6:23 AM To: arslist@ARSLIST.ORG Subject: Mid Tier - Long Applet Load Time ** Hi, All - We are developing our first true Mid Tier application, and are finding that anytime we perform an Admin cache of the mid tier server, the first time an end user then loads the applet, it is taking 15 - 30 seconds. This seems long to us. Can we please get input from others about load times? TIA... *Lori System Specs: ARS & Mid Tier 6.3, p17 HelpDesk 5.6 Oracle 9.2 Sun Solaris 9 * Lori Gumbiner IT Systems Architecture - Process Automation Initiatives Walgreens Co. __20060125___This posting was submitted with HTML in it___ __20060125___This posting was submitted with HTML in it___
Re: Mid Tier - Long Applet Load Time
Title: RE: Mid Tier - Long Applet Load Time ** Lori: Looks about right. The system has to generate the Java Server Pages code for the form and that definitely takes time. Second and later loads of the page should be < one second. James McKenzie L-3 GSI From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Lori Gumbiner Sent: Monday, October 16, 2006 6:23 AM To: arslist@ARSLIST.ORG Subject: Mid Tier - Long Applet Load Time ** Hi, All - We are developing our first true Mid Tier application, and are finding that anytime we perform an Admin cache of the mid tier server, the first time an end user then loads the applet, it is taking 15 - 30 seconds. This seems long to us. Can we please get input from others about load times? TIA... *Lori System Specs: ARS & Mid Tier 6.3, p17 HelpDesk 5.6 Oracle 9.2 Sun Solaris 9 * Lori Gumbiner IT Systems Architecture - Process Automation Initiatives Walgreens Co. __20060125___This posting was submitted with HTML in it___
Re: Mid Tier - Long Applet Load Time
** Every time you clear and reload the cache on the server you will experience this issue. As the users constantly login/out of the midtier and you don’t re-cache the server, the times will decrease to the point where 2 seconds or less is normal. Thank You, Chris Doble Mobile:949-533-5346 Email: [EMAIL PROTECTED] Web: http://www.aisconsulting.net From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Lori Gumbiner Sent: Monday, October 16, 2006 6:23 AM To: arslist@ARSLIST.ORG Subject: Mid Tier - Long Applet Load Time ** Hi, All - We are developing our first true Mid Tier application, and are finding that anytime we perform an Admin cache of the mid tier server, the first time an end user then loads the applet, it is taking 15 - 30 seconds. This seems long to us. Can we please get input from others about load times? TIA... *Lori System Specs: ARS & Mid Tier 6.3, p17 HelpDesk 5.6 Oracle 9.2 Sun Solaris 9 * Lori Gumbiner IT Systems Architecture - Process Automation Initiatives Walgreens Co. 847.914.5796 __20060125___This posting was submitted with HTML in it___ __20060125___This posting was submitted with HTML in it___
Re: Mid Tier - Long Applet Load Time
Title: Message ** Lori, Unfortunately it is hard to compare load times for forms because it partially depends on the complexity of the form (e.g. number of fields, number of extra items like tabs, view fields, etc) and the performance of the mid tier server itself. In my experience when it takes a long time to load the first time but everything comes up at a decent speed each time each time after that, it is generally that the form is too complex to load quickly. If it loads slow the first time and always loads slowly after that, then it's probably the performance of the mid tier itself. You shouldn't need to reload the cache much in a production environment. I hope this helps, Shawn Pierson -Original Message-From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Lori GumbinerSent: Monday, October 16, 2006 8:23 AMTo: arslist@ARSLIST.ORGSubject: Mid Tier - Long Applet Load Time** Hi, All - We are developing our first true Mid Tier application, and are finding that anytime we perform an Admin cache of the mid tier server, the first time an end user then loads the applet, it is taking 15 - 30 seconds. This seems long to us. Can we please get input from others about load times? TIA... *Lori System Specs: ARS & Mid Tier 6.3, p17 HelpDesk 5.6 Oracle 9.2 Sun Solaris 9 *Lori GumbinerIT Systems Architecture - Process Automation InitiativesWalgreens Co.847.914.5796 __20060125___This posting was submitted with HTML in it___The information in this e-mail, and any files transmitted with it, is intended for the exclusive use of the recipient(s) to which it is addressed and may contain confidential, proprietary or privileged information. If you are not an intended recipient, you have received this transmission in error and any use, review, dissemination, distribution, printing or copying of this information is strictly prohibited. If you have received this e-mail in error, please notify the sender immediately of the erroneous transmission by reply e-mail, immediately delete this e-mail and all electronic copies of it from your system and destroy any hard copies of it that you may have made. Thank you. __20060125___This posting was submitted with HTML in it___
Re: Mid Tier - Long Applet Load Time
** That's not all that atypical, Lori. You probably also noticed that subsequent loads are on the order of 1-2 seconds. If you can upgrade your Mid-Tier to 7.0 (OK with ARS 6.3), you'll see a performance increase. Rick On 10/16/06, Lori Gumbiner <[EMAIL PROTECTED]> wrote: ** Hi, All - We are developing our first true Mid Tier application, and are finding that anytime we perform an Admin cache of the mid tier server, the first time an end user then loads the applet, it is taking 15 - 30 seconds. This seems long to us. Can we please get input from others about load times? TIA... *Lori System Specs: ARS & Mid Tier 6.3, p17 HelpDesk 5.6 Oracle 9.2 Sun Solaris 9 *Lori GumbinerIT Systems Architecture - Process Automation Initiatives Walgreens Co.847.914.5796 __20060125___This posting was submitted with HTML in it___ -- Rick CookCook Enterprises253-278-4112 __20060125___This posting was submitted with HTML in it___
Mid Tier - Long Applet Load Time
** Hi, All - We are developing our first true Mid Tier application, and are finding that anytime we perform an Admin cache of the mid tier server, the first time an end user then loads the applet, it is taking 15 - 30 seconds. This seems long to us. Can we please get input from others about load times? TIA... *Lori System Specs: ARS & Mid Tier 6.3, p17 HelpDesk 5.6 Oracle 9.2 Sun Solaris 9 * Lori Gumbiner IT Systems Architecture - Process Automation Initiatives Walgreens Co. 847.914.5796 __20060125___This posting was submitted with HTML in it___
