|
On Mon, Aug 5, 2013 at 10:33 AM, Petite AbeilleI believe Mr. Hipp has committed a fallacy here.
<petite.abeille@gmail.com> wrote:
>
> On Aug 5, 2013, at 4:55 AM, Henrique Gogó <henriquegogo@gmail.com> wrote:
>
>> But I've been read that cgi is too slow, and FastCGI is better.
>
> Regarding that entire "CGI ... is highly inefficient" meme, here is Richard Hipp's take,
>
> http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg02065.html
The workloads described are for sites that are generally rather
static. I wouldn't trust it to scale to even 100 concurrent users for
a highly-interactive site like a forum with a moderate amount of
traffic -- or at least, not without putting a lot of effort into
juggling state in shared memory (memcached for example).
They're also compiled C code. Startup time is minuscule because
they're small microservers that aren't parsing scripts or loading
heavy dependencies.
And finally, his proposed SCGI implementation... sucks. OF COURSE
that's not going to perform any better. It's just a waste of time --
it's using an SCGI wrapper... to perform a standard CGI invocation.
The point of using something like FastCGI is to allow you to change
your METHODOLOGY to something more efficient.
Yes, there's something to be said about the robustness of a
non-persistent microserver approach, but that's not always plausible.
/s/ Adam