6.0 to 8.0 ... Processes running slower?

[beleyrs]

We have upgraded from 6.0 to 8.0 and are in the midst of user testing. We have about 10 users, all of whom connect through a terminal server which has the 8.0 client install.

they have been complaingin that processes are taking longer. WE have upgraded the GP server to Win2003 and the terminal server is win2000.

Couple examples:

IM in the 6.0 environment processed in say 20 minutes. In 8.0, using the same 6.0 IM drivers, it is taking 40 minutes. Fixed asset depreciation, used to take about 1 hour, now its taking about 2.5 hours.

Are there slow downs that can be attributed to upgrading? If I run IM and FA Depreciation local to the GP server, they are closer to the original run times. However, I noticed that if I monitor CPU, it never goes above about 40%. Is there any place that might be preventing dyna?ics and sql server from taking too much processor?

TIA...

 

[beleyrs]

in addition, would activity tracking be adding a lot of overhead?

 

[jazgeek]

activity tracking is a major hog in terms of processing power. turn off if possible.

did you upgrade to minimum/recommended specs in terms of hardware?



-----------
and they wonder why they call it Great Pains!

jaz

 

[beleyrs]

turned off activity tracking...didn't help the situation much...

yes, we upgraded toward the high end recommendation (win 2003 server, dual xeon, 2GB of RAM). client is installed on win2000. we exepected to atleast match performance of the 6.0 GP system running on NT4! But we are not.

Get this, we can run IM on the server in 8.0 on these great high powered machines, and get about 4 records per second. Go back to 6.0 on NT4, its 18 recs/sec. Fixed Asset depreciation has gone from taking an average of 55 minute to 120 minutes.

Today we epxerimented with changing from TCP/IP ODBC to Named Pipes ODBC, but if antying, the named pipes slowed down the client connection. Didn't have much impact on the local client either.

dynamics.exe runs with about 32M of memory allocation and i think i saw it exceed about 30% CPU just a couple times. If I watch the server at the same time, it hovers around 20-30%. Network should not be a bottle neck, both client and server reside on teh same lan (physically right next to eachother).

i am at a lost tonight!

 

[beleyrs]

we *think* we figured it out...just in case anyone is interested.

the auto procedures for our custom tables were never dropped and recreated. this is apparently a step in the upgrade process. without the procedures, apparently dynamics and SQL are tyring to execute ad-hoc queries to read these tables. assuming thats true, makes sense that so much overhead was being added.

once we dropped and recreated the procedures, system was flying again, though not as fast as I'd like...