|
database
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Why VC++ ADO runs slow on WIN2003 cluster ?I have a performance problem with component written in: - VC++ 6.0 as console application which uses - ADO for connecting to SQLServer2000 for - exporting data from one table into ASCII file. Component works fine on my laptop (WinXP,1GB RAM). But, when I run this component on Win2003 cluster on 2 CPU machine with 4GB RAM/node, performance is 5 times worse than on my laptop. I suppose that problem lies in ADO, but I don know how to fix it. To rewrite the application which will not use ADO is not the option :-( Does anybody experienced similar behavior ? Help!
Show quote
"ikaliy" <ika***@yahoo.com> wrote in message No. There should be nothing inherent in SQL Running on a Server (or news:1152965144.892634.10100@p79g2000cwp.googlegroups.com... > Hello, > > > I have a performance problem with component written in: > - VC++ 6.0 as console application which uses > - ADO for connecting to SQLServer2000 for > - exporting data from one table into ASCII file. > > > Component works fine on my laptop (WinXP,1GB RAM). > > > But, when I run this component on Win2003 cluster on > 2 CPU machine with 4GB RAM/node, performance > is 5 times worse than on my laptop. > > > I suppose that problem lies in ADO, but I don know > how to fix it. > > > To rewrite the application which will not use ADO > is not the option :-( > > > Does anybody experienced similar behavior ? > Cluster) or ADO to cause this. Are all the components running on the server? Is the application just reading data, or writing it too? Where is it writing data to? David David Browne je napisao/la:
> No. There should be nothing inherent in SQL Running on a Server (or Application reads data from database table, make some conversion, and> Cluster) or ADO to cause this. Are all the components running on the > server? Is the application just reading data, or writing it too? Where is > it writing data to? write them to ASCII file. All components are running on the same server. I'm assuming that you are NOT running Windows 2003 on your laptop. One
possible cause for the problem is write-ahead disk caching, which is enabled by default on Windows XP, but disabled (as it should be) on Windows 2003 Server. Write ahead caching can substantially improve disk write times (like writng to a flat file) but can cause havoc for many database operations in the case of a power failure. You may want to google write-ahead caching and disable it on Windows XP and retest your application. That may give you the incentive to seek out alternate performance tweaks. Stu ikaliy wrote: Show quote > David Browne je napisao/la: > > No. There should be nothing inherent in SQL Running on a Server (or > > Cluster) or ADO to cause this. Are all the components running on the > > server? Is the application just reading data, or writing it too? Where is > > it writing data to? > > Application reads data from database table, make some conversion, and > write them to ASCII file. All components are running on the same server. I cannot change caching feature on my laptop and retest the
application. But, if write caching would increase performance, then many application would be running faster on desktop machine in comparance to server cluster. Any other ideas ? ikaliy wrote:
> I cannot change caching feature on my laptop and retest the Not necessarily; if the applications are write-intensive (as it sounds> application. > But, if write caching would increase performance, then many application > would be running faster on desktop machine in comparance to server > cluster. > like your scenario is) then write-caching can definitely be a factor; not every application is write-intensive, so there may be no differenc for those apps. Just curious, why can't you retest? And no, that's the only idea I can think of for this issue. Stu Show quote > Any other ideas ? It seems that ado does not scale good on multiprocessor machines.
I made simple test. Aplication loads 600 000 records from local database table, and just run trough the recordset without any logic or writing to the file. Result on laptop: 60 seconds Result on cluster: 140 seconds What I am suppose to do ?  |
|||||||||||||||||||||||
Other interesting topics