>>Sounds like an I/O problem. Perhaps you need more horses, especially as fast SSD disk solution.
>
>If that would be an I/O problem, it would not affect the database server as the network transmission would simply take longer to reach the database server but once the request processed at SQL Server level, it would be a fast as usual. Unless, you are talking about the database server itself having problem to communicate with its own disk. Is that what you are referring to?

Yes... what does your disk storage look like?

>>Another solution might be to tweak the isolation levels. For some queries you might lower them to read uncommitted. This will not issue read locks and reduce I/O.

>All queries are sent with (NOLOCK). Once I did that, this helped to increase the performance overall in the product. However, updates and inserts, for example, cannot be sent like that.

NOLOCK certainly would help, but it would not hurt to look at the isolationlevels as well. But only if it cannot be resolved by having faster disks.

Walter,