Use case for OpenResty

mike · 2016-08-02T21:35:11+00:00

Hello! On Fri, Jul 29, 2016 at 1:56 PM, Robert Paprocki <rpap...@fearnothingproductions.net> wrote: > >> It sounds like a good exercise to po...

Use case for OpenResty

mike

I am developing the architecture for a web application with native non-browser clients communicating via binary messages through secure websockets to a server complex. Servers are configured with Ubuntu 16.04 LTS, planning on using nginx for load leveling and reverse proxy. Back-end database is planned for VoltDB, with app workers in C++. The last piece I need is the app server itself, and I just discovered OpenResty. Is it a good solution for the use-case described above? If so, are there any special considerations, particularly with C++ workers? I’m a recent escapee from the Microsoft world and don’t have hands-on familiarity with this environment. Any guidance will be much appreciated.

rpaprocki

This is a bit vague. What exactly is your web app doing? I could spit some generic openresty advice about ensuring your workers don't block and try to avoid messy string concats, but that's kinda useless without know what your nginx + lua environment is going to be doing.

Also, welcome to the world of free open source! ;)

On Aug 2, 2016, at 06:35, m...@techcitysouth.com wrote:

I am developing the architecture for a web application with native non-browser clients communicating via binary messages through secure websockets to a server complex. Servers are configured with Ubuntu 16.04 LTS, planning on using nginx for load leveling and reverse proxy. Back-end database is planned for VoltDB, with app workers in C++. The last piece I need is the app server itself, and I just discovered OpenResty. Is it a good solution for the use-case described above? If so, are there any special considerations, particularly with C++ workers? I’m a recent escapee from the Microsoft world and don’t have hands-on familiarity with this environment. Any guidance will be much appreciated.

.

mike

Thanks Robert. My main concern is about the proper way to structure C++ apps to work with the environment.

The app itself is a collection of relatively simple data-driven business transactions, primarily store-and-retrieve. It is designed to follow the microservices architecture (see https://www.nginx.com/blog/introduction-to-microservices/), with about 6 different service categories. It is fundamentally set up as MVC, with the view layer at the client and a data management layer at the back-end. No graphic rendering is done at the server and all messaging is binary data in both directions. There is a need to maintain multiple data panels at the client, with relatively heavy use of the bidirectional capabilities afforded by websocket connections. That also means that multiple services need to communicate through the same connection, which will normally remain open for lengthy periods (the services can be combined if needed, but will cause activation of threads). Session data will be maintained in the database, and sessions can span websocket connection timeouts. Idle periods beyond a specified length will cause a silent disconnect/reconnect process. We anticipate that the server will have a large number of connections open, but that cpu burden/connection will be modest. I don’t yet know enough about how OpenResty/nginx manages connections and I’m seeking the best way to accomplish this.

Mike Lowry

Email Mike@TechCitySouth.com

Phone 678-462-2338

From: openresty-en@googlegroups.com [mailto:openresty-en@googlegroups.com] On Behalf Of Robert Paprocki
Sent: Tuesday, August 2, 2016 9:47 AM
To: openresty-en@googlegroups.com
Subject: Re: [openresty-en] Use case for OpenResty

Also, welcome to the world of free open source! ;)

On Aug 2, 2016, at 06:35, m...@techcitysouth.com wrote:

I am developing the architecture for a web application with native non-browser clients communicating via binary messages through secure websockets to a server complex. Servers are configured with Ubuntu 16.04 LTS, planning on using nginx for load leveling and reverse proxy. Back-end database is planned for VoltDB, with app workers in C++. The last piece I need is the app server itself, and I just discovered OpenResty. Is it a good solution for the use-case described above? If so, are there any special considerations, particularly with C++ workers? I’m a recent escapee from the Microsoft world and don’t have hands-on familiarity with this environment. Any guidance will be much appreciated.
.

rpaprocki

Sounds like checking out the existing documents might be a good start! Have a look at agentzh's excellent tutorial series:

https://openresty.org/download/agentzh-nginx-tutorials-en.html

There's also the official nginx docs, which can be quite detailed depending on where you dig:

https://nginx.org/en/docs/

You may want to look at both the TCP streaming and HTTP reverse proxy modules, depending on your need. There's also some (a bit) dated literature on nginx architecture:

http://www.aosabook.org/en/nginx.html

Good luck with it!

On Aug 2, 2016, at 07:27, Mike Lowry <m...@techcitysouth.com> wrote:

Thanks Robert. My main concern is about the proper way to structure C++ apps to work with the environment.

The app itself is a collection of relatively simple data-driven business transactions, primarily store-and-retrieve. It is designed to follow the microservices architecture (see https://www.nginx.com/blog/introduction-to-microservices/), with about 6 different service categories. It is fundamentally set up as MVC, with the view layer at the client and a data management layer at the back-end. No graphic rendering is done at the server and all messaging is binary data in both directions. There is a need to maintain multiple data panels at the client, with relatively heavy use of the bidirectional capabilities afforded by websocket connections. That also means that multiple services need to communicate through the same connection, which will normally remain open for lengthy periods (the services can be combined if needed, but will cause activation of threads). Session data will be maintained in the database, and sessions can span websocket connection timeouts. Idle periods beyond a specified length will cause a silent disconnect/reconnect process. We anticipate that the server will have a large number of connections open, but that cpu burden/connection will be modest. I don’t yet know enough about how OpenResty/nginx manages connections and I’m seeking the best way to accomplish this.

Mike Lowry
Email Mike@TechCitySouth.com
Phone 678-462-2338

From: openresty-en@googlegroups.com [mailto:openresty-en@googlegroups.com] On Behalf Of Robert Paprocki
Sent: Tuesday, August 2, 2016 9:47 AM
To: openresty-en@googlegroups.com
Subject: Re: [openresty-en] Use case for OpenResty

This is a bit vague. What exactly is your web app doing? I could spit some generic openresty advice about ensuring your workers don't block and try to avoid messy string concats, but that's kinda useless without know what your nginx + lua environment is going to be doing.

Also, welcome to the world of free open source! ;)

On Aug 2, 2016, at 06:35, m...@techcitysouth.com wrote:
I am developing the architecture for a web application with native non-browser clients communicating via binary messages through secure websockets to a server complex. Servers are configured with Ubuntu 16.04 LTS, planning on using nginx for load leveling and reverse proxy. Back-end database is planned for VoltDB, with app workers in C++. The last piece I need is the app server itself, and I just discovered OpenResty. Is it a good solution for the use-case described above? If so, are there any special considerations, particularly with C++ workers? I’m a recent escapee from the Microsoft world and don’t have hands-on familiarity with this environment. Any guidance will be much appreciated.
.

mike

I am going through them now. I had hoped to get confirmation that the use-case is workable before investing the time to go through the learning curve.

Mike Lowry

Email Mike@TechCitySouth.com

Phone 678-462-2338

From: openresty-en@googlegroups.com [mailto:openresty-en@googlegroups.com] On Behalf Of Robert Paprocki
Sent: Tuesday, August 2, 2016 10:52 AM
To: openresty-en@googlegroups.com
Subject: Re: [openresty-en] Use case for OpenResty

Sounds like checking out the existing documents might be a good start! Have a look at agentzh's excellent tutorial series:

https://openresty.org/download/agentzh-nginx-tutorials-en.html

There's also the official nginx docs, which can be quite detailed depending on where you dig:

https://nginx.org/en/docs/

You may want to look at both the TCP streaming and HTTP reverse proxy modules, depending on your need. There's also some (a bit) dated literature on nginx architecture:

http://www.aosabook.org/en/nginx.html

Good luck with it!

On Aug 2, 2016, at 07:27, Mike Lowry <m...@techcitysouth.com> wrote:

Thanks Robert. My main concern is about the proper way to structure C++ apps to work with the environment.

The app itself is a collection of relatively simple data-driven business transactions, primarily store-and-retrieve. It is designed to follow the microservices architecture (see https://www.nginx.com/blog/introduction-to-microservices/), with about 6 different service categories. It is fundamentally set up as MVC, with the view layer at the client and a data management layer at the back-end. No graphic rendering is done at the server and all messaging is binary data in both directions. There is a need to maintain multiple data panels at the client, with relatively heavy use of the bidirectional capabilities afforded by websocket connections. That also means that multiple services need to communicate through the same connection, which will normally remain open for lengthy periods (the services can be combined if needed, but will cause activation of threads). Session data will be maintained in the database, and sessions can span websocket connection timeouts. Idle periods beyond a specified length will cause a silent disconnect/reconnect process. We anticipate that the server will have a large number of connections open, but that cpu burden/connection will be modest. I don’t yet know enough about how OpenResty/nginx manages connections and I’m seeking the best way to accomplish this.

Mike Lowry
Email Mike@TechCitySouth.com
Phone 678-462-2338

From: openresty-en@googlegroups.com [mailto:openresty-en@googlegroups.com] On Behalf Of Robert Paprocki
Sent: Tuesday, August 2, 2016 9:47 AM
To: openresty-en@googlegroups.com
Subject: Re: [openresty-en] Use case for OpenResty

This is a bit vague. What exactly is your web app doing? I could spit some generic openresty advice about ensuring your workers don't block and try to avoid messy string concats, but that's kinda useless without know what your nginx + lua environment is going to be doing.

Also, welcome to the world of free open source! ;)

On Aug 2, 2016, at 06:35, m...@techcitysouth.com wrote:
I am developing the architecture for a web application with native non-browser clients communicating via binary messages through secure websockets to a server complex. Servers are configured with Ubuntu 16.04 LTS, planning on using nginx for load leveling and reverse proxy. Back-end database is planned for VoltDB, with app workers in C++. The last piece I need is the app server itself, and I just discovered OpenResty. Is it a good solution for the use-case described above? If so, are there any special considerations, particularly with C++ workers? I’m a recent escapee from the Microsoft world and don’t have hands-on familiarity with this environment. Any guidance will be much appreciated.
.

jonathan

FWIW: We use another approach. We use OpenResty as the gateway / core coordinator for a series of webapps, some large and some designed as microservices. Most of the webapps are Python and use uwsgi as the appserver/container. We use OpenResty instead of nginx, because it gives us access to numerous hooks (such as customized ssl) and we're able to integrate routing and caching directly into the gateway.

mike

That sounds pretty much like what we are seeking to do, except that we need to use C++ app modules. I’m not quite far enough into OpenResty yet to figure out how to activate them and manage the connections. We definitely need to have interaction at the websocket connection request point and be able to manage multiple services using the same connection.

Mike Lowry

Email Mike@TechCitySouth.com

Phone 678-462-2338

From: openresty-en@googlegroups.com [mailto:openresty-en@googlegroups.com] On Behalf Of jon...@findmeon.com
Sent: Tuesday, August 2, 2016 11:49 AM
To: openresty-en <openresty-en@googlegroups.com>
Subject: [openresty-en] Re: Use case for OpenResty

jonathan

On Tuesday, August 2, 2016 at 1:04:23 PM UTC-4, Mike Lowry wrote:

That sounds pretty much like what we are seeking to do, except that we need to use C++ app modules. I’m not quite far enough into OpenResty yet to figure out how to activate them and manage the connections. We definitely need to have interaction at the websocket connection request point and be able to manage multiple services using the same connection.

We're *mostly* using a proxypass to communicate with the applications, which run independently. We also use some of the libraries that leverage cosockets to communicate with them at other points (and some processing/serving is done entirely in openresty too, but that is a slow migration).

You can manage/coordinate websockets within openresty (see https://github.com/openresty/lua-resty-websocket), so the question is really just going to be how you want to stack services and coordinate. You'll probably discover that resty is flexible enough that you won't be constrained by tech - and your design decisions will likely just dictate which modules you use.

wojonstech

Mike,

So Where i work we are in the IOT space and we are currently doing a POC to use openresty for our socket server we spent the last few days rebuilding our protocol using nginx socket streams and are going to begin testing but it is already looking very promising.

On Tuesday, August 2, 2016 at 8:01:59 AM UTC-7, Mike Lowry wrote:

I am going through them now. I had hoped to get confirmation that the use-case is workable before investing the time to go through the learning curve.

Mike Lowry
Email Mike@TechCitySouth.com
Phone 678-462-2338

From: openre...@googlegroups.com [mailto:openre...@googlegroups.com] On Behalf Of Robert Paprocki
Sent: Tuesday, August 2, 2016 10:52 AM
To: openre...@googlegroups.com
Subject: Re: [openresty-en] Use case for OpenResty

Sounds like checking out the existing documents might be a good start! Have a look at agentzh's excellent tutorial series:

https://openresty.org/download/agentzh-nginx-tutorials-en.html

There's also the official nginx docs, which can be quite detailed depending on where you dig:

https://nginx.org/en/docs/

You may want to look at both the TCP streaming and HTTP reverse proxy modules, depending on your need. There's also some (a bit) dated literature on nginx architecture:

http://www.aosabook.org/en/nginx.html

Good luck with it!
On Aug 2, 2016, at 07:27, Mike Lowry <mi...@techcitysouth.com> wrote:
Thanks Robert. My main concern is about the proper way to structure C++ apps to work with the environment.

The app itself is a collection of relatively simple data-driven business transactions, primarily store-and-retrieve. It is designed to follow the microservices architecture (see https://www.nginx.com/blog/introduction-to-microservices/), with about 6 different service categories. It is fundamentally set up as MVC, with the view layer at the client and a data management layer at the back-end. No graphic rendering is done at the server and all messaging is binary data in both directions. There is a need to maintain multiple data panels at the client, with relatively heavy use of the bidirectional capabilities afforded by websocket connections. That also means that multiple services need to communicate through the same connection, which will normally remain open for lengthy periods (the services can be combined if needed, but will cause activation of threads). Session data will be maintained in the database, and sessions can span websocket connection timeouts. Idle periods beyond a specified length will cause a silent disconnect/reconnect process. We anticipate that the server will have a large number of connections open, but that cpu burden/connection will be modest. I don’t yet know enough about how OpenResty/nginx manages connections and I’m seeking the best way to accomplish this.

Mike Lowry
Email Mike@TechCitySouth.com
Phone 678-462-2338

From: openre...@googlegroups.com [mailto:op...@googlegroups.com] On Behalf Of Robert Paprocki
Sent: Tuesday, August 2, 2016 9:47 AM
To: openre...@googlegroups.com
Subject: Re: [openresty-en] Use case for OpenResty

This is a bit vague. What exactly is your web app doing? I could spit some generic openresty advice about ensuring your workers don't block and try to avoid messy string concats, but that's kinda useless without know what your nginx + lua environment is going to be doing.

Also, welcome to the world of free open source! ;)

On Aug 2, 2016, at 06:35, mi...@techcitysouth.com wrote:
I am developing the architecture for a web application with native non-browser clients communicating via binary messages through secure websockets to a server complex. Servers are configured with Ubuntu 16.04 LTS, planning on using nginx for load leveling and reverse proxy. Back-end database is planned for VoltDB, with app workers in C++. The last piece I need is the app server itself, and I just discovered OpenResty. Is it a good solution for the use-case described above? If so, are there any special considerations, particularly with C++ workers? I’m a recent escapee from the Microsoft world and don’t have hands-on familiarity with this environment. Any guidance will be much appreciated.
.

wojonstech

Mike,

So our first round of tests came back around 10k devices for about 0.1 load avg on c4 class aws instances

On Friday, August 12, 2016 at 11:28:54 AM UTC-7, Alexis Okuwa wrote:

Mike,

So Where i work we are in the IOT space and we are currently doing a POC to use openresty for our socket server we spent the last few days rebuilding our protocol using nginx socket streams and are going to begin testing but it is already looking very promising.

On Tuesday, August 2, 2016 at 8:01:59 AM UTC-7, Mike Lowry wrote:
I am going through them now. I had hoped to get confirmation that the use-case is workable before investing the time to go through the learning curve.

Mike Lowry
Email Mike@TechCitySouth.com
Phone 678-462-2338

From: openre...@googlegroups.com [mailto:openre...@googlegroups.com] On Behalf Of Robert Paprocki
Sent: Tuesday, August 2, 2016 10:52 AM
To: openre...@googlegroups.com
Subject: Re: [openresty-en] Use case for OpenResty

Sounds like checking out the existing documents might be a good start! Have a look at agentzh's excellent tutorial series:

https://openresty.org/download/agentzh-nginx-tutorials-en.html

There's also the official nginx docs, which can be quite detailed depending on where you dig:

https://nginx.org/en/docs/

You may want to look at both the TCP streaming and HTTP reverse proxy modules, depending on your need. There's also some (a bit) dated literature on nginx architecture:

http://www.aosabook.org/en/nginx.html

Good luck with it!
On Aug 2, 2016, at 07:27, Mike Lowry <mi...@techcitysouth.com> wrote:
Thanks Robert. My main concern is about the proper way to structure C++ apps to work with the environment.

The app itself is a collection of relatively simple data-driven business transactions, primarily store-and-retrieve. It is designed to follow the microservices architecture (see https://www.nginx.com/blog/introduction-to-microservices/), with about 6 different service categories. It is fundamentally set up as MVC, with the view layer at the client and a data management layer at the back-end. No graphic rendering is done at the server and all messaging is binary data in both directions. There is a need to maintain multiple data panels at the client, with relatively heavy use of the bidirectional capabilities afforded by websocket connections. That also means that multiple services need to communicate through the same connection, which will normally remain open for lengthy periods (the services can be combined if needed, but will cause activation of threads). Session data will be maintained in the database, and sessions can span websocket connection timeouts. Idle periods beyond a specified length will cause a silent disconnect/reconnect process. We anticipate that the server will have a large number of connections open, but that cpu burden/connection will be modest. I don’t yet know enough about how OpenResty/nginx manages connections and I’m seeking the best way to accomplish this.

Mike Lowry
Email Mike@TechCitySouth.com
Phone 678-462-2338

From: openre...@googlegroups.com [mailto:op...@googlegroups.com] On Behalf Of Robert Paprocki
Sent: Tuesday, August 2, 2016 9:47 AM
To: openre...@googlegroups.com
Subject: Re: [openresty-en] Use case for OpenResty

This is a bit vague. What exactly is your web app doing? I could spit some generic openresty advice about ensuring your workers don't block and try to avoid messy string concats, but that's kinda useless without know what your nginx + lua environment is going to be doing.

Also, welcome to the world of free open source! ;)

On Aug 2, 2016, at 06:35, mi...@techcitysouth.com wrote:
I am developing the architecture for a web application with native non-browser clients communicating via binary messages through secure websockets to a server complex. Servers are configured with Ubuntu 16.04 LTS, planning on using nginx for load leveling and reverse proxy. Back-end database is planned for VoltDB, with app workers in C++. The last piece I need is the app server itself, and I just discovered OpenResty. Is it a good solution for the use-case described above? If so, are there any special considerations, particularly with C++ workers? I’m a recent escapee from the Microsoft world and don’t have hands-on familiarity with this environment. Any guidance will be much appreciated.
.

evan

OpenResty uses LuaJIT, which can be extended with C++. So you can either create a C++ shared library loaded by LuaJIT (google around for C++ binding libraries) or expose a C API yourself (just functions and structs) and bind it with the LuaJIT FFI (very performant). You could then use that library in your Lua request handlers or in resty-cli usage.

On Tuesday, August 2, 2016 at 1:04:23 PM UTC-4, Mike Lowry wrote:

That sounds pretty much like what we are seeking to do, except that we need to use C++ app modules. I’m not quite far enough into OpenResty yet to figure out how to activate them and manage the connections. We definitely need to have interaction at the websocket connection request point and be able to manage multiple services using the same connection.

Mike Lowry
Email Mike@TechCitySouth.com
Phone 678-462-2338

From: openre...@googlegroups.com [mailto:openre...@googlegroups.com] On Behalf Of jona...@findmeon.com
Sent: Tuesday, August 2, 2016 11:49 AM
To: openresty-en <openre...@googlegroups.com>
Subject: [openresty-en] Re: Use case for OpenResty

FWIW: We use another approach. We use OpenResty as the gateway / core coordinator for a series of webapps, some large and some designed as microservices. Most of the webapps are Python and use uwsgi as the appserver/container. We use OpenResty instead of nginx, because it gives us access to numerous hooks (such as customized ssl) and we're able to integrate routing and caching directly into the gateway.
.