wu-sheng commented on PR #13703:
URL: https://github.com/apache/skywalking/pull/13703#issuecomment-3945645389

   ## Armeria HTTP Event Loop Fix & gRPC/HTTP Thread Model Documentation
   
   **Commit:** `5c7faa71` — Fix Armeria HTTP event loop sizing and document 
gRPC/HTTP thread models
   
   ### Code change
   
   Fixed shared HTTP event loop formula from `max(5, cores/4)` to `min(5, 
cores)`.
   
   The previous formula was incorrect:
   - `cores/4` gives 0 on 2-core (bumped to 5 by `max`), 2 on 8-core, 6 on 
24-core
   - Intent was to cap at 5 since non-blocking I/O multiplexing needs few 
threads
   
   `min(5, cores)` gives the correct behavior:
   | cores | old `max(5, cores/4)` | new `min(5, cores)` |
   |-------|----------------------|---------------------|
   | 2     | 5                    | 2                   |
   | 4     | 5                    | 4                   |
   | 8     | 5                    | 5                   |
   | 10    | 5                    | 5                   |
   | 24    | 6                    | 5                   |
   
   ### Thread model documentation
   
   Added comprehensive class-level javadoc to both `GRPCServer` and 
`HTTPServer` documenting:
   
   **GRPCServer** — three-tier thread model:
   1. Boss event loop (1 thread, accepts connections)
   2. Worker event loop (`cores` threads, shared via `SharedResourcePool`, I/O 
multiplexing)
   3. Application executor (where `onMessage`/`onHalfClose` callbacks run)
   
   **HTTPServer** — two-tier thread model:
   1. Event loop (`min(5, cores)` shared across all 7 servers)
   2. Blocking task executor (where `@Blocking` handlers run)
   
   ### Handler executor policy (both servers)
   
   | | gRPC | HTTP (Armeria) |
   |---|---|---|
   | JDK 25+ | Virtual threads | Virtual threads |
   | JDK <25 | gRPC default `CachedThreadPool` (unbounded) | Armeria default 
cached pool (up to 200) |
   
   Both keep framework defaults on JDK <25:
   - **gRPC**: `CachedThreadPool` (`SynchronousQueue`, `Integer.MAX_VALUE` max 
threads). SkyWalking extensions may register gRPC handlers with long-blocking 
I/O — a bounded pool would starve other services.
   - **HTTP**: Armeria's `ScheduledThreadPoolExecutor` (200 core threads, 
unbounded `DelayedWorkQueue`). HTTP handlers block on storage/DB queries 
(BanyanDB, Elasticsearch, 10ms–seconds) — a smaller pool would cause request 
queuing and UI timeouts.
   
   On JDK 25+, virtual threads replace both pools.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to