More often than not, speed issues with SQL Server can be attributed to just about anything, other than the configuration of the SQL Server settings themselves. Usually, there are three main bottlenecks that will slow down a SQL Server.
The first bottleneck is data access speed. If your software (SQL Server) can not access and update your data fast on the physical hard drive(s) then you will get slow performance regardless of any other system hardware specification. It doesn't matter how much memory you have, how many CPUs you have, or how fast your network connection is, you will get slow performance with one user and slow performance with a thousand users. You need to make sure that your SQL data is contained on fast SCSI drives. The most ideal situation is to have a drive for your system, a drive for the SQL Data, and a drive for the SQL Log; each of these running on separate SCSI drive controllers. The reality is that the cost of doing this is often overwhelming so you need to find a happy medium.
The second performance bottlneck is in processing requests. If your SQL Server is overwhelmed by requests by too many clients then the system will slow down. The way to improve your SQL Server's ability to process requests is to increase CPU speed and multiplicity as well as increase the amount of memory in the server.
The third performance bottleneck is request result bandwidth. This bottleneck occurs when you have to many clients requesting large amounts of data to be returned over the network. The solution for this problem is a faster and smarter network. You should use switches not hubs, and if at all possible provide a Gigabit network connection to your SQL Server from your switch. My personal feeling is that providing a Gigabit connection to each client is overkill, and rarely provides a cost benifit.
That being said, it is possible that SQL Server is not the one slowing down your processing throughout the day. It is possible that some program such as a backup application or a scheduling program is running a process that is slowing things down. Of course it is also possible that SQL Server's own backups are slowing things down during the middle of the day.
Scott Travis
infoSpring, LLC.
scott.travis@infospring.net