log_by_lua
語法： log_by_lua <lua-script-str>
上下文： http,server,location,location if
時期： log
注意 從v0.9.17版本開始，不建議 使用這個指令，使用log_by_lua_block 代替。
在log請求處理階段運行<lua-script-str>的Lua源代碼。這并不會替換當前的訪問日志。只是在它之前執行而已。
主要下面的API方法在這個上下文中目前是被禁用的：
- 輸出API方法（例如：ngx.say和ngx.send_headers）
- 控制API方法（例如： ngx.exit）
- 子請求API方法(例如：ngx.location.capture和ngx.location.capture_multi)
- Cosocket API方法（例如： ngx.socket.tcp 和 ngx.req.socket）。
下面是一個收集$upstream_response_time平均數據的例子：
lua_shared_dict log_dict 5M;
server {
location / {
proxy_pass http://mybackend;
log_by_lua'
local log_dict = ngx.shared.log_dict
local upstream_time = tonumber(ngx.var.upstream_response_time)
local sum = log_dict:get("upstream_time-sum") or 0
sum = sum + upstream_time
log_dict:set("upstream_time-sum",sum)
local newval,err = log_dict:incr("upstream_time-nb",1)
if not newval and err == "not found" then
log_dict:add("upstream_time-nb",0)
log_dict:incr("upstream_time-nb",1)
end
';
}
location = /status {
content_by_lua_block {
local log_dict = ngx.shared.log_dict
local sum = log_dict:get("upstream_time-sum")
local nb = log_dict:get("upstream_time-nb")
if nb and sum then
ngx.say("average upstream response time: ", sum / nb, "(",nb," reqs)")
else
ngx.say("no data yet")
end
}
}
}
這個指令首先從v0.5.0rc31版本被介紹。
log_by_lua_block
語法： log_by_lua_block { lua-script }
上下文： http,server,location,location if
時期： log
和log_by_lua指令相似，除了這個指令將Lua源代碼直接通過一對大括號 ({}) 包含起來而不是Nginx字符串（需要特殊字符轉碼）。
例如：
log_by_lua_block {
print("I need no extra escaping here, for example: \r\nblah")
}
這個指令首先在v0.9.17版本中被介紹。
log_by_lua_file
語法： log_by_lua_file <path-to-lua-script-file>
上下文: http,server,location,location if
時期： log
和log_by_lua等價，除了<path-to-lua-script-file>指定包含Lua代碼的文件，或者，從v0.5.0rc32版本開始，Lua/LuaJIT bytecode被排除了。
當給出一個相對的地址例如foo/bar.lua，它們會將其根據server prefix路徑轉化為一個絕對地址，server prefix路徑是在啟動Nginx服務器時在命令行參數-p PATH里面指定的。
這個指令首先在v0.5.0rc31版本中被介紹。
balancer_by_lua_block
語法： balancer_by_lua_block { lua-script }
上下文： upstream
時期： content
這個指令作為一個upstream均衡器運行Lua代碼，可以在upstream {}配置塊定義的所有upstream實體中使用。
例如：
upstream foo {
server 127.0.0.1;
balancer_by_lua_block {
-- 使用Lua在這里來做一些有趣的事
-- 作為一個動態的均衡器
}
}
server {
location / {
proxy_pass http://foo;
}
}
由此產生的Lua負載均衡器可以和現有的nginx upstream模塊一起使用，例如： ngx_proxy和ngx_fastcgi。
另外，這個Lua負載均衡器可以和標準upstream連接池機制一同工作，例如，標準keepalive指令。
只要確保這個keepalive 指令在一個單獨的upstream{}配置塊中的balancer_by_lua_block的 后面 使用。
這個Lua負載均衡器可以完全忽略掉定義在upstream{}塊中定義的servers列表并且從一個完全動態的server列表（即使在每個請求中改變）中選擇，通過lua-resty-core庫中的ngx.balancer模塊。
當nginx的upstream機制重試請求中指令指定的條件，如proxy_next_upstream指令，這個指令注冊的Lua代碼處理器可能在一個單獨的downstream請求中被調用不止一次。
這個上下文中執行的Lua代碼并不支持yielding,所以可能yield的Lua APIs(例如 cosockets 和 "light threads")在這個上下文中是被禁用的。通過在早期階段處理程序（如：access_by_lua*）處理這種操作和通過ngx.ctx table傳遞結果給這個上下文的解決方法可以繞過這個限制。
這個指令首先在v0.10.0版本中被介紹。
balancer_by_lua_file
語法： balancer_by_lua_file <path-to-lua-script-file>
上下文： upstream
時期： content
和balancer_by_lua_block等價，除了通過<path-to-lua-script-file>指定包含Lua代碼的文件，后者，從v0.5.0rc32版本開始， Lua/LuaJIT bytecode被排除了。
當給定一個相對地址如foo/bar.lua，它們會相對于server prefix轉成絕對地址，server prefix路徑是在啟動Nginx服務器時通過命令行里面的-p PATH參數定義的。
這個指令首先在v0.10.0版本中被介紹。
lua_need_request_body
語法： lua_need_request_body <on|off>
默認： off
上下文： http,server,location,location if
時期： denpends on usage
決定在執行 rewrite/access/access_by_lua*之前是否強制讀取request body數據。Nginx內核默認情況下不讀取client的reqeust body，所以如果需要request body,所以這個指令應該被轉換為on或者在lua代碼里調用ngx.req.read_body方法。
為了通過$request_body變量來讀取request body數據，client_body_buffer_size必須要和client_max_body_size有同樣的值。這是因為當content長度超過了client_body_buffer_size但是比client_max_body_size要少，Nginx會緩存數據到磁盤的一個臨時文件上，這樣會導致$request_body變量為空值。
如果當前location包含 rewrite_by_lua*指令，那么request body會在rewrite_by_lua*代碼運行（rewrite時期也是一樣）之前被讀取。
同樣的，如果只指定了 content_by_lua，request body將不會被讀取知道content處理的Lua代碼將要運行（例如，request body將會在content時期被讀取）。
不過建議，要使用ngx.req.read_body和ngx.req.discard_body方法來更好的控制request body讀取的過程。
這個同時適用于access_by_lua*。
ssl_certificate_by_lua_block
語法： ssl_certificate_by_lua_block { lua-script }
上下文： server
時期： right-before-SSL-handshake
當Nginx要準備開始downstream SSL(https)連接握手的時候，這個指令運行用戶的Lua代碼。
這個對于設置SSL證書鏈和根據每個請求對應的私鑰特別管用。對于從遠程加載非阻塞的握手配置也是非常有用（例如， 使用cosocket API）。并且在這里也可以在純Lua里面給每一個請求做OCSP stapling處理。
另一個典型用例是在這個上下文中來非阻塞的做SSL握手的流量控制。例如：使用lua-resty-limit-traffic#readme庫的幫助。
另外在client端的SSL握手請求時也可以做一些有趣的事情，例如拒絕老的SSL client使用 SSLv3協議甚至選擇更低的。
lua-resty-core庫里面提供的ngx.ssl和ngx.ocspLua模塊在這個上下文中特別有用。你可以使用這兩個模塊提供的Lua API來操縱SSL證書鏈和啟動當前SSL鏈接的私鑰。
然而，當NGINX/OpenSSL通過SSL session IDs或者TLS session tickets對當前的SSL連接成功恢復了SSL session,這個Lua處理器并不運行。換句話說，這個Lua處理器僅僅在Nginx乣初始化一個完整的SSL握手時運行。
下面是一個在同一時間使用ngx.ssl模塊的小例子：
server {
listen 443 ssl;
server_name test.com;
ssl_certificate_by_lua_block {
print("About to initiate a new SSL handshake!")
}
location / {
root html;
}
}
查看ngx.ssl和ngx.ocspLua模塊的官方文檔的復雜的例子。
用戶Lua代碼里未捕獲的Lua異常會立即終止當前的SSL session，ngx.exit調用是用了一個error code例如ngx.ERROR也是如此。
Lua代碼執行上下文 確實 支持yielding，所以可能yield的Lua APIs（如 cosockets,sleeping,和“light threads”）在這個上下問中是可用的。
注意，無論如何，你使用需要配置ssl_certificate 和ssl_certificate_key指令，即使你不會使用這個靜態證書和私鑰。這是因為Nginx core需要他們的appearance否則你在啟動Nginx時會看到這個錯誤：
nginx: [emerg] no ssl configured for the server
這個指令目前需要以下nginx核心補丁，才能正常工作：
http://mailman.nginx.org/pipermail/nginx-devel/2016-January/007748.html
在OpenResty 1.9.72(或更高)版本捆綁的Nginx核心已經應用了這個補丁。
除此之外，至少需要OpenSSL 1.0.2e指令工作。
這個指令首先在v0.10.0版本中被介紹。
ssl_certificate_by_lua_file
語法： ssl_certificate_by_lua_file <path-to-lua-script-file>
上下文： server
時期： right-before-SSL-handshake
和ssl_certificate_by_lua_block等價除了通過 <path-to-lua-script-file>指定的文件包含Lua代碼，從v0.5.0rc32版本開始， Lua/LuaJIT bytecode被排除了。
當給定了一個相對地址如foo/bar.lua，他們會將其相對server prefix路徑轉換為絕對路徑，這個server prefix是在啟動Nginx服務器時通過命令行參數中的-p PATH指定的。
這個指令首先在v0.10.0版本中被介紹。
ssl_session_fetch_by_lua_block
語法： ssl_session_fetch_by_lua_block { lua-script }
上下文： http
時期： right-before-SSL-handshake
這個指令運行Lua代碼來查找和加載SSL會話（若有的話），根據的是為downstream當前SSL握手請求提供的session ID。
在lua-resty-core庫里的ngx.ssl.sessionLua模塊提供用來獲取當前會話ID和加載緩存的SSL session數據的Lua API。
可能會yield的Lua APIs,例如 ngx.sleep和cosockets在這個上下文中是可用的。
這個鉤子，和ssl_session_store_by_lua*鉤子一起，可以在純Lua中用來實現分布式緩存機制（例如，基于cosocket API），如果找到一個緩存的SSL session并且被加載到當前SSL連接上下文中，SSL session恢復可以被立即啟動，并且繞過整個SSL握手的過程，這個過程占用非常昂貴的CPU時間。
請注意，TLS session tickets是非常不同的并且當session tickets被使用到時這是client的責任來緩存SSL session狀態。
不需要經過這個鉤子（也不需要ssl_session_store_by_lua_block鉤子），基于TLS session tickets的SSL session恢復會自動發生。
這個鉤子主要用于通過或多或少的通過SSL client通過session IDs來做SSL sessions。
當同時指定了ssl_certificate_by_lua*，這個鉤子通常在ssl_certificate_by_lua*之前運行。當SSL session被找到并且被當前SSL連接順利加載，SSL會話恢復會發生并且會完全繞過ssl_certificate_by_lua*鉤子。在這種情況下，Nginx也會繞過ssl_session_store_by_lua_block鉤子，因為明顯的原因。
為了使用一個現代的web瀏覽器本地測試這個鉤子，你可以暫時把下面一行放在你的https服務塊中來禁用TLS session ticket支持：
ssl_session_tickets off;
但是不要忘了在你對外發布你的網站時注釋掉這行。
如果你使用OpenResty的official pre-built packages 1.11.2.1或者更新版，那么一切都是正常工作的。
如果你使用不是由OpenResty提供的OpenSSL庫，那么你需要在OpenSSL 1.0.2h或更新版使用下面的補丁：
如果你使用OpenResty1.11.2.1或者更新版攜帶的Nginx核心，那么需要為標準的Nginx核心1.11.2或者更新版使用下面的補丁：
http://openresty.org/download/nginx-1.11.2-nonblocking_ssl_handshake_hooks.patch
這個指令首先在v0.10.6版本中被介紹。
注意：從v0.10.7版本開始，這個指令只允許在 http context 里使用。
（這是因為SSL session恢復是在server名稱dispatch之前發生）
ssl_session_fetch_by_lua_file
語法： ssl_session_fetch_by_lua_file <path-to-lua-script-file>
上下文： http
時期： right-before-SSL-handshake
和ssl_session_fetch_by_lua_block等價，除了通過<path-to-lua-script-file>指定包含Lua代碼的文件，更準確的說， Lua/LuaJIT bytecode被排除了。
當給定一個相對地址如 foo/bar.lua ，他們會根據server prefix將其轉換為絕對地址，server prefix是在啟動Nginx服務器時通過命令行參數里面的-p PATH來指定的。
這個指令在v0.10.6版本中被首次介紹。
注意：從v.0.10.7版本開始，這個指令只允許在 http context 中使用。
（這是因為SSL session恢復在server名稱dispatch之前發生）
ssl_session_store_by_lua_block
語法： ssl_session_store_by_lua_block { lua-script }
上下文： http
時期： right-after-SSL-handshake
這個指令運行Lua代碼來獲取和保存SSL session(如果有的話)，根據為當前downstream的SSL握手請求提供的session ID。這個被保存或者被緩存的SSL session數據可以被用來將來的SSL連接來恢復SSL session而不需要經歷完成的SSL握手過程（這個過程是非常耗CPU時間的）。
可能會yield的Lua API,例如ngx.sleep 和cosockets在這個上下文中是 禁用 的。然而你仍然可以使用ngx.timer.atAPI來創建一個0延遲的定時器來異步的保存SSL session數據到外部的設備中（如redis或者memcached）。
在lua-resty-core庫中的ngx.ssl.sessionLua模塊提供的Lua API獲取當前session ID和相關的session狀態數據。
為了使用現代的web瀏覽器在本地容易的測試這個鉤子，你可以臨時在你的https服務器塊中使用下面的行來禁用TLS session ticket的支持：
ssl_session_tickets off;
但是不要忘記在你公布你的網站的時候注釋掉這行。
這個指令首先在v0.10.6版本中被介紹。
注意：從v0.10.7版本開始，這個指令緊緊允許在 http content 中被使用（這是因為SSL session恢復發生在server名稱dispatch之前）。
ssl_session_store_by_lua_file
語法： ssl_session_store_by_lua_file <path-to-lua-script-file>
上下文： http
時期： right-after-SSL-handshake
和ssl_session_store_by_lua_block等價，除了通過<path-to-lua-script-file>指定包含Lua代碼的文件，精確來說，Lua/LuaJIT bytecode被排除了。
當給定一個相對的地址如foo/bar.lua，他們會根據server prefix來將其轉換為絕對地址，server prefix路徑通過啟動Nginx服務器時通過命令行參數里面的-p PATH來指定。
這個指令首先在 v0.10.6 版本中被介紹。
注意：從 v0.10.7 版本開始，這個指令只允許在 http context 中被使用。
（因為SSL session恢復發生在server名稱dispatch之前）
lua_shared_dict
語法： lua_shared_dict <name> <size>
默認： no
上下文： http
時期： denpends on usage
聲明一個共享的內存區域，<name>，基于Lua字典 ngx.shared.<name>作為一個存儲器來提供共享存儲。
共享內存區總是被當前nginx服務器實例的所有nginx工作進程共享。
這個<size>參數接受大小單位例如k和m:
http {
lua_shared_dict dogs 10m;
...
}
硬編碼的最小大小為8KB然而實際最小值依據實際的用戶數據集（一些人也從12KB開始）
查看ngx.shared.DICT的細節。
這個指令首先在 v0.3.1rc22版本中被介紹。
lua_socket_connect_timeout
語法： lua_socket_connect_timeout <time>
默認： lua_socket_connect_timeout 60s
上下文： http,server,location
這個指令控制用于TCP/unix-domain 套接字對象connect 方法的默認的超時值，并且能夠被settimeout或者settimeouts方法來覆蓋。
這個<time>參數可以是一個整數，附帶一個可選的時間單位，例如s (second), ms (millisecond), m (minute)。默認的時間單位是s，例如， "second".默認的時間是 60s。
這個指令首先在v0.5.0rc1版本中被介紹。
lua_socket_send_timeout
語法： lua_socket_send_timeout <time>
默認： lua_socket_send_timeout 60s
上下文： http,server,location
控制用于TCP/unix-domain套接字對象send方法的默認的超時值，并且能夠被settimeout或者settimeouts方法來覆蓋。
這個<time>參數可以是一個整數，附帶一個可選的時間單位，例如s (second), ms (millisecond), m (minute)。默認的時間單位是s，例如， "second".默認的時間是 60s。
這個指令首先在v0.5.0rc1版本中被介紹。
lua_socket_send_lowat
語法： lua_socket_send_lowat <size>
默認： lua_socket_send_lowat 0
上下文： http,server,location
控制cosocket send buffer的lowat (low water)值。
lua_socket_read_timeout
語法： lua_socket_read_timeout <time>
默認： lua_socket_read_timeout 60s
上下文： http,server,location
時期： depends on usage
這個指令控制在TCP/unix-domain socket 對象receive方法的默認的超時值并且通過receiveuntil方法返回迭代函數。這個設置可以被
settimeout或者settimeouts方法覆蓋。
這個<time>參數可以是一個整數，附帶一個可選的時間單位，例如s (second), ms (millisecond), m (minute)。默認的時間單位是s，例如， "second".默認的時間是 60s。
這個指令首先在v0.5.0rc1版本中被介紹。
lua_socket_buffer_size
語法： lua_socket_buffer_size <size>
默認： lua_socket_buffer_size 4k/8k
上下文： http,server,location
指定通過cosocket讀取操作所使用的緩沖區的大小。
這個緩沖區不需要大到在同一個時間把所有的東西都hold主，這是因為cosocket 100%支持非緩存的讀和解析。所以即使1 byte 緩沖大小也應該在所有地方正常工作但是表現會很糟。
這個指令首先在v0.5.0rc1版本中被介紹。
lua_socket_pool_size
語法： lua_socket_pool_size <size>
默認： lua_socket_pool_size 30
上下文： http,server,location
為每一個與遠程服務器關聯的cosocket連接池指定大小限制（根據連接數）。（如：由主機端口對或者unix域socket文件路徑來鑒定）
默認每個池30個連接。
當連接池超過可用的大小限制，在池中最近最少使用的（空閑）連接將被關閉來為當前連接騰出地方。
注意這個cosocket連接池是每個nginx工作進程的而不是每個nginx服務器實例，所以這里指定的size大小同樣也適用于每個單獨的nginx工作進程。
這個指令首先在v0.5.0rc1版本中被介紹。
lua_socket_keepalive_timeout
語法： lua_socket_keepalive_timeout <time>
默認： lua_socket_keepalive_timeout 60s
上下文 http,server,location
改指令控制在cosocket內置連接池中連接的最大空閑時間。當達到這個超時時間，空閑連接將被關閉并且從池中移除。這個何止可以被cosocket對象 setkeepalive方法覆蓋。
這個<time>參數可以是個整數，攜帶一個可選的時間單位，例如s (second), ms (millisecond), m (minute)。默認的時間單位是s，例如， "second".默認的時間是 60s。
這個指令首先在v0.5.0rc1版本中被介紹。
log_socket_log_errors
語法： lua_socket_log_errors on|off
默認： lua_socket_log_errors on
上下文： http,server,location
這個指令可以被用來開關錯誤日志當TCP或者UDP cosockets發生錯誤時。如果你已經做了適當的錯誤處理并且在你的Lua代碼里面記錄了，那么推薦將這個指令off來放著數據flush到你的nginx錯誤log文件里（這通常是非常昂貴的）。
這個指令首先在v0.5.13版本中被介紹。
lua_ssl_ciphers
語法： lua_ssl_ciphers <ciphers>
默認： lua_ssl_ciphers DEFAULT
上下文： http,server,location
在tcpsock:sslhandshake方法中指定為請求啟用SSL/TLS服務器的密碼。這個指定的密碼是OpenSSL庫中可以理解的格式。
使用“openssl ciphers”命令可以看到完成的列表。
這個指令首先在v0.9.11版本中被介紹。
lua_ssl_crl
語法： lua_ssl_crl <file>
默認： no
上下文： http,server,location
指定一個使用PEM格式的撤銷的證書（CRL）文件用來在tcpsock:sslhandshake方法中驗證SSL/TLS服務器的證書。
這個指令首先在v0.9.11版本中被介紹。
lua_ssl_protocols
語法： lua_ssl_protocols [SSLv2] [SSLv3] [TLSv1] [TLSv1.1] [TLSv1.2]
默認： lua_ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2
上下文： http,server,location
在tcpsock:sslhandshake方法中為SSL/TLS服務器的請求開啟指定的協議。
這個指令首先在v0.9.11版本中被介紹。
lua_ssl_trusted_certificate
語法： lua_ssl_trusted_certificate <file>
默認： no
上下文： http,server,location
在tcpsock:sslhandshake方法中指定一個文件路徑含有PEM格式的受信任的CA證書用來驗證SSL/TLS服務器。
這個指令首先在v0.9.11版本中被介紹。
lua_ssl_verfy_depth
語法： lua_ssl_verfy_depth <number>
默認： lua_ssl_verfy_depth 1
上下文： http,server,location
設置驗證服務器證書鏈中的深度。
這個指令首先在v0.9.11版本中被介紹。
另外請參見lua_ssl_trusted_certificate.
lua_http10_buffering
語法： lua_http10_buffering on|off
默認： lua_http10_buffering on
上下文： http,server,location,location-if
啟用或者禁用HTTP 1.0(或更老版本)請求的自動響應緩存。這種緩沖機制主要用于HTTP 1.0 keep-alive，這個依賴于響應頭中的適當的Content-Length。
如果在發送headers之前Lua代碼顯示的設置一個Content-Length響應頭（顯示的通過ngx.send_headers 或者隱式的通過ngx.say或者ngx.print調用），那么即使這個指令設置為 on 那么HTTP 1.0響應緩存也被會禁用。
為了以流媒體的方式輸出一個很大的響應數據（例如通過ngx.flush調用），這個指令必須關閉以減少內存的使用。
這個指令默認情況下是設置為 on。
這個指令首先在v0.5.0rc19版本中被介紹。
rewrite_by_lua_no_postpone
語法 rewrite_by_lua_no_postpone on|off
默認 rewrite_by_lua_no_postpone off
上下文： http
控制是否禁用推遲rewrite_by_lua* 指令在rewirte請求處理階段的末尾執行。在默認情況下，這個指令是設置為off的并且Lua代碼是在rewrite階段的末尾推遲執行的。
這個指令首先在v0.5.0rc19版本中被介紹。
access_by_lua_no_postpone
語法： access_by_lua_no_postpone on|off
默認： access_by_lua_no_postpone off
上下文： http
控制是否禁用推遲access_by_lua*指令在access請求處理階段的末尾執行。在默認情況下，這個指令是設置為off的并且Lua代碼是在access階段的末尾推遲執行的。
這個指令首先在v0.9.20版本中被介紹。
lua_transform_underscores_in_response_headers
語法： lua_transform_underscores_in_response_headers on|off
默認： lua_transform_underscores_in_response_headers on
上下文： http,server,location,location-if
控制是否轉換在ngx.header.HEADER API中指定的響應頭名稱下劃線(_)為橫線(-)。
這個指令首先在v0.5.0rc32版本中被介紹。
lua_check_client_abort
語法： lua_check_client_abort on|off
默認： lua_check_client_abort off
上下文： http,server,location,location-if
這個指令控制是否檢查過早的客戶端連接終止。
當這個指令開啟，ngx_lua模塊將會監控在downstream連接的過早的連接關閉事件并且當發生這種事件時，它會調用用戶的Lua回調函數（通過ngx.on_abort注冊的），或者當這里沒有注冊用戶回調方法時，會僅僅停止并清除掉在當前請求的請求處理器中的所有的Lua "light threads"。
根據當前的實現，然而，如果在Lua代碼通過ngx.req.socket結束讀取請求body數據之前，客戶端關閉了連接，那么ngx_lua將既不會關閉所有運行的"light threads"也不會調用用戶的回調（如果ngx.on_abort被調用了）。而是，在ngx.req.socket的讀取操作會僅僅返回"client aborted"的錯誤信息作為第二個返回值（第一個返回值肯定是nil）。
當TCP keepalive被禁用，它是依靠客戶端方優雅的關閉socket（通過發送一個FIN包或者類似的）。對于（soft）實時web程序，強烈推薦在你系統的TCP棧實現配置TCP keepalive支持來即時檢查“半開”TCP連接。
例如，在Linux上，你可以在你的nginx.conf文件中配置標準的listen指令，如下所示：
listen 80 so_keepalive=2s:2s:8
在FreeBSD上，你只能為TCP keepalive調整系統級的配置，例如：
# sysctl net.inet.tcp.keepintvl=2000
# sysctl net.inet.tcp.keepidle=2000
這個指令首先在v0.7.4版本中被介紹。
參閱ngx.on_abort。
lua_max_pending_timers
語法： lua_max_pending_timers <count>
默認： lua_max_pending_timers 1024
上下文： http
控制允許使用的最大數量的等待計時器。
等待計時器是那些還沒有過期的計時器。
當超過這個限制，ngx.timer.at調用會立刻返回nil和錯誤字符串"too many pending timers"。
這個指令首先在v0.8.0版本中被介紹。
lua_max_running_timers
語法： lua_max_running_timers <count>
默認： lua_max_running_timers 256
上下文： http
控制允許使用的最大數量的運行計數器。
運行計時器是那些用戶回調函數仍然運行的。
當超過這個限制，Nginx會停止運行新定時器到期的回調并且記錄一個錯誤信息 “N lua_max_running_timers are not enough” ，"N"是這個指令的當前值。
這個指令首先在v0.8.0版本中被介紹。
