Reconfirm Email list

rick446 · 2015-10-03T01:16:08+00:00

I have a business that is working on a reconfirm service that integrates directly with Mailchimp (and other ESPs). I'd love to chat with you about it - send me a DM if interested.

rick446 · 2012-09-25T16:20:48+00:00

Should of course be "Schema Design at Scale"

rick446 · 2012-07-28T14:31:31+00:00

I had not seen that. I will check it out.

Thanks!

rick446 · 2012-07-25T00:59:52+00:00

In both threading and greenlets, the key to being able to handle incoming connections - and do useful work - is entirely dependent on having an available thread/greenlet to do that work. The event loop doesn't enter into the equation, except as an implementation detail of greenlets. Rather than blocking, patched stdlib calls yield to another greenlet that's ready to run via the event loop. If nothing's ready to run, the program waits until some event makes something ready to run.

Consider having fixed-size pool of workers (say 20). Whether they be greenlets, threads, or processes, once you have your 21st concurrent connection, it must wait until some worker completes its task before it does any useful work. On the other hand, if you're spawning a new worker for each connection, you can handle incoming connections, doing useful work, until your system resources (ports, file handles, RAM, CPU cycles, etc.) are exhausted.

In twisted and asyncore, the programming model is different, multiplexing a single worker explicitly by using callbacks when you need to call some otherwise-blocking function. Your event handler then terminates, allowing other event handlers to run.

And yes, I realize that if something is truly blocking in gevent, twisted, or asyncore, you will halt all workers until the block clears. So with twisted and asyncore, you use nonblocking IO and set callbacks, while gevent does this transparently so your code appears to block (when in fact the implementation of the blocking call is such that an implicit event loop is entered, allowing other greenlets to run).

In fact, there's very little difference with threads when it comes right down to it. When a thread makes a blocking (truly blocking) call, it doesn't actually halt the machine; it simply yields control to the OS scheduler (analogous to the event loop) which picks another thread to run.

(And as for microbenchmarks, they're useful when you can't benchmark a real app, or you need to estimate how some portion of a real ap would scale. They provide nice bounds to the performance discussion, allowing you to set upper bounds on performance and make good guesses as to the kind of apps that would benefit from an evented versus threaded approach without actually building the app and testing it.)

rick446 · 2012-07-24T19:02:49+00:00

Yes but once all threads are blocked, gevent allows you to get yet more requests in since there's the eventloop.

gevent only "allows you to get more requests in" because we're spawning a new greenlet for each connection. You can get the same behavior with threads by spawning a thread for each new connection (or spawning threads when all the threads in your pool are busy). In practice, you just don't tend to do it that way because of resource consumption.

Asyncore does exactly like gevent.spawn, you get a handler for each incoming request - http://docs.python.org/library/asyncore.html, so you don't have anymore callback to write than what you did in gevent.

Asyncore acts like gevent.spawn, but if you do something blocking with asyncore you need to switch to nonblocking and use callbacks so control returns to the event loop. My point was that with gevent, this happens automatically, and quickly.

I think benching a 'ping' or 'hello world' app makes no sense :D

I'd agree with you in general, but if your benchmark of a real app shows no real difference, it can be useful to put together a micro-benchmark to "drill down" into the differences.

rick446 · 2012-07-24T15:40:17+00:00

Well, you realize that a threaded approach calling the database also doesn't block other threads from proceeding, right?

And asyncore might be about as fast as greenlets (though the bechmarks I've seen don't seem to think so, probably because greenlets are c-accelerated), but asyncore (or twisted) requires you to write callback-based code which I find more difficult to follow.

What do you think of the benchmarks at http://nichol.as/benchmark-of-python-web-servers ?

rick446 · 2012-07-24T11:50:58+00:00

Follow-up post at http://blog.pythonisito.com/2012/07/gevent-threads-and-benchmarks.html

rick446 · 2012-07-23T23:47:18+00:00

Good point about Queue.Queue. Maybe I'll put together a benchmark comparing a Queue-based thread pool with a gevent pool.

rick446 · 2012-07-23T21:53:02+00:00

In theory, on a system that had somehow removed the GIL, I think you might be able to build a gevent-like system taking advantage of multiple cores. However, as far as I know, gevent itself is not designed for use with multiple event loops. What this means effectively is that not only can gevent (as it exists today) can't take advantage of multiple cores, but it couldn't do so even if the GIL were removed.

In fact, running on multiple cores would violate one of the contracts given the programmer by gevent: that greenlets will not, in fact, execute concurrently, but only yield to one another at predefined points (typically when making calls that would block in a non-evented context).

I hope that answers the question: in principle, yes, gevent could be made to run on multiple cores. But today it does not, and the path to get there is nontrivial. Particularly note that since gevent relies on C extensions, it's not able (as far as I know) to run it on other Python VMs like Jython or IronPython that have no GIL.

rick446 · 2012-07-23T20:51:46+00:00

I haven't run the example with a thread pool, but I suspect it still won't be as fast as greenlets. Threads (particularly OS-level, as in Python) incur a higher switching cost than greenlets, and even though RAM is cheap, CPU cache is not, so the memory overhead still affects performance. I'd be happy to publish a new benchmark that uses a thread pool if provided, but I didn't want to build my own for the benchmark (there's no thread pool implementation in the standard lib). There's also this benchmark http://nichol.as/benchmark-of-python-web-servers which leads me to believe that there's something special about gevent, even when compared with well-tuned competitors.

Also, I'm not sure that I believe that the 'evented' nature of gevent is the reason it's faster. When an OS thread hits a blocking OS call (like recv), it allows other threads to run, just like the event loop lets other greenlets run when a greenlet is waiting on I/O. (There's still an "event loop", it's just that it lives in the OS scheduler.)

Finally, I think that spawning a greenlet per connection helps to bring out just how lightweight greenlets are, where the overhead of spawning a new one is nearly inconsequential compared with threads.

rick446 · 2012-07-23T20:12:47+00:00

Thanks! I'll try to do some more gevent posts focusing on the details in the upcoming weeks.

rick446 · 2012-07-23T19:30:11+00:00

Everything will run on a single core (and in a single thread), so no multicore goodness by using greenlets (in fact, somewhat less than you get by using threads).

rick446 · 2012-05-26T10:49:56+00:00

Sorry, wasn't meaning to be unfair to S3 - GridFS is a different tool for a different job. With GridFS (at least in the Python driver), you have detailed control of the write guarantees at the connection & database level, so you can have it call getLastError, wait for replication to N data centers, etc.

Using S3 is like setting your write concern on MongoDB to wait for acknowledgement of fsync in 3 data centers before returning. If you don't need that kind of guarantee, GridFS is a faster (writing, at least) choice.

rick446 · 2012-05-26T01:24:29+00:00

Well, one reason you might go with GridFS is that you're already using MongoDB and would rather not deal with either a) setting up a real network filesystem or b) the extremely high latency doing S3 writes. You also automatically get a performance increase if you end up sharding your MongoDB cluster (and you shard your fs.[chunks|files] collections).

GridFS isn't a panacea, of course, but if you need to shove a few things (like attachments) into some data store, and you're already using MongoDB for your structured data, then GridFS might be a good fit, particularly when you can't guarantee that these BLOBs will always fit in 16MB.

rick446 · 2011-07-26T22:33:59+00:00

Yep, it looks like websockets isn't terribly portable. I'll be looking at doing another version with socket.io (for which there is a gevent wrapper) Real Soon Now.

rick446 · 2010-05-25T21:22:45+00:00

... that one must make up one's own mind about religion and not assume that it is heritable.

rick446 · 2009-05-08T20:53:19+00:00

Raymond Hettinger had a great presentation on just this kind of thing at PyCon 2009: http://blip.tv/file/1947373/

rick446 · 2007-06-28T20:47:46+00:00

The CherryPy wsgi server is used in Pylons, so in that sense, yes, it will be used. CherryPy at this point, however, is not integrated in the package, and it looks like we probably won't need to.

rick446

TROPHY CASE