Re: Server Performance Issues??
- for completion of a call + for start of a call Axton Grams On 8/30/07, David Sanders <[EMAIL PROTECTED]> wrote: > Hi Misi and Axton > > Thanks for the feedback. Yes, that was my suspicion (and hope) that arwklga > was wrong. Arwklga was claiming that these process calls are taking 2 > minutes to complete, but as far as I could see the +EXECAL to -EXECAL OK is > completed quickly. > > I had 2 theories: > > 1) that the thread is actually idle and waiting for 2 minutes, or > > 2) that the @@:Application-Generate-GUID process is kicked off, the -EXECAL > OK is returned immediately, but it is taking a further 2 minutes to return > the result of the process. > > So the real question is, does the -EXECAL OK indicate that the process call > has been started successfully, or completed successfully? > > Axton - I'll see if I can get some AL/Filter logs when this happens to > compare with the API logs - that might answer the above question. > > Regards... Dave > > David Sanders > Remedy Solution Architect > Enterprise Service Suite @ Work > == > ARS List Award Winner 2005 > Best 3rd party Remedy Application > > See the ESS Concepts Guide > > tel +44 1494 468980 > mobile +44 7710 377761 > email [EMAIL PROTECTED] > > web http://www.westoverconsulting.co.uk > > -Original Message- > From: Action Request System discussion list(ARSList) > [mailto:[EMAIL PROTECTED] On Behalf Of Misi Mladoniczky > Sent: Thursday, August 30, 2007 7:04 PM > To: arslist@ARSLIST.ORG > Subject: Re: Server Performance Issues?? > > Hi David, > > The detailed log rows does not show that the API-call is taking much time. > There is a wait-time in between the calls, but... > > If you look at the RPC ID, you see a jump from 0016990986 to 0016991463, > so the server has performed 477 API-calls between these calls. They may > have been thread executed by other threads. > > Could arwklga have missinformed you? > > Best Regards - Misi, RRR AB, http://www.rrr.se > > Products from RRR Scandinavia: > * RRR|License - Not enough Remedy licenses? Save money by optimizing. > * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs. > * RRR|Translator - Manage and automate your language translations. > Find these products, and many free tools and utilities, at http://rrr.se. > > > Hi List > > > > I wonder whether anyone has come across a situation like this and can > > throw > > any light on what might be causing these performance issues. > > > > ARS Server 6.03.00 patch 013 > > SunOS 5.10 > > Oracle 9.2.0.5.0 64bit on remote machine (shared with other apps) > > > > Running arwklga against combined API+SQL logs throws up several lines like > > this: > > > > 2:40.5023 205245 actlink_set Wed Aug 29 2007 13:43:24.9652 > > SELECT assignShort,assignLong FROM actlink_set WHERE actlinkId = 6881 AND > > actionIndex = 0 AND fieldId = 1077077 > > > > 2:23.4299 191087 actlink_set Wed Aug 29 2007 13:32:39.6091 > > SELECT assignShort,assignLong FROM actlink_set WHERE actlinkId = 6881 AND > > actionIndex = 0 AND fieldId = 1077077 > > > > Looking at one of these in detail gives > > > > 205243API 0016990986 List390620 lp2d06 Wed Aug 29 > 2007 > > 13:43:24.9636 > > +EXECAL ARExecuteProcessForActiveLink from Remedy User (protocol 11) at IP > > address 152.78.134.145 > > > > 205244SQL 0016990986 List390620 lp2d06 Wed Aug 29 > 2007 > > 13:43:24.9638 > > SELECT actlinkId from actlink where name = 'RPQ:SHR-Lock0' > > > > 205245SQL 0016990986 List390620 lp2d06 Wed Aug 29 > 2007 > > 13:43:24.9652 > > SELECT assignShort,assignLong FROM actlink_set WHERE actlinkId = 6881 AND > > actionIndex = 0 AND fieldId = 1077077 > > > > 205246API 0016990986 List390620 lp2d06 Wed Aug 29 > 2007 > > 13:43:24.9668 > > -EXECAL OK > > > > 208592API 0016991463 List390620 lai Wed Aug 29 > 2007 > > 13:46:05.4660 > > +GLE ARGetListEntry -- schema RPQ:Log from Remedy User > > > > 208593SQL 0016991463 List390620 lai Wed Aug 29 > 2007 > > 13:46:05.4675 > > SELECT T201.C1,C8,C700037500,C700037000,C700034003,C73000 FROM T201 > > WHERE . > > > > That is, these set fields actions seem to be taking a couple of minutes to > > complete. Looking at the objects involved, they are doing > > @@:Application-Generate-GUID or @@:Application-Confirm-Gro
Re: Server Performance Issues??
Hi Misi and Axton Thanks for the feedback. Yes, that was my suspicion (and hope) that arwklga was wrong. Arwklga was claiming that these process calls are taking 2 minutes to complete, but as far as I could see the +EXECAL to -EXECAL OK is completed quickly. I had 2 theories: 1) that the thread is actually idle and waiting for 2 minutes, or 2) that the @@:Application-Generate-GUID process is kicked off, the -EXECAL OK is returned immediately, but it is taking a further 2 minutes to return the result of the process. So the real question is, does the -EXECAL OK indicate that the process call has been started successfully, or completed successfully? Axton - I'll see if I can get some AL/Filter logs when this happens to compare with the API logs - that might answer the above question. Regards... Dave David Sanders Remedy Solution Architect Enterprise Service Suite @ Work == ARS List Award Winner 2005 Best 3rd party Remedy Application See the ESS Concepts Guide tel +44 1494 468980 mobile +44 7710 377761 email [EMAIL PROTECTED] web http://www.westoverconsulting.co.uk -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Misi Mladoniczky Sent: Thursday, August 30, 2007 7:04 PM To: arslist@ARSLIST.ORG Subject: Re: Server Performance Issues?? Hi David, The detailed log rows does not show that the API-call is taking much time. There is a wait-time in between the calls, but... If you look at the RPC ID, you see a jump from 0016990986 to 0016991463, so the server has performed 477 API-calls between these calls. They may have been thread executed by other threads. Could arwklga have missinformed you? Best Regards - Misi, RRR AB, http://www.rrr.se Products from RRR Scandinavia: * RRR|License - Not enough Remedy licenses? Save money by optimizing. * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs. * RRR|Translator - Manage and automate your language translations. Find these products, and many free tools and utilities, at http://rrr.se. > Hi List > > I wonder whether anyone has come across a situation like this and can > throw > any light on what might be causing these performance issues. > > ARS Server 6.03.00 patch 013 > SunOS 5.10 > Oracle 9.2.0.5.0 64bit on remote machine (shared with other apps) > > Running arwklga against combined API+SQL logs throws up several lines like > this: > > 2:40.5023 205245 actlink_set Wed Aug 29 2007 13:43:24.9652 > SELECT assignShort,assignLong FROM actlink_set WHERE actlinkId = 6881 AND > actionIndex = 0 AND fieldId = 1077077 > > 2:23.4299 191087 actlink_set Wed Aug 29 2007 13:32:39.6091 > SELECT assignShort,assignLong FROM actlink_set WHERE actlinkId = 6881 AND > actionIndex = 0 AND fieldId = 1077077 > > Looking at one of these in detail gives > > 205243API 0016990986 List390620 lp2d06 Wed Aug 29 2007 > 13:43:24.9636 > +EXECAL ARExecuteProcessForActiveLink from Remedy User (protocol 11) at IP > address 152.78.134.145 > > 205244SQL 0016990986 List390620 lp2d06 Wed Aug 29 2007 > 13:43:24.9638 > SELECT actlinkId from actlink where name = 'RPQ:SHR-Lock0' > > 205245SQL 0016990986 List390620 lp2d06 Wed Aug 29 2007 > 13:43:24.9652 > SELECT assignShort,assignLong FROM actlink_set WHERE actlinkId = 6881 AND > actionIndex = 0 AND fieldId = 1077077 > > 205246API 0016990986 List390620 lp2d06 Wed Aug 29 2007 > 13:43:24.9668 > -EXECAL OK > > 208592API 0016991463 List390620 lai Wed Aug 29 2007 > 13:46:05.4660 > +GLE ARGetListEntry -- schema RPQ:Log from Remedy User > > 208593SQL 0016991463 List390620 lai Wed Aug 29 2007 > 13:46:05.4675 > SELECT T201.C1,C8,C700037500,C700037000,C700034003,C73000 FROM T201 > WHERE . > > That is, these set fields actions seem to be taking a couple of minutes to > complete. Looking at the objects involved, they are doing > @@:Application-Generate-GUID or @@:Application-Confirm-Group processes. > The > +EXECAL to -EXECAL OK is quick, but the thread then does nothing for 2 > mins > 39 secs before the next action from another user. > > Is arwkloga misleading me when it says the actlink_set is taking 2 mins > 40s > - is there an issue with the PROCESS actions? - or is the thread just > idle? > > Does anyone know what might take an Application-Generate-GUID process over > 2 > minutes to complete? As far as I can see, list and fast threads usage are > OK and the system is not waiting for a thread. > > Thanks for any advice > > David Sanders > Remedy Solution Architect > Enterprise Service Suite @ Work >
Re: Server Performance Issues??
Hi David, The detailed log rows does not show that the API-call is taking much time. There is a wait-time in between the calls, but... If you look at the RPC ID, you see a jump from 0016990986 to 0016991463, so the server has performed 477 API-calls between these calls. They may have been thread executed by other threads. Could arwklga have missinformed you? Best Regards - Misi, RRR AB, http://www.rrr.se Products from RRR Scandinavia: * RRR|License - Not enough Remedy licenses? Save money by optimizing. * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs. * RRR|Translator - Manage and automate your language translations. Find these products, and many free tools and utilities, at http://rrr.se. > Hi List > > I wonder whether anyone has come across a situation like this and can > throw > any light on what might be causing these performance issues. > > ARS Server 6.03.00 patch 013 > SunOS 5.10 > Oracle 9.2.0.5.0 64bit on remote machine (shared with other apps) > > Running arwklga against combined API+SQL logs throws up several lines like > this: > > 2:40.5023 205245 actlink_set Wed Aug 29 2007 13:43:24.9652 > SELECT assignShort,assignLong FROM actlink_set WHERE actlinkId = 6881 AND > actionIndex = 0 AND fieldId = 1077077 > > 2:23.4299 191087 actlink_set Wed Aug 29 2007 13:32:39.6091 > SELECT assignShort,assignLong FROM actlink_set WHERE actlinkId = 6881 AND > actionIndex = 0 AND fieldId = 1077077 > > Looking at one of these in detail gives > > 205243API 0016990986 List390620 lp2d06 Wed Aug 29 2007 > 13:43:24.9636 > +EXECAL ARExecuteProcessForActiveLink from Remedy User (protocol 11) at IP > address 152.78.134.145 > > 205244SQL 0016990986 List390620 lp2d06 Wed Aug 29 2007 > 13:43:24.9638 > SELECT actlinkId from actlink where name = 'RPQ:SHR-Lock0' > > 205245SQL 0016990986 List390620 lp2d06 Wed Aug 29 2007 > 13:43:24.9652 > SELECT assignShort,assignLong FROM actlink_set WHERE actlinkId = 6881 AND > actionIndex = 0 AND fieldId = 1077077 > > 205246API 0016990986 List390620 lp2d06 Wed Aug 29 2007 > 13:43:24.9668 > -EXECAL OK > > 208592API 0016991463 List390620 lai Wed Aug 29 2007 > 13:46:05.4660 > +GLE ARGetListEntry -- schema RPQ:Log from Remedy User > > 208593SQL 0016991463 List390620 lai Wed Aug 29 2007 > 13:46:05.4675 > SELECT T201.C1,C8,C700037500,C700037000,C700034003,C73000 FROM T201 > WHERE > > That is, these set fields actions seem to be taking a couple of minutes to > complete. Looking at the objects involved, they are doing > @@:Application-Generate-GUID or @@:Application-Confirm-Group processes. > The > +EXECAL to EXECAL OK is quick, but the thread then does nothing for 2 > mins > 39 secs before the next action from another user. > > Is arwkloga misleading me when it says the actlink_set is taking 2 mins > 40s > is there an issue with the PROCESS actions? or is the thread just > idle? > > Does anyone know what might take an Application-Generate-GUID process over > 2 > minutes to complete? As far as I can see, list and fast threads usage are > OK and the system is not waiting for a thread. > > Thanks for any advice > > David Sanders > Remedy Solution Architect > Enterprise Service Suite @ Work > == > ARS List Award Winner 2005 > Best 3rd party Remedy Application > > See the ESS Concepts Guide > > tel +44 1494 468980 > mobile +44 7710 377761 > email [EMAIL PROTECTED] > > web http://www.westoverconsulting.co.uk > > > > ___ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where > the Answers Are" > ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
Re: Server Performance Issues??
The pause is between api calls: 13:43:24.9668 -EXECAL OK ... 13:46:05.4660 +GLE ARGetListEntry -- schema RPQ:Log from Remedy User There is maybe something else that is causing the wait time? If you run AL and Filter logs, where do you see the pause? Axton Grams On 8/30/07, David Sanders <[EMAIL PROTECTED]> wrote: > Hi List > > I wonder whether anyone has come across a situation like this and can throw > any light on what might be causing these performance issues. > > ARS Server 6.03.00 patch 013 > SunOS 5.10 > Oracle 9.2.0.5.0 64bit on remote machine (shared with other apps) > > Running arwklga against combined API+SQL logs throws up several lines like > this: > > 2:40.5023 205245 actlink_set Wed Aug 29 2007 13:43:24.9652 > SELECT assignShort,assignLong FROM actlink_set WHERE actlinkId = 6881 AND > actionIndex = 0 AND fieldId = 1077077 > > 2:23.4299 191087 actlink_set Wed Aug 29 2007 13:32:39.6091 > SELECT assignShort,assignLong FROM actlink_set WHERE actlinkId = 6881 AND > actionIndex = 0 AND fieldId = 1077077 > > Looking at one of these in detail gives > > 205243 API 0016990986 List390620 lp2d06 Wed Aug 29 2007 > 13:43:24.9636 > +EXECAL ARExecuteProcessForActiveLink from Remedy User (protocol 11) at IP > address 152.78.134.145 > > 205244 SQL 0016990986 List390620 lp2d06 Wed Aug 29 2007 > 13:43:24.9638 > SELECT actlinkId from actlink where name = 'RPQ:SHR-Lock0' > > 205245 SQL 0016990986 List390620 lp2d06 Wed Aug 29 2007 > 13:43:24.9652 > SELECT assignShort,assignLong FROM actlink_set WHERE actlinkId = 6881 AND > actionIndex = 0 AND fieldId = 1077077 > > 205246 API 0016990986 List390620 lp2d06 Wed Aug 29 2007 > 13:43:24.9668 > -EXECAL OK > > 208592 API 0016991463 List390620 lai Wed Aug 29 2007 > 13:46:05.4660 > +GLE ARGetListEntry -- schema RPQ:Log from Remedy User > > 208593 SQL 0016991463 List390620 lai Wed Aug 29 2007 > 13:46:05.4675 > SELECT T201.C1,C8,C700037500,C700037000,C700034003,C73000 FROM T201 > WHERE … > > That is, these set fields actions seem to be taking a couple of minutes to > complete. Looking at the objects involved, they are doing > @@:Application-Generate-GUID or @@:Application-Confirm-Group processes. The > +EXECAL to –EXECAL OK is quick, but the thread then does nothing for 2 mins > 39 secs before the next action from another user. > > Is arwkloga misleading me when it says the actlink_set is taking 2 mins 40s > – is there an issue with the PROCESS actions? – or is the thread just idle? > > Does anyone know what might take an Application-Generate-GUID process over 2 > minutes to complete? As far as I can see, list and fast threads usage are > OK and the system is not waiting for a thread. > > Thanks for any advice > > David Sanders > Remedy Solution Architect > Enterprise Service Suite @ Work > == > ARS List Award Winner 2005 > Best 3rd party Remedy Application > > See theESS Concepts Guide > > tel +44 1494 468980 > mobile +44 7710 377761 > email [EMAIL PROTECTED] > > web http://www.westoverconsulting.co.uk > > > > ___ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the > Answers Are" > ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
Re: Server performance issues?
** We've only got two active systems : The ARS 5.1.1/Helpdesk 4 Live system (archaic, albeit reliable hardware) The ARS 6.3/Helpdesk 6 test system - this is the one I'm working on. I've just connected to the server via virtual desktop, its running at patch 15. Tried the same thing - doing an export of the defs related to HPD:HelpDesk, and its freezing at the Export all related. I'll check the developer cache; I'd forgotten about that. Still doesn't adequately explain the crabby performance though, especially on much higher spec hardware, with considerably lower loading (the live server handles definition exports quite nicely, regardless of the number of users, always has done, the test server has just 2 users connected at the moment). Ta, Dave On 08/05/06, McKenzie, James J C-E LCMC HQISEC/L3 <[EMAIL PROTECTED]> wrote: ** Rick: I highly recommend turning on and off the Developer Cache mode ONLY when you are working on forms on a production machine (why aren't you working on a dev machine anyhow). If you can get it, take the old production machine and use it as your dev machine. This will allow you to run on a smaller scale to see what effects you will have if you are running a larger production machine with hundreds of users. James McKenzie Remedy Engineer Enterprise Systems Device Management Enterprise Systems Engineering Directorate C-E LCMC ISEC Fort Huachuca, Arizona 85613 Phone: (520) 538-3171 From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Rick Cook Sent: Monday, May 08, 2006 8:39 AM To: arslist@ARSLIST.ORG Subject: Re: Server performance issues? ** Dave, One thing that's a little different about how ARS 6.3 works is that there's more initial caching at the client level to speed up performance in subsequent transactions. This can be controlled to some extent by changing your caching thresholds, and by turning on the Developer Cache Mode for production systems. Mid-Tier is especially susceptible to the caching issue - initial downloads of a large form may take close to a minute. But once that's done, if recaching isn't required, subsequent updates and normal transactions are very quick. Rick From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Dave Barber Sent: Monday, May 08, 2006 8:34 AM To: arslist@ARSLIST.ORG Subject: Server performance issues? ** All, I'm working nicely through the changes required to our test installation of ARS 6.3/Helpdesk 6 (I can't really call it ITSM6 yet), and the server performance isn't looking too good at the moment. When I talk performance, I'm talking about general working in the Admin tool - saving forms/active links and filters, exporting data. It was slow on our old server (Win2k, ARS 5.1.1, Helpdesk 4, running dual 500mHz processors with 1gig of ram), but its definitely slower on the new server (Win2k3, ARS 6.3, Helpdesk 6, running dual 3gig processors with 4gig of ram). Right now I'm trying to do a definitions back of the helpdesk form, and I've been sitting waiting for what feels like an eternity - go the export defs window open, selected HPD:HelpDesk, and I've done a "Add All Related", and its just hanging. Any suggestions where to look on our servers? Have to admit that the Admin tool is unpatched though - does anyone expect that I'd have performance improvements in moving to a later patch? Regards, Dave ps. How to get an ARS 5.1.1 to 6.3/Helpdesk 4 to 6 migration done in less than 2 weeks - I'll tell you by the end of the week, which is my supposed deadline :) __20060125___This posting was submitted with HTML in it___ __20060125___This posting was submitted with HTML in it___ __20060125___This posting was submitted with HTML in it___ __20060125___This posting was submitted with HTML in it___
Re: Server performance issues?
Title: RE: Server performance issues? ** Rick: I highly recommend turning on and off the Developer Cache mode ONLY when you are working on forms on a production machine (why aren't you working on a dev machine anyhow). If you can get it, take the old production machine and use it as your dev machine. This will allow you to run on a smaller scale to see what effects you will have if you are running a larger production machine with hundreds of users. James McKenzie Remedy Engineer Enterprise Systems Device Management Enterprise Systems Engineering Directorate C-E LCMC ISEC Fort Huachuca, Arizona 85613 Phone: (520) 538-3171 From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Rick Cook Sent: Monday, May 08, 2006 8:39 AM To: arslist@ARSLIST.ORG Subject: Re: Server performance issues? ** Dave, One thing that's a little different about how ARS 6.3 works is that there's more initial caching at the client level to speed up performance in subsequent transactions. This can be controlled to some extent by changing your caching thresholds, and by turning on the Developer Cache Mode for production systems. Mid-Tier is especially susceptible to the caching issue - initial downloads of a large form may take close to a minute. But once that's done, if recaching isn't required, subsequent updates and normal transactions are very quick. Rick From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Dave Barber Sent: Monday, May 08, 2006 8:34 AM To: arslist@ARSLIST.ORG Subject: Server performance issues? ** All, I'm working nicely through the changes required to our test installation of ARS 6.3/Helpdesk 6 (I can't really call it ITSM6 yet), and the server performance isn't looking too good at the moment. When I talk performance, I'm talking about general working in the Admin tool - saving forms/active links and filters, exporting data. It was slow on our old server (Win2k, ARS 5.1.1, Helpdesk 4, running dual 500mHz processors with 1gig of ram), but its definitely slower on the new server (Win2k3, ARS 6.3, Helpdesk 6, running dual 3gig processors with 4gig of ram). Right now I'm trying to do a definitions back of the helpdesk form, and I've been sitting waiting for what feels like an eternity - go the export defs window open, selected HPD:HelpDesk, and I've done a "Add All Related", and its just hanging. Any suggestions where to look on our servers? Have to admit that the Admin tool is unpatched though - does anyone expect that I'd have performance improvements in moving to a later patch? Regards, Dave ps. How to get an ARS 5.1.1 to 6.3/Helpdesk 4 to 6 migration done in less than 2 weeks - I'll tell you by the end of the week, which is my supposed deadline :) __20060125___This posting was submitted with HTML in it___ __20060125___This posting was submitted with HTML in it___ __20060125___This posting was submitted with HTML in it___
Re: Server performance issues?
** Dave, One thing that's a little different about how ARS 6.3 works is that there's more initial caching at the client level to speed up performance in subsequent transactions. This can be controlled to some extent by changing your caching thresholds, and by turning on the Developer Cache Mode for production systems. Mid-Tier is especially susceptible to the caching issue - initial downloads of a large form may take close to a minute. But once that's done, if recaching isn't required, subsequent updates and normal transactions are very quick. Rick From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Dave BarberSent: Monday, May 08, 2006 8:34 AMTo: arslist@ARSLIST.ORGSubject: Server performance issues? ** All, I'm working nicely through the changes required to our test installation of ARS 6.3/Helpdesk 6 (I can't really call it ITSM6 yet), and the server performance isn't looking too good at the moment. When I talk performance, I'm talking about general working in the Admin tool - saving forms/active links and filters, exporting data. It was slow on our old server (Win2k, ARS 5.1.1, Helpdesk 4, running dual 500mHz processors with 1gig of ram), but its definitely slower on the new server (Win2k3, ARS 6.3, Helpdesk 6, running dual 3gig processors with 4gig of ram). Right now I'm trying to do a definitions back of the helpdesk form, and I've been sitting waiting for what feels like an eternity - go the export defs window open, selected HPD:HelpDesk, and I've done a "Add All Related", and its just hanging. Any suggestions where to look on our servers? Have to admit that the Admin tool is unpatched though - does anyone expect that I'd have performance improvements in moving to a later patch? Regards, Dave ps. How to get an ARS 5.1.1 to 6.3/Helpdesk 4 to 6 migration done in less than 2 weeks - I'll tell you by the end of the week, which is my supposed deadline :)__20060125___This posting was submitted with HTML in it___ __20060125___This posting was submitted with HTML in it___
Server performance issues?
** All, I'm working nicely through the changes required to our test installation of ARS 6.3/Helpdesk 6 (I can't really call it ITSM6 yet), and the server performance isn't looking too good at the moment. When I talk performance, I'm talking about general working in the Admin tool - saving forms/active links and filters, exporting data. It was slow on our old server (Win2k, ARS 5.1.1, Helpdesk 4, running dual 500mHz processors with 1gig of ram), but its definitely slower on the new server (Win2k3, ARS 6.3, Helpdesk 6, running dual 3gig processors with 4gig of ram). Right now I'm trying to do a definitions back of the helpdesk form, and I've been sitting waiting for what feels like an eternity - go the export defs window open, selected HPD:HelpDesk, and I've done a "Add All Related", and its just hanging. Any suggestions where to look on our servers? Have to admit that the Admin tool is unpatched though - does anyone expect that I'd have performance improvements in moving to a later patch? Regards, Dave ps. How to get an ARS 5.1.1 to 6.3/Helpdesk 4 to 6 migration done in less than 2 weeks - I'll tell you by the end of the week, which is my supposed deadline :) __20060125___This posting was submitted with HTML in it___
