Question

My first question is

Does SQL Server work asynchronously or synchronously?

• if it works asynchronously:
  how many inserting (or any other) asynchronous calls can be handled by SQL Server, or is it dependent on virtual memory?

• if it works synchronously:
  how many synchronous calls can be handled by SQL Server? Is there any queue maintained by SQL Server for pending requests? If yes, then how many pending request can be handled..

Answer 1

I hope I understand your question correctly…

Any call to the database is synchronous: you call, you wait for a result. But asynchronous vs synchronous isn’t really how RDBMS work

Going further…

The main thing for any RDBMS is concurrency. RDBMS are designed to handle 1000s of concurrent connections

You can have many overlapping and concurrent readers until the server runs out of resources.

Where you do get some concept of asynchronous vs synchronous is around writes. These are exclusive and serialised (by default) and wil blokc reader for the duration of the transation.

For resources (some generalisations here which makes them susepct 🙂

• Write throughput is determined by IO bandwidth mostly and lot by code design
• Read throughout is limited by network/CPU and code design again, mostly.
• Memory shouldn’t be an issue normally because cached data is shared
• In practice, poor code or design affects resource usage most except for large DBs/load

For example, poor indexing is one of the biggest killer of database performance