Re: Openresty : security, upgrades

agentzh · 2013-01-31T03:19:56+00:00

Am 11.02.2013 20:35 schrieb "agentzh" <age...@gmail.com>: > On Mon, Feb 11, 2013 at 2:42 AM, Onur Bozkurt wrote: > > Also I tried...

Re: Openresty : security, upgrades

agentzh

Hello!

On Wed, Jan 30, 2013 at 2:07 AM, alain meunier wrote:
> I just discovered your bundle for nginx.
> Seems nice, but rather difficult to maintain on a production environment (it
> is very difficult -performance-wise on the server-side to compile the new
> version at every update).
>

People usually prepare their own binary RPM or Debian packages for
ngx_openresty when deploying it in production.

You're welcome to contribute your own binary packages.

As the maintainer of ngx_openresty, I do not have the resource (yet)
to maintain official binary packages for every operating system (and
every Linux distribution). And you may understand that :)

> I am on debian64. Any plan to introduce it in the binary repos ?

I think it's better to ask the debian repository maintainers instead of me :)

> If there is no chance, do you have a "quick install" way to do things
> without breaking all the settings already in place ?
>

I don't understand how ngx_openresty will break all your existing
settings. Can you elaborate?

> Is it safe to use it in production environment ? Secure ?
>

Many big Internet companies have been running ngx_openresty (or its
core components) for really busy online services for long. Taobao,
Qunar, Sina, 360, NTES, Tencent, Reblaze, CloudFlare, just to name a
few.

> Your benchmark is impressive and can help saving lot of money if there is a,
> say,  2x (at min) improvement over standart nginx on real application.
>

Actually it's common to see more than 2x speedup after migrating PHP
services over to ngx_openresty/Lua. For example, this company has
observed 7x speedup for their production services:

    http://visualwebsiteoptimizer.com/split-testing-blog/geo-distributed-architecture/

> I don't really understand how your version could be faster. Did you rewrite
> parts of the code ?
>

If you use ngx_openresty in exactly the same way as the vanilla Nginx,
then you'll not see any difference because ngx_openresty bundles the
vanilla Nginx core (except some important bug fixes in the core).

You'll only see dramatic improvement when you port your application
logic over to Lua and run it on the ngx_lua module, which is the core
component bundled by ngx_openresty:

    http://wiki.nginx.org/HttpLuaModule

BTW, I'm cc'ing the openresty-en mailing list:
https://groups.google.com/group/openresty-en And you're very welcome
to join there :)

Best regards,
-agentzh

brian

On Wed, Jan 30, 2013 at 2:19 PM, agentzh <age...@gmail.com> wrote:
> People usually prepare their own binary RPM or Debian packages for
> ngx_openresty when deploying it in production.

I have a shell script that does builds of openresty (along with some
other 3rd party modules) and packages it as deb's and uploads them to
our internal apt repo.  Took an afternoon to write the script and I
just kick it off when I need a new build and it taks ~ 10 minutes or
so as I run it on a virtualbox vm on my laptop.  I do the actual
packaging using fpm - https://github.com/jordansissel/fpm

perusio

On 30 Jan 2013 20h19 CET, age...@gmail.com wrote:

Hello agentzh,

Going off in tangent here:

<snip>

> Many big Internet companies have been running ngx_openresty (or its
> core components) for really busy online services for long. Taobao,
> Qunar, Sina, 360, NTES, Tencent, Reblaze, CloudFlare, just to name a
> few.
>
>> Your benchmark is impressive and can help saving lot of money if
>> there is a, say, 2x (at min) improvement over standart nginx on
>> real application.
>>

I'm working on a mass SSL hosting project. I've discovered that when
trying to load 50k hosts (server blocks) the Lua VM bombs out with:

       Reloading nginx configuration: nginx: [error] failed to
       initialize Lua VM in /etc/nginx/nginx.conf:192 nginx:
       configuration file /etc/nginx/nginx.conf test failed

As you can see it happens during the configuration testing. I'm not
familiar with the specific way Lua is implemented inside Nginx, but
we've hit bottleneck here. It loads 50k SSL hosts w/o problem. This is
Nginx build w/o Lua.

Is this normal? Or is just an artifact due to disappear in the near
future as the Lua implementation inside Nginx progresses?

Thank you,
--- appa

PS: Anyone else has any input to give on this matter? Please speak
your mind on the subject.

agentzh

Hello!

On Wed, Jan 30, 2013 at 7:09 PM, António P. P. Almeida wrote:
> I'm working on a mass SSL hosting project. I've discovered that when
> trying to load 50k hosts (server blocks) the Lua VM bombs out with:
>
>        Reloading nginx configuration: nginx: [error] failed to
>        initialize Lua VM in /etc/nginx/nginx.conf:192 nginx:
>        configuration file /etc/nginx/nginx.conf test failed
>

It looks like a memory allocation issue when initializing the Lua VM.

Are you using LuaJIT 2.0? If yes, then your Nginx may just eat up the
low 4GB process address space that is required by LuaJIT's memory
allocator.

You can check out the discussions and workarounds proposed by Robert
Gabriel Jakabosky at the end of thread:

    https://github.com/chaoslawful/lua-nginx-module/issues/148

BTW, please start new topic when discussing unrelated issues :) Thank you.

Best regards,
-agentzh