Add performance notes, tweak the receive loop to not setup extra unnecessary SqlDependencies when it can be avoided.

Author: ascott18

README.md

@@ -77,9 +77,17 @@ services.Configure<SqlServerOptions>(Configuration.GetSection("SignalR:SqlServer
 
 ## Caveats
 
-* As mentioned above, if SQL Server Service Broker is not available, messages will not always be transmitted immediately since a fallback of periodic querying must be used.
-* This is not the right solution for applications with a need for very high throughput, or very high degrees of scale-out. Consider Redis or Azure SignalR Service instead for such cases. You should always do an appropriate amount of testing to determine if a particular solution is suitable for your application.
-* While this uses the same table schema as the classic ASP.NET SignalR SQL Server backplane, the message payloads are completely different. If you are migrating, consider configuring a different `SchemaName` to prevent conflicts.
+As mentioned above, if SQL Server Service Broker is not available, messages will not always be transmitted immediately since a fallback of periodic querying must be used.
+
+While this uses the same table schema as the classic ASP.NET SignalR SQL Server backplane, the message payloads are completely different. If you are migrating, consider configuring a different `SchemaName` to prevent conflicts.
+
+### Performance
+
+This is not the right solution for applications with a need for very high throughput, or very high degrees of scale-out. Consider Redis or Azure SignalR Service instead for such cases. You should always do an appropriate amount of testing to determine if a particular solution is suitable for your application. 
+
+The results of some ad-hoc performance testing yielded that you can expect about 1000 messages per second per table (setting `TableCount`). However, increasing table count does have diminishing returns; attempting to push 20,000 messages/sec with 20 tables had a throughput of only ~10,000 messages/sec. This was observed with a SQL Server instance and load generator running on the same machine, an i9 9900k with an SSD, with a message size of ~200 bytes. A Redis backplane on the same hardware sustained 20,000 messages per second without issue.
+
+Do note that a broadcast message is considered a single message. Any call to `SendAsync` within a hub is a single message.
 
 ## License
 

src/IntelliTect.AspNetCore.SignalR.SqlServer/Internal/SqlServer/SqlReceiver.cs

@@ -107,6 +107,13 @@ private async Task NotificationLoop(CancellationToken cancellationToken)
 
                     if (recordCount > 0)
                     {
+                        // If we got one message, there might be more coming right after.
+                        // Keep consuming as fast as we can until we stop getting more messages.
+                        while (recordCount > 0)
+                        {
+                            recordCount = await ReadRows(null);
+                        }
+
                         _logger.LogDebug("{0}Records were returned by the command that sets up the SQL notification, restarting the receive loop", _tracePrefix);
                         continue;
                     }
@@ -122,7 +129,16 @@ private async Task NotificationLoop(CancellationToken cancellationToken)
                         case SqlNotificationType.Change when depResult.Info is SqlNotificationInfo.Update:
                             // Typically means new records are available. (TODO: verify this?).
                             // Loop again to pick them up by performing another query.
-                            _logger.LogTrace("{0}SQL notification details: Type={1}, Source={2}, Info={3}", _tracePrefix, depResult.Type, depResult.Source, depResult.Info); continue;
+                            _logger.LogTrace("{0}SQL notification details: Type={1}, Source={2}, Info={3}", _tracePrefix, depResult.Type, depResult.Source, depResult.Info);
+
+                            // Read rows immediately, since on the next loop we know for certain there will be rows.
+                            // There's no point doing a full loop that includes setting up a SqlDependency that
+                            // will go unused due to the fact that we pulled back rows.
+                            while (recordCount > 0)
+                            {
+                                recordCount = await ReadRows(null);
+                            }
+                            continue;
 
                         case SqlNotificationType.Change when depResult.Source is SqlNotificationSource.Timeout:
                             // Expected while there is no activity. We put a timeout on our SqlDependency so they're not running infinitely.