My company has developed a VB.NET 2003 application which interfaces with the SQL Server database of another software package. We are experiencing serious performance differences at one of our client sites on a particular query that is one of the frequent queries that runs in our software which I will try to outline below.
Our database and the accounting system database are in separate instances on the same SQL Server 2005 box. Our query is a simple SELECT statement with filtering which properly utilizes the built-in indexes for that table. In their case it returns roughly 13000 records (vendor listing). There is no report of slowness regarding other queries as none of them return the volume that this particular query does.
On one offending workstation: if we run this query, it takes less than a second to get results back in SQL Management Studio's query window. This is consistent with the accounting software which takes about 2 seconds to run the query and display the results in a grid (the accounting system is Viewpoint, a leading construction accounting system written in VB6). In our system, attempting to do the same thing as the accounting system, it is taking nearly 16 seconds to retrieve and display the results. This workstation is running on WIndows XP SP2. They are experiencing this same behavior on several workstations.
At the same client site, they have identified two Windows 2000 workstations which can run the query and display the results from our system in approx. 2 seconds - which is what we would expect and is also what we experience internally on our development platform, and 12 other clients who run our software and interface with the same accounting system - regardless of OS on the workstation.
Based on the results in the query window and the results on the 2000 workstations and the success of other clients who have as many records if not more than this particular client - i don't think we have an issue with the query or the code. The results are very consistent on each workstation as well so I don't think it's a network traffic or activity issue. My gut points me at .NET Framework version differences - since the things that would affect this process are framework items - SQL Server OLEDB drivers and objects, DataGrids, Datatables and DataViews,etc.
On one of the XP workstations I had them remove .NET framework 3.0 which had no effect on the problem, but they also have v. 1.0.3705, 1.0 Hotfix (KBB886906), Framework 1.1, 1.1. Hotfix (KBB886903), Framework 2.0 with 2 security updates (KB917823 and BK922770).
Can anyone point me in a direction on things that I can check that might be different between their XP and 2000 workstations which might affect this process? I am working on some caching logic which will reduce the number of times this query is run, but I would like to understand why there is a behavioral difference.
Any help is appreciated. Please let me know if there is any other information I can provide.
Thanks.
PaulJudging from the fact that some workstations are experiencing problems while others are not, I would concentrate on the workstations experiencing the problems, rather than the query or the database server. First thing I would check is what speed and duplex settings are on a machine that performs well, and one that does not perform well. I would wager these are not the same. The reason you only see it on this one query (or a set of queries) is that you are trying to bring back 13,000 rows of data in these queries (a more significant network load than the usual < 100 rows per operation).|||The problem turned out to be an issue with a "chimney offload" setting on one of their NIC cards on the server.
Once this setting was disabled, the slowness disappeared.
See article below:
http://support.microsoft.com/kb/942861/en-us
Wednesday, March 21, 2012
Query performance issue - Need direction
Labels:
application,
company,
database,
developed,
direction,
experiencing,
interfaces,
microsoft,
mysql,
net,
oracle,
package,
performance,
query,
server,
software,
sql
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment