試試 maxConnections
====以上答案作廢====
資訊系統的世界裡
同時處理多筆要求的為大宗
一次處理一筆的也不是沒有
這兩種分類都只是完成資訊系統的多種架構之一(How)

真正的重點在於你要做的是什麼資訊系統(What and Why)
如果你願意比較詳細一點說明你要做的是什麼系統
而不只是切一段局部的技術問題出來問

或許討論起來會比較有效率一點
也比較能解決你的問題

說不定
queue 不是在 HTTP 這段處理
而是在資料庫那段處理
或者在程式裡處理
又甚至
根本不用 queue 的機制

曾經implement過兩種架構：

1. Critical Application：完全不能漏掉任何request，我採用資料庫當作佇列，以時間為primary key。
2. Non-critical Application：純粹發出訊息，我採用 Redis，使用內建的list。

你這個問題，得要先了解需不需要回應。
才可以來計劃打算。

如果不需要回應的情況下。
就可以採用緩存處理的程序來處理。如上面說的 MSMQ。

但是，如果有需要等待回應。一般來說會比較無解。
畢竟這還需要去處理超時的問題。
如已經等待處理了。但對方因為等太久需要視為失敗處理。
那你正在排隊的指令你該怎麼處理?

我曾經也做過類似的東西，當時我的處理是一但斷開之後。
就在給與一個刪除的指令動作。
原本相安無事用了快1年多。

只到有一天。因廠商誤寫了一段請求指令。
把我的機器給操掛。

若出發點是維護數據庫的consistence,
可以在 controller/middleware中控制如何呼叫找數據的涵式
例如在java 中就有 synchronize 這一個keyword可用.

A request 先來, 先處理
B request 時, A 還在處理 就等待?
等 A處理好, 再觸理B?
如果是這樣 那 B可以等待多久?
其實如果不考慮 B 可以等待過久 TIME OUT 的話!
或 A, B 都可以接收 處理完後回頭request的話!
那可以如下架構方式處理:

1. 寫個接收前台 request 的 asp/aspx/jsp ... 等等網頁程式
2. 寫個後台批次處理EXE/vbs...等程式

前台接收request後, 將request存入SQL SERVER Queue 表 , 然後等待
後台 批次處理Queue 表資料, 將結果寫回
前台程式查詢到其Queue 處理完後, 回應回去

希望以上能解決您的問題!