PHP as a thttpd module vs CGI in terms of memory usage

Question

I am planning to use php in an embedded environment. Our current web server is thttpd. I am considering two options now: whether to run it as a cgi or as SAPI module. I know cgi has advantage in terms of security. But if we are to use php as cgi, an instance of the php should be loaded into the memory for each request.

I have tried compiling it as a SAPI module of thttpd and I have observed that thttpd's memory usage, specifically rss, does not grow larger as the number of request increases.

Can anybody explain how thttpd loads php? Is it loaded just one time and stays resident to the memory as long as thttpd is running? If so, we may consider this as an alternative to cgi.

Does it perform multi-threading, i.e. if there's multiple http request at the same time? or does it process request one at a time?

Is there a good documentation discussing behavior of php as a module of thttpd?

Answer 1

I have no experience with thttpd, but here are some pointers:

• the PHP engine is thread safe, but some extensions aren't, so usually people shy away from using it in a multi-threaded environment and rather go with the one-process - one-request method
• yes, usually webserver modules (like the Apache mod_* stuff) works by staying resident, but the big speedbump for PHP is that it needs to parse the source file (or even multiple source files if you use include / require) for each request. You can cut down on this by using something like APC which caches the parsed version of the files
• there is also a protocol called FastCGI which you might want to look at - it basically is a crossover between the module and CGI solution - it spins up a couple of processes, each process hosts a single instance of the CGI problem (PHP in this case) and uses them to process requests. Instances are recycled (ie. they can process multiple requests, one after the other).