The users are saying there is a noticeable improvement. It takes almost 1.5 hours to cache the required forms (mostly Incident Management stuff) but once complete the users are able to enter tickets faster than before.
I did tinker with IIS and Tomcat compression but in this configuration (users close to web server) it was not going to make a difference Thankx to all who supplied input. On Fri, Jan 29, 2010 at 5:45 PM, Doug Blair <d...@blairing.com> wrote: > ** > 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: >> arsl...@arslist.org] *On Behalf Of *Frank Caruso >> *Sent:* Thursday, January 28, 2010 9:05 AM >> *To:* arslist@ARSLIST.ORG >> *Subject:* Remote MidTier Server >> >> >> ** >> >> Windows 2003 >> >> SQL Server 2005 >> >> ARS 7.1p6 >> >> MidTier 7.1p5 >> >> ITSM 7.03 >> >> >> 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? >> >> >> Frank Caruso >> >> Iraq >> >> >> >> _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: "Where the Answers >> Are"_ >> _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: "Where the Answers >> Are"_ >> >> >> >> >> Doug >> >> -- >> Doug Blair >> d...@blairing.com >> +1 224-558-5462 >> >> 200 North Arlington Heights Road >> Arlington Heights, Illinois 60004 >> >> >> >> _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: "Where the Answers >> Are"_ >> > > _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: "Where the Answers > Are"_ > > > > > Doug > > -- > Doug Blair > d...@blairing.com > +1 224-558-5462 > > 200 North Arlington Heights Road > Arlington Heights, Illinois 60004 > > > > _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: "Where the Answers > Are"_ > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: "Where the Answers Are"
