I'm writing a program in C++ that will run all the time in the background to do different tasks - a deamon.
Apart from it's usual tasks a web application should communicate with it (AJAX requests in doing a COMET pattern = lots of open but sleeping connections).
So the question is: how should I connect it to the web server (apache and lighttpd are relevant)?
Of what I've read FastCGI would be very interesting for that task, but all references I've read were talking about the web server starting the FastCGI application when necessary. This wouldn't work here as the deamon would already be running...
I've also read that the web server would talk via socets with the FastCGI application - so that could be an entry point for me, the deamon would "only" need to talk to such a socket.
But are there good libraries available for that?
Looking at the features of http://cppcms.com/wikipp/en/page/main it looks very interesting for me - but could that work in my case? And could it be stripped down - offering even a SQL connection is far too heavy for my case...
So what advice can you give me?
PS: Performance wise I recon a single threaded but asynchronous implementation would work for the deamon <-> web server glue.
FastCGI is the standard protocol to communicate with the web server. All mentioned web servers can communicate with the remote deamon application via fastcgi.
http://cppcms.com/wikipp/en/page/cppcms_1x_tut_web_server_config
Also if you are looking for Comet support, that what CppCMS provides you natively:
http://blog.cppcms.com/post/107
And could it be stripped down - offering even a SQL connection is far too heavy for my case...
CppCMS library is very small also it allows to reduce its size:
http://cppcms.com/wikipp/en/page/cppcms_1x_build#Build.Options
also SQL connectivity CppDB is independent part.
Performance wise I recon a single threaded but asynchronous implementation would work for the deamon <-> web server glue.
It is one of the standard CppCMS run mode - running asynchronous web applications.
Update:
Of what I've read FastCGI would be very interesting for that task, but all references I've read were talking about the web server starting the FastCGI application when necessary. This wouldn't work here as the deamon would already be running..
Indeed some web servers start the fast cgi applications but:
Lighttpd allows both to start FastCGI and SCGI application or connect to independent one
Cherokee (AFAIR) allows both to start FastCGI and SCGI application or connect to independent one
Apache:
mod_fascgi allows both to start FastCGI application or connect to independent one
mod_scgi connects to independent application - does not start application.
mod_fcgid always starts application - does not suite you
Also as general note, apache does not suit a pattern of working with many idle connections as it uses thread (or even process depending mpm) per connection.
Nginx - does not start applications at all, however for fastcgi currently not the best for comet streaming because of buffering, so SCGI would be better with nginx (assuming you are using latest nginx version)
Small note: SCGI is a protocol that is very similar to FastCGI but significantly simpler.
Related
I'm a bit underwhelmed by the Nginx module documentation. I've a lot of C++ code, and a REST Service already running using Boost Beast, and I'd like to compare performance between Beast and NGINX using the C++ module interface against a Benchmark I'll write accordingly to my needs.
I've seen this tutorial here: https://www.evanmiller.org/nginx-modules-guide.html
But I've thus far not seen a concise, short example to just get started.
Is there a hidden documentation? Alternatively, do you have an example showing how to use Nginx as a REST service in C(++)?
Short answer: Do not embed any application code into nginx.
Long answer:
You can make new nginx module to help nginx to do its work better, for example:
add some new method of authentication
or some new transport to back-end, like shared memory.
Nginx was designed to serve static content, proxy requests and do some filtering like modifying headers.
Main objective of nginx - do these things as fast as possible and spend as less resources as possible.
It allows your application server to scale dynamically without affecting currently connected users.
Nginx is good web server but was never designed to become application server.
It does not makes much sense to embed application logic into nginx just because it is built with C language.
If you need to have the best of both worlds (proxy, static files and rest server) then just use them both (nginx and Beast) with each having its own responsibility.
Nginx will take care of balancing, encryption and any other non-application specific function and app server will do its work.
Nginx's architecture is based on non-blocking network/file calls and all connections are served in a single thread and Nginx do it well because it just shuffles data back and forth.
If the code of your application can generate content fast and without blocking calls to external services then you could embed your app into nginx with consequences of loosing scalability. And if some part of your app requires CPU bound work or blocking calls then you need to move such things off main networking loop and it complicates things "a bit".
By embedding your logic into nginx you could probably save some microseconds and file handles on communications.
For multi-user websocket app like chat or stock feed (i.e. app with long-term open connections) it could liberate extra resources but for the REST app with fast responses it would not make any gain.
Your REST app most likely uses SSL encryption. This encryption adds much more microseconds(milliseconds) to your response time compared to what you could gain by such implementation.
My advice: Leave nginx to do its things and do not interfere with it
Background: I've got an C++/Qt-based application that communicates with servers on the user's LAN. It uses non-blocking TCP and UDP sockets, and the networking is implemented via calls to the BSD sockets API (i.e. socket()/send()/recv()/select()/etc). It all works well.
The other day, just for fun, I decided to recompile the application using emscripten, so that it could run as a WebAssembly app inside a web browser.
This worked surprisingly well -- within an hour or two, I had my app up and running inside Google Chrome. However, the app's usefulness in this configuration is severely limited by the fact that it isn't able to connect to any servers -- presumably this is because it is running in a restricted/sandboxed environment.
If I wanted to pursue this line of development beyond the clever-hack-demo stage and try to make it useful, I would need to find a way for my program to discover and connect to servers on the user's LAN.
My question is: is that functionality at all possible for a Emscripten/WebAssembly-based app to perform? If so, what steps would I need to take? (i.e. would it require upgrading the LAN's servers to handle WebSocket-based connections? Would it require adding some sort of proxy server to run on the web server that the web page was served from? Is UDP even a thing in a web-app context? Are there other hoops that would also have to be jumped through?)
Nginx is my WEB Server,and there is a TCP Server used for processing data.I want to use fcgi process to communicate with TCP Server,the fcgi process is code in C++.I need a process manager between WEB Server and C++ fcgi.
Actually,I found a C++ fcgi process manager ---- "spawn_fcgi".But in my case,it always lost connections in stress test(maybe the problem came from the C++ fastcgi++2.1，a third party library，but I'm not sure).
Now, I want to change some part to locate problem,but I only find "spawn_fcgi",is there another C++ fcgi process manager?
Anyway,apologize for my bad English and thanks in advance.
In the Django docs for setting up mod_wsgi, the tutorial notes:
Django doesn’t serve files itself; it leaves that job to whichever Web
server you choose.
We recommend using a separate Web server – i.e., one that’s not also
running Django – for serving media. Here are some good choices:
Nginx
A stripped-down version of Apache
I understand this might be due to wasted resources when Apache spawns new processes to serve each static file, which Nginx avoids. However, Apache's (newish?) Event MPM seems to act similar to an Nginx instance handing off requests to an Apache worker mpm. Therefore I'd like to ask: instead of setting up Nginx to be a reverse proxy for Apache, would using an Apache Event MPM be sufficient for serving static files in Apache?
Apache doesn't spawn a new process for each static file. Apache keeps persistent processes to handle concurrent and subsequent requests just like nginx. The difference is that nginx uses a full async model, whereas Apache relies on processes and/or threading for concurrency, although event MPM uses an async model for initial request acceptance and keep alive connections now. For the majority of people, Apache alone is still a more than acceptable solution. So don't get ahead of yourself if you are just starting out and think you need a Google/Facebook scale solution from the outset.
More important than separate web server is that if using Apache/mod_wsgi, serve the static files under a different host name. That way you avoid heavy weight cookie information being sent for all static file requests. You can do this using virtual hosts in Apache. Also ensure you are using daemon mode of mod_wsgi for running the Django application as that is a better architecture and provides lots more options for setting timeouts so you can have your application recover from various situations which might otherwise cause the server to lock up when overloaded.
For a system which provides a better out of the box configuration and experience than using Apache/mod_wsgi directly and configuring it yourself, look at using mod_wsgi-express.
https://pypi.python.org/pypi/mod_wsgi
http://blog.dscpl.com.au/2015/04/introducing-modwsgi-express.html
http://blog.dscpl.com.au/2015/04/using-modwsgi-express-with-django.html
http://blog.dscpl.com.au/2015/04/integrating-modwsgi-express-as-django.html
The advice about separating the webservers has two advantages. One clearly outlined by Graham. The other is "predictable resource consumption".
The number of resources per HTML page differ. Leaving one webserver to serve the application and the other to serve static resources, has the advantage that you know exactly how many concurrent visitors you can serve: the MaxClients setting of Apache.
If this slows down the loading of images, those webservers need very few modules and no measurable amount of CPU power so a one core machine with SSD disks is all you need and scaling is cheap.
As Graham indicates it starts with a STATIC_URL that has a different hostname. Run it at the same server at the start. When scaling up, tie that hostname to a reverse proxy that serves from several image server backend machines.
I have an apache server in which I am setting up fcgi. I was contemplating if I've to setup the tailor made mod_fastcgi or the plain old cgi-fcgi.
mod-fastcgi doesn't seem to support the "multiplexing" features of fcgi, and the web service I am building is a very high traffic service with several thousand calls per minute and I want them to be processed as quick as possible.
Any suggestions or advice??
Indeed, mod_fastcgi does not support multiplexing. I suppose this is because the Apache web server handles concurrent processing itself. You've probably dealt with it's various Multi-Processing-Models (MPMs) already...
Apache is highly optimized around the several (request) phases provided. The various modules can hook in where-ever you like, which makes the Apache an excellent server to directly integrate high performance and/or really complex applications (e.g. with custom modules in c, mod_perl and so on) as modules themselves.
But both, mod_fastcgi and cgi-fcgi, are IMHO only used to provide response and/or filter handler. Thus; many of the great features (configuration, mapping, post-request logging & cleanup...) provided with Apache are just not used in such a setup.
Thus; if your application is built on top of FGCI, I'd rather not recommend using Apache. Especially for high performance applications under high load; One may prefer a more lightweight but fast HTTP daemon. There are plenty of alternatives like nginx or lighttpd.
Usually one would use them as proxies/balancer to the FCGI processes, cache, SSL handler and logging provider. Of course, Apache is also capable of these tasks, but it's somehow like using a helicopter to direct the traffic at the intersection...
Cheers!