<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Jan 30, 2015 at 8:57 AM, Michael Van Canneyt <span dir="ltr"><<a href="mailto:michael@freepascal.org" target="_blank">michael@freepascal.org</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>
On Fri, 30 Jan 2015, Michael Schnell wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
On 01/30/2015 08:46 AM, Michael Van Canneyt wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Only if you use proxy fastcgi (i.e. a separately running binary listening on a fixed port, not started in Apache), then threading may be useful.<br>
<br>
</blockquote>
Am I wrong thinking, that using "proxy FCGI" projects are a lot easier to manage, anyway, as here you can use normal debugging means (e.g. Lazarus) ?<br>
</blockquote>
<br></span>
Not really. On windows they must be service programs, which are an absolute horror to debug.<span><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
And with a permanently running  independent executable, you also can do a lot of stuff that might be difficult to accomplish with a program started and killed by the Server.<br>
</blockquote>
<br></span>
Well, I switched from proxy fcgi to normal fastcgi for performance reasons.<br>
It simply scales better.<br></blockquote><div><br></div><div>I think you should test your fcgi as proxy again after we implement the multi-thread support.</div><div><br></div><div>A tool as AB, that simulate multiple requests per second, it will have a low performance in in currenty implementation of proxy fcgi, because when AB call a second request, for example, the first probably will be still processing, since the interval between requests in AB is too short.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
With all the virtualization happening these days, introducing state on the server is a very bad idea anyway, so I would not recommend this approach.<br>
<br>
As for debugging: it rarely happens that I must debug an actual running fastcgi program.<br>
All code is unit tested, and the unit tests run in a CLI program.<br>
<br>
The nice thing of web is that it is simply "text in, text out". Can perfectly be simulated on the command-line.</blockquote></div><div><br></div>-- <br><div>Silvio Clécio<br>My public projects - <a href="http://github.com/silvioprog" target="_blank">github.com/silvioprog</a></div>
</div></div>