**
Davin's suggestion of measuring and limiting round-trip end-to-end network latency, is correct. If the overall objective is improved performance, you have several options. In no particular order, they are:

1. Make extensive use of Remedy MidTier and run as many sessions through a web browser as practical. (This may not be a popular option, as MidTier's performance can be disappointing.)

2. Deploy Citrix MetaFrame to substantially reduce the traffic between remote sites and your Remedy servers. (I believe this also requires installing a small ICA client on each user's machine.)

3. Deploy a traffic control tool, such as Packeteer's PacketShaper, to either reserve specific application bandwidth across the wide area network link, and/or compress the traffic and thus consume less bandwidth (and incur less latency) across the wide area network link. (Contrary to popular opinion, packet shaping is commonly accomplished with an appliance deployed only at the central site -- there is no need to deploy appliances at all remote sites.)

- http://www.packeteer.com/prod-sol/products/packetshaper.cfm (general information)
- http://www.packeteer.com/prod-sol/products/xpress.cfm (general information)
- http://www.packeteer.com/prod-sol/products/packetshaperwanlink.cfm (sample topology for dedicated/leased lines between sites)
- http://www.packeteer.com/prod-sol/products/packetshaperinternetlink.cfm (sample topology for Internet connectivity)

(The good news is, a Citrix solution or a Packeteer solution can be used for more than just your Remedy applications!)

My suggestion is to run several sample "ping" tests between remote Remedy clients and the central Remedy server, over multiple days and during peak load times. If the roundtrip times are over 300ms (milliseconds) you may want to investigate some of the above options.

Please DO contact me directly (off the ARSlist) if there's anything more I may provide.

-- Bing

Bradford Bingel ("Bing")
ITM3 California
bing@itm3.com (email)
925-260-6394 (mobile)

-----Original Message-----
From: Action Request System discussion list(ARSList) [mailto:ARSLIST@ARSLIST.ORG] On Behalf Of Kevin
Sent: Wednesday, December 24, 2003 5:46 AM
To: ARSLIST@ARSLIST.ORG
Subject: Remedy WAN issues


**

I would be interested to hear others experiences with Remedy over a WAN.
We have requirement to investigate the possibility, due to new departmental ownership of Unix and Oracle and our Remedy server hardware, of client access over a WAN. I can think of many objections, the most serious being performance but would prefer to hear it from the horses mouth so to speak. We currently have approx 300 users who would require access over an existing ?MB link (not sure of the capacity at this stage ), so this link would not be dedicated anyway having office network traffic in addition.

You can reply to the list or to me offline

Compliments of the season to all

Regard
K Rutenberg

This posting was submitted via the Web interface
This posting was submitted via the Web interface

All good solutions.

Since our helpdesk moved (but the servers remained) we have been running
across the net (WAN) now for a few months with very few problems.

We use a heavily customized version of ars 5.01 (Win2k, SQL 2000) and with
all the required helpdesk windows open its a bit chaotic on screen,
therefore using midtier was really not an option (as mentioned earlier,
midtier is somewhat slow in performance).

You really only need to consider two things, what is the Link used where
the servers are and what is the link used for the clients?

If both are acceptable, then i don't see any reason why you shouldn't just
run with that.

Citrix was mentioned, but this isn't really needed, you could run with just
MS terminal server, or if you have the cash invest in Citrix for the added
features.

Have fun

Mark

Thanks for all your input folks. Some interesting suggestions i most
certainly will be looking into, as well as sharing your personal experiences
in this area.

Hoping 2004 is a good one for all of you...
.and that the Remedy product moves onwards and upwards for the benefit of us
all!

-----Original Message-----
From: Action Request System discussion list(ARSList)
[mailto:ARSLIST@ARSLIST.ORG]On Behalf Of Davin Lindner-Green
Sent: 29 December 2003 22:02
To: ARSLIST@ARSLIST.ORG
Subject: Re: Remedy WAN issues


Although I am no networking expert, I have found that a more critical
measurement than bandwidth is the latency of the WAN link. Latency is the
time it takes a packet to traverse the link, including any routers or
concentrators along the way. This is roughly the "ping" round trip time,
and is usually measured in milliseconds (ms). I don't suspect that
generally packet sizees are large for Remedy traffic hence little
dependency on bandwidth.

Remedy is an interactive application, in both native client and web client
forms. A return key, menu selection or button click will require an event
be sent back to the server and a response. So, you can add the latency x 2
as a round trip delay between action and response, on top of processing
time on the server/database/client. If you latency is 50ms, you might not
notice the addtional .1 sec delay, but if your latency is at 600ms, the 1.2
sec of addtional delay can add up fast. If I recall a rule of thumb,
between 100-200ms is when you start getting into trouble.

For users with extremely slow links, you may have to go with a non-
interactive interface, such as email, since this does not depend on client
to server communication in real time. Using email engine, you could allow
for query, submit and update for these users. Of course, for such a WAN
link, any interactive product would suffer the same fate as Remedy, so it
would be a problem those users no doubt are dealing with today with your
other applications.

HTH,
Davin



UNSUBSCRIBE or access ARSList Archives at http://www.ARSLIST.org (Support:
mailto:support@arslist.org ) ARSList is hosted by QMX SUPPORT SERVICES at
www.QMXS.com
---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.551 / Virus Database: 343 - Release Date: 11/12/2003

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.557 / Virus Database: 349 - Release Date: 30/12/2003