| **
Frank,
I've not experimented with compressing the traffic between the mid-tier and the AR server, just between the mid-tier and the desktop. I think in your case turning on compression would help if you leave the mid-tier distant from the browser but might not even be noticed if the mid-tier is in the same building or campus as the user desktops.
Turning on compression for tomcat can be done by editing the server.xml file. That's in /etc/tomcat5 on most Linuxes, also could be in a cof directory. The default server.xml contains instructions in the comments, or contact me off list if you get stuck...
Doug On Jan 29, 2010, at 12:53 AM, Frank Caruso wrote: **
Like the compression idea.
We use IIS with Tomcat as the JSP. Would I need to turn on compress in both or just the JSP?
Thank you
On Fri, Jan 29, 2010 at 7:34 AM, Doug Blair <d...@blairing.com> wrote:
**
Hi...
We have run a local mid-tier server on the other end of a transatlantic hop, and a second in the middle east, fed by an AR server in the middle of the US. Dr. Strauss is right, the results as perceived by the user are significant, and the closer your desktop web browser is to the mid-tier server, the better. Setting up the pre-fetch file is critical, and creating your users from templates so that their permission groups are *identical* is very important too.
The data that goes between the server and the desktop - the text in an individual ticket - has to go through that whole network chain regardless of what you do, but the layouts, labels, any images which are part of the form all do display faster.
Another avenue worth trying before you invest in a distant-office mid-tier (although you really don't need anything more expensive than a small PC to feed a remote office of a few dozen desktops) is turning on compression in your main mid-tier web server. This is pretty easy to do in tomcat (only one I have actually used) and is just a check option in IIS. Most of the data that travels between a browser and a Remedy server is text, not image data, and it does compress well. One extreme test case with a very slow network connection the time to display an incident (ITSM 7.0) went from about a minute to about 12 seconds - a very significant improvement. Try this yourself with the worst connection you can arrange - find an old modem in your storage locker and call a modem pool on another continent or something. You'll be surprised!
Hope this helps
Doug
On Jan 28, 2010, at 9:27 AM, strauss wrote:
**
Most sites that I have heard discuss this believed that they got better performance with a mid-tier server placed at or near the remote site. BTW, any mid-tier 7.1 server that is pre-fetching and caching the ITSM 7.0 application is going to take about 30 minutes to do so, even if it is sitting on the same subnet (and in the same rack) as the AR Server. If you add more forms to the pre-fetch list (there are several called from the Incident Management app that you will want to add, like CTM:People Search and HPD:WorkLog), it may take longer due to the network “distance” between your servers. My pre-fetch xml file has 525 lines per user and three levels of user and caches about 175 forms. The difference in performance once it has been cached, as seen by the user, is dramatic.
Christopher Strauss, Ph.D.
Call Tracking Administration Manager
University of North Texas Computing & IT Center
http://itsm.unt.edu/
From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Frank Caruso
Sent: Thursday, January 28, 2010 9:05 AM
To: arslist@ARSLIST.ORG
Subject: Remote MidTier Server
**
Will locating a Remedy MidTier server closer to a group of users help with performance? Some of our remote sites are feeding off of very small pipes back to the ARS host. Users frequently get errors popping up in the MidTier which I can only figure are due to network latencies. Use of the Remedy user tool can also be painfully slow. We have fixed some issues with network routes (5 hops) but looking at ping times of 500 - 600 ms. I have built a new web server at the remote site and am now in the process of caching the forms. So far this process has been very slow - around 30 minutse to cache Home page and Incident console.
Any thoughts on whether users will see an increase in performance? _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: "Where the Answers Are"_ _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: "Where the Answers Are"_
Doug
--
Doug Blair
+1 224-558-5462
200 North Arlington Heights Road
Arlington Heights, Illinois 60004
![]()
Doug
-- Doug Blair +1 224-558-5462
200 North Arlington Heights Road Arlington Heights, Illinois 60004
|
