Winsock本地客户端-服务端性能测试及线程实现优化咨询

Hey there! Let's break down your problem step by step since you're new to Winsock—this is a common starting point, so don't worry, we'll get you sorted.

Let's split this into two focused parts: single-client fixed-request testing, and multi-client parallel testing.

1.1 Single-Client Fixed-Request Test #

The goal here is to send a fixed number of requests (like 10,000) and measure how long the server takes to process them all. Here's how to approach it:

Client Side #

• Wrap basic Winsock logic: Write a reusable function to initialize Winsock, create a socket, connect to the server, send a request, and receive the response.
• Loop for fixed requests: Run this function in a loop 10,000 times. If you want pure server processing time (not including network latency), exclude the initial connection setup from your stats.
• High-precision timing: Use Windows' QueryPerformanceCounter() and QueryPerformanceFrequency() for accurate timing—this is far better than GetTickCount64() for small, fast operations. Example snippet:

  LARGE_INTEGER start, end, freq;
  QueryPerformanceFrequency(&freq);
  QueryPerformanceCounter(&start);
  
  // Run your 10,000 request loop here
  
  QueryPerformanceCounter(&end);
  double totalTime = (double)(end.QuadPart - start.QuadPart) / freq.QuadPart;
  printf("Total time for 10,000 requests: %.2f seconds\n", totalTime);
  

Server Side #

To get accurate server processing time (not network latency), add timing directly in the server's request handler:

• When the server receives a request, record the start time.
• After processing the request and sending the response, record the end time.
• Accumulate total processing time across all requests, and calculate averages/totals at the end.
• Protect shared stats (like total time) with synchronization primitives if multiple threads are updating them (more on that later).

1.2 Multi-Client Parallel Test #

This tests how the server handles concurrent requests. Here's how to implement it:

• Use threads (or thread pools): Create multiple client threads, each running the same request-sending logic as the single-client test. Start with 10, 50, or 100 threads to simulate different concurrency levels.
• Synchronize thread completion: Use a counting semaphore or event objects to wait for all client threads to finish before calculating aggregate stats. Example with CreateSemaphore:

  HANDLE hSemaphore = CreateSemaphore(NULL, 0, numClients, NULL);
  
  // Create each client thread, pass the semaphore handle as parameter
  for (int i = 0; i < numClients; i++) {
    CreateThread(NULL, 0, ClientThreadFunc, hSemaphore, 0, NULL);
  }
  
  // Wait for all threads to signal completion
  for (int i = 0; i < numClients; i++) {
    WaitForSingleObject(hSemaphore, INFINITE);
  }
  CloseHandle(hSemaphore);
  

• Measure key metrics: Track total throughput (requests per second), average response time, peak CPU/memory usage on the server, and any error rates (failed connections/responses).

Since you mentioned the program uses threads, let's cover common pitfalls and fixes:

2.1 Common Unconventional Thread Practices #

If your current implementation does any of these, it's likely not optimal:

• Creating a new thread per request: Spawning and destroying threads 10,000 times has massive overhead (context switches, memory allocation). This will kill performance, especially under high concurrency.
• Not cleaning up thread resources: Forgetting to call CloseHandle() on thread handles (from CreateThread) leads to handle leaks, which can eventually crash your server.
• No thread limit: Letting unlimited threads run at once will exhaust system memory and CPU, leading to thrashing.
• Unprotected shared data: If multiple threads update global stats (like request counts) without locks, you'll get data races and incorrect results.
• Missing error handling: Threads that crash unhandled can take down the entire server, or leave resources in a broken state.

2.2 Improvements and Why They Matter #

• Switch to a thread pool: Use Windows' native thread pool API (CreateThreadpool, SubmitThreadpoolWork) or C++20's std::jthread with a thread pool. Threads are reused instead of created/destroyed, cutting overhead drastically. For high-performance Winsock servers, pair this with IO Completion Ports (IOCP)—this is the industry standard for scalable network apps on Windows, as it lets a small number of threads handle thousands of concurrent connections efficiently.
• Proper resource cleanup: Always close thread handles with CloseHandle() after the thread exits. For C++ std::thread, use join() to wait for completion before destroying the thread object, or detach() if you don't need to track it.
• Add synchronization for shared data: Use CRITICAL_SECTION (lightweight for same-process sync) or std::atomic variables to protect shared stats. For example:

  CRITICAL_SECTION cs;
  InitializeCriticalSection(&cs);
  
  // In thread function, when updating total time:
  EnterCriticalSection(&cs);
  totalProcessingTime += currentRequestTime;
  LeaveCriticalSection(&cs);
  

• Catch exceptions in threads: Wrap your thread function logic in a try-catch block (for C++) to catch unexpected errors, log them, and clean up resources gracefully. This prevents unhandled exceptions from crashing the server.
• Limit concurrent threads: If you're not using a thread pool, set a maximum number of active threads (e.g., 10-20, depending on your server's CPU cores). This prevents resource exhaustion and keeps context switching manageable.

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