Disable component

royc · 2016-06-28T18:37:58+00:00

Cool, I understand the process and timeline now. I can tell you that the http/2 fix patched clearnly to Openresty 1.9.15.1, so I am pretty confident tha...

Disable component

royc

Hi There,

First, the openeresty bundle is great!

Second, I didn't found any documentation for disabling components that are enabled by default.

How can I choose which component to load?

How can I disable component that is automatically load.

rpaprocki

What do you need disabled? What do you need enabled? Why would you need to disable something?

Also, by "components", do you mean Nginx modules written in C? Lua modules? What specifically are you trying to accomplish?

On Tuesday, June 28, 2016 at 3:37:58 AM UTC-7, Roy Cohen wrote:

Hi There,

First, the openeresty bundle is great!
Second, I didn't found any documentation for disabling components that are enabled by default.
How can I choose which component to load?
How can I disable component that is automatically load.

royc

There are many compiled components that I'm not using and as far as I understand the less modules you compile to NGINX to faster it works.

I'm almost sure that my statement above is correct, if not it would be great if you can share your thoughts.

I'm not using all the modules which compiled with NGINX. For example:

On Wednesday, June 29, 2016 at 3:25:23 AM UTC+3, rpaprocki wrote:

What do you need disabled? What do you need enabled? Why would you need to disable something?

Also, by "components", do you mean Nginx modules written in C? Lua modules? What specifically are you trying to accomplish?

On Tuesday, June 28, 2016 at 3:37:58 AM UTC-7, Roy Cohen wrote:
Hi There,

First, the openeresty bundle is great!
Second, I didn't found any documentation for disabling components that are enabled by default.
How can I choose which component to load?
How can I disable component that is automatically load.

rpaprocki

On Tue, Jun 28, 2016 at 10:12 PM, Roy Cohen <r...@panda-os.com> wrote:

There are many compiled components that I'm not using and as far as I understand the less modules you compile to NGINX to faster it works.

I'm almost sure that my statement above is correct, if not it would be great if you can share your thoughts.

I strongly doubt that you'll end up with improved performance because some modules were not built. You will indeed build a smaller binary, but that's not likely to have any measurable impact on performance, given Nginx's architecture.

I'm not using all the modules which compiled with NGINX. For example:
ArrayVarNginxModule
AuthRequestNginxModule
CoolkitNginxModule
DrizzleNginxModule
EchoNginxModule
EncryptedSessionNginxModule
FormInputNginxModule
HeadersMoreNginxModule
IconvNginxModule
StandardLuaInterpreter
MemcNginxModule
LuaRestyUploadLibrary
LuaRestyUpstreamHealthcheckLibrary
LuaRestyWebSocketLibrary
LuaUpstreamNginxModule
PostgresNginxModule
RdsCsvNginxModule
RdsJsonNginxModule
RedisNginxModule
Redis2NginxModule
RestyCLI
SetMiscNginxModule
SrcacheNginxModule
XssNginxModule

You can disable compiling in this modules at compile-time with the configure script. See ./configure --help for details when building OpenResty.

jonathan

On Wednesday, June 29, 2016 at 1:12:59 AM UTC-4, Roy Cohen wrote:

There are many compiled components that I'm not using and as far as I understand the less modules you compile to NGINX to faster it works.

Coming to OpenResty after 10 years of nginx, I tested that theory several years ago, and you are right -- fewer modules = smaller binary = eventual performance improvements.

The improvements are negligible though, and have no measurable effect in the real world. You're not going to free up enough memory that lets you run more instances of anything or expand workmem of anything else to have an impact.

You'll also end up in the situation where you realize you need a module, then have to recompile / test / redeploy. It is a pain.

royc

Hi,

I've tested it many many times and there might be a big performance gain.

NGINX is working async with sort of a HOCK mechanism.

The less modules which involves the hock process the less work NGINX do.

Let's say that we have several modules which are executed in some phase in NGINX, they will be executed in every request.

Maybe for standard web apps it's ok, but I want to gain the best out of NGINX, and in my tests i saw it improves significantly.

Allocating memory and every raw of code can be important in some cases.

Thanks for "./configure --help", I will take a look into that, and if I'll find there the solution then it will be great.

On Wednesday, June 29, 2016 at 7:12:53 PM UTC+3, jona...@findmeon.com wrote:

On Wednesday, June 29, 2016 at 1:12:59 AM UTC-4, Roy Cohen wrote:
There are many compiled components that I'm not using and as far as I understand the less modules you compile to NGINX to faster it works.

Coming to OpenResty after 10 years of nginx, I tested that theory several years ago, and you are right -- fewer modules = smaller binary = eventual performance improvements.

The improvements are negligible though, and have no measurable effect in the real world. You're not going to free up enough memory that lets you run more instances of anything or expand workmem of anything else to have an impact.

You'll also end up in the situation where you realize you need a module, then have to recompile / test / redeploy. It is a pain.

agentzh

Hello!

On Wed, Jun 29, 2016 at 9:36 AM, Roy Cohen wrote:
> I've tested it many many times and there might be a big performance gain.
> NGINX is working async with sort of a HOCK mechanism.
> The less modules which involves the hock process the less work NGINX do.
> Let's say that we have several modules which are executed in some phase in
> NGINX, they will be executed in every request.

Well, the truth is almost all the OpenResty modules only register
hooks when you actually reference their directives in your nginx.conf.
This even applies to output filter modules and access/rewrite phase
handler modules, which is unusual in the 3rd-party NGINX module world.
And I'm pretty proud of that.

Significant efforts have been put on ensuring that you do not pay if
you do not use :)

And yes, you can still disable modules at build time via ./configure's
--without-xxx options if you are a minimalist. See ./configure --help
for a complete list of such options.

Best regards,
-agentzh