Cython-based websocket speedup

[Ben Darnell]

I've just committed a cython-based implementation of the websocket mask function, which greatly improves the performance of large uploads over websockets.  This is currently experimental: it will be used if Cython is present when Tornado is installed, and otherwise the pure-python version will be used.

Of course, depending on the order of installation of different packages is not a good idea, so I want to change this before the next release of Tornado.  I don't want to make the cython extensions required because I know it's a pain to get a suitable C compiler setup on windows, but I would like to make the extensions mandatory on linux and probably mac.  Is there anyone out there using Tornado on linux in an environment where building cython-based extensions is difficult?  On mac, are the xcode developer tools reasonably ubiquitous, or should we support a pure-python version there too?  Are there conventions used by other packages for opting into or out of optional C extensions?

https://github.com/facebook/tornado/commit/e8dc5e427d2e244c519c4211fb1796e747b77ed1

-Ben

[Shane Spencer]

I actually like how pymongo handles this.  I've always been very happy with pure python winning when building C extensions fails through good exception handling.

setuptools and the feature option sound like the most acceptable method: 

 

 https://github.com/mongodb/mongo-python-driver/blob/master/setup.py#L121

 https://bitbucket.org/tarek/distribute/src/055afac65a20/setuptools/dist.py#cl-153

- Shane

[Ben Darnell]

If we're using Cython I don't think we can catch the exception and recover (if our dependencies can't be satisfied our setup.py won't even be called).  In this case the extension is simple enough that we could easily do it as a pure C module, but I'd like to keep Cython in the mix because it handles a lot of things that are otherwise tricky to get right (refcounting, error handling, 2.x vs 3.x differences) and I think there are other opportunities to use it in Tornado.

Setuptools "features" give you a setup.py command-line flag to configure things, but they don't work well with pip requirements files.  "Extras" work in requirements files, but they seem to be limited to installing extra dependencies.  The cython dependency might actually work out in our favor in this case: build the extension whenever cython is present, but only force the installation of cython if the correct "extra" is requested. This means that installations would be slow by default (since I don't think you can have an "extra" on by default), but apps that care can specify tornado[speedups] in their requirements file and know that they'd never silently fall back to slow mode.

-Ben

--
You received this message because you are subscribed to the Google Groups "Tornado Web Server" group.
To unsubscribe from this group and stop receiving emails from it, send an email to python-tornad...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Ben Darnell]

On Sun, Oct 27, 2013 at 12:28 PM, Ben Darnell <b...@bendarnell.com> wrote:

If we're using Cython I don't think we can catch the exception and recover (if our dependencies can't be satisfied our setup.py won't even be called).  In this case the extension is simple enough that we could easily do it as a pure C module, but I'd like to keep Cython in the mix because it handles a lot of things that are otherwise tricky to get right (refcounting, error handling, 2.x vs 3.x differences) and I think there are other opportunities to use it in Tornado.

Setuptools "features" give you a setup.py command-line flag to configure things, but they don't work well with pip requirements files.  "Extras" work in requirements files, but they seem to be limited to installing extra dependencies.  The cython dependency might actually work out in our favor in this case: build the extension whenever cython is present, but only force the installation of cython if the correct "extra" is requested. This means that installations would be slow by default (since I don't think you can have an "extra" on by default), but apps that care can specify tornado[speedups] in their requirements file and know that they'd never silently fall back to slow mode.

It appears that dependencies installed by "extras" are handled too late, so they can't be used at build time.  Even if it's not an optional extra, just getting cython installed early enough that "pip install tornado" can build the extension appears to require some hacks.  Maybe it is better to drop cython and just make it a bare C extension.  

[aliane abdelouahab]

hi

on windows, here is the Cython binary installer:

http://www.lfd.uci.edu/~gohlke/pythonlibs/#cython

[Ben Darnell]

On Sun, Oct 27, 2013 at 6:12 PM, aliane abdelouahab <alabde...@gmail.com> wrote:

hi

on windows, here is the Cython binary installer:

http://www.lfd.uci.edu/~gohlke/pythonlibs/#cython

That doesn't include a compiler, does it?  Without a compiler it won't be possible to actually build any extensions that use cython.  

-Ben

[aliane abdelouahab]

yes! i completly forgot about it :D

sorry :D

i just found this, using GCC, but it is not as easy as posix compilation :(

http://stackoverflow.com/questions/6985109/how-to-compile-c-code-from-cython-with-gcc

[Shane Spencer]

I personally wouldn't mind installing a versioned torando-cython (aka tornado-accel or tornado-f6) :) if it meant not you had optimized resources available through it.. a bit like reportlab 

[Shane Spencer]

Or tornado-ext.

[Antoine Pitrou]

Le Sat, 26 Oct 2013 22:35:10 -0400,
Ben Darnell <b...@bendarnell.com> a écrit :

> I've just committed a cython-based implementation of the websocket
> mask function, which greatly improves the performance of large
> uploads over websockets. This is currently experimental: it will be
> used if Cython is present when Tornado is installed, and otherwise
> the pure-python version will be used.
>
> Of course, depending on the order of installation of different
> packages is not a good idea, so I want to change this before the next
> release of Tornado. I don't want to make the cython extensions
> required because I know it's a pain to get a suitable C compiler
> setup on windows, but I would like to make the extensions mandatory
> on linux and probably mac. Is there anyone out there using Tornado
> on linux in an environment where building cython-based extensions is
> difficult?

AFAIR, you should be able to bundle the C code generated by Cython
inside source distributions, so that users can compile the module
without Cython installed (you still need a C compiler, though,
obviously, but this one is much more likely to be already installed on
the average Unix setup).

Regards

Antoine.

[Ben Darnell]

I've changed my mind on cython - for now our extension needs are simple enough that it's easy to use a hand-written C module (https://github.com/facebook/tornado/blob/master/tornado/speedups.c).  We can revisit pymongo when or if we need extensions that would be difficult to build by hand (or if we want to use cython's "pure mode" to compile large portions of Tornado to C.  I've tried that and it actually seems to work pretty well in my limited testing).  I've borrowed pymongo's technique for making the extension optional.  I'm not thrilled with the fact that you can end up with the slow implementation without realizing it, but I don't want to add more hurdles for getting Tornado up and running at all.

Speaking of hurdles, I've also added a new dependency (after running with nothing but the standard library since Tornado 2.0).  We now (in the version that will become 3.2) require the "backports.ssl_match_hostname" module when running on Python 2.  Tornado previously included its own copy of this function, but it had gotten out of date.  If you're installing with pip (or run setup.py with setuptools installed), this will be installed automatically.  Hopefully the automatic dependency installation will go smoother now than it did when I tried it with pycurl in the Tornado 1.x days (we saw some weird issues that I think involved the debian/ubuntu site-packages vs dist-packages split).

-Ben

[Shane Spencer]

I was not a fan of the pycurl issues either.  There were definate problems with pycurl in the past that magically went away one day and I got to use it in my tornado apps.  this is......... somewhat......... similar to this situation and I'm very curious of the speedups could be set or unset by default similar to setting the default tornado.httpclient module.

[Ben Darnell]

On Wed, Nov 6, 2013 at 3:01 AM, Shane Spencer <sh...@bogomip.com> wrote:

I was not a fan of the pycurl issues either.  There were definate problems with pycurl in the past that magically went away one day and I got to use it in my tornado apps.  this is......... somewhat......... similar to this situation and I'm very curious of the speedups could be set or unset by default similar to setting the default tornado.httpclient module.

It doesn't make sense to configure them at runtime (well, I did add an undocumented environment variable to disable the extensions, but that's just so I can run benchmarks easily).  If the extension builds successfully there's no reason not to use it.  Pycurl had some issues because it linked with an external library, but our extension is self-contained.

-Ben