I have heard the "Remote Mid-Tier Rumor" as well, and honestly have tested it internally and it seems to not hold true, at least for our environment(s).
We have 6.3 servers (DEV/TEST/PROD) in NA/EU/AP and when I point the NA web server to AP/EU, it seems just as slow as using the native client. (Win2003, IIS, Servlet Exec) We have one 7.x server (DEV/TEST/PROD) in EU and a sandbox in NA, when I point NA to EU, it seems just as slow as using the native client. (Win2003, Tomcat, Jboss) While there might be a slight performance increase, it is not "human perceivable" from the UI stand point. Workflow is still workflow, which must query forms, etc. Our network team is currently trying to find web-accelerators (compression, etc) to stick on both ends as a test... >> HOWEVER << For all performance related issues I always suggest: Establish a "Base Line" timing for certain key forms (we use Remedy Support, HPD:HelpDesk and CHG:Change) for "Certain Operations" (query by ID, submit, etc) and obtain the client LOG FILE (API only) for this reference. Setup simple "Monitoring" which runs periodically during the day (ours is every half hour) to perform certain operations. (our little VB Application just does a "query where '1' = "known_value") Obviously take the response time, and stuff it in a history table for trending. Now you are "set with baseline"... if you are not happy with the baseline, then you can do Performance-101 (do not do table refreshes on display, reduce # fields on the view, etc) Then when something is reported you can ask "what changed to cause the issue" >> Comparison to baseline is x% worse? Something to really worry about or just 'whiny users' :-) >> Release? >> # Users increased? >> ticket volume increase? >> link volume increase? Although you indicate it is dedicated, is other traffic getting routed through somehow? Unfortunately, performance is in the eyes of the end-user, and without a baseline, you have no comparison. Thanks-n-advance; HDT Platform Incident / Problem Manager & Architect Robert Molenda IT OS PA Tel: +1 408 503 2701 Fax: +1 408 503 2912 Mobile: +1 408 472 8097 [EMAIL PROTECTED] Quality begins with your actions. ________________________________ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of L. J. Head Sent: Thursday, May 17, 2007 6:09 AM To: [email protected] Subject: Re: Remedy performance Overseas I don't know if this applies to you but I have been told via the list that if you have a slow link between client and server and are using Mid-Tier that you can place a mid-tier the other side of the link (client side) and although the initial caching will be slow, overall speed to the clients will increase. It is true what another poster said about chattiness between the client and server...but in this case the 'server' would be the mid-tier...which would be local...so the only information that would need to transfer over the wire would be the Data ________________________________ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of John Kovalcik Sent: Thursday, May 17, 2007 5:25 AM To: [email protected] Subject: Remedy performance Overseas ** All, We are having an issue with performance across the pond to our India location. Currently, we have one HPUX server here in the States with a dedicated network line overseas. Now, granted the line is not as big as it should be and I know that Remedy is resource intensive, but is there anything that we can do to help performance ?? Any info would be greatly appreciated. Thanks, John M. Kovalcik Service Management Sr. Analyst ITIL Foundations Certified Global Information Technology Kennametal Inc. 1600 Technology Way Phone: 724-539-5228 Fax: 724-539-5797 __20060125_______________________This posting was submitted with HTML in it___ __20060125_______________________This posting was submitted with HTML in it___ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
