As it stands, though, the module system would be very helpful for OS packagers, because they don't have to worry about signature mismatch.
This is going to create headaches for anyone wanting to package nginx, either they will have to compile all the modules when building nginx (creating many sub-packages) or there will have to be coordination between package maintainers to do a mass rebuild of all loadable modules every time the nginx package gets bumped. Neither situation is desirable, and I hope they release a stable ABI because until then nobody is going to waste time packaging loadable modules.
Of course, serving the output would be harder, but still not impossible.
Plus, if there's a custom module you'd really like to have in your nginx you're practically forced into building your own because there's no way to get that module loaded into the distro nginx.
Yes. There's some overhead to dynamic modules. Yes. There's a (minuscule) performance advantage to static linking.
But having the ability to ship modules independently of the web server core is a very important usability feature which, frankly, outweighs the performance overhead for most installs.
If you're really CPU bound on that nginx instance where you need the additional modules and you removing that overhead gives you that little bit extra performance you need, then you always have the option of hard-linking them.
Is that actually true? I would have thought networking latency overshadows any memory latency introduced in a `call foo@PLT` v. `call *(foo@GOT)`.
Are you aware of anyone who has benchmarked this? i.e. not a microbenchmark e.g. inside something like nginx?
If so, it might be worth fixing the dynamic linker: the cost difference is absolutely fixable, as it's a tradeoff for sharing pages with other processes.
I guess it allows us to split the nginx-included modules into separate packages, but it does nothing to aid with packaging extra modules until nginx provides a stable ABI for modules to use.
load webserver.nlm
Seems an odd feature for 1.9.11, why not wait for 2.0?
In NGINX 1.9.11 onwards a new way of loading modules dynamically has been introduced. This means that selected modules can be loaded into NGINX at runtime based on configuration files. They can also be unloaded by editing the configuration files and reloading NGINX.
I just see a single bullet point regarding "Dynamic modules", anywhere I can get more info?
http://nginx.org/en/docs/http/ngx_http_stub_status_module.ht...
I'm using the nginx mainline PPA and didn't have a problem enabling it.
This module is not built by default, it should be enabled
with the --with-http_stub_status_module configuration
parameter
Nginx is the only server software that I have to compile myself, just to get a basic status feature. It's a way to upsale people to their NginxPlus which offer a lot more status data in the binary.
We'll take a read through the comments here and are looking forward to answering questions and receive feedback. You may also email the NGINX development mailing list (info in blog post).
(I work @ NGINX).
I've just created a separate HN submission pointing to your blog post.
I hope you don't mind.
Keep up the amazing work!
It's worth to note that an nginx fork called Tengine (by Taobao) has a similar feature before.
While I'm not on the bandwagon that says all Apache installations would be better on nginx (and I still run Apache on all of our servers, except nginx test machines), I do think this makes the case quite a bit more compelling, particularly for people who package and distribute the web server (OS vendors, control panel maintainers like me, container builders, etc.).
load_module "modules/ngx_http_image_filter_module.so";
load_module "modules/ngx_http_headers_more_filter_module.so";
load_module "modules/ngx_http_set_misc_module.so";
load_module "modules/ngx_http_echo_module.so";
load_module "modules/ngx_http_geoip_module.so";
load_module "modules/ngx_stream_module.so";