[Fwd: Re: FASTCGI with Apache on Windows]

Thierry Pierron wrote:

Hello Mr Pierron, thanks again 4 your answer !

> Yes, you can use that model. Start a bunch of processes and let the 
> fastcgi module to submit request sequentially to each of them. This is 
> basically CGI-restarted-less-often.

And, of course, if I start up 100 processes and 10 more requests come in 
at the same time, I'll have 10 more processes running, isnt it ?

> Another model is to use a FastCGI server. Every HTTP request (POST, 
> GET, HEAD, ...) to a given URL, say "/cgi-bin/fast.cgi" will be 
> redirected to one persistant process on the web server. If this server 
> is not multi-threaded, it will process one request at a time, which 
> often worst than restarting each time a new process, like for CGI.

I like the persistant approach cause is very similar to what I do here. 
In my case, from the http server, I dump the request into a ramdrive 
folder and, I have another process (persistant) that does the job 
delivering back at the same folder the result. Then, http server 
dispatches the answer to the browser.

FastCGI server is an independent product ? Or is it simply Apache 
configured 4 that ?

When you said that it is not MT on Windows, is this model that you said 
that does not work ?

In fact, it MUST be MT !

> You have to handle concurent connection through separate threads, like 
> shown in the threaded.c example (fcgiapp dll), so that a slow 
> connection won't block your entire server.

Of course. And it's the elegant way to do that.

> But, well, all of this is rather low level, and painful to manage, 
> even with careful design. C/C++ is useful only when speed does really 
> matters, for performing overkill process. For most cases, I would look 
> at higher level language, or at least more adapted, like PHP, Python 
> or Ruby. All those implement mecanisms similar to FastCGI, like 
> persistant process, load-balancing, and the likes .... you'll spent 
> much less times with them than C/C++.

OK. What I need is simply something to make a bridge amongst the http 
server and this external process that I told you above. Currently I do 
that using the http server API but, I have to replace it. It's written 
in C++ but I dont manage the thread creation. I simply run "inside" a 
previously created thread. So, that's not so difficult.

But, this web server (WebSite from OReilly) has been discontinued. So, 
I'll throw away it all...

> All work is done inside a FastCGI server, that can be directly 
> accessed through a specific URL. Messaging is done through simple 
> text/plain, images transfered as PNG or JPEG, and a bit of HTML for 
> linking all that. Low-level access to bitmap along with fancy image 
> format make that C/C++/FastCGI work pretty well for us.

Again, I'm confused (intrigued) about what you call a FastCGI server....

Aur revoir !

-- 
Obrigado,
------------------------------------------------------------------------------
               Jose Adriano Baltieri - Analista de Sistemas
               DTI - CENTRO - UNIMEP - Universidade Metodista de Piracicaba
               PIRACICABA - SP - Brasil - Fone : (19) 3124-1858
------------------------------------------------------------------------------




-- 
Obrigado,
------------------------------------------------------------------------------
                Jose Adriano Baltieri - Analista de Sistemas
                DTI - CENTRO - UNIMEP - Universidade Metodista de Piracicaba
                PIRACICABA - SP - Brasil - Fone : (19) 3124-1858
------------------------------------------------------------------------------

___________________________________
fastcgi-developers mailing list
http://fastcgi.com/fastcgi-developers/