本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# Amazon Neptune 中的查詢佇列
<a name="access-graph-queuing"></a>

開發和調校圖形應用程式時，了解資料庫將查詢排入佇列的方式會很有幫助。在 Amazon Neptune 中，查詢佇列發生方式如下：
+ 無論執行個體大小為何，每個執行個體可以在佇列中等候的查詢數目上限為 8,192 個。超過該數目的任何查詢都會被拒絕，並且會失敗而產生 `ThrottlingException`。
+ 一次可執行的查詢數目上限取決於指派的工作者執行緒數目，通常該數目設定為可用虛擬 CPU 核心 (vCPU) 數目的兩倍。
+ 查詢延遲包含查詢花費在佇列中的時間，以及網路往返時間和實際執行時間。

## 判定佇列在指定時刻有多少個查詢
<a name="access-graph-queuing-count"></a>

`MainRequestQueuePendingRequests` CloudWatch 指標會以五分鐘的精細程度記錄輸入佇列中等待的請求數目 (請參閱 [Neptune CloudWatch 指標](cw-metrics.md))。

若是 Gremlin，您可以使用 [Gremlin 查詢狀態 API](gremlin-api-status.md) 傳回的 `acceptedQueryCount` 值來取得佇列中目前的查詢計數。但請注意，[SPARQL 查詢狀態 API](sparql-api-status.md) 傳回的 `acceptedQueryCount` 值包含從伺服器啟動以來接受的所有查詢，包括完成的查詢。

## 查詢佇列如何影響逾時時間
<a name="access-graph-queuing-timeouts"></a>

如上所述，查詢延遲包含查詢花費在佇列中的時間，以及執行所花費的時間。

由於查詢的逾時期間通常是從查詢進入佇列起算，因此移動緩慢的佇列可能會使許多查詢一移出佇列就立即逾時。這個情況顯然不好，所以應避免將大量查詢排入佇列，除非它們可以快速執行。