Concurrency

[Joan Miller]

Pylons is a great project, thanks! But I'm supposed that it would be
faster if it were ready for concurrency.

Today is not necessary to use Twisted; it's great, but forces you into
callback hell. In change, pyev [1] is a great solution.

[1] http://code.google.com/p/pyev/

[Mike Orr]

Pylons itself does not deal with network I/O or threads; it just takes
a WSGI request and returns a WSGI response. What you'd need is a WSGI
server that uses pyev. I don't know if there are any. But if you do
find one that has Paste-compatible entry points, you can configure it
in the server section of the INI file.

The flup project (http://trac.saddi.com/flup) has several servers, but
none that use pyev as far as I can tell.

Pylons does not make any attempt to avoid blocking. However, most
blocking occurs with network or database access. The network part is
handled by the WSGI server. Pylons does not include a database (just
a suggested configuration for SQLAlchemy), so you're on your own
there. I'm not sure if disk access is considered blocking, but if so,
the session configuration and Mako template caching would be concerns.

--
Mike Orr <slugg...@gmail.com>

[lasizoillo]

2009/12/15 Joan Miller <pelo...@gmail.com>:

Pylons are designed for a threaded model. Pyev implements a event
model. There are



> --
>
> You received this message because you are subscribed to the Google Groups "pylons-devel" group.
> To post to this group, send email to pylons...@googlegroups.com.
> To unsubscribe from this group, send email to pylons-devel...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
>
>
>

[Mike Orr]

On Tue, Dec 15, 2009 at 5:18 PM, Mike Orr <slugg...@gmail.com> wrote:
> On Tue, Dec 15, 2009 at 2:39 PM, Joan Miller <pelo...@gmail.com> wrote:
>> Pylons is a great project, thanks! But I'm supposed that it would be
>> faster if it were ready for concurrency.
>>
>> Today is not necessary to use Twisted; it's great, but forces you into
>> callback hell. In change, pyev [1] is a great solution.
>>
>> [1] http://code.google.com/p/pyev/

One other issue is that the thread overhead is not usually the
bottleneck in a WSGI application. Database access has a much bigger
impact on performance. If you need to handle thousands of
simultaneous requests, you probably need multiple servers anyway.

Offloading static files to Apache or Nginx or a proxy server is
another way to boost performance and keep the thread count down in
Pylons. You can also try the CherryPy server, which although also
threaded, is supposed to have better performance than Paste's HTTP
sever.

Also, make sure you really need the capacity. Many people
overestimate the number of simultaneous requests they will have. A
moderately large (but not huge) site may get only four requests per
minute.



--
Mike Orr <slugg...@gmail.com>

[lasizoillo]

2009/12/16 lasizoillo <lasiz...@gmail.com>:

> 2009/12/15 Joan Miller <pelo...@gmail.com>:
>> Pylons is a great project, thanks! But I'm supposed that it would be
>> faster if it were ready for concurrency.
>>
>> Today is not necessary to use Twisted; it's great, but forces you into
>> callback hell. In change, pyev [1] is a great solution.
>>
>> [1] http://code.google.com/p/pyev/
>>
>

Excuse my previous (unfinished response).

I don't want repeat excelent Mike Orr response. I'll try complement this.

You can use a libev based wsgi server called fapws3:
http://wiki.github.com/william-os4y/fapws3

But remember that blocking functions are an issue for event model.
Twisted are prepared for non-blocking calls, but pylons not.

If you want use Twisted without callbaks inferno, you can use inlineCallbacks:
http://blog.mekk.waw.pl/archives/14-Twisted-inlineCallbacks-and-deferredGenerator.html

Excuse my poor english.

[Damjan]

> One other issue is that the thread overhead is not usually the
> bottleneck in a WSGI application. Database access has a much bigger
> impact on performance.  If you need to handle thousands of
> simultaneous requests, you probably need multiple servers anyway.

depends,
if you need to handle thousands of requests that are at the same time
pretty idle (see Comet for ex), the memory that threads consume is a
big issue.

An event based framework solves this by saving as litle state as
needed (or possible) so that it could handle a large number of
otherwise slow or idle connections.

Python in general is not so well suited for all of this. I've been
playing with Erlang latelly and this kind of stuff is impresivelly
easier there.

[Joan Miller]

I've to starting to play with Go to manage the concurrency and it's
awesome.

[jgar...@jonathangardner.net]

What about Python greenlets to handle concurrency?

http://pypi.python.org/pypi/greenlet

Basically, it's Stackless in CPython as a module import.

[Mike Orr]

I don't know, and if anybody does know, they haven't said. But a
Pylons request would run inside a tread / greenlet / process /
async-thing. So you can make a HTTP server that spawns worker
greenlets instead of threads. Maybe PasteHTTPServer can be subclassed
for this. Then, if you get it working, you can make an entry point so
it can be loaded from the INI file.

There may possibly be issues with StackedObjectProxy (the Pylons
special globals) and SQLAlchemy's scoped_session, but Ben or Ian or
Mike Bayer could answer that better than I can.

--Mike

--
Mike Orr <slugg...@gmail.com>

[Joan Miller]

There is a comparison [1] of eight different asynchronous networking
frameworks in Python. Tornado and Gevent [2] have the better
performance.

[1] http://nichol.as/asynchronous-servers-in-python
[2] http://gevent.org/

On 13 ene, 20:36, "jgard...@jonathangardner.net"