GAD performance degrades over time

[JTL]

An interesting one this...

A relatively basic (and Outbound only, no multimedia) GAD installation currently in testing. The server is way overspecced, but screenpopping is taking too long.

It starts off relatively quick, but performance degrades over time.

Until today, it was running straight onto Tomcat - but this morning I went through the deployment guide steps to introduce Apache to serve the pages, and to tune the server.

Using Fiddler also shows that the compression is on and working to the client PC, but behaviour is pretty much the same.

Why would GAD screenpop performance degrade over time (just a few interactions) and what can I do about it!?

[alistairt]

Which browser are you using - IE? If so which version?

I've seen a similar problem which was caused by a bug in IE. It is easily spotted as the memory used by IE increases dramatically with each interaction.

Microsoft have patched this (a while ago). Might be worth applying Microsoft updates - if this is straightforward - otherwise I'll try to find details of the specific patch.

[JTL]

Ah... now that might be something.

Customer has a really ancient version of IE6 which, unfortunately, I can do nothing about since they need it for a legacy app.

I will get some tests done with a different browser though to see if we can pinpoint whether that's the issue or not.

[alistairt]

This is the entry in the Genesys Release Note (GAD 7.6) Known Issues section. It is a little cryptic but is the same issue as I experienced previously with Outbound:

Agent: For Microsoft Internet Explorer (IE) 6 with Windows 2000 users, a memory leak occurs in the process that renders Genesys Desktop in IE 6 windows. This causes the operation of Genesys Desktop and other applications to slow down, resulting in longer response times and other possible malfunctions. The impact is very limited when running voice interactions without Universal Contact Server (UCS), but is more apparent with complex interfaces such as e-mail and voice with UCS. (ER# 177933865)

Microsoft has reported that the memory leak occurs in Internet Explorer 6 when working with JScript rich applications such as Genesys Desktop. More information can be found in the Microsoft Knowledge Base article 929874: http://support.microsoft.com/kb/929874

To avoid any issue with Internet Explorer 6 on Windows XP ensure that you employ at least Cumulative Security Update for Internet Explorer MS07-033: http://support.microsoft.com/kb/933566

To avoid any issue with Internet Explorer 6 on Windows 2003 ensure that you employ at least Cumulative Security Update for Internet Explorer MS08-010: http://support.microsoft.com/kb/944533

Workaround: Agents should periodically log out from Genesys Desktop and then log in again. This will close the Internet Explorer instance and create a new one, resetting the consumed memory. The interval that you should wait before you should log in again depends on your environment, such as the installed physical memory, and the number of interactions that the agent has handled.

[Gulden_NL]

[quote author=alistairt link=topic=5171.msg22891#msg22891 date=1266835694]
This is the entry in the Genesys Release Note (GAD 7.6) Known Issues section. It is a little cryptic but is the same issue as I experienced previously with Outbound:

Agent: For Microsoft Internet Explorer (IE) 6 with Windows 2000 users, a memory leak occurs in the process that renders Genesys Desktop in IE 6 windows. This causes the operation of Genesys Desktop and other applications to slow down, resulting in longer response times and other possible malfunctions. [/quote]

LOL - I was reading down the post listings and ready to respond..... your post is correct about this issue.

I ran into this with a client 18 months ago.  Why oh why do major corporations sometimes insist on running crap in their enterprises?

JTL - What version of IE (down to the .version level) and OS with Service Pack are you running?

[JTL]

alistairt and Guilden_NL are absolutely spot-on. Thanks guys.

The customer was running 6.0.2900.2180.xpsp_sp2_gdr.050301-1519 which they have now patched, and the screenpop has stabilised at approx 2 seconds.

They are required to use IE6 because of a legacy app / system which needs to retain compatibility.