> Hi! > > I'm deploying uwsgi on Amazon EC2, behind Amazon's ELB load balancer in > HTTP mode, running one Django app -- so nothing fancy regarding emperors > and such things, just --master :) > > As I'm trying to keep the app server architecture as lean as possible and > we're serving static data out of Amazon S3 anyway, I've opted on using > --http for the socket and just exposing it to the load balancer directly. > It seems to work alright in empirical tests. > > Firstly -- is the HTTP parser in uwsgi robust enough to actually run it > like this, or do you think I might eventually hit some nasty problems? I > already learned the hard way that uwsgi doesn't add a Length: header or > such (for the record, this causes ELB to return "Bad Gateway"). I fixed > this by attaching the header in Django, so no problem there. (Our app > isn't streaming anything anyway, so it's a non-issue.)
Currently we are investing a lot in the routing infrastructure of uWSGI, as the demand for not having a full webserver is increasing. The biggest part of development is going on in 1.3, but something has already been backported to 1.2 tree. For that reason i suggest you to use this repository: http://projects.unbit.it/hg/uwsgi-1.2 Obviously i would be a foolish in claiming "robustness" on something relatively new. By the way i am already moving a bunch of my personal server to this setup. Remember this is only a router, so it will never parses/fixes the headers sent by your app (as the Content-Length header) > > Secondly, I gathered the difference between --http and --http-socket is > that the former spins up a HTTP server that "proxies" over the uwsgi > protocol to the master, and the latter makes the master itself parse HTTP > and shift the request over to the workers. Is there a performance > difference between the two, or is one preferable over the other in a > scenario like this? http-socket is faster as it does not need to make another connection and build another request. I do not know if ELB is a buffering server (it will send the whole request to your instance only after it has get all of the data from the client) or a streaming one. In the second case you could be easily DOSsed as a slow request will block a whole process/core. In the first one use --http-socket to gain memory and cpu. > > And thirdly -- and slightly off-topic for this mail -- are there any > general uwsgi-related performance tips to wring out as much performance of > our app servers as I possibly could? As for some reason, benchmarking with > `ab` (no matter which concurrency level) _feels_ much slower than using a > browser to navigate the site. Any idea why? > hard to say, i suggest you to run the stats server and use uwsgitop to check how the app is behaving: http://projects.unbit.it/uwsgi/wiki/StatsServer -- Roberto De Ioris http://unbit.it _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
