Take the 2-minute tour ×

I have a RESTful web service with a C++ API at the back-end. I am using the FastCGI library to facilitate the REST interface. My C++ API has multiple functions that may be used independently. I am looking for a way to make it as fast as possible. Here are a few ideas I got:

  1. Have one FastCGI application that gets the function to be executed, executes that function and returns the output. This way the API calls keep waiting until one 'function' is complete, even though the next call is for a different independent function.

  2. Have multiple FastCGI applications, each having access to only one function from the API, each getting inputs for that particular app and returning outputs of that particular app alone.

This way I can have concurrent calls made to all the different functions, and separate process queues would be made for each function that I have, instead of having one generic process queue to the FastCGI application consisting of calls to different independent functions.

While this looks like it would perform better, I am not sure if it is possible to implement a system such as this - i.e having many FastCGI apps running in parallel from the same server. If it is possible, can someone tell me how to implement this?

share|improve this question
The same way you would for one FCGI app...? I am not sure where you think would be a problem. –  Amadan May 28 '12 at 23:47
I'm concerned about the environment variables. I am not sure if there would be a clash there because of multiple apps running in parallel, each with their own environmental variable. –  Giridhar Murali May 29 '12 at 0:04
CGI and FCGI are drastically different. FCGI does not communicate through environment variables. And for CGI, every process gets its own environment. –  Amadan May 29 '12 at 0:06
Also, even if the 'functions' in the API are independent of each other, they all share common header files and read from a common database. I'm also concerned if that will be a problem. –  Giridhar Murali May 29 '12 at 0:07
Nope, not a problem. Sharing header files is utterly harmless; accessing the same database could be a problem if you're using a half-baked home-grown database; but all the commonly used database engines have as one of the main goals the facility with multiple connections. –  Amadan May 29 '12 at 0:08

1 Answer 1

up vote 2 down vote accepted

Each FastCGI application is a separate program, running in a loop, and communicating with Apache in a binary protocol defined by FastCGI specification. The only possible concurrency problems are the same concurrency problems you would experience if you were running concurrent CGI or PHP requests, with just one exception: since FastCGI processes do not terminate, any limited resources will have to be carefully managed. For example, if you only have a ten-client licence to a database server, you can't have eleven FastCGI processes using the database unless you manage connections better than "open at start, let it close at the end" method often used in CGI or PHP.

share|improve this answer
Is there an upper limit to the number of FCGI applications I can run in parallel on the same server? And also, is there an upper limit to the number of requests that can be queued by each FCGI process/application? –  Giridhar Murali May 29 '12 at 17:56
I am not aware of preset limits, i.e. nothing you can't change in your configuration; but in practical terms, you're limited by your memory. All FCGI processes are actually running all the time (although the inactive ones will be sleeping, and can be mostly paged out, I suppose). I don't know about the queueing. –  Amadan May 29 '12 at 22:35

Your Answer


