The subnet calculator helps you design networks by taking an IP address and network mask and returning information such as network, broadcast address, and host range.
One of a set of tools we're offering as a way of saying thank you for being a part of the community.
#1. If you're going to have several people running your app at the same time, in effect this is the same as threading since it means your database server will be running several queries at the same time. In this case, threading would help a single person but when several people run the performance would be unchanged.
#2. Use a code profiler on your app to be sure it spends most of its time waiting on the database. If it only spends 20% of its time waiting on the db, and you thread it to cut that in half, you've only boosted your performance by 10%.
#3. If your app is waiting on the db for most of the time, use sql profiler to identify the queries that take the longest and then optimize those queries. A simple index change can have a dramatic effect on performance.
#4. If none of those help, then look at the SqlCommand methods like BeginExecuteReader and BeginExecuteNonQuery. Those are the easiest ways to thread things when db performance is the bottleneck. They limit the scope of the threading. They make coding a little more difficult because code needs to start several queries (loading up multiple cpus) and then react when they queries finish. If you're using databound controls, threading isn't an option.