Re: Remedy - sensitive to network performance?

[Robert Molenda]

I personally utilize the wonderful ulitilty 'iPerf' www.noc.ucf.edu/Tools/*
Iperf*/  for all network connectivity
issues, record baseline timings, setup some periodic testing & recording,
etc.

Setup the daemon on the server - then use the executable to record from all
locations with various packet sizes the timings...
--
There have been excellent responses for hardware issues to check such as the
Gig-E 'Auto' setting (only hard code FULL on the adapter and switch), etc.
--

HTH and good luck
Robert Molenda

On Thu, Jun 26, 2008 at 6:11 AM, Barber, David <[EMAIL PROTECTED]> wrote:

> **
>
> Hi,
>
> Has anyone experienced end-user performance problems with Remedy over
> larger networks?
>
> We're running a suite of bespoke applications, and are finding that some
> tasks such as opening/updating incidents can take orders of magnitude longer
> in some locations.  For example it can take me 8 seconds, but a colleague at
> another location 2 or 3 minutes.
>
> Have been able to do some local benchmarks - typical ping responses are
> circa 10ms, but at points when we find that even our performance is hit, we
> find the network is responding to pings at maybe 60+ms.  Our network guys
> invariably say that the network is running fine ...
>
> So it appears that Remedy, or at least the applications we're running, are
> incredibly sensitive to network performance.  Any suggestions from the list
> as to what we can do to improve performance?
>
> Regards
>
> Dave
>
> This e-mail has been scanned for viruses by the Cable & Wireless e-mail
> security system - powered by MessageLabs. For more information on a
> proactive managed e-mail security service, visit
> http://www.cw.com/uk/emailprotection/
>
> The information contained in this e-mail is confidential and may also be
> subject to legal privilege. It is intended only for the recipient(s) named
> above. If you are not named above as a recipient, you must not read, copy,
> disclose, forward or otherwise use the information contained in this email.
> If you have received this e-mail in error, please notify the sender (whose
> contact details are above) immediately by reply e-mail and delete the
> message and any attachments without retaining any copies.
>
> Cable and Wireless plc
> Registered in England and Wales.Company Number 238525
> Registered office: 3rd Floor, 26 Red Lion Square, London WC1R 4HQ
> __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
> html___




-- 
If it were not for the gutter, my mind would be homeless!

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

Re: Remedy - sensitive to network performance?

[Dave Saville]

On Fri, 27 Jun 2008 10:08:35 -0400, Axton wrote:

>Dave,
>
>Unless you have a network that supports jumbo frames, all the data
>sent over the network gets broken into 1500 or less bytes per packet.
>There is no reason to use packets bigger than 1500 bytes unless you
>want to test fragmentation/defragmentation at each of the end points.
>For measuring throughput: firewalls are typically limited by packets
>per second, not bytes per second, up to the bandwidth the links
>support; switches typically have a fiber capacity measured in
>throughput (bits).

Fair point - But at at *least* use 1500 rather than the default 56 - I
have seen what I said happen many times.

--
Regards

Dave Saville

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

Re: Remedy - sensitive to network performance?

[Axton]

Dave,

Unless you have a network that supports jumbo frames, all the data
sent over the network gets broken into 1500 or less bytes per packet.
There is no reason to use packets bigger than 1500 bytes unless you
want to test fragmentation/defragmentation at each of the end points.
For measuring throughput: firewalls are typically limited by packets
per second, not bytes per second, up to the bandwidth the links
support; switches typically have a fiber capacity measured in
throughput (bits).

QoS is only going to have an impact when a switch or router becomes
congested, if there is no congestion, then prioritization based on the
quality of service bits has no impact.  The one exception would be if
there are separate routes between two points where the qos bits are
used to give alternate routes.  This is unlikely though if these are
two remote sites connected by a tunnel over the open internet.

Axton Grams

On Fri, Jun 27, 2008 at 7:23 AM, Dave Saville <[EMAIL PROTECTED]> wrote:
> On Thu, 26 Jun 2008 12:06:25 -0600, Dave Wilmot wrote:
>
>>Dave,
>>
>>Your systems administrator(s) should easily be able to isolate the network
>>as the problem (or not) by running one or more utilities which will check
>>network "round-trip" times.  One such tool might be the Solaris (Sun Unix)
>>"ping -sRv" command, which shows trip times to each "hop" or "router" on
>>the way to the remote location/server.
>
> Bear in mind that your average sysadmin will execute "ping
> server_appearing_slow_to_ars_client" and pronounce that there is
> nothing wrong with the network. This is because ping by default only
> generates a tiny packet, like 56 bytes or similar. You need to specify
> a *big* packet size ( integer number after host - ping host 8192 for
> example for an 8K packet.) Yes Remedy is very chatty over the network,
> but they are also often big packets
>
> --
> Regards
>
> Dave Saville
>
> ___
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
>

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

Re: Remedy - sensitive to network performance?

[Dave Saville]

On Thu, 26 Jun 2008 12:06:25 -0600, Dave Wilmot wrote:

>Dave,
>
>Your systems administrator(s) should easily be able to isolate the network
>as the problem (or not) by running one or more utilities which will check
>network "round-trip" times.  One such tool might be the Solaris (Sun Unix)
>"ping -sRv" command, which shows trip times to each "hop" or "router" on
>the way to the remote location/server.

Bear in mind that your average sysadmin will execute "ping
server_appearing_slow_to_ars_client" and pronounce that there is
nothing wrong with the network. This is because ping by default only
generates a tiny packet, like 56 bytes or similar. You need to specify
a *big* packet size ( integer number after host - ping host 8192 for
example for an 8K packet.) Yes Remedy is very chatty over the network,
but they are also often big packets

--
Regards

Dave Saville

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

Re: Remedy - sensitive to network performance?

[Barber, David]

We have a mix - some running reports on Remedy itself, but (hopefully) the 
majority are working off a data warehouse running on Business Objects.  The 
latter is of concern, as it is semi-live.  It looks for deltas on the SQL 
Server/Remedy database.  Every 5 minutes.

Regards

Dave

-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] Behalf Of T. Dee
Sent: 26 June 2008 19:14
To: arslist@ARSLIST.ORG
Subject: Re: Remedy - sensitive to network performance?


Do you have your users running reports during business hours?  This
can slow down Remedy quite a bit - unless you have a dedicated
reporting server.  Or perhaps you have users running unqualified
searches - that will also impact performance.



On 6/26/08, Dave Wilmot <[EMAIL PROTECTED]> wrote:
> **
> Dave,
>
> Your systems administrator(s) should easily be able to isolate the network
> as the problem (or not) by running one or more utilities which will check
> network "round-trip" times.  One such tool might be the Solaris (Sun Unix)
> "ping -sRv" command, which shows trip times to each "hop" or "router" on the
> way to the remote location/server.
>
> I've been out of the systems-admin world for many years now so my command
> options above may not be perfect.  Talk to your system administrator(s) and
> as them to check the round-trip times for you.  If there is an obvious
> problem with the network performance, it should show up in the output
> generated by the "ping" test, or an equivalent command/utility.  They
> probably have a network monitoring application as well which would could be
> used to perform the same or similar test.
>
> Finally, the question still exists as to what is an acceptable transaction
> time for a network packet to travel about on the network.  That is really
> something each company must decide for themselves.  Your S/A should be able
> to give you a good general understanding of what to expect on a well-tuned
> WAN (all depends on your infrastructure).
>
> Don't forget to check the load on the various servers.  You could have a WEB
> server, database server, application server, etc which may be bogged down.
>
> Best of luck,
>
> Dave Wilmot
>
>
>
> Dave Wilmot
> President
> Rapid Technologies
> 303.948.1014 ext 101
> 303.948.1614 (fax)
> [EMAIL PROTECTED]
> www.raptek.com
> 
> From: Action Request System discussion list(ARSList)
> [mailto:[EMAIL PROTECTED] On Behalf Of Barber, David
> Sent: Thursday, June 26, 2008 7:12 AM
> To: arslist@ARSLIST.ORG
> Subject: Remedy - sensitive to network performance?
>
> **
>
> Hi,
>
> Has anyone experienced end-user performance problems with Remedy over larger
> networks?
>
> We're running a suite of bespoke applications, and are finding that some
> tasks such as opening/updating incidents can take orders of magnitude longer
> in some locations.  For example it can take me 8 seconds, but a colleague at
> another location 2 or 3 minutes.
>
> Have been able to do some local benchmarks - typical ping responses are
> circa 10ms, but at points when we find that even our performance is hit, we
> find the network is responding to pings at maybe 60+ms.  Our network guys
> invariably say that the network is running fine ...
>
> So it appears that Remedy, or at least the applications we're running, are
> incredibly sensitive to network performance.  Any suggestions from the list
> as to what we can do to improve performance?
>
> Regards
>
> Dave
> This e-mail has been scanned for viruses by the Cable & Wireless e-mail
> security system - powered by MessageLabs. For more information on a
> proactive managed e-mail security service, visit
> http://www.cw.com/uk/emailprotection/
>
> The information contained in this e-mail is confidential and may also be
> subject to legal privilege. It is intended only for the recipient(s) named
> above. If you are not named above as a recipient, you must not read, copy,
> disclose, forward or otherwise use the information contained in this email.
> If you have received this e-mail in error, please notify the sender (whose
> contact details are above) immediately by reply e-mail and delete the
> message and any attachments without retaining any copies.
>
> Cable and Wireless plc
> Registered in England and Wales.Company Number 238525
> Registered office: 3rd Floor, 26 Red Lion Square, London WC1R 4HQ
> __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
> html___
> __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
> html___

_

Re: Remedy - sensitive to network performance?

[Barber, David]

Susan,
 
I think thats a QoS setup - certain packet types/data types can be allocated 
more network time?  I'm not really that knowledgeable on networks, but my last 
placement was working with a few network engineers who were working on such 
setups.
 
Regards

Dave

-Original Message-
From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] 
Behalf Of Susan Palmer
Sent: 26 June 2008 17:44
To: arslist@ARSLIST.ORG
Subject: Re: Remedy - sensitive to network performance?


** 
Dave,
 
All of these are very good 'Remedy' answers.  But it is likely your gut 
instinct of network is correct.  Went through this a few years back.  Of course 
the network is never to blame.  One location 5 mi from the server was much 
slower than a location 200 mi from the server.  We used coordinated stop-watch 
timings initially to document the issue.  Then we moved to sniffer stuff.  It 
was finally acknowledged that the building only 5 mi away had a very poorly 
designed network (old) and it showed many hops within the building.  Probably 
went further than the 200 mi building.  
 
Another factor that always played in a bit was how much video was being played 
at PC's.  Remedy is chatty and all those little packets get stuck behind those 
big blobs of video.  I don't remember the network terms, but had something to 
do with setting the priority of the applications on  the network so our packets 
would go first before those other things.  I think there was network  load 
balancing in play too for that.  Forgive me my poor network language.
 
Good luck ... uphill battle against the network team !
 
Susan


On Thu, Jun 26, 2008 at 11:13 AM, Ciplak, Can < [EMAIL PROTECTED]> wrote:


Dave,

When did you notice this issue? Have you introduced any change to the
applications recently?

If that is the case, try deleting .arv and .arf files at the client side
and see if deleting the files helps with the issue.

Can Ciplak
NAV CANADA

613) 563-3512




-Original Message-
From: Action Request System discussion list(ARSList)

[mailto: [EMAIL PROTECTED] On Behalf Of Barber, David
Sent: June 26, 2008 10:18 AM
To: arslist@ARSLIST.ORG

Subject: Re: Remedy - sensitive to network performance?


Sorry ...

Clients are all running on v7.0.01 user tool.  No mid tier in use.
AR Server is running on Win2k3, 8 procssors
Database is running sql server on similar hardware/OS to the AR Server

The server/database are very close to each other.  Based in a data
center somewhere very remote from us in head office.  Invariably here at
head office performance is fine, its other users who generally have
problems.

From the experience and tests we've done it does appear to be sensitive
to network performance.  Although having said that AR Server load is
around 20-25%, SQL Server normally 90+% load.

Regards

Dave

-Original Message-
From: Action Request System discussion list(ARSList)
[mailto: [EMAIL PROTECTED] Behalf Of William Rentfrow
Sent: 26 June 2008 15:06
To: arslist@ARSLIST.ORG
Subject: Re: Remedy - sensitive to network performance?


Can you give us more information about your setup?  Database type,
server OS, web server type, etc?

I assume you are using 1 AR Server connected to a local (relative to the
server) database.

You did not mention whether or not you are using the Web or Windows
clients either.

William Rentfrow
Principal Consultant, StrataCom
[EMAIL PROTECTED]
O 952-432-0227
C 701-306-6157



From: Action Request System discussion list(ARSList) on behalf of
Barber, David
Sent: Thu 6/26/2008 8:11 AM
To: arslist@ARSLIST.ORG
Subject: Remedy - sensitive to network performance?


**

Hi,

Has anyone experienced end-user performance problems with Remedy over
larger networks?

We're running a suite of bespoke applications, and are finding that some
tasks such as opening/updating incidents can take orders of magnitude
longer in some locations.  For example it can take me 8 seconds, but a
colleague at another location 2 or 3 minutes.

Have been able to do some local benchmarks - typical ping responses are
circa 10ms, but at points when we find that even our performance is hit,
we find the network is responding to pings at maybe 60+ms.  Our network
guys invariably say that the network is running fine ...

So it appears that Remedy, or at least the applications we're running,
are incredibly sensitive to network performance.  Any suggestions from
the list as to what we can do to improve performance?

Regards

Dave


This e-mail has been scanned for viruses by the Cable & Wireless e-mail
security system - powered by MessageLabs. For more information on a
proactive managed e-mail security service, visit
http://www.cw.com/uk/emailprotection/

The information contained in this e-mail is confidential and may also be
subject to legal privilege. It is intended only for the recipient(s)
named above. If you are not named above as a rec

Re: Remedy - sensitive to network performance?

[Gary Opela (Corporate)]

Look through the logs to identify if the slowness is on the client side, or the 
server side. If you see a very long time between the time a query is sent to 
the server, and the time it is received, then you will know it is either server 
side, or an issue with the network.

Next, you can go to the server side, and monitor the duration it takes for the 
query. If the duration on the server is short, then this should narrow it down 
to something on the network.

Thanks,



Gary Opela, Jr., RSP

Remedy Engineer

Leader Communications, Inc.

http://www.5pointleader.com

http://www.lcibest.com

Best Product, Best People, Best PriceTM

An ISO 9001:2000 Certified, CMMI(r) Level 3 Rated Company

-Original Message-
From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] 
On Behalf Of T. Dee
Sent: Thursday, June 26, 2008 1:14 PM
To: arslist@ARSLIST.ORG
Subject: Re: Remedy - sensitive to network performance?

Do you have your users running reports during business hours?  This
can slow down Remedy quite a bit - unless you have a dedicated
reporting server.  Or perhaps you have users running unqualified
searches - that will also impact performance.



On 6/26/08, Dave Wilmot <[EMAIL PROTECTED]> wrote:
> **
> Dave,
>
> Your systems administrator(s) should easily be able to isolate the network
> as the problem (or not) by running one or more utilities which will check
> network "round-trip" times.  One such tool might be the Solaris (Sun Unix)
> "ping -sRv" command, which shows trip times to each "hop" or "router" on the
> way to the remote location/server.
>
> I've been out of the systems-admin world for many years now so my command
> options above may not be perfect.  Talk to your system administrator(s) and
> as them to check the round-trip times for you.  If there is an obvious
> problem with the network performance, it should show up in the output
> generated by the "ping" test, or an equivalent command/utility.  They
> probably have a network monitoring application as well which would could be
> used to perform the same or similar test.
>
> Finally, the question still exists as to what is an acceptable transaction
> time for a network packet to travel about on the network.  That is really
> something each company must decide for themselves.  Your S/A should be able
> to give you a good general understanding of what to expect on a well-tuned
> WAN (all depends on your infrastructure).
>
> Don't forget to check the load on the various servers.  You could have a WEB
> server, database server, application server, etc which may be bogged down.
>
> Best of luck,
>
> Dave Wilmot
>
>
>
> Dave Wilmot
> President
> Rapid Technologies
> 303.948.1014 ext 101
> 303.948.1614 (fax)
> [EMAIL PROTECTED]
> www.raptek.com
> 
> From: Action Request System discussion list(ARSList)
> [mailto:[EMAIL PROTECTED] On Behalf Of Barber, David
> Sent: Thursday, June 26, 2008 7:12 AM
> To: arslist@ARSLIST.ORG
> Subject: Remedy - sensitive to network performance?
>
> **
>
> Hi,
>
> Has anyone experienced end-user performance problems with Remedy over larger
> networks?
>
> We're running a suite of bespoke applications, and are finding that some
> tasks such as opening/updating incidents can take orders of magnitude longer
> in some locations.  For example it can take me 8 seconds, but a colleague at
> another location 2 or 3 minutes.
>
> Have been able to do some local benchmarks - typical ping responses are
> circa 10ms, but at points when we find that even our performance is hit, we
> find the network is responding to pings at maybe 60+ms.  Our network guys
> invariably say that the network is running fine ...
>
> So it appears that Remedy, or at least the applications we're running, are
> incredibly sensitive to network performance.  Any suggestions from the list
> as to what we can do to improve performance?
>
> Regards
>
> Dave
> This e-mail has been scanned for viruses by the Cable & Wireless e-mail
> security system - powered by MessageLabs. For more information on a
> proactive managed e-mail security service, visit
> http://www.cw.com/uk/emailprotection/
>
> The information contained in this e-mail is confidential and may also be
> subject to legal privilege. It is intended only for the recipient(s) named
> above. If you are not named above as a recipient, you must not read, copy,
> disclose, forward or otherwise use the information contained in this email.
> If you have received this e-mail in error, please notify the sender (whose
> contact details are above) immediately by reply e-mail and delete the
> message and any attachments without retaining an

Re: Remedy - sensitive to network performance?

[T. Dee]

Do you have your users running reports during business hours?  This
can slow down Remedy quite a bit - unless you have a dedicated
reporting server.  Or perhaps you have users running unqualified
searches - that will also impact performance.



On 6/26/08, Dave Wilmot <[EMAIL PROTECTED]> wrote:
> **
> Dave,
>
> Your systems administrator(s) should easily be able to isolate the network
> as the problem (or not) by running one or more utilities which will check
> network "round-trip" times.  One such tool might be the Solaris (Sun Unix)
> "ping -sRv" command, which shows trip times to each "hop" or "router" on the
> way to the remote location/server.
>
> I've been out of the systems-admin world for many years now so my command
> options above may not be perfect.  Talk to your system administrator(s) and
> as them to check the round-trip times for you.  If there is an obvious
> problem with the network performance, it should show up in the output
> generated by the "ping" test, or an equivalent command/utility.  They
> probably have a network monitoring application as well which would could be
> used to perform the same or similar test.
>
> Finally, the question still exists as to what is an acceptable transaction
> time for a network packet to travel about on the network.  That is really
> something each company must decide for themselves.  Your S/A should be able
> to give you a good general understanding of what to expect on a well-tuned
> WAN (all depends on your infrastructure).
>
> Don't forget to check the load on the various servers.  You could have a WEB
> server, database server, application server, etc which may be bogged down.
>
> Best of luck,
>
> Dave Wilmot
>
>
>
> Dave Wilmot
> President
> Rapid Technologies
> 303.948.1014 ext 101
> 303.948.1614 (fax)
> [EMAIL PROTECTED]
> www.raptek.com
> 
> From: Action Request System discussion list(ARSList)
> [mailto:[EMAIL PROTECTED] On Behalf Of Barber, David
> Sent: Thursday, June 26, 2008 7:12 AM
> To: arslist@ARSLIST.ORG
> Subject: Remedy - sensitive to network performance?
>
> **
>
> Hi,
>
> Has anyone experienced end-user performance problems with Remedy over larger
> networks?
>
> We're running a suite of bespoke applications, and are finding that some
> tasks such as opening/updating incidents can take orders of magnitude longer
> in some locations.  For example it can take me 8 seconds, but a colleague at
> another location 2 or 3 minutes.
>
> Have been able to do some local benchmarks - typical ping responses are
> circa 10ms, but at points when we find that even our performance is hit, we
> find the network is responding to pings at maybe 60+ms.  Our network guys
> invariably say that the network is running fine ...
>
> So it appears that Remedy, or at least the applications we're running, are
> incredibly sensitive to network performance.  Any suggestions from the list
> as to what we can do to improve performance?
>
> Regards
>
> Dave
> This e-mail has been scanned for viruses by the Cable & Wireless e-mail
> security system - powered by MessageLabs. For more information on a
> proactive managed e-mail security service, visit
> http://www.cw.com/uk/emailprotection/
>
> The information contained in this e-mail is confidential and may also be
> subject to legal privilege. It is intended only for the recipient(s) named
> above. If you are not named above as a recipient, you must not read, copy,
> disclose, forward or otherwise use the information contained in this email.
> If you have received this e-mail in error, please notify the sender (whose
> contact details are above) immediately by reply e-mail and delete the
> message and any attachments without retaining any copies.
>
> Cable and Wireless plc
> Registered in England and Wales.Company Number 238525
> Registered office: 3rd Floor, 26 Red Lion Square, London WC1R 4HQ
> __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
> html___
> __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
> html___

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

Re: Remedy - sensitive to network performance?

[T. Dee]

Good point - as well sometimes I have seen cards set to "auto detect"
and you would get funky things happening as well.


On 6/26/08, Chowdhury, Tauf <[EMAIL PROTECTED]> wrote:
> As far as the network goes, you may also want to check the link speed on
> the network cards on the servers in question and compare them to the
> switch port configuration. Often times, if the link speeds don't match,
> you will get a lot of funky things happening.
>
> Tauf Chowdhury | Forest Laboratories, Inc.
> Sr. Analyst
> Informatics Service Desk
> 631.858.
>
>
> -Original Message-
> From: Action Request System discussion list(ARSList)
> [mailto:[EMAIL PROTECTED] On Behalf Of Axton
> Sent: Thursday, June 26, 2008 1:44 PM
> To: arslist@ARSLIST.ORG
> Subject: Re: Remedy - sensitive to network performance?
>
> You are probably referring to the QoS and ToS, but that really
> shouldn't be necessary unless the issue is caused by network
> saturation.  Chances are, latency is the core issue.  The only things
> I know of to address the apparent performance issue, assuming latency
> is the issue, include:
>
> - reduce the number of round trips between the client and server
> - alter the network topology so that the latency is reduced
> - identify devices that are overloaded causing increases in the
> latency and address them
>
> Axton Grams
>
> On Thu, Jun 26, 2008 at 12:43 PM, Susan Palmer <[EMAIL PROTECTED]>
> wrote:
> > **
> > Dave,
> >
> > All of these are very good 'Remedy' answers.  But it is likely your
> gut
> > instinct of network is correct.  Went through this a few years back.
> Of
> > course the network is never to blame.  One location 5 mi from the
> server was
> > much slower than a location 200 mi from the server.  We used
> coordinated
> > stop-watch timings initially to document the issue.  Then we moved to
> > sniffer stuff.  It was finally acknowledged that the building only 5
> mi away
> > had a very poorly designed network (old) and it showed many hops
> within the
> > building.  Probably went further than the 200 mi building.
> >
> > Another factor that always played in a bit was how much video was
> being
> > played at PC's.  Remedy is chatty and all those little packets get
> stuck
> > behind those big blobs of video.  I don't remember the network terms,
> but
> > had something to do with setting the priority of the applications on
> the
> > network so our packets would go first before those other things.  I
> think
> > there was network  load balancing in play too for that.  Forgive me my
> poor
> > network language.
> >
> > Good luck ... uphill battle against the network team !
> >
> > Susan
> >
> > On Thu, Jun 26, 2008 at 11:13 AM, Ciplak, Can <[EMAIL PROTECTED]>
> wrote:
> >>
> >> Dave,
> >>
> >> When did you notice this issue? Have you introduced any change to the
> >> applications recently?
> >>
> >> If that is the case, try deleting .arv and .arf files at the client
> side
> >> and see if deleting the files helps with the issue.
> >>
> >> Can Ciplak
> >> NAV CANADA
> >>
> >> 613) 563-3512
> >>
> >>
> >>
> >> -Original Message-
> >> From: Action Request System discussion list(ARSList)
> >> [mailto:[EMAIL PROTECTED] On Behalf Of Barber, David
> >> Sent: June 26, 2008 10:18 AM
> >> To: arslist@ARSLIST.ORG
> >> Subject: Re: Remedy - sensitive to network performance?
> >>
> >> Sorry ...
> >>
> >> Clients are all running on v7.0.01 user tool.  No mid tier in use.
> >> AR Server is running on Win2k3, 8 procssors
> >> Database is running sql server on similar hardware/OS to the AR
> Server
> >>
> >> The server/database are very close to each other.  Based in a data
> >> center somewhere very remote from us in head office.  Invariably here
> at
> >> head office performance is fine, its other users who generally have
> >> problems.
> >>
> >> From the experience and tests we've done it does appear to be
> sensitive
> >> to network performance.  Although having said that AR Server load is
> >> around 20-25%, SQL Server normally 90+% load.
> >>
> >> Regards
> >>
> >> Dave
> >>
> >> -Original Message-
> >> From: Action Request System discussion list(ARSList)
> >> [mailto:[EMAIL PROTECTED] Behalf Of William Rentfrow
> >> Sent

Re: Remedy - sensitive to network performance?

[Dave Wilmot]

Dave,
 
Your systems administrator(s) should easily be able to isolate the network
as the problem (or not) by running one or more utilities which will check
network "round-trip" times.  One such tool might be the Solaris (Sun Unix)
"ping -sRv" command, which shows trip times to each "hop" or "router" on
the way to the remote location/server.
 
I've been out of the systems-admin world for many years now so my command
options above may not be perfect.  Talk to your system administrator(s)
and as them to check the round-trip times for you.  If there is an obvious
problem with the network performance, it should show up in the output
generated by the "ping" test, or an equivalent command/utility.  They
probably have a network monitoring application as well which would could
be used to perform the same or similar test.
 
Finally, the question still exists as to what is an acceptable transaction
time for a network packet to travel about on the network.  That is really
something each company must decide for themselves.  Your S/A should be
able to give you a good general understanding of what to expect on a
well-tuned WAN (all depends on your infrastructure).
 
Don't forget to check the load on the various servers.  You could have a
WEB server, database server, application server, etc which may be bogged
down.
 
Best of luck,
 
Dave Wilmot
 
Dave Wilmot
President
Rapid Technologies
303.948.1014 ext 101
303.948.1614 (fax)
[EMAIL PROTECTED]
www.raptek.com 


  _  

From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Barber, David
Sent: Thursday, June 26, 2008 7:12 AM
To: arslist@ARSLIST.ORG
Subject: Remedy - sensitive to network performance?


** 

Hi, 

Has anyone experienced end-user performance problems with Remedy over
larger networks? 

We're running a suite of bespoke applications, and are finding that some
tasks such as opening/updating incidents can take orders of magnitude
longer in some locations.  For example it can take me 8 seconds, but a
colleague at another location 2 or 3 minutes.

Have been able to do some local benchmarks - typical ping responses are
circa 10ms, but at points when we find that even our performance is hit,
we find the network is responding to pings at maybe 60+ms.  Our network
guys invariably say that the network is running fine ...

So it appears that Remedy, or at least the applications we're running, are
incredibly sensitive to network performance.  Any suggestions from the
list as to what we can do to improve performance?

Regards 

Dave 


This e-mail has been scanned for viruses by the Cable & Wireless e-mail
security system - powered by MessageLabs. For more information on a
proactive managed e-mail security service, visit
http://www.cw.com/uk/emailprotection/ 

The information contained in this e-mail is confidential and may also be
subject to legal privilege. It is intended only for the recipient(s) named
above. If you are not named above as a recipient, you must not read, copy,
disclose, forward or otherwise use the information contained in this
email. If you have received this e-mail in error, please notify the sender
(whose contact details are above) immediately by reply e-mail and delete
the message and any attachments without retaining any copies.

Cable and Wireless plc 
Registered in England and Wales.Company Number 238525 
Registered office: 3rd Floor, 26 Red Lion Square, London WC1R 4HQ
__Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
html___

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

Re: Remedy - sensitive to network performance?

[Chowdhury, Tauf]

As far as the network goes, you may also want to check the link speed on
the network cards on the servers in question and compare them to the
switch port configuration. Often times, if the link speeds don't match,
you will get a lot of funky things happening.

Tauf Chowdhury | Forest Laboratories, Inc.
Sr. Analyst
Informatics Service Desk
631.858.
 

-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Axton
Sent: Thursday, June 26, 2008 1:44 PM
To: arslist@ARSLIST.ORG
Subject: Re: Remedy - sensitive to network performance?

You are probably referring to the QoS and ToS, but that really
shouldn't be necessary unless the issue is caused by network
saturation.  Chances are, latency is the core issue.  The only things
I know of to address the apparent performance issue, assuming latency
is the issue, include:

- reduce the number of round trips between the client and server
- alter the network topology so that the latency is reduced
- identify devices that are overloaded causing increases in the
latency and address them

Axton Grams

On Thu, Jun 26, 2008 at 12:43 PM, Susan Palmer <[EMAIL PROTECTED]>
wrote:
> **
> Dave,
>
> All of these are very good 'Remedy' answers.  But it is likely your
gut
> instinct of network is correct.  Went through this a few years back.
Of
> course the network is never to blame.  One location 5 mi from the
server was
> much slower than a location 200 mi from the server.  We used
coordinated
> stop-watch timings initially to document the issue.  Then we moved to
> sniffer stuff.  It was finally acknowledged that the building only 5
mi away
> had a very poorly designed network (old) and it showed many hops
within the
> building.  Probably went further than the 200 mi building.
>
> Another factor that always played in a bit was how much video was
being
> played at PC's.  Remedy is chatty and all those little packets get
stuck
> behind those big blobs of video.  I don't remember the network terms,
but
> had something to do with setting the priority of the applications on
the
> network so our packets would go first before those other things.  I
think
> there was network  load balancing in play too for that.  Forgive me my
poor
> network language.
>
> Good luck ... uphill battle against the network team !
>
> Susan
>
> On Thu, Jun 26, 2008 at 11:13 AM, Ciplak, Can <[EMAIL PROTECTED]>
wrote:
>>
>> Dave,
>>
>> When did you notice this issue? Have you introduced any change to the
>> applications recently?
>>
>> If that is the case, try deleting .arv and .arf files at the client
side
>> and see if deleting the files helps with the issue.
>>
>> Can Ciplak
>> NAV CANADA
>>
>> 613) 563-3512
>>
>>
>>
>> -----Original Message-----
>> From: Action Request System discussion list(ARSList)
>> [mailto:[EMAIL PROTECTED] On Behalf Of Barber, David
>> Sent: June 26, 2008 10:18 AM
>> To: arslist@ARSLIST.ORG
>> Subject: Re: Remedy - sensitive to network performance?
>>
>> Sorry ...
>>
>> Clients are all running on v7.0.01 user tool.  No mid tier in use.
>> AR Server is running on Win2k3, 8 procssors
>> Database is running sql server on similar hardware/OS to the AR
Server
>>
>> The server/database are very close to each other.  Based in a data
>> center somewhere very remote from us in head office.  Invariably here
at
>> head office performance is fine, its other users who generally have
>> problems.
>>
>> From the experience and tests we've done it does appear to be
sensitive
>> to network performance.  Although having said that AR Server load is
>> around 20-25%, SQL Server normally 90+% load.
>>
>> Regards
>>
>> Dave
>>
>> -Original Message-
>> From: Action Request System discussion list(ARSList)
>> [mailto:[EMAIL PROTECTED] Behalf Of William Rentfrow
>> Sent: 26 June 2008 15:06
>> To: arslist@ARSLIST.ORG
>> Subject: Re: Remedy - sensitive to network performance?
>>
>>
>> Can you give us more information about your setup?  Database type,
>> server OS, web server type, etc?
>>
>> I assume you are using 1 AR Server connected to a local (relative to
the
>> server) database.
>>
>> You did not mention whether or not you are using the Web or Windows
>> clients either.
>>
>> William Rentfrow
>> Principal Consultant, StrataCom
>> [EMAIL PROTECTED]
>> O 952-432-0227
>> C 701-306-6157
>>
>> 
>>
>> From: Action Request System discussion list(ARSList) on behalf of
>> Barber, Da

Re: Remedy - sensitive to network performance?

[Axton]

You are probably referring to the QoS and ToS, but that really
shouldn't be necessary unless the issue is caused by network
saturation.  Chances are, latency is the core issue.  The only things
I know of to address the apparent performance issue, assuming latency
is the issue, include:

- reduce the number of round trips between the client and server
- alter the network topology so that the latency is reduced
- identify devices that are overloaded causing increases in the
latency and address them

Axton Grams

On Thu, Jun 26, 2008 at 12:43 PM, Susan Palmer <[EMAIL PROTECTED]> wrote:
> **
> Dave,
>
> All of these are very good 'Remedy' answers.  But it is likely your gut
> instinct of network is correct.  Went through this a few years back.  Of
> course the network is never to blame.  One location 5 mi from the server was
> much slower than a location 200 mi from the server.  We used coordinated
> stop-watch timings initially to document the issue.  Then we moved to
> sniffer stuff.  It was finally acknowledged that the building only 5 mi away
> had a very poorly designed network (old) and it showed many hops within the
> building.  Probably went further than the 200 mi building.
>
> Another factor that always played in a bit was how much video was being
> played at PC's.  Remedy is chatty and all those little packets get stuck
> behind those big blobs of video.  I don't remember the network terms, but
> had something to do with setting the priority of the applications on  the
> network so our packets would go first before those other things.  I think
> there was network  load balancing in play too for that.  Forgive me my poor
> network language.
>
> Good luck ... uphill battle against the network team !
>
> Susan
>
> On Thu, Jun 26, 2008 at 11:13 AM, Ciplak, Can <[EMAIL PROTECTED]> wrote:
>>
>> Dave,
>>
>> When did you notice this issue? Have you introduced any change to the
>> applications recently?
>>
>> If that is the case, try deleting .arv and .arf files at the client side
>> and see if deleting the files helps with the issue.
>>
>> Can Ciplak
>> NAV CANADA
>>
>> 613) 563-3512
>>
>>
>>
>> -Original Message-
>> From: Action Request System discussion list(ARSList)
>> [mailto:[EMAIL PROTECTED] On Behalf Of Barber, David
>> Sent: June 26, 2008 10:18 AM
>> To: arslist@ARSLIST.ORG
>> Subject: Re: Remedy - sensitive to network performance?
>>
>> Sorry ...
>>
>> Clients are all running on v7.0.01 user tool.  No mid tier in use.
>> AR Server is running on Win2k3, 8 procssors
>> Database is running sql server on similar hardware/OS to the AR Server
>>
>> The server/database are very close to each other.  Based in a data
>> center somewhere very remote from us in head office.  Invariably here at
>> head office performance is fine, its other users who generally have
>> problems.
>>
>> From the experience and tests we've done it does appear to be sensitive
>> to network performance.  Although having said that AR Server load is
>> around 20-25%, SQL Server normally 90+% load.
>>
>> Regards
>>
>> Dave
>>
>> -Original Message-
>> From: Action Request System discussion list(ARSList)
>> [mailto:[EMAIL PROTECTED] Behalf Of William Rentfrow
>> Sent: 26 June 2008 15:06
>> To: arslist@ARSLIST.ORG
>> Subject: Re: Remedy - sensitive to network performance?
>>
>>
>> Can you give us more information about your setup?  Database type,
>> server OS, web server type, etc?
>>
>> I assume you are using 1 AR Server connected to a local (relative to the
>> server) database.
>>
>> You did not mention whether or not you are using the Web or Windows
>> clients either.
>>
>> William Rentfrow
>> Principal Consultant, StrataCom
>> [EMAIL PROTECTED]
>> O 952-432-0227
>> C 701-306-6157
>>
>> 
>>
>> From: Action Request System discussion list(ARSList) on behalf of
>> Barber, David
>> Sent: Thu 6/26/2008 8:11 AM
>> To: arslist@ARSLIST.ORG
>> Subject: Remedy - sensitive to network performance?
>>
>>
>> **
>>
>> Hi,
>>
>> Has anyone experienced end-user performance problems with Remedy over
>> larger networks?
>>
>> We're running a suite of bespoke applications, and are finding that some
>> tasks such as opening/updating incidents can take orders of magnitude
>> longer in some locations.  For example it can take me 8 seconds, but a
>> colleague at another location 2 or 

Re: Remedy - sensitive to network performance?

[Susan Palmer]

Dave,

All of these are very good 'Remedy' answers.  But it is likely your gut
instinct of network is correct.  Went through this a few years back.  Of
course the network is never to blame.  One location 5 mi from the server was
much slower than a location 200 mi from the server.  We used coordinated
stop-watch timings initially to document the issue.  Then we moved to
sniffer stuff.  It was finally acknowledged that the building only 5 mi away
had a very poorly designed network (old) and it showed many hops within the
building.  Probably went further than the 200 mi building.

Another factor that always played in a bit was how much video was being
played at PC's.  Remedy is chatty and all those little packets get stuck
behind those big blobs of video.  I don't remember the network terms, but
had something to do with setting the priority of the applications on  the
network so our packets would go first before those other things.  I think
there was network  load balancing in play too for that.  Forgive me my poor
network language.

Good luck ... uphill battle against the network team !

Susan

On Thu, Jun 26, 2008 at 11:13 AM, Ciplak, Can <[EMAIL PROTECTED]> wrote:

> Dave,
>
> When did you notice this issue? Have you introduced any change to the
> applications recently?
>
> If that is the case, try deleting .arv and .arf files at the client side
> and see if deleting the files helps with the issue.
>
> Can Ciplak
> NAV CANADA
>
> 613) 563-3512
>
>
>
> -Original Message-
> From: Action Request System discussion list(ARSList)
> [mailto:[EMAIL PROTECTED] On Behalf Of Barber, David
> Sent: June 26, 2008 10:18 AM
> To: arslist@ARSLIST.ORG
> Subject: Re: Remedy - sensitive to network performance?
>
>  Sorry ...
>
> Clients are all running on v7.0.01 user tool.  No mid tier in use.
> AR Server is running on Win2k3, 8 procssors
> Database is running sql server on similar hardware/OS to the AR Server
>
> The server/database are very close to each other.  Based in a data
> center somewhere very remote from us in head office.  Invariably here at
> head office performance is fine, its other users who generally have
> problems.
>
> From the experience and tests we've done it does appear to be sensitive
> to network performance.  Although having said that AR Server load is
> around 20-25%, SQL Server normally 90+% load.
>
> Regards
>
> Dave
>
> -Original Message-
> From: Action Request System discussion list(ARSList)
> [mailto:[EMAIL PROTECTED] Behalf Of William Rentfrow
> Sent: 26 June 2008 15:06
> To: arslist@ARSLIST.ORG
> Subject: Re: Remedy - sensitive to network performance?
>
>
> Can you give us more information about your setup?  Database type,
> server OS, web server type, etc?
>
> I assume you are using 1 AR Server connected to a local (relative to the
> server) database.
>
> You did not mention whether or not you are using the Web or Windows
> clients either.
>
> William Rentfrow
> Principal Consultant, StrataCom
> [EMAIL PROTECTED]
> O 952-432-0227
> C 701-306-6157
>
> ____
>
> From: Action Request System discussion list(ARSList) on behalf of
> Barber, David
> Sent: Thu 6/26/2008 8:11 AM
> To: arslist@ARSLIST.ORG
> Subject: Remedy - sensitive to network performance?
>
>
> **
>
> Hi,
>
> Has anyone experienced end-user performance problems with Remedy over
> larger networks?
>
> We're running a suite of bespoke applications, and are finding that some
> tasks such as opening/updating incidents can take orders of magnitude
> longer in some locations.  For example it can take me 8 seconds, but a
> colleague at another location 2 or 3 minutes.
>
> Have been able to do some local benchmarks - typical ping responses are
> circa 10ms, but at points when we find that even our performance is hit,
> we find the network is responding to pings at maybe 60+ms.  Our network
> guys invariably say that the network is running fine ...
>
> So it appears that Remedy, or at least the applications we're running,
> are incredibly sensitive to network performance.  Any suggestions from
> the list as to what we can do to improve performance?
>
> Regards
>
> Dave
>
>
> This e-mail has been scanned for viruses by the Cable & Wireless e-mail
> security system - powered by MessageLabs. For more information on a
> proactive managed e-mail security service, visit
> http://www.cw.com/uk/emailprotection/
>
> The information contained in this e-mail is confidential and may also be
> subject to legal privilege. It is intended only for the recipient(s)
> named above. If you are not named above as a recipient, you must not
> read, copy

Re: Remedy - sensitive to network performance?

[Ciplak, Can]

Dave,

When did you notice this issue? Have you introduced any change to the
applications recently? 

If that is the case, try deleting .arv and .arf files at the client side
and see if deleting the files helps with the issue. 

Can Ciplak 
NAV CANADA 

613) 563-3512



-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Barber, David
Sent: June 26, 2008 10:18 AM
To: arslist@ARSLIST.ORG
Subject: Re: Remedy - sensitive to network performance?

Sorry ...

Clients are all running on v7.0.01 user tool.  No mid tier in use.
AR Server is running on Win2k3, 8 procssors
Database is running sql server on similar hardware/OS to the AR Server

The server/database are very close to each other.  Based in a data
center somewhere very remote from us in head office.  Invariably here at
head office performance is fine, its other users who generally have
problems.

>From the experience and tests we've done it does appear to be sensitive
to network performance.  Although having said that AR Server load is
around 20-25%, SQL Server normally 90+% load.

Regards

Dave

-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] Behalf Of William Rentfrow
Sent: 26 June 2008 15:06
To: arslist@ARSLIST.ORG
Subject: Re: Remedy - sensitive to network performance?


Can you give us more information about your setup?  Database type,
server OS, web server type, etc?
 
I assume you are using 1 AR Server connected to a local (relative to the
server) database.
 
You did not mention whether or not you are using the Web or Windows
clients either.  
 
William Rentfrow
Principal Consultant, StrataCom
[EMAIL PROTECTED]
O 952-432-0227
C 701-306-6157



From: Action Request System discussion list(ARSList) on behalf of
Barber, David
Sent: Thu 6/26/2008 8:11 AM
To: arslist@ARSLIST.ORG
Subject: Remedy - sensitive to network performance?


** 

Hi, 

Has anyone experienced end-user performance problems with Remedy over
larger networks? 

We're running a suite of bespoke applications, and are finding that some
tasks such as opening/updating incidents can take orders of magnitude
longer in some locations.  For example it can take me 8 seconds, but a
colleague at another location 2 or 3 minutes.

Have been able to do some local benchmarks - typical ping responses are
circa 10ms, but at points when we find that even our performance is hit,
we find the network is responding to pings at maybe 60+ms.  Our network
guys invariably say that the network is running fine ...

So it appears that Remedy, or at least the applications we're running,
are incredibly sensitive to network performance.  Any suggestions from
the list as to what we can do to improve performance?

Regards 

Dave 


This e-mail has been scanned for viruses by the Cable & Wireless e-mail
security system - powered by MessageLabs. For more information on a
proactive managed e-mail security service, visit
http://www.cw.com/uk/emailprotection/ 

The information contained in this e-mail is confidential and may also be
subject to legal privilege. It is intended only for the recipient(s)
named above. If you are not named above as a recipient, you must not
read, copy, disclose, forward or otherwise use the information contained
in this email. If you have received this e-mail in error, please notify
the sender (whose contact details are above) immediately by reply e-mail
and delete the message and any attachments without retaining any copies.

Cable and Wireless plc 
Registered in England and Wales.Company Number 238525 
Registered office: 3rd Floor, 26 Red Lion Square, London WC1R 4HQ
__Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
html___


___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

This e-mail has been scanned for viruses by the Cable & Wireless e-mail
security system - powered by MessageLabs. For more information on a
proactive managed e-mail security service, visit
http://www.cw.com/uk/emailprotection/ 

The information contained in this e-mail is confidential and may also be
subject to legal privilege. It is intended only for the recipient(s)
named above. If you are not named above as a recipient, you must not
read, copy, disclose, forward or otherwise use the information contained
in this email. If you have received this e-mail in error, please notify
the sender (whose contact details are above) immediately by reply e-mail
and delete the message and any attachments without retaining any copies.
 
Cable and Wireless plc 
Registered in England and Wales.Company Number 238525 
Registered office: 3rd Floor, 26 Red Lion Square, London WC1R 4HQ


___

Re: Remedy - sensitive to network performance?

[Rick Cook]

Good advice.  One other quick win is to ensure that the forms aren't
populating or auto-refreshing table fields until requested to do so.

The probable answer, though, is in the configuration of one of the network
hops, as others have suggested.  I'd put a sniffer on that sucker.

Rick

On Thu, Jun 26, 2008 at 7:59 AM, Axton <[EMAIL PROTECTED]> wrote:

> Then it's something you are going to have to live with.  You can tweak
> your apps to be less chatty.  Active link table walks, active link set
> fields, active link push fields, etc. all require a round trip back to
> the server.  Filter actions of the same type do not require a round
> trip to the server.  If you enable the active link and api logging on
> the client side, it should be fairly evident where the time is going.
> See what you can eliminate and what you can offload to the server
> side.
>
> Axton Grams
>
> On Thu, Jun 26, 2008 at 10:35 AM, Barber, David <[EMAIL PROTECTED]>
> wrote:
> > **
> > Tickets raised per day is anyones guess, typically several 5-6 thousand+
> >
> > We have gone through a lot of this at the same time as other users, and
> no
> > matter what time of day we get similar differentials - 10secs here, up to
> > 2-3 minutes elsewhere.
> >
> > We've found that our performance doesn't tend to vary much on/off peak -
> the
> > only time I've found it hitting me happens to be when the network
> responds
> > at an average of say 60ms, rather than the normal 10ms.
> >
> > Tried going over this with some of the networking teams.  Hate to say it,
> > but the repsonse is invariably one of "network is fine, no packet loss"
> ...
> > frustrating.
> >
> > Regards
> >
> > Dave
> >
> > -Original Message-
> > From: Action Request System discussion list(ARSList)
> > [mailto:[EMAIL PROTECTED] Behalf Of Howard Richter
> > Sent: 26 June 2008 15:30
> > To: arslist@ARSLIST.ORG
> > Subject: Re: Remedy - sensitive to network performance?
> >
> > **
> > David,
> >
> > That sounds about right on the load (but with out knowing the number of
> > users and tickets created per day that is a guess).
> >
> > You could go olld school to pin down the issue. Have one of your remote
> > users (that see the slow down) with you at the same time and do the same
> > functions and time them. Do it at peak times as well as non-peak.
> > Also have your network admin on the phone.
> >
> > hbr
> >
> >
> > On 6/26/08, Barber, David <[EMAIL PROTECTED]> wrote:
> >>
> >> Sorry ...
> >>
> >> Clients are all running on v7.0.01 user tool.  No mid tier in use.
> >> AR Server is running on Win2k3, 8 procssors
> >> Database is running sql server on similar hardware/OS to the AR Server
> >>
> >> The server/database are very close to each other.  Based in a data
> center
> >> somewhere very remote from us in head office.  Invariably here at head
> >> office performance is fine, its other users who generally have problems.
> >>
> >> From the experience and tests we've done it does appear to be sensitive
> to
> >> network performance.  Although having said that AR Server load is around
> >> 20-25%, SQL Server normally 90+% load.
> >>
> >> Regards
> >>
> >> Dave
> >>
> >> -Original Message-
> >> From: Action Request System discussion list(ARSList)
> >> [mailto:[EMAIL PROTECTED] Behalf Of William Rentfrow
> >> Sent: 26 June 2008 15:06
> >> To: arslist@ARSLIST.ORG
> >> Subject: Re: Remedy - sensitive to network performance?
> >>
> >>
> >> Can you give us more information about your setup?  Database type,
> server
> >> OS, web server type, etc?
> >>
> >> I assume you are using 1 AR Server connected to a local (relative to the
> >> server) database.
> >>
> >> You did not mention whether or not you are using the Web or Windows
> >> clients either.
> >>
> >> William Rentfrow
> >> Principal Consultant, StrataCom
> >> [EMAIL PROTECTED]
> >> O 952-432-0227
> >> C 701-306-6157
> >>
> >> 
> >>
> >> From: Action Request System discussion list(ARSList) on behalf of
> Barber,
> >> David
> >> Sent: Thu 6/26/2008 8:11 AM
> >> To: arslist@ARSLIST.ORG
> >> Subject: Remedy - sensitive to network performance?
> >>
> >>
> >> **
>

Re: Remedy - sensitive to network performance?

[Barber, David]

We have tried with a few users changing from the full server name to its IP 
address.  No difference in performance, unless they're at a location that is 
having DNS issues (which is thankfully very rare).

Regards

Dave

-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] Behalf Of Rocky Rockwell
Sent: 26 June 2008 16:07
To: arslist@ARSLIST.ORG
Subject: Re: Remedy - sensitive to network performance?


We did have issues with the many dns servers. People would use the 
server name instead of the fully qualified name. At the time we also had 
the domain up to the top of the dns list on peoples PC. But we do not 
use this network config anymore. I know it is a long shot, but these 2 
items cuased us many issues at first.

*Rocky*

Rocky Rockwell
Remedy/BMC Application Designer
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
Ph#1: 214-567-8874
Ph#2: 325-450-5076



Barber, David wrote:
> **
>
> Hi,
>
> Has anyone experienced end-user performance problems with Remedy over 
> larger networks?
>
> We're running a suite of bespoke applications, and are finding that 
> some tasks such as opening/updating incidents can take orders of 
> magnitude longer in some locations.  For example it can take me 8 
> seconds, but a colleague at another location 2 or 3 minutes.
>
> Have been able to do some local benchmarks - typical ping responses 
> are circa 10ms, but at points when we find that even our performance 
> is hit, we find the network is responding to pings at maybe 60+ms.  
> Our network guys invariably say that the network is running fine ...
>
> So it appears that Remedy, or at least the applications we're running, 
> are incredibly sensitive to network performance.  Any suggestions from 
> the list as to what we can do to improve performance?
>
> Regards
>
> Dave
>
>
> This e-mail has been scanned for viruses by the Cable & Wireless 
> e-mail security system - powered by MessageLabs. For more information 
> on a proactive managed e-mail security service, visit 
> http://www.cw.com/uk/emailprotection/
>
> The information contained in this e-mail is confidential and may also 
> be subject to legal privilege. It is intended only for the 
> recipient(s) named above. If you are not named above as a recipient, 
> you must not read, copy, disclose, forward or otherwise use the 
> information contained in this email. If you have received this e-mail 
> in error, please notify the sender (whose contact details are above) 
> immediately by reply e-mail and delete the message and any attachments 
> without retaining any copies.
>
> Cable and Wireless plc
> Registered in England and Wales.Company Number 238525
> Registered office: 3rd Floor, 26 Red Lion Square, London WC1R 4HQ
> __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" 
> html___ 

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

This e-mail has been scanned for viruses by the Cable & Wireless e-mail 
security system - powered by MessageLabs. For more information on a proactive 
managed e-mail security service, visit http://www.cw.com/uk/emailprotection/ 

The information contained in this e-mail is confidential and may also be 
subject to legal privilege. It is intended only for the recipient(s) named 
above. If you are not named above as a recipient, you must not read, copy, 
disclose, forward or otherwise use the information contained in this email. If 
you have received this e-mail in error, please notify the sender (whose contact 
details are above) immediately by reply e-mail and delete the message and any 
attachments without retaining any copies.
 
Cable and Wireless plc 
Registered in England and Wales.Company Number 238525 
Registered office: 3rd Floor, 26 Red Lion Square, London WC1R 4HQ

Re: Remedy - sensitive to network performance?

[Axton]

Latency has little to do with bandwidth; don't let one guide you to a
belief about the other.  You can get the network latency without using
windows ping (which uses icmp packets).  Check out some of the tcp/udp
ping utilities that are out there.

http://perform.wpi.edu/downloads/udp-tools/udp-heart.tgz
http://webscripts.softpedia.com/scriptDownload/TCP-Ping-Download-11907.html

Axton Grams

On Thu, Jun 26, 2008 at 10:43 AM, Barber, David <[EMAIL PROTECTED]> wrote:
> **
> With some of the local admin lockdowns not all can do ping/tracert.  Adds to
> the frustration.
>
> Have been going over this repeatedly over a few months, and most times have
> asked the network teams for their feedback - invariably just get the "its
> fine" responses.
>
> Latency differences between 1Gb/s and 10Mb/s would be huge, I've asked what
> the network speeds are to some of the trouble spots.  They somehow evade the
> questions.  I may start considering banging my head against a wall instead
> of actually asking the network teams for assistance ;)
>
> Regards
>
> Dave
>
>
>
> -Original Message-
> From: Action Request System discussion list(ARSList)
> [mailto:[EMAIL PROTECTED] Behalf Of Gary Opela (Corporate)
> Sent: 26 June 2008 15:38
> To: arslist@ARSLIST.ORG
> Subject: Re: Remedy - sensitive to network performance?
>
> **
>
> Do a tracert from the remote user's computers J I don't know if it will help
> or not, but I like to run them. Maybe you could see the hop that is causing
> the 60 m/s ping times.
>
>
>
> Did your network guy check all of the network interfaces to make sure they
> are all set on 1Gb/s? I've seen multiple times where a switch, or pc, set to
> auto-negotiate, chose 10Mb/s instead of 1Gb/s, boy is there a big difference
> there!
>
>
>
> Thanks,
>
>
>
> Gary Opela, Jr., RSP
>
> Remedy Engineer
>
> Leader Communications, Inc.
>
> http://www.5pointleader.com
>
> http://www.lcibest.com
>
> Best Product, Best People, Best PriceTM
>
> An ISO 9001:2000 Certified, CMMI(R) Level 3 Rated Company
>
> ____________
>
> From: Action Request System discussion list(ARSList)
> [mailto:[EMAIL PROTECTED] On Behalf Of Howard Richter
> Sent: Thursday, June 26, 2008 9:30 AM
> To: arslist@ARSLIST.ORG
> Subject: Re: Remedy - sensitive to network performance?
>
>
>
> **
>
> David,
>
>
>
> That sounds about right on the load (but with out knowing the number of
> users and tickets created per day that is a guess).
>
>
>
> You could go olld school to pin down the issue. Have one of your remote
> users (that see the slow down) with you at the same time and do the same
> functions and time them. Do it at peak times as well as non-peak.
>
> Also have your network admin on the phone.
>
>
>
> hbr
>
>
>
> On 6/26/08, Barber, David <[EMAIL PROTECTED]> wrote:
>
> Sorry ...
>
> Clients are all running on v7.0.01 user tool.  No mid tier in use.
> AR Server is running on Win2k3, 8 procssors
> Database is running sql server on similar hardware/OS to the AR Server
>
> The server/database are very close to each other.  Based in a data center
> somewhere very remote from us in head office.  Invariably here at head
> office performance is fine, its other users who generally have problems.
>
> From the experience and tests we've done it does appear to be sensitive to
> network performance.  Although having said that AR Server load is around
> 20-25%, SQL Server normally 90+% load.
>
> Regards
>
> Dave
>
> -Original Message-
> From: Action Request System discussion list(ARSList)
> [mailto:[EMAIL PROTECTED] Behalf Of William Rentfrow
> Sent: 26 June 2008 15:06
> To: arslist@ARSLIST.ORG
> Subject: Re: Remedy - sensitive to network performance?
>
>
> Can you give us more information about your setup?  Database type, server
> OS, web server type, etc?
>
> I assume you are using 1 AR Server connected to a local (relative to the
> server) database.
>
> You did not mention whether or not you are using the Web or Windows clients
> either.
>
> William Rentfrow
> Principal Consultant, StrataCom
> [EMAIL PROTECTED]
> O 952-432-0227
> C 701-306-6157
>
> 
>
> From: Action Request System discussion list(ARSList) on behalf of Barber,
> David
> Sent: Thu 6/26/2008 8:11 AM
> To: arslist@ARSLIST.ORG
> Subject: Remedy - sensitive to network performance?
>
>
> **
>
> Hi,
>
> Has anyone experienced end-user performance problems with Remedy over larger
> networks?
>
> We're running a suite of bespoke

Re: Remedy - sensitive to network performance?

[Rocky Rockwell]

We did have issues with the many dns servers. People would use the 
server name instead of the fully qualified name. At the time we also had 
the domain up to the top of the dns list on peoples PC. But we do not 
use this network config anymore. I know it is a long shot, but these 2 
items cuased us many issues at first.


*Rocky*

Rocky Rockwell
Remedy/BMC Application Designer
[EMAIL PROTECTED] 
Ph#1: 214-567-8874
Ph#2: 325-450-5076



Barber, David wrote:

**

Hi,

Has anyone experienced end-user performance problems with Remedy over 
larger networks?


We're running a suite of bespoke applications, and are finding that 
some tasks such as opening/updating incidents can take orders of 
magnitude longer in some locations.  For example it can take me 8 
seconds, but a colleague at another location 2 or 3 minutes.


Have been able to do some local benchmarks - typical ping responses 
are circa 10ms, but at points when we find that even our performance 
is hit, we find the network is responding to pings at maybe 60+ms.  
Our network guys invariably say that the network is running fine ...


So it appears that Remedy, or at least the applications we're running, 
are incredibly sensitive to network performance.  Any suggestions from 
the list as to what we can do to improve performance?


Regards

Dave


This e-mail has been scanned for viruses by the Cable & Wireless 
e-mail security system - powered by MessageLabs. For more information 
on a proactive managed e-mail security service, visit 
http://www.cw.com/uk/emailprotection/


The information contained in this e-mail is confidential and may also 
be subject to legal privilege. It is intended only for the 
recipient(s) named above. If you are not named above as a recipient, 
you must not read, copy, disclose, forward or otherwise use the 
information contained in this email. If you have received this e-mail 
in error, please notify the sender (whose contact details are above) 
immediately by reply e-mail and delete the message and any attachments 
without retaining any copies.


Cable and Wireless plc
Registered in England and Wales.Company Number 238525
Registered office: 3rd Floor, 26 Red Lion Square, London WC1R 4HQ
__Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" 
html___ 


___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

Re: Remedy - sensitive to network performance?

[Barber, David]

Totally custom apps, nothing out of the box at all.  Performing similar tasks, 
ticketing, change management, but the lions share of work is done via 
ticketing.  Probably 95% of the activity.

-Original Message-
From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] 
Behalf Of William Rentfrow
Sent: 26 June 2008 15:52
To: arslist@ARSLIST.ORG
Subject: Re: Remedy - sensitive to network performance?


** 
No packet loss != fine :)
 
Obviously there is some network degradation during those times.
 
Does your network team have some kind of SLA regard what "acceptable" network 
response time is?
 
It is presumably a good exercise to do your API logs as well and make sure you 
have the correct # of threads available.
 
Now - to go a step off the deep end.
 
Are you using Remedy OOB apps?  If you are using Incident Management you can do 
a couple interesting reports.  Just make a simple report formula of:
 
'Submit Time/Date' - 'Reported Time/Date'.
 
Reported time/date is stamped by the client on window open.  Submit date/time 
is stamped by the server on create (as I'm sure you know).  So basically this 
gives you the time between when the window was opened and when the case was 
actually created.
 
If on average all other factors are the same (technician time spent opening a 
case) then the change in time over the course of a day for case creation should 
be able to be seen quite easily on a graph.  Your peak times will result in a 
much higher number from this formula.
 
You can then possibly correlate that with activities going on around the 
enterprise (i.e., does the guy in HR pull all his agent performance metrics at 
a certain time every day).

  _  

From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] 
On Behalf Of Barber, David
Sent: Thursday, June 26, 2008 9:36 AM
To: arslist@ARSLIST.ORG
Subject: Re: Remedy - sensitive to network performance?


** 
Tickets raised per day is anyones guess, typically several 5-6 thousand+
 
We have gone through a lot of this at the same time as other users, and no 
matter what time of day we get similar differentials - 10secs here, up to 2-3 
minutes elsewhere.
 
We've found that our performance doesn't tend to vary much on/off peak - the 
only time I've found it hitting me happens to be when the network responds at 
an average of say 60ms, rather than the normal 10ms.
 
Tried going over this with some of the networking teams.  Hate to say it, but 
the repsonse is invariably one of "network is fine, no packet loss" ... 
frustrating.
 
Regards
 
Dave

-Original Message-
From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] 
Behalf Of Howard Richter
Sent: 26 June 2008 15:30
To: arslist@ARSLIST.ORG
Subject: Re: Remedy - sensitive to network performance?


** 
David,
 
That sounds about right on the load (but with out knowing the number of users 
and tickets created per day that is a guess). 
 
You could go olld school to pin down the issue. Have one of your remote users 
(that see the slow down) with you at the same time and do the same functions 
and time them. Do it at peak times as well as non-peak.
Also have your network admin on the phone.
 
hbr

 
On 6/26/08, Barber, David < [EMAIL PROTECTED]> wrote: 

Sorry ...

Clients are all running on v7.0.01 user tool.  No mid tier in use.
AR Server is running on Win2k3, 8 procssors
Database is running sql server on similar hardware/OS to the AR Server

The server/database are very close to each other.  Based in a data center 
somewhere very remote from us in head office.  Invariably here at head office 
performance is fine, its other users who generally have problems.

From the experience and tests we've done it does appear to be sensitive to 
network performance.  Although having said that AR Server load is around 
20-25%, SQL Server normally 90+% load.

Regards

Dave

-Original Message-
From: Action Request System discussion list(ARSList)
[mailto: [EMAIL PROTECTED] Behalf Of William Rentfrow
Sent: 26 June 2008 15:06
To: arslist@ARSLIST.ORG
Subject: Re: Remedy - sensitive to network performance?


Can you give us more information about your setup?  Database type, server OS, 
web server type, etc?

I assume you are using 1 AR Server connected to a local (relative to the 
server) database.

You did not mention whether or not you are using the Web or Windows clients 
either.

William Rentfrow
Principal Consultant, StrataCom
[EMAIL PROTECTED]
O 952-432-0227
C 701-306-6157



From: Action Request System discussion list(ARSList) on behalf of Barber, David
Sent: Thu 6/26/2008 8:11 AM
To: arslist@ARSLIST.ORG
Subject: Remedy - sensitive to network performance?


**

Hi,

Has anyone experienced end-user performance problems with Remedy over larger 
networks?

We're running a suite of bespoke applications, and are fi

Re: Remedy - sensitive to network performance?

[Axton]

Then it's something you are going to have to live with.  You can tweak
your apps to be less chatty.  Active link table walks, active link set
fields, active link push fields, etc. all require a round trip back to
the server.  Filter actions of the same type do not require a round
trip to the server.  If you enable the active link and api logging on
the client side, it should be fairly evident where the time is going.
See what you can eliminate and what you can offload to the server
side.

Axton Grams

On Thu, Jun 26, 2008 at 10:35 AM, Barber, David <[EMAIL PROTECTED]> wrote:
> **
> Tickets raised per day is anyones guess, typically several 5-6 thousand+
>
> We have gone through a lot of this at the same time as other users, and no
> matter what time of day we get similar differentials - 10secs here, up to
> 2-3 minutes elsewhere.
>
> We've found that our performance doesn't tend to vary much on/off peak - the
> only time I've found it hitting me happens to be when the network responds
> at an average of say 60ms, rather than the normal 10ms.
>
> Tried going over this with some of the networking teams.  Hate to say it,
> but the repsonse is invariably one of "network is fine, no packet loss" ...
> frustrating.
>
> Regards
>
> Dave
>
> -Original Message-
> From: Action Request System discussion list(ARSList)
> [mailto:[EMAIL PROTECTED] Behalf Of Howard Richter
> Sent: 26 June 2008 15:30
> To: arslist@ARSLIST.ORG
> Subject: Re: Remedy - sensitive to network performance?
>
> **
> David,
>
> That sounds about right on the load (but with out knowing the number of
> users and tickets created per day that is a guess).
>
> You could go olld school to pin down the issue. Have one of your remote
> users (that see the slow down) with you at the same time and do the same
> functions and time them. Do it at peak times as well as non-peak.
> Also have your network admin on the phone.
>
> hbr
>
>
> On 6/26/08, Barber, David <[EMAIL PROTECTED]> wrote:
>>
>> Sorry ...
>>
>> Clients are all running on v7.0.01 user tool.  No mid tier in use.
>> AR Server is running on Win2k3, 8 procssors
>> Database is running sql server on similar hardware/OS to the AR Server
>>
>> The server/database are very close to each other.  Based in a data center
>> somewhere very remote from us in head office.  Invariably here at head
>> office performance is fine, its other users who generally have problems.
>>
>> From the experience and tests we've done it does appear to be sensitive to
>> network performance.  Although having said that AR Server load is around
>> 20-25%, SQL Server normally 90+% load.
>>
>> Regards
>>
>> Dave
>>
>> -Original Message-
>> From: Action Request System discussion list(ARSList)
>> [mailto:[EMAIL PROTECTED] Behalf Of William Rentfrow
>> Sent: 26 June 2008 15:06
>> To: arslist@ARSLIST.ORG
>> Subject: Re: Remedy - sensitive to network performance?
>>
>>
>> Can you give us more information about your setup?  Database type, server
>> OS, web server type, etc?
>>
>> I assume you are using 1 AR Server connected to a local (relative to the
>> server) database.
>>
>> You did not mention whether or not you are using the Web or Windows
>> clients either.
>>
>> William Rentfrow
>> Principal Consultant, StrataCom
>> [EMAIL PROTECTED]
>> O 952-432-0227
>> C 701-306-6157
>>
>> 
>>
>> From: Action Request System discussion list(ARSList) on behalf of Barber,
>> David
>> Sent: Thu 6/26/2008 8:11 AM
>> To: arslist@ARSLIST.ORG
>> Subject: Remedy - sensitive to network performance?
>>
>>
>> **
>>
>> Hi,
>>
>> Has anyone experienced end-user performance problems with Remedy over
>> larger networks?
>>
>> We're running a suite of bespoke applications, and are finding that some
>> tasks such as opening/updating incidents can take orders of magnitude longer
>> in some locations.  For example it can take me 8 seconds, but a colleague at
>> another location 2 or 3 minutes.
>>
>> Have been able to do some local benchmarks - typical ping responses are
>> circa 10ms, but at points when we find that even our performance is hit, we
>> find the network is responding to pings at maybe 60+ms.  Our network guys
>> invariably say that the network is running fine ...
>>
>> So it appears that Remedy, or at least the applications we're running, are
>> incredibly sensitive to network performance.  Any suggestions from the

Re: Remedy - sensitive to network performance?

[William Rentfrow]

No packet loss != fine :)
 
Obviously there is some network degradation during those times.
 
Does your network team have some kind of SLA regard what "acceptable"
network response time is?
 
It is presumably a good exercise to do your API logs as well and make
sure you have the correct # of threads available.
 
Now - to go a step off the deep end.
 
Are you using Remedy OOB apps?  If you are using Incident Management you
can do a couple interesting reports.  Just make a simple report formula
of:
 
'Submit Time/Date' - 'Reported Time/Date'.
 
Reported time/date is stamped by the client on window open.  Submit
date/time is stamped by the server on create (as I'm sure you know).  So
basically this gives you the time between when the window was opened and
when the case was actually created.
 
If on average all other factors are the same (technician time spent
opening a case) then the change in time over the course of a day for
case creation should be able to be seen quite easily on a graph.  Your
peak times will result in a much higher number from this formula.
 
You can then possibly correlate that with activities going on around the
enterprise (i.e., does the guy in HR pull all his agent performance
metrics at a certain time every day).



From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Barber, David
Sent: Thursday, June 26, 2008 9:36 AM
To: arslist@ARSLIST.ORG
Subject: Re: Remedy - sensitive to network performance?


** 
Tickets raised per day is anyones guess, typically several 5-6 thousand+
 
We have gone through a lot of this at the same time as other users, and
no matter what time of day we get similar differentials - 10secs here,
up to 2-3 minutes elsewhere.
 
We've found that our performance doesn't tend to vary much on/off peak -
the only time I've found it hitting me happens to be when the network
responds at an average of say 60ms, rather than the normal 10ms.
 
Tried going over this with some of the networking teams.  Hate to say
it, but the repsonse is invariably one of "network is fine, no packet
loss" ... frustrating.
 
Regards
 
Dave

-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] Behalf Of Howard Richter
Sent: 26 June 2008 15:30
    To: arslist@ARSLIST.ORG
    Subject: Re: Remedy - sensitive to network performance?


** 
David,
 
That sounds about right on the load (but with out knowing the
number of users and tickets created per day that is a guess). 
 
You could go olld school to pin down the issue. Have one of your
remote users (that see the slow down) with you at the same time and do
the same functions and time them. Do it at peak times as well as
non-peak.
Also have your network admin on the phone.
 
hbr

 
On 6/26/08, Barber, David <[EMAIL PROTECTED]> wrote: 

Sorry ...

Clients are all running on v7.0.01 user tool.  No mid
tier in use.
AR Server is running on Win2k3, 8 procssors
Database is running sql server on similar hardware/OS to
the AR Server

The server/database are very close to each other.  Based
in a data center somewhere very remote from us in head office.
Invariably here at head office performance is fine, its other users who
generally have problems.

From the experience and tests we've done it does appear
to be sensitive to network performance.  Although having said that AR
Server load is around 20-25%, SQL Server normally 90+% load.

Regards

Dave

-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] Behalf Of William
Rentfrow
Sent: 26 June 2008 15:06
    To: arslist@ARSLIST.ORG
Subject: Re: Remedy - sensitive to network performance?


Can you give us more information about your setup?
Database type, server OS, web server type, etc?

I assume you are using 1 AR Server connected to a local
(relative to the server) database.

You did not mention whether or not you are using the Web
or Windows clients either.

William Rentfrow
Principal Consultant, StrataCom
[EMAIL PROTECTED]
O 952-432-0227
C 701-306-6157



From: Action Request System discussion list(ARSList)

Re: Remedy - sensitive to network performance?

[Axton]

What is the difference in network bandwidth/latency for the two sites?
 Remedy is a chatty application (to varying degrees based on how the
apps are written - server side vs client side workflow), therefore
higher latency can result in a linear degradation in performance.

http://msdn.microsoft.com/en-us/library/aa374342(VS.85).aspx

Axton Grams

On Thu, Jun 26, 2008 at 10:30 AM, Howard Richter <[EMAIL PROTECTED]> wrote:
> **
> David,
>
> That sounds about right on the load (but with out knowing the number of
> users and tickets created per day that is a guess).
>
> You could go olld school to pin down the issue. Have one of your remote
> users (that see the slow down) with you at the same time and do the same
> functions and time them. Do it at peak times as well as non-peak.
> Also have your network admin on the phone.
>
> hbr
>
>
> On 6/26/08, Barber, David <[EMAIL PROTECTED]> wrote:
>>
>> Sorry ...
>>
>> Clients are all running on v7.0.01 user tool.  No mid tier in use.
>> AR Server is running on Win2k3, 8 procssors
>> Database is running sql server on similar hardware/OS to the AR Server
>>
>> The server/database are very close to each other.  Based in a data center
>> somewhere very remote from us in head office.  Invariably here at head
>> office performance is fine, its other users who generally have problems.
>>
>> From the experience and tests we've done it does appear to be sensitive to
>> network performance.  Although having said that AR Server load is around
>> 20-25%, SQL Server normally 90+% load.
>>
>> Regards
>>
>> Dave
>>
>> -Original Message-
>> From: Action Request System discussion list(ARSList)
>> [mailto:[EMAIL PROTECTED] Behalf Of William Rentfrow
>> Sent: 26 June 2008 15:06
>> To: arslist@ARSLIST.ORG
>> Subject: Re: Remedy - sensitive to network performance?
>>
>>
>> Can you give us more information about your setup?  Database type, server
>> OS, web server type, etc?
>>
>> I assume you are using 1 AR Server connected to a local (relative to the
>> server) database.
>>
>> You did not mention whether or not you are using the Web or Windows
>> clients either.
>>
>> William Rentfrow
>> Principal Consultant, StrataCom
>> [EMAIL PROTECTED]
>> O 952-432-0227
>> C 701-306-6157
>>
>> 
>>
>> From: Action Request System discussion list(ARSList) on behalf of Barber,
>> David
>> Sent: Thu 6/26/2008 8:11 AM
>> To: arslist@ARSLIST.ORG
>> Subject: Remedy - sensitive to network performance?
>>
>>
>> **
>>
>> Hi,
>>
>> Has anyone experienced end-user performance problems with Remedy over
>> larger networks?
>>
>> We're running a suite of bespoke applications, and are finding that some
>> tasks such as opening/updating incidents can take orders of magnitude longer
>> in some locations.  For example it can take me 8 seconds, but a colleague at
>> another location 2 or 3 minutes.
>>
>> Have been able to do some local benchmarks - typical ping responses are
>> circa 10ms, but at points when we find that even our performance is hit, we
>> find the network is responding to pings at maybe 60+ms.  Our network guys
>> invariably say that the network is running fine ...
>>
>> So it appears that Remedy, or at least the applications we're running, are
>> incredibly sensitive to network performance.  Any suggestions from the list
>> as to what we can do to improve performance?
>>
>> Regards
>>
>> Dave
>>
>>
>> This e-mail has been scanned for viruses by the Cable & Wireless e-mail
>> security system - powered by MessageLabs. For more information on a
>> proactive managed e-mail security service, visit
>> http://www.cw.com/uk/emailprotection/
>>
>> The information contained in this e-mail is confidential and may also be
>> subject to legal privilege. It is intended only for the recipient(s) named
>> above. If you are not named above as a recipient, you must not read, copy,
>> disclose, forward or otherwise use the information contained in this email.
>> If you have received this e-mail in error, please notify the sender (whose
>> contact details are above) immediately by reply e-mail and delete the
>> message and any attachments without retaining any copies.
>>
>> Cable and Wireless plc
>> Registered in England and Wales.Company Number 238525
>> Registered office: 3rd Floor, 26 Red Lion Square, London WC1R 4HQ
>> __Platinum Sponsor: www.rmspor

Re: Remedy - sensitive to network performance?

[Barber, David]

With some of the local admin lockdowns not all can do ping/tracert.  Adds to 
the frustration.
 
Have been going over this repeatedly over a few months, and most times have 
asked the network teams for their feedback - invariably just get the "its fine" 
responses.
 
Latency differences between 1Gb/s and 10Mb/s would be huge, I've asked what the 
network speeds are to some of the trouble spots.  They somehow evade the 
questions.  I may start considering banging my head against a wall instead of 
actually asking the network teams for assistance ;)
 
Regards
 
Dave
 
 

-Original Message-
From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] 
Behalf Of Gary Opela (Corporate)
Sent: 26 June 2008 15:38
To: arslist@ARSLIST.ORG
Subject: Re: Remedy - sensitive to network performance?


** 

Do a tracert from the remote user's computers :-) I don't know if it will help 
or not, but I like to run them. Maybe you could see the hop that is causing the 
60 m/s ping times.

 

Did your network guy check all of the network interfaces to make sure they are 
all set on 1Gb/s? I've seen multiple times where a switch, or pc, set to 
auto-negotiate, chose 10Mb/s instead of 1Gb/s, boy is there a big difference 
there!

 

Thanks,

 

Gary Opela, Jr., RSP

Remedy Engineer

Leader Communications, Inc.

http://www.5pointleader.com

http://www.lcibest.com

Best Product, Best People, Best PriceTM

An ISO 9001:2000 Certified, CMMI® Level 3 Rated Company


  _  


From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] 
On Behalf Of Howard Richter
Sent: Thursday, June 26, 2008 9:30 AM
To: arslist@ARSLIST.ORG
Subject: Re: Remedy - sensitive to network performance?

 

** 

David,

 

That sounds about right on the load (but with out knowing the number of users 
and tickets created per day that is a guess). 

 

You could go olld school to pin down the issue. Have one of your remote users 
(that see the slow down) with you at the same time and do the same functions 
and time them. Do it at peak times as well as non-peak.

Also have your network admin on the phone.

 

hbr

 

On 6/26/08, Barber, David < [EMAIL PROTECTED]> wrote: 

Sorry ...

Clients are all running on v7.0.01 user tool.  No mid tier in use.
AR Server is running on Win2k3, 8 procssors
Database is running sql server on similar hardware/OS to the AR Server

The server/database are very close to each other.  Based in a data center 
somewhere very remote from us in head office.  Invariably here at head office 
performance is fine, its other users who generally have problems.

From the experience and tests we've done it does appear to be sensitive to 
network performance.  Although having said that AR Server load is around 
20-25%, SQL Server normally 90+% load.

Regards

Dave

-Original Message-
From: Action Request System discussion list(ARSList)
[mailto: [EMAIL PROTECTED] Behalf Of William Rentfrow
Sent: 26 June 2008 15:06
To: arslist@ARSLIST.ORG
Subject: Re: Remedy - sensitive to network performance?


Can you give us more information about your setup?  Database type, server OS, 
web server type, etc?

I assume you are using 1 AR Server connected to a local (relative to the 
server) database.

You did not mention whether or not you are using the Web or Windows clients 
either.

William Rentfrow
Principal Consultant, StrataCom
[EMAIL PROTECTED]
O 952-432-0227
C 701-306-6157



From: Action Request System discussion list(ARSList) on behalf of Barber, David
Sent: Thu 6/26/2008 8:11 AM
To: arslist@ARSLIST.ORG
Subject: Remedy - sensitive to network performance?


**

Hi,

Has anyone experienced end-user performance problems with Remedy over larger 
networks?

We're running a suite of bespoke applications, and are finding that some tasks 
such as opening/updating incidents can take orders of magnitude longer in some 
locations.  For example it can take me 8 seconds, but a colleague at another 
location 2 or 3 minutes.

Have been able to do some local benchmarks - typical ping responses are circa 
10ms, but at points when we find that even our performance is hit, we find the 
network is responding to pings at maybe 60+ms.  Our network guys invariably say 
that the network is running fine ...

So it appears that Remedy, or at least the applications we're running, are 
incredibly sensitive to network performance.  Any suggestions from the list as 
to what we can do to improve performance?

Regards

Dave


This e-mail has been scanned for viruses by the Cable & Wireless e-mail 
security system - powered by MessageLabs. For more information on a proactive 
managed e-mail security service, visit http://www.cw.com/uk/emailprotection/

The information contained in this e-mail is confidential and may also be 
subject to legal privilege. It is intended only for the recipient(s) named 
above. If you are not named above as a re

Re: Remedy - sensitive to network performance?

[Gary Opela (Corporate)]

Do a tracert from the remote user's computers :) I don't know if it will help 
or not, but I like to run them. Maybe you could see the hop that is causing the 
60 m/s ping times.

Did your network guy check all of the network interfaces to make sure they are 
all set on 1Gb/s? I've seen multiple times where a switch, or pc, set to 
auto-negotiate, chose 10Mb/s instead of 1Gb/s, boy is there a big difference 
there!

Thanks,

Gary Opela, Jr., RSP
Remedy Engineer
Leader Communications, Inc.
http://www.5pointleader.com
http://www.lcibest.com
Best Product, Best People, Best PriceTM
An ISO 9001:2000 Certified, CMMI(r) Level 3 Rated Company

From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] 
On Behalf Of Howard Richter
Sent: Thursday, June 26, 2008 9:30 AM
To: arslist@ARSLIST.ORG
Subject: Re: Remedy - sensitive to network performance?

**
David,

That sounds about right on the load (but with out knowing the number of users 
and tickets created per day that is a guess).

You could go olld school to pin down the issue. Have one of your remote users 
(that see the slow down) with you at the same time and do the same functions 
and time them. Do it at peak times as well as non-peak.
Also have your network admin on the phone.

hbr


On 6/26/08, Barber, David <[EMAIL PROTECTED]<mailto:[EMAIL PROTECTED]>> wrote:
Sorry ...

Clients are all running on v7.0.01 user tool.  No mid tier in use.
AR Server is running on Win2k3, 8 procssors
Database is running sql server on similar hardware/OS to the AR Server

The server/database are very close to each other.  Based in a data center 
somewhere very remote from us in head office.  Invariably here at head office 
performance is fine, its other users who generally have problems.

>From the experience and tests we've done it does appear to be sensitive to 
>network performance.  Although having said that AR Server load is around 
>20-25%, SQL Server normally 90+% load.

Regards

Dave

-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG>]On Behalf Of William 
Rentfrow
Sent: 26 June 2008 15:06
To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG>
Subject: Re: Remedy - sensitive to network performance?


Can you give us more information about your setup?  Database type, server OS, 
web server type, etc?

I assume you are using 1 AR Server connected to a local (relative to the 
server) database.

You did not mention whether or not you are using the Web or Windows clients 
either.

William Rentfrow
Principal Consultant, StrataCom
[EMAIL PROTECTED]<mailto:[EMAIL PROTECTED]>
O 952-432-0227
C 701-306-6157



From: Action Request System discussion list(ARSList) on behalf of Barber, David
Sent: Thu 6/26/2008 8:11 AM
To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG>
Subject: Remedy - sensitive to network performance?


**

Hi,

Has anyone experienced end-user performance problems with Remedy over larger 
networks?

We're running a suite of bespoke applications, and are finding that some tasks 
such as opening/updating incidents can take orders of magnitude longer in some 
locations.  For example it can take me 8 seconds, but a colleague at another 
location 2 or 3 minutes.

Have been able to do some local benchmarks - typical ping responses are circa 
10ms, but at points when we find that even our performance is hit, we find the 
network is responding to pings at maybe 60+ms.  Our network guys invariably say 
that the network is running fine ...

So it appears that Remedy, or at least the applications we're running, are 
incredibly sensitive to network performance.  Any suggestions from the list as 
to what we can do to improve performance?

Regards

Dave


This e-mail has been scanned for viruses by the Cable & Wireless e-mail 
security system - powered by MessageLabs. For more information on a proactive 
managed e-mail security service, visit http://www.cw.com/uk/emailprotection/

The information contained in this e-mail is confidential and may also be 
subject to legal privilege. It is intended only for the recipient(s) named 
above. If you are not named above as a recipient, you must not read, copy, 
disclose, forward or otherwise use the information contained in this email. If 
you have received this e-mail in error, please notify the sender (whose contact 
details are above) immediately by reply e-mail and delete the message and any 
attachments without retaining any copies.

Cable and Wireless plc
Registered in England and Wales.Company Number 238525
Registered office: 3rd Floor, 26 Red Lion Square, London WC1R 4HQ
__Platinum Sponsor: www.rmsportal.com<http://www.rmsportal.com> ARSlist: "Where 
the Answers Are" html___

___
UNSU

Re: Remedy - sensitive to network performance?

[Barber, David]

Tickets raised per day is anyones guess, typically several 5-6 thousand+
 
We have gone through a lot of this at the same time as other users, and no 
matter what time of day we get similar differentials - 10secs here, up to 2-3 
minutes elsewhere.
 
We've found that our performance doesn't tend to vary much on/off peak - the 
only time I've found it hitting me happens to be when the network responds at 
an average of say 60ms, rather than the normal 10ms.
 
Tried going over this with some of the networking teams.  Hate to say it, but 
the repsonse is invariably one of "network is fine, no packet loss" ... 
frustrating.
 
Regards
 
Dave

-Original Message-
From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] 
Behalf Of Howard Richter
Sent: 26 June 2008 15:30
To: arslist@ARSLIST.ORG
Subject: Re: Remedy - sensitive to network performance?


** 
David,
 
That sounds about right on the load (but with out knowing the number of users 
and tickets created per day that is a guess). 
 
You could go olld school to pin down the issue. Have one of your remote users 
(that see the slow down) with you at the same time and do the same functions 
and time them. Do it at peak times as well as non-peak.
Also have your network admin on the phone.
 
hbr

 
On 6/26/08, Barber, David < [EMAIL PROTECTED]> wrote: 

Sorry ...

Clients are all running on v7.0.01 user tool.  No mid tier in use.
AR Server is running on Win2k3, 8 procssors
Database is running sql server on similar hardware/OS to the AR Server

The server/database are very close to each other.  Based in a data center 
somewhere very remote from us in head office.  Invariably here at head office 
performance is fine, its other users who generally have problems.

From the experience and tests we've done it does appear to be sensitive to 
network performance.  Although having said that AR Server load is around 
20-25%, SQL Server normally 90+% load.

Regards

Dave

-Original Message-
From: Action Request System discussion list(ARSList)
[mailto: [EMAIL PROTECTED] Behalf Of William Rentfrow
Sent: 26 June 2008 15:06
To: arslist@ARSLIST.ORG
Subject: Re: Remedy - sensitive to network performance?


Can you give us more information about your setup?  Database type, server OS, 
web server type, etc?

I assume you are using 1 AR Server connected to a local (relative to the 
server) database.

You did not mention whether or not you are using the Web or Windows clients 
either.

William Rentfrow
Principal Consultant, StrataCom
[EMAIL PROTECTED]
O 952-432-0227
C 701-306-6157



From: Action Request System discussion list(ARSList) on behalf of Barber, David
Sent: Thu 6/26/2008 8:11 AM
To: arslist@ARSLIST.ORG
Subject: Remedy - sensitive to network performance?


**

Hi,

Has anyone experienced end-user performance problems with Remedy over larger 
networks?

We're running a suite of bespoke applications, and are finding that some tasks 
such as opening/updating incidents can take orders of magnitude longer in some 
locations.  For example it can take me 8 seconds, but a colleague at another 
location 2 or 3 minutes.

Have been able to do some local benchmarks - typical ping responses are circa 
10ms, but at points when we find that even our performance is hit, we find the 
network is responding to pings at maybe 60+ms.  Our network guys invariably say 
that the network is running fine ...

So it appears that Remedy, or at least the applications we're running, are 
incredibly sensitive to network performance.  Any suggestions from the list as 
to what we can do to improve performance?

Regards

Dave


This e-mail has been scanned for viruses by the Cable & Wireless e-mail 
security system - powered by MessageLabs. For more information on a proactive 
managed e-mail security service, visit http://www.cw.com/uk/emailprotection/

The information contained in this e-mail is confidential and may also be 
subject to legal privilege. It is intended only for the recipient(s) named 
above. If you are not named above as a recipient, you must not read, copy, 
disclose, forward or otherwise use the information contained in this email. If 
you have received this e-mail in error, please notify the sender (whose contact 
details are above) immediately by reply e-mail and delete the message and any 
attachments without retaining any copies.

Cable and Wireless plc
Registered in England and Wales.Company Number 238525
Registered office: 3rd Floor, 26 Red Lion Square, London WC1R 4HQ
__Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" html___

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

This e-mail has been scanned for viruses by the Cable & Wireless e-mail 
security system - p

Re: Remedy - sensitive to network performance?

[Howard Richter]

David,

That sounds about right on the load (but with out knowing the number of
users and tickets created per day that is a guess).

You could go olld school to pin down the issue. Have one of your remote
users (that see the slow down) with you at the same time and do the same
functions and time them. Do it at peak times as well as non-peak.
Also have your network admin on the phone.

hbr


On 6/26/08, Barber, David <[EMAIL PROTECTED]> wrote:
>
> Sorry ...
>
> Clients are all running on v7.0.01 user tool.  No mid tier in use.
> AR Server is running on Win2k3, 8 procssors
> Database is running sql server on similar hardware/OS to the AR Server
>
> The server/database are very close to each other.  Based in a data center
> somewhere very remote from us in head office.  Invariably here at head
> office performance is fine, its other users who generally have problems.
>
> From the experience and tests we've done it does appear to be sensitive to
> network performance.  Although having said that AR Server load is around
> 20-25%, SQL Server normally 90+% load.
>
> Regards
>
> Dave
>
> -Original Message-
> From: Action Request System discussion list(ARSList)
> [mailto:[EMAIL PROTECTED] Behalf Of William Rentfrow
> Sent: 26 June 2008 15:06
> To: arslist@ARSLIST.ORG
> Subject: Re: Remedy - sensitive to network performance?
>
>
> Can you give us more information about your setup?  Database type, server
> OS, web server type, etc?
>
> I assume you are using 1 AR Server connected to a local (relative to the
> server) database.
>
> You did not mention whether or not you are using the Web or Windows clients
> either.
>
> William Rentfrow
> Principal Consultant, StrataCom
> [EMAIL PROTECTED]
> O 952-432-0227
> C 701-306-6157
>
> 
>
> From: Action Request System discussion list(ARSList) on behalf of Barber,
> David
> Sent: Thu 6/26/2008 8:11 AM
> To: arslist@ARSLIST.ORG
> Subject: Remedy - sensitive to network performance?
>
>
> **
>
> Hi,
>
> Has anyone experienced end-user performance problems with Remedy over
> larger networks?
>
> We're running a suite of bespoke applications, and are finding that some
> tasks such as opening/updating incidents can take orders of magnitude longer
> in some locations.  For example it can take me 8 seconds, but a colleague at
> another location 2 or 3 minutes.
>
> Have been able to do some local benchmarks - typical ping responses are
> circa 10ms, but at points when we find that even our performance is hit, we
> find the network is responding to pings at maybe 60+ms.  Our network guys
> invariably say that the network is running fine ...
>
> So it appears that Remedy, or at least the applications we're running, are
> incredibly sensitive to network performance.  Any suggestions from the list
> as to what we can do to improve performance?
>
> Regards
>
> Dave
>
>
> This e-mail has been scanned for viruses by the Cable & Wireless e-mail
> security system - powered by MessageLabs. For more information on a
> proactive managed e-mail security service, visit
> http://www.cw.com/uk/emailprotection/
>
> The information contained in this e-mail is confidential and may also be
> subject to legal privilege. It is intended only for the recipient(s) named
> above. If you are not named above as a recipient, you must not read, copy,
> disclose, forward or otherwise use the information contained in this email.
> If you have received this e-mail in error, please notify the sender (whose
> contact details are above) immediately by reply e-mail and delete the
> message and any attachments without retaining any copies.
>
> Cable and Wireless plc
> Registered in England and Wales.Company Number 238525
> Registered office: 3rd Floor, 26 Red Lion Square, London WC1R 4HQ
> __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
> html___
>
>
> ___
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
>
> This e-mail has been scanned for viruses by the Cable & Wireless e-mail
> security system - powered by MessageLabs. For more information on a
> proactive managed e-mail security service, visit
> http://www.cw.com/uk/emailprotection/
>
> The information contained in this e-mail is confidential and may also be
> subject to legal privilege. It is intended only for the recipient(s) named
> above. If you are not named above as a recipient, you must not read, copy,
> disclose, forward or otherwise use the information conta

Re: Remedy - sensitive to network performance?

[Barber, David]

About 750 users .
 
dba reckons there's nothing to be done at that end, but to be honest I can't 
see it being a database issue.  Its the fact that the same task, performed at 
the same time, at two different locations, has a mahoosive difference in time 
taken.
 
And yes, new hardware is coming in "soon", but I'm just trying to get 
information to further investigate the problems, I get a feeling it'll still 
happen on the new hardware, just maybe not so pronounced.
 
Regards

Dave

-Original Message-
From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] 
Behalf Of Howard Richter
Sent: 26 June 2008 15:19
To: arslist@ARSLIST.ORG
Subject: Re: Remedy - sensitive to network performance?


** 
There are so many reasons for slow responce other then networks, however as 
William said, we need more info.
 
To add to his list, is ther a difference between the client and web? How many 
users? Has your dba looked at the database and the server its runing on? Have 
you turned on logging?
 
Lots and lots of questions,
 
Hbr

 
On 6/26/08, William Rentfrow < [EMAIL PROTECTED]> wrote: 

Can you give us more information about your setup?  Database type, server OS, 
web server type, etc?

I assume you are using 1 AR Server connected to a local (relative to the 
server) database.

You did not mention whether or not you are using the Web or Windows clients 
either.

William Rentfrow
Principal Consultant, StrataCom
[EMAIL PROTECTED]
O 952-432-0227
C 701-306-6157



From: Action Request System discussion list(ARSList) on behalf of Barber, David
Sent: Thu 6/26/2008 8:11 AM
To: arslist@ARSLIST.ORG
Subject: Remedy - sensitive to network performance?


**

Hi,

Has anyone experienced end-user performance problems with Remedy over larger 
networks?

We're running a suite of bespoke applications, and are finding that some tasks 
such as opening/updating incidents can take orders of magnitude longer in some 
locations.  For example it can take me 8 seconds, but a colleague at another 
location 2 or 3 minutes.

Have been able to do some local benchmarks - typical ping responses are circa 
10ms, but at points when we find that even our performance is hit, we find the 
network is responding to pings at maybe 60+ms.  Our network guys invariably say 
that the network is running fine ...

So it appears that Remedy, or at least the applications we're running, are 
incredibly sensitive to network performance.  Any suggestions from the list as 
to what we can do to improve performance?

Regards

Dave


This e-mail has been scanned for viruses by the Cable & Wireless e-mail 
security system - powered by MessageLabs. For more information on a proactive 
managed e-mail security service, visit http://www.cw.com/uk/emailprotection/

The information contained in this e-mail is confidential and may also be 
subject to legal privilege. It is intended only for the recipient(s) named 
above. If you are not named above as a recipient, you must not read, copy, 
disclose, forward or otherwise use the information contained in this email. If 
you have received this e-mail in error, please notify the sender (whose contact 
details are above) immediately by reply e-mail and delete the message and any 
attachments without retaining any copies.

Cable and Wireless plc
Registered in England and Wales.Company Number 238525
Registered office: 3rd Floor, 26 Red Lion Square, London WC1R 4HQ
__Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" html___

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"





-- 
Howard Richter
Red Hat Certified Technician
CompTIA Linux+ Certified
ITIL Foundation Certified 
E-Mail = [EMAIL PROTECTED]
LinkedIn Profile = http://www.linkedin.com/in/hbr4270 __Platinum Sponsor: 
www.rmsportal.com ARSlist: "Where the Answers Are" html___ 


This e-mail has been scanned for viruses by the Cable & Wireless e-mail 
security system - powered by MessageLabs. For more information on a proactive 
managed e-mail security service, visit http://www.cw.com/uk/emailprotection/ 

The information contained in this e-mail is confidential and may also be 
subject to legal privilege. It is intended only for the recipient(s) named 
above. If you are not named above as a recipient, you must not read, copy, 
disclose, forward or otherwise use the information contained in this email. If 
you have received this e-mail in error, please notify the sender (whose contact 
details are above) immediately by reply e-mail and delete the message and any 
attachments without retaining any copies.
 
Cable and Wireless plc 
Registered in England and Wales.Comp

Re: Remedy - sensitive to network performance?

[Howard Richter]

There are so many reasons for slow responce other then networks, however
as William said, we need more info.

To add to his list, is ther a difference between the client and web? How
many users? Has your dba looked at the database and the server its runing
on? Have you turned on logging?

Lots and lots of questions,

Hbr


On 6/26/08, William Rentfrow <[EMAIL PROTECTED]> wrote:
>
> Can you give us more information about your setup?  Database type, server
> OS, web server type, etc?
>
> I assume you are using 1 AR Server connected to a local (relative to the
> server) database.
>
> You did not mention whether or not you are using the Web or Windows clients
> either.
>
> William Rentfrow
> Principal Consultant, StrataCom
> [EMAIL PROTECTED]
> O 952-432-0227
> C 701-306-6157
>
> 
>
> From: Action Request System discussion list(ARSList) on behalf of Barber,
> David
> Sent: Thu 6/26/2008 8:11 AM
> To: arslist@ARSLIST.ORG
> Subject: Remedy - sensitive to network performance?
>
>
> **
>
> Hi,
>
> Has anyone experienced end-user performance problems with Remedy over
> larger networks?
>
> We're running a suite of bespoke applications, and are finding that some
> tasks such as opening/updating incidents can take orders of magnitude longer
> in some locations.  For example it can take me 8 seconds, but a colleague at
> another location 2 or 3 minutes.
>
> Have been able to do some local benchmarks - typical ping responses are
> circa 10ms, but at points when we find that even our performance is hit, we
> find the network is responding to pings at maybe 60+ms.  Our network guys
> invariably say that the network is running fine ...
>
> So it appears that Remedy, or at least the applications we're running, are
> incredibly sensitive to network performance.  Any suggestions from the list
> as to what we can do to improve performance?
>
> Regards
>
> Dave
>
>
> This e-mail has been scanned for viruses by the Cable & Wireless e-mail
> security system - powered by MessageLabs. For more information on a
> proactive managed e-mail security service, visit
> http://www.cw.com/uk/emailprotection/
>
> The information contained in this e-mail is confidential and may also be
> subject to legal privilege. It is intended only for the recipient(s) named
> above. If you are not named above as a recipient, you must not read, copy,
> disclose, forward or otherwise use the information contained in this email.
> If you have received this e-mail in error, please notify the sender (whose
> contact details are above) immediately by reply e-mail and delete the
> message and any attachments without retaining any copies.
>
> Cable and Wireless plc
> Registered in England and Wales.Company Number 238525
> Registered office: 3rd Floor, 26 Red Lion Square, London WC1R 4HQ
> __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
> html___
>
>
> ___
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
>



-- 
Howard Richter
Red Hat Certified Technician
CompTIA Linux+ Certified
ITIL Foundation Certified
E-Mail = [EMAIL PROTECTED]
LinkedIn Profile = http://www.linkedin.com/in/hbr4270

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

Re: Remedy - sensitive to network performance?

[Barber, David]

Sorry ...

Clients are all running on v7.0.01 user tool.  No mid tier in use.
AR Server is running on Win2k3, 8 procssors
Database is running sql server on similar hardware/OS to the AR Server

The server/database are very close to each other.  Based in a data center 
somewhere very remote from us in head office.  Invariably here at head office 
performance is fine, its other users who generally have problems.

From the experience and tests we've done it does appear to be sensitive to 
network performance.  Although having said that AR Server load is around 
20-25%, SQL Server normally 90+% load.

Regards

Dave

-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] Behalf Of William Rentfrow
Sent: 26 June 2008 15:06
To: arslist@ARSLIST.ORG
Subject: Re: Remedy - sensitive to network performance?


Can you give us more information about your setup?  Database type, server OS, 
web server type, etc?
 
I assume you are using 1 AR Server connected to a local (relative to the 
server) database.
 
You did not mention whether or not you are using the Web or Windows clients 
either.  
 
William Rentfrow
Principal Consultant, StrataCom
[EMAIL PROTECTED]
O 952-432-0227
C 701-306-6157



From: Action Request System discussion list(ARSList) on behalf of Barber, David
Sent: Thu 6/26/2008 8:11 AM
To: arslist@ARSLIST.ORG
Subject: Remedy - sensitive to network performance?


** 

Hi, 

Has anyone experienced end-user performance problems with Remedy over larger 
networks? 

We're running a suite of bespoke applications, and are finding that some tasks 
such as opening/updating incidents can take orders of magnitude longer in some 
locations.  For example it can take me 8 seconds, but a colleague at another 
location 2 or 3 minutes.

Have been able to do some local benchmarks - typical ping responses are circa 
10ms, but at points when we find that even our performance is hit, we find the 
network is responding to pings at maybe 60+ms.  Our network guys invariably say 
that the network is running fine ...

So it appears that Remedy, or at least the applications we're running, are 
incredibly sensitive to network performance.  Any suggestions from the list as 
to what we can do to improve performance?

Regards 

Dave 


This e-mail has been scanned for viruses by the Cable & Wireless e-mail 
security system - powered by MessageLabs. For more information on a proactive 
managed e-mail security service, visit http://www.cw.com/uk/emailprotection/ 

The information contained in this e-mail is confidential and may also be 
subject to legal privilege. It is intended only for the recipient(s) named 
above. If you are not named above as a recipient, you must not read, copy, 
disclose, forward or otherwise use the information contained in this email. If 
you have received this e-mail in error, please notify the sender (whose contact 
details are above) immediately by reply e-mail and delete the message and any 
attachments without retaining any copies.

Cable and Wireless plc 
Registered in England and Wales.Company Number 238525 
Registered office: 3rd Floor, 26 Red Lion Square, London WC1R 4HQ
__Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" html___

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

This e-mail has been scanned for viruses by the Cable & Wireless e-mail 
security system - powered by MessageLabs. For more information on a proactive 
managed e-mail security service, visit http://www.cw.com/uk/emailprotection/ 

The information contained in this e-mail is confidential and may also be 
subject to legal privilege. It is intended only for the recipient(s) named 
above. If you are not named above as a recipient, you must not read, copy, 
disclose, forward or otherwise use the information contained in this email. If 
you have received this e-mail in error, please notify the sender (whose contact 
details are above) immediately by reply e-mail and delete the message and any 
attachments without retaining any copies.
 
Cable and Wireless plc 
Registered in England and Wales.Company Number 238525 
Registered office: 3rd Floor, 26 Red Lion Square, London WC1R 4HQ

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

Re: Remedy - sensitive to network performance?

[William Rentfrow]

Can you give us more information about your setup?  Database type, server OS, 
web server type, etc?
 
I assume you are using 1 AR Server connected to a local (relative to the 
server) database.
 
You did not mention whether or not you are using the Web or Windows clients 
either.  
 
William Rentfrow
Principal Consultant, StrataCom
[EMAIL PROTECTED]
O 952-432-0227
C 701-306-6157



From: Action Request System discussion list(ARSList) on behalf of Barber, David
Sent: Thu 6/26/2008 8:11 AM
To: arslist@ARSLIST.ORG
Subject: Remedy - sensitive to network performance?


** 

Hi, 

Has anyone experienced end-user performance problems with Remedy over larger 
networks? 

We're running a suite of bespoke applications, and are finding that some tasks 
such as opening/updating incidents can take orders of magnitude longer in some 
locations.  For example it can take me 8 seconds, but a colleague at another 
location 2 or 3 minutes.

Have been able to do some local benchmarks - typical ping responses are circa 
10ms, but at points when we find that even our performance is hit, we find the 
network is responding to pings at maybe 60+ms.  Our network guys invariably say 
that the network is running fine ...

So it appears that Remedy, or at least the applications we're running, are 
incredibly sensitive to network performance.  Any suggestions from the list as 
to what we can do to improve performance?

Regards 

Dave 


This e-mail has been scanned for viruses by the Cable & Wireless e-mail 
security system - powered by MessageLabs. For more information on a proactive 
managed e-mail security service, visit http://www.cw.com/uk/emailprotection/ 

The information contained in this e-mail is confidential and may also be 
subject to legal privilege. It is intended only for the recipient(s) named 
above. If you are not named above as a recipient, you must not read, copy, 
disclose, forward or otherwise use the information contained in this email. If 
you have received this e-mail in error, please notify the sender (whose contact 
details are above) immediately by reply e-mail and delete the message and any 
attachments without retaining any copies.

Cable and Wireless plc 
Registered in England and Wales.Company Number 238525 
Registered office: 3rd Floor, 26 Red Lion Square, London WC1R 4HQ
__Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" html___

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

Remedy - sensitive to network performance?

[Barber, David]

Hi,

Has anyone experienced end-user performance problems with Remedy over larger 
networks?

We're running a suite of bespoke applications, and are finding that some tasks 
such as opening/updating incidents can take orders of magnitude longer in some 
locations.  For example it can take me 8 seconds, but a colleague at another 
location 2 or 3 minutes.

Have been able to do some local benchmarks - typical ping responses are circa 
10ms, but at points when we find that even our performance is hit, we find the 
network is responding to pings at maybe 60+ms.  Our network guys invariably say 
that the network is running fine ...

So it appears that Remedy, or at least the applications we're running, are 
incredibly sensitive to network performance.  Any suggestions from the list as 
to what we can do to improve performance?

Regards

Dave

This e-mail has been scanned for viruses by the Cable & Wireless e-mail 
security system - powered by MessageLabs. For more information on a proactive 
managed e-mail security service, visit http://www.cw.com/uk/emailprotection/ 

The information contained in this e-mail is confidential and may also be 
subject to legal privilege. It is intended only for the recipient(s) named 
above. If you are not named above as a recipient, you must not read, copy, 
disclose, forward or otherwise use the information contained in this email. If 
you have received this e-mail in error, please notify the sender (whose contact 
details are above) immediately by reply e-mail and delete the message and any 
attachments without retaining any copies.
 
Cable and Wireless plc 
Registered in England and Wales.Company Number 238525 
Registered office: 3rd Floor, 26 Red Lion Square, London WC1R 4HQ

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"