does python have a generic object pool like commons-pool in Java

[Graham Dumpleton]

On Jul 16, 3:05 pm, John Nagle <na... at animats.com> wrote:
> alex23 wrote:
> > On Jul 16, 2:03 pm, John Nagle <na... at animats.com> wrote:
> >>      "fcgi" is an option for this sort of thing.  With "mod_fcgi" installed
> >> in Apache, and "fcgi.py" used to manage the Python side of the problem, you
> >> can have semi-persistent programs started up and shut down for you on the
> >> server side.
>
> > Hey John,
>
> > The environments in which I've been asked to develop webs apps using
> > Python have all utilisedmod_wsgi. Do you have any experience with
> >mod_wsgivs mod_fcgi, and if so, can you comment on any relevant
> > performance / capability / ease-of-use differences?
>
> > Cheers,
> > alex23
>
>     FCGI seems to be somewhat out of favor, perhaps because it isn't
> complicated enough.

I doubt that is the reason. It is out of favour for Python web hosting
at least, because web hosting companies provide really crappy support
for using Python with it and also don't like long lived processes.
Most FASTCGI deployments are configured in a way more appropriate for
PHP because that is what the default settings favour. This works to
the detriment of Python. Even when people setup FASTCGI themselves,
they still don't play with the configuration to optimise it for their
specific Python application. Thus it can still run poorly.

> It's a mature technology and works reasonably well.

But is showing its age. It really needs a refresh. Various of its
design decisions were from when network speeds and bandwidth were much
lower and this complicates the design. Making the protocol format
simpler in some areas would make it easier to implement. The protocol
could also be built on to make process management more flexible,
rather than relying on each implementation to come up with adhoc ways
of managing it.

Part of the problem with FASTCGI, or hosting of dynamic applications
in general, is that web servers primary focus is serving of static
files. Any support for dynamic web applications is more of a bolt on
feature. Thus, web applications using Python will always be at a
disadvantage. PHP manages okay because their model of operation is
closer to the one shot processing of static files. Python requires
persistent to work adequately with modern fat applications.

> It's been a puzzle to me that FCGI was taken out of the
> main Apache code base, because it gives production-level performance
> with CGI-type simplicity.

As far as I know FASTCGI support has in the past never been a part of
the Apache code base. Both mod_fastcgi and mod_fcgid were developed by
independent people and not under the ASF.

In Apache 2.3 development versions (to become 2.4 when released),
there will however be a mod_proxy_fcgi. The ASF has also taken over
management of mod_fcgid and working out how that may be incorporated
into future Apache versions.

>     WSGI has a mode for running Python inside the Apache process,
> which is less secure and doesn't allow multiple Python processes.

Depending on the requirements it is more than adequate and if
configured correctly gives better performance and scalability. Not
everyone runs in a shared hosting environment. The different modes of
mod_wsgi therefore give choice.

> That complicates mod_wsgi considerably,

No it doesn't. It is actual daemon mode that complicates things, not
embedded mode.

> and ties it very closely
> to specific versions of Python and Python modules.  As a result,
> the WSGI developers are patching at a great rate.

What are you talking about when you say 'As a result, the WSGI
developers are patching at a great rate'? As with some of your other
comments, this is leaning towards being FUD and nothing more. There is
no 'patching at a great rate' going on.

> I think the thing has too many "l33t features".

It is all about choice and providing flexibility. You may not see a
need for certain features, but it doesn't mean other people don't have
a need for it.

> I'd avoid "embedded mode".  "Daemon mode" is the way to go if you use WSGI.

I'd agree, but not sure you really understand the reasons for why it
would be preferred.

> I haven't tried WSGI;

Then why comment on it as if you are knowledgeable on it.

> I don't need the grief of a package under heavy development.

More FUD.

Graham