&gt; Technically, there&#x27;s no good reason why a FastCGI based system would be significantly slower than a custom reimplementation like this.<p>An HTTP server speaking to a FastCGI application will:<p>• read the HTTP message<p>• decode HTTP<p>• encode FastCGI<p>• write to application<p>The FastCGI application will then:<p>• read the FastCGI message<p>• decode the FastCGI message<p>• do application stuff<p>• encode the FastCGI response<p>• write to the web server<p>The webserver then resumes:<p>• reading the FastCGI response<p>• decoding the FastCGI response<p>• writing the HTTP response<p>Meanwhile, an in-process HTTP server (like nxweb) system will simply:<p>• read the HTTP message<p>• decode HTTP<p>• do application stuff<p>• write the HTTP response<p>Less code runs faster; it is obvious to me why this is faster.