Allan Saddi's projects blog - Comments

Anonymous: CASMiddleware

nospam@example.com () — Mon, 11 Apr 2011 15:15:04 -0700

I approve of this middleware.

Steven: scgi-wsgi for Python 3.2

nospam@example.com (Steven) — Thu, 17 Mar 2011 09:10:49 -0700

You are awesome. I just got it working great with:

CherryPy 3.2, Lighttpd V1.4.26 and Python 3.2

I documented what i did here. http://tools.cherrypy.org/wiki/ScgiWsgi

Seems to work fine with the limited testing i've done.

Allan Saddi: Dabbling in Python 3.0

nospam@example.com (Allan Saddi) — Wed, 16 Mar 2011 11:04:40 -0700

Thanks for the heads up on all of these issues. Looks like I've got a lot of catching up to do on 3.2.

Also, the trac issue is most likely due to the switch to scgi-wsgi. That can't be good...

Steven: Dabbling in Python 3.0

nospam@example.com (Steven) — Wed, 16 Mar 2011 07:53:58 -0700

I tried to build ajp-wsgi-py3 but it fails with Python 3.2 because the C API was deprecated in 3.1 and removed on favour of capsules. I would have logged it as a bug, but trac wont let me log in with trac/trac1234......

I looked at it to see if i could fix it, but i cant work out the python c api, and cant find any good docs on it, or the changes needed to switch to capsules. sorry, or i would have sent a patch.

I am messing with this, because its kind of needed for using cherrypy with apache or lighttpd which now supports Python 3.2

Steven: Dabbling in Python 3.0

nospam@example.com (Steven) — Wed, 16 Mar 2011 06:42:34 -0700

Your current setup.py does not work with Python 3.2 and is not compatible as far as i can tell with distribute. here is one that works. Using this, ez_setup.py is redundant.

# Bootstrap setuptools
from setuptools import setup, find_packages
import sys

extra = {}

if sys.version_info >= (3,):
extra['use_2to3'] = False
# extra['convert_2to3_doctests'] = ['src/your/module/README.txt']
# extra['use_2to3_fixers'] = ['your.fixers']

setup(
name = 'flup',
version = '1.0.2',
packages = find_packages(),
zip_safe = True,

entry_points = {
'paste.server_runner' : [
'ajp = flup.server.paste_factory:run_ajp_thread',
'fcgi = flup.server.paste_factory:run_fcgi_thread',
'scgi = flup.server.paste_factory:run_scgi_thread',
'ajp_thread = flup.server.paste_factory:run_ajp_thread',
'fcgi_thread = flup.server.paste_factory:run_fcgi_thread',
'scgi_thread = flup.server.paste_factory:run_scgi_thread',
'ajp_fork = flup.server.paste_factory:run_ajp_fork',
'fcgi_fork = flup.server.paste_factory:run_fcgi_fork',
'scgi_fork = flup.server.paste_factory:run_scgi_fork',
]
} ,

author = 'Allan Saddi',
author_email = 'allan@saddi.com',
description = 'Random assortment of WSGI servers',
license = 'BSD',
url='http://www.saddi.com/software/flup/',
classifiers = [
'Development Status :: 5 - Production/Stable',
'Environment :: Web Environment',
'Intended Audience :: Developers',
'License :: OSI Approved :: BSD License',
'Operating System :: OS Independent',
'Programming Language :: Python :: 3',
'Topic :: Internet :: WWW/HTTP :: WSGI :: Server',
'Topic :: Software Development :: Libraries :: Python Modules',
],
)

Robert Brewer: mod_proxy_scgi, why?!?!

nospam@example.com (Robert Brewer) — Tue, 22 Feb 2011 09:06:26 -0800

I'm seeing the same behavior from mod_fastcgi (while trying to test the next release of CherryPy). You might consider adding the same tweak to fcgi.WSGIServer.

Allan Saddi: scgi-wsgi?

nospam@example.com (Allan Saddi) — Sat, 22 Jan 2011 12:48:47 -0800

I couldn't find any obvious ways to run an external server from "paster serve." The main blocker is that Paste's server_runner/server_factory expect an app object to be passed in. (No way to really pass that on to an external program.)

SCGI definitely is more efficient than AJP, mainly because AJP is packet-based. So that means for AJP to do 'wsgi.input' stuff, there needs to be a lot of copying/slicing going on, which is where I believe the slowness is coming from.

Even in ajp-wsgi it's unavoidable -- though I did manage to bring it down from copying 'wsgi.input' data twice to just copying it once.

However I'm not sure if it would really account for the massive slowness in flup's AJP. I'm mildly curious and will probably look into it sometime, though the pure-C WSGI servers have my attention right now.

Jon: scgi-wsgi?

nospam@example.com (Jon) — Fri, 21 Jan 2011 11:52:43 -0800

Regarding ajp-wsgi and paste frameworks -- what I want is the opposite, I think. I want to edit a (an?) .ini file and have paster make use of ajp-wsgi as a 'server'.

I don't think the threadpool/prefork stuff needs to be in C, but perhaps having part of the protocol in C wouldn't hurt. Sort of like a protocol accelerator the way SQLAlchemy can make (optional) use of C extensions for performance.

I suspect the SCGI protocol is also much more efficient for large payloads than AJP, but I can't be sure since I'm not that well-versed in AJP.

What could be done to the Python ajp protocol layer to speed it up?

Allan Saddi: scgi-wsgi?

nospam@example.com (Allan Saddi) — Fri, 21 Jan 2011 11:07:32 -0800

I noticed that last night as well. My test program was a bit off-spec -- turns out, you're not supposed to read beyond CONTENT_LENGTH. After I fixed that, I saw that flup AJP (and I suspect FastCGI as well, since it's the same code) is horribly slow due to all the buffering/copying, while flup SCGI simply wraps the socket with a file object.

Though ajp-wsgi is actually on-par, as far as request body uploads are concerned. So it's a problem with the Python implementation.

I did originally think about including the ajp-wsgi stuff into flup, but it would be the opposite of what it actually is: a C program that makes calls into a Python WSGI app. Though I am curious if flup would benefit from having the transport/threadpool/prefork stuff in C.

As for getting ajp-wsgi (and scgi-wsgi now) working with Paste or any Paste-based framework, it's a simple matter of writing a two line Python script:

from paste.deploy import loadapp
app = loadapp('config:production.ini', relative_to='.')

Save it into foo.py, then invoke ajp-wsgi like so: ajp-wsgi foo app

Jon: scgi-wsgi?

nospam@example.com (Jon) — Fri, 21 Jan 2011 07:58:43 -0800

Regarding AJP vs SCGI performance.
One of the big wins with SCGI over AJP, despite AJP having persistent connections, seems to be that with large bodies SCGI is obscenely fast.

For example, using flup (a very recent version as of this writing) and flup's AJP support, a 10MB upload took about a minute. With flup's SCGI support, the same upload took fractions of a second. I did not test ajp-wsgi (the C code) as it doesn't hook into paste that I'm aware of.

Might I suggest modifying ajp-wsgi in such a way that it could be included with flup as an optional performance enhancement with paste factory support?

James: flup 1.0.2 released

nospam@example.com (James) — Wed, 10 Jun 2009 10:02:29 -0700

Hi,

I'm forced to use the prefork method in my django-fastcgi configuration as when using the threaded method, the django fastcgi process seg-faults - again, it works fine in prefork.

When I say it seg-faults, let me explain:

python manage.py runfcgi host=127.0.0.1 port=8001 method=threaded daemonize=false debug=true

is the django fastcgi startup comment I'm testing with. If I then run a benchmark test to load the server like so:

ab -n1000 -c15 -H 'Host: www.example.com' http://127.0.0.1/

With nginx running on port 80 in a fastcgi configuration to port 8001, a few requests will go through successfully, but then eventually the fastcgi process segfaults. No stack trace.

I'm hoping to use the threaded model in the future as it should use less memory than the prefork. Anyhow, the only reason I can think of as to why this is bugging out is to do with threading issues to do with the Python GIL (http://docs.python.org/c-api/init.html#thread-state-and-the-global-interpreter-lock)

Thoughts? Can I provide further information to you? Feel free to email me. Thank you!

James

amittiwari: flup 1.0.2 released

nospam@example.com (amittiwari) — Tue, 09 Jun 2009 00:36:50 -0700

marketing

Jon Nelson: flup 1.0.1 released

nospam@example.com (Jon Nelson) — Thu, 21 May 2009 11:38:04 -0700

I just saw in mercurial that you have done this.
Fantastic!

I'll try to give this a test soon.

I'm really looking forward to the next release!

Allan Saddi: flup 1.0.1 released

nospam@example.com (Allan Saddi) — Mon, 18 May 2009 15:35:31 -0700

I don't really remember the rationale for deprecating the factories in Paste. Though I guess it makes more sense if they were packaged with flup.

A problem is that flup's paste_factory is a one-size-fits-all deal. (And it doesn't really fit all...)

I guess I might look into pulling Paste's factories into flup. This may cause some issues, mainly with regards to defaults.

Jon: flup 1.0.1 released

nospam@example.com (Jon) — Mon, 18 May 2009 14:56:16 -0700

Another problem is that PasteScript is deprecating the use of this style of factory:

use = egg:PasteScript#flup_fcgi_thread

However, if one does this:

use = egg:flup#fcgi
(or egg:flup#fcgi_thread, they are the same)

PasteScript#flup_fcgi_thread accepts any of

host, port, and socket
(and a few others that aren't relevant here).

If you don't specify them, then bindAddress=None is used.
There is no way to replicate bindAddress=None (that I can see) using flup#fcgi, a problem for any app that relies on that behavior.

Can you think of a reasonable fix?
Also, when might the next flup release be?