[Date Prev][Date Next][Thread Prev][Thread Next] [Search] [Date Index] [Thread Index]

Re: [MacPerl] acgi vs cgi



Dear MacPerlers,

Your discussion is definitely on the right track.

With MacPerl, CGI and ACGI are nearly the same thing. In both cases, the
webserver queues incoming requests and makes them available to MacPerl. In
the ACGI case, the webserver will accept other connections before the ACGI
script returns whereas with CGI, the webserver is waits for the script to
return before accepting more work. As a practical matter, there isn't much
advantage to the ACGI if your scripts are designed to execute very quickly.

In the unix environment, the OS spawns multiple processes to handle CGI
scripts in parallel. On MacOS the requests are handled one after another by
the single MacPerl thread.

With the other scripting engine (Frontier), a new thread is initiated for
each incoming webserver request, so that the requests are handled as ACGIs
rather than CGIs. Even so, it's still important to design scripts that
execute quickly so your net guests won't have to wait.

I once had a cgi that was very slow because it invoked a sendmail and
waited for the response. This design was unsatisfactory in either the
MacPerl or the Frontier environment, because people don't want to wait. So,
I implemented a mail queue to handle the outgoing mail with another thread
so the net guest doesn't have to wait. My point with this story is that you
can design your cgi to execute very quickly, and sometimes that might mean
farming out some of the work to another program or thread.

Hope this helps,

Marty

>
>I've read the manual recently and it doesn't really help in the context of
>MacPerl CGIs. It basically says what you state above, but it's unclear
>whether this really MATTERS to MacPerl scripters!?! My take on it (someone
>correct me if I'm wrong):
>
>	ACGI is better in that the server is freed up to handle other
>requests. This does NOT mean the ACGI will process more than one request at
>a time, but the SERVER is able to serve other pages while the ACGI is
>working. This may be pathological if the same ACGI is hit multiple times
>over a short period. It is unclear to me what happens if the ACGI takes a
>very long time to process (other server/client timeouts come in to play I
>think). It is also unclear to me whether one needs to change MacPerl
>scripts in any way to take advantage of ACGI. For example, the ACGIs I
>tried DID NOT return any faster than CGI. I think this was because they had
>to get to the first print statement before control was released. Since
>printing the response HTML page is often the last thing my CGIs do, ACGI
>really has no advantage as far as I can tell.
>
>Corrections?
>
>Thanks, RR

Marty Crouch | http://weboncall.net | (503)335.3442
Free WebTips Newsletter - http://weboncall.net/subscribeme.html



***** Want to unsubscribe from this list?
***** Send mail with body "unsubscribe" to mac-perl-request@iis.ee.ethz.ch