Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I used this thing in a desktop app that consumed a RESTful API service and received notifications (HTTP POSTs) from the API service.

At a high rate, bottle just dies. So if you have a situation where you are making many requests to it, be careful; your mileage may vary.



What WSGI server were you deploying on? I'm thinking of using Bottle for some providing some REST services, so any details you can provide would be helpful.


I can't speak for the parent poster, but I deployed bottle with the grandparent poster without any significant performance issues*. This was first under mod_wsgi, then paste.deploy once mod_wsgi got to be a headache, and now I'm looking at gunicorn as a simpler alternative to paste.deploy.

So, why the asterisk next to "no issues"? I was able to wedge our app once by doing frequent, unbuffered, blocking socket.reads for one byte at a time in our RPC library... the GIL is a fearsome thing and it didn't play well with this strategy under highly concurrent request loads. I don't see that as a bottle problem, though.

If you're anticipating high loads, though, I wholly recommend looking at Brubeck (http://brubeck.io/) or Tornado (http://www.tornadoweb.org/)


I'd be curious for the details other asked for (define high rate, and how did you serve bottle)... Bottle services requests admirably. Not much there other than regexing your path and calling your function. If you had scalability issues I'd be tempted to believe it wasn't bottle code that was causing your problem (assuming you were using a real webserver to serve bottle workers).




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: