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.)

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?

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?

Best,
Aarni Koskela
Anders Inno Oy
_______________________________________________
uWSGI mailing list
[email protected]
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi

Reply via email to