Environment: init_worker_by_lua, set_by_lua, rewrite_by_lua, access_by_lua, content_by_lua, header_filter_by_lua, body_filter_by_lua, log_by_lua, ngx.timer., balancer_by_lua
This Lua table can be used to store request-based Lua environment data, and its lifetime is the same as the current request (similar to Nginx variables).
Refer to the following example,
location /test {
rewrite_by_lua_block {
ngx.ctx.foo = 76
}
access_by_lua_block {
ngx.ctx.foo = ngx.ctx.foo 3
}
content_by_lua_block {
ngx.say(ngx.ctx.foo)
}
}
Access GET /test output
79
That is, ngx.ctx.foo entries are consistent across the rewrite, access, and content processing stages of a request.
Each request, including subrequests, has its own ngx.ctx table. For example:
location /sub {
content_by_lua_block {
ngx.say("sub pre: ", ngx.ctx.blah)
ngx.ctx.blah = 32
ngx.say("sub post: ", ngx.ctx.blah)
}
}
location /main {
content_by_lua_block {
ngx.ctx.blah = 73
ngx.say("main pre: ", ngx.ctx.blah)
Local res = ngx.location.capture("/sub")
ngx.print(res.body)
ngx.say("main post: ", ngx.ctx.blah)
}
}
Access GET /main output
main pre: 73
sub pre: nil
sub post: 32
main post: 73
Here, modifying the ngx.ctx.blah entry in the child request does not affect the entry with the same name in the parent request, since they each maintain a different version of ngx.ctx.blah.
The internal redirect will destroy the ngx.ctx data (if any) in the original request, and the new request will have an empty ngx.ctx table. For example,
location /new {
content_by_lua_block {
ngx.say(ngx.ctx.foo)
}
}
location /orig {
content_by_lua_block {
ngx.ctx.foo = "hello"
ngx.exec("/new")
}
}
Accessing GET /orig will output
nil
instead of the original "hello" value.
Arbitrary data values, including Lua closures and nested tables, can be inserted into this "magic" table, which also allows custom metamethods to be registered.
It is also possible to overwrite ngx.ctx with a new Lua table, for example,
ngx.ctx = { foo = 32, bar = 54 }
When used in an init_worker_by_lua* environment, this table is identical to the current Lua handle lifetime.
ngx.ctx table queries require relatively expensive meta-method calls, which are much slower than passing request-based data directly through the user's own function parameters. So don't abuse this API just to save user function parameters, as it may have a significant impact on performance.
And because of the metamethod "magic", don't try to use "local" level ngx.ctx at the lua module level, for example worker-level data sharing. The following example is bad:
-- mymodule.lua
local _M = {}
-- The ngx.ctx in the following line belongs to a single request, but the ctx variable is at the Lua module level
-- and belongs to a single worker.
local ctx = ngx.ctx
function _M.main()
ctx.foo = "bar"
end
return _M
The following should be used instead:
-- mymodule.lua
local _M = {}
function _M.main(ctx)
ctx.foo = "bar"
end
return _M
That is to say, the caller's call to the ctx table should be completed by passing function parameters.
The above is the detailed content of How nginx uses ctx to achieve data sharing. For more information, please follow other related articles on the PHP Chinese website!

NGINXUnit can be used to deploy and manage applications in multiple languages. 1) Install NGINXUnit. 2) Configure it to run different types of applications such as Python and PHP. 3) Use its dynamic configuration function for application management. Through these steps, you can efficiently deploy and manage applications and improve project efficiency.

NGINX is more suitable for handling high concurrent connections, while Apache is more suitable for scenarios where complex configurations and module extensions are required. 1.NGINX is known for its high performance and low resource consumption, and is suitable for high concurrency. 2.Apache is known for its stability and rich module extensions, which are suitable for complex configuration needs.

NGINXUnit improves application flexibility and performance with its dynamic configuration and high-performance architecture. 1. Dynamic configuration allows the application configuration to be adjusted without restarting the server. 2. High performance is reflected in event-driven and non-blocking architectures and multi-process models, and can efficiently handle concurrent connections and utilize multi-core CPUs.

NGINX and Apache are both powerful web servers, each with unique advantages and disadvantages in terms of performance, scalability and efficiency. 1) NGINX performs well when handling static content and reverse proxying, suitable for high concurrency scenarios. 2) Apache performs better when processing dynamic content and is suitable for projects that require rich module support. The selection of a server should be decided based on project requirements and scenarios.

NGINX is suitable for handling high concurrent requests, while Apache is suitable for scenarios where complex configurations and functional extensions are required. 1.NGINX adopts an event-driven, non-blocking architecture, and is suitable for high concurrency environments. 2. Apache adopts process or thread model to provide a rich module ecosystem that is suitable for complex configuration needs.

NGINX can be used to improve website performance, security, and scalability. 1) As a reverse proxy and load balancer, NGINX can optimize back-end services and share traffic. 2) Through event-driven and asynchronous architecture, NGINX efficiently handles high concurrent connections. 3) Configuration files allow flexible definition of rules, such as static file service and load balancing. 4) Optimization suggestions include enabling Gzip compression, using cache and tuning the worker process.

NGINXUnit supports multiple programming languages and is implemented through modular design. 1. Loading language module: Load the corresponding module according to the configuration file. 2. Application startup: Execute application code when the calling language runs. 3. Request processing: forward the request to the application instance. 4. Response return: Return the processed response to the client.

NGINX and Apache have their own advantages and disadvantages and are suitable for different scenarios. 1.NGINX is suitable for high concurrency and low resource consumption scenarios. 2. Apache is suitable for scenarios where complex configurations and rich modules are required. By comparing their core features, performance differences, and best practices, you can help you choose the server software that best suits your needs.


Hot AI Tools

Undresser.AI Undress
AI-powered app for creating realistic nude photos

AI Clothes Remover
Online AI tool for removing clothes from photos.

Undress AI Tool
Undress images for free

Clothoff.io
AI clothes remover

Video Face Swap
Swap faces in any video effortlessly with our completely free AI face swap tool!

Hot Article

Hot Tools

MantisBT
Mantis is an easy-to-deploy web-based defect tracking tool designed to aid in product defect tracking. It requires PHP, MySQL and a web server. Check out our demo and hosting services.

Dreamweaver Mac version
Visual web development tools

SublimeText3 Mac version
God-level code editing software (SublimeText3)

PhpStorm Mac version
The latest (2018.2.1) professional PHP integrated development tool

WebStorm Mac version
Useful JavaScript development tools