C# multi-threaded application from 32 bit to 64 bit results performance degraded

[nataraj2502]

Hi,


I have just configured my C# multi-threaded application from 32 bit to 64 bit platform for getting more memory support. But my application runs up to 40 - 50% slower as compared to 32 bit platform.

The overall idea about the multithreaded application is, we do recalculation for server hundred thousand records available in the database. Fetch the records from the table and do the recalculation finally it will update it into the table.


Earlier we had the following sever configuration as bellow

OS- Windows 2003 server 32 bit version
SQL - SQL Server 2005 Enterprise Edition for 32 bit version
8GB RAM


Now we changed to the latest version

OS- Windows 2003 server 64 bit version
SQL - SQL Server 2008 Standard Edition for 64 bit version
8GB RAM

The application was working fine and recalculated 3000 records per minute. But now after changing to 64 bit version it is calculating only 1200 records per minute.


I have tried with the following scenarios.

Changed to enterprise edition 64 bit version and tested - no improvement (memory utilization is high)
Page lock in memory in enterprise version and tested - no improvement (memory utilization is high).


Can you suggest where I need to concentrate to improve the performance? (OS Level / SQL Level /Application)

Thanks,
Natarajan.M

[mldisibio]

I am no expert in this matter, and there are myriad design and system points that could play a part, but here are a couple of thoughts:
- Looks like you physical maching memory has stayed the same (8gb). The change from 32 to 64 allows more instructions per CPU cycle, but the quantity of data cached in memory is probably still the same.
- If you are pulling and updating from the same db table, it may indeed be processing much faster now, and potentially resulting in a higher percentage of table deadlocks: more threads trying to update the same table at the same time;
- You would have to post a very simplified, minimal version of your multi-threading design for someone to analyze for thread race conditions or deadlocks. Are you using signaling, especially for the updates? Your db reads will always be faster and uncontended than your db writes. At a quick glance, I would envision a synchronized update thread with a Queue that sends processed data sets back to the db one at a time (if going to the same table). The reads and re-calculations can certainly be asynchronous.
- Finally, consider even limiting the number of read threads. There is probably a "bell-curve" relation between number of threads working at any one time and actual increase in overall speed, that may start to degrade if the 64 bit scenario overburdens itself with too many threads to manage.