如何调试运行在IIS生产服务器上的Blazor 6.0实时应用

Great question—debugging Blazor Server apps on IIS (especially when dealing with Circuit-heavy game logic) can be tricky, but there are solid tools and practices to get to the bottom of your issues. Let's break this down step by step based on your scenario:

1. Monitoring Memory Usage on IIS #

Keeping tabs on memory is critical to catch leaks or unexpected spikes that might cause player-side crashes:

• IIS Worker Process Dashboard: Open IIS Manager, navigate to your site, and click "Worker Processes" in the right-hand pane. You’ll see the memory footprint (Private Bytes) of your Blazor app’s process. If it climbs steadily without dropping, you might have a memory leak (e.g., orphaned Circuits or un-disposed timers).
• Performance Monitor: Add these counters to track key metrics:
  • Microsoft.AspNetCore.Components.Server/Circuits Active to monitor live player connections
  • .NET CLR Memory/Private Bytes for overall app memory usage
  • Microsoft.AspNetCore.Components.Server/Circuits Disconnected to verify unused Circuits are being cleaned up properly
• dotnet-counters: Attach to your app’s process ID (from IIS Worker Processes) with this CLI tool for real-time monitoring:

  dotnet counters monitor --process-id <YOUR_APP_PID> Microsoft.AspNetCore.Components.Server System.Runtime
  

  This shows live Circuit counts, garbage collection stats, and memory usage.

2. Hunting Down Unhandled Server-Side Errors #

Your suspicion about null reference exceptions (e.g., accessing a deleted Circuit) is spot-on. Here’s how to capture those details:

• Enable Detailed Logging: Update your appsettings.json to log Blazor and SignalR activity at the Debug level—this reveals Circuit lifecycle events and connection errors:

  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft.AspNetCore.Components.Server": "Debug",
      "Microsoft.AspNetCore.SignalR": "Debug",
      "Microsoft.AspNetCore.Http.Connections": "Debug"
    }
  }
  

• Global Exception Handling: Add Circuit-specific error handling in Program.cs to log unexpected closures:

  builder.Services.AddServerSideBlazor().AddCircuitOptions(options =>
  {
      // Enable detailed errors temporarily in production for debugging
      options.DetailedErrors = builder.Environment.IsDevelopment() || builder.Configuration.GetValue<bool>("EnableDetailedErrors");
      
      options.OnCircuitClosed = async circuit =>
      {
          var logger = builder.Services.BuildServiceProvider().GetRequiredService<ILogger<Program>>();
          logger.LogWarning("Circuit {CircuitId} closed unexpectedly", circuit.Id);
      };
  });
  

• Windows Event Viewer: Check the Application log under Windows Logs—.NET Runtime errors here provide full stack traces for unhandled exceptions (including null references that might crash players).
• IIS Request Logs: Look in C:\inetpub\logs\LogFiles for 500-level status codes or failed SignalR connection attempts, which point to server-side issues triggering player crashes.

3. Tracking Real-Time & Disconnected Circuit States #

To manage your game’s Circuits effectively, you need visibility into their lifecycle:

• Custom Circuit Registry: Build a singleton service to track active Circuits and link them to player IDs—this lets you quickly verify a Circuit exists before accessing it:

  public class CircuitRegistry
  {
      private readonly ConcurrentDictionary<string, CircuitInfo> _activeCircuits = new();
      public IReadOnlyDictionary<string, CircuitInfo> ActiveCircuits => _activeCircuits;
  
      public void Register(Circuit circuit, string playerId)
      {
          _activeCircuits.TryAdd(circuit.Id, new CircuitInfo(circuit.Id, playerId, DateTime.UtcNow));
      }
  
      public void Unregister(string circuitId)
      {
          _activeCircuits.TryRemove(circuitId, out _);
      }
  
      public CircuitInfo? GetByPlayerId(string playerId)
      {
          return _activeCircuits.Values.FirstOrDefault(c => c.PlayerId == playerId);
      }
  }
  
  public record CircuitInfo(string CircuitId, string PlayerId, DateTime OpenedAt);
  

  Register this in Program.cs with builder.Services.AddSingleton<CircuitRegistry>(), then update your game components to register/unregister Circuits on initialization/disposal.
• Expose a Monitoring Endpoint: Add an API controller to query active Circuits at any time:

  [ApiController]
  [Route("api/game/circuits")]
  public class CircuitMonitorController : ControllerBase
  {
      private readonly CircuitRegistry _registry;
  
      public CircuitMonitorController(CircuitRegistry registry)
      {
          _registry = registry;
      }
  
      [HttpGet]
      public IActionResult GetActiveCircuits()
      {
          return Ok(_registry.ActiveCircuits);
      }
  }
  

• dotnet-counters: As mentioned earlier, this tool shows live counts of active/disconnected Circuits without writing custom code.

4. Specific Fixes for Your Game's Timeout & Crash Issues #

Given your timer-based exit logic and scalability goals, here are targeted tips:

• Validate Timeout Configurations: Double-check Blazor and SignalR settings to match your game’s needs. Misconfigured timeouts can cause unexpected Circuit closures:

  builder.Services.AddServerSideBlazor().AddCircuitOptions(options =>
  {
      // How long to keep disconnected Circuits before cleanup
      options.DisconnectedCircuitRetentionPeriod = TimeSpan.FromMinutes(10);
  });
  
  builder.Services.AddSignalR(options =>
  {
      // Frequency of keep-alive messages to players
      options.KeepAliveInterval = TimeSpan.FromSeconds(10);
      // How long to wait before assuming a player is disconnected
      options.ClientTimeoutInterval = TimeSpan.FromSeconds(20);
  });
  

• Guard Against Null References: Always check if a Circuit exists before accessing it in timer logic. Cancel timers when a Circuit closes to avoid orphaned tasks:

  private CancellationTokenSource _timeoutCts = new();
  [Inject] private CircuitRegistry _circuitRegistry { get; set; }
  [Inject] private Circuit Circuit { get; set; }
  private string _currentPlayerId;
  
  protected override async Task OnInitializedAsync()
  {
      _currentPlayerId = GetCurrentPlayerId();
      _circuitRegistry.Register(Circuit, _currentPlayerId);
  
      // Start timeout timer with cancellation support
      _ = Task.Run(async () =>
      {
          try
          {
              await Task.Delay(TimeSpan.FromMinutes(5), _timeoutCts.Token);
              var circuit = _circuitRegistry.GetByPlayerId(_currentPlayerId);
              if (circuit == null) return;
  
              // Execute timeout exit logic safely
              await HandlePlayerTimeout(_currentPlayerId);
          }
          catch (OperationCanceledException)
          {
              // Timer was canceled (player left or Circuit closed)
          }
      }, _timeoutCts.Token);
  }
  
  public async ValueTask DisposeAsync()
  {
      _timeoutCts.Cancel();
      _timeoutCts.Dispose();
      _circuitRegistry.Unregister(Circuit.Id);
  }
  

• Load Test Early: Use tools like k6 to simulate 200+ concurrent players and stress-test your Circuit logic. This catches scalability issues (like memory leaks or race conditions) before they affect real players.

内容的提问来源于stack exchange，提问作者Bennyboy1973