Re: [uWSGI] getting websockets to work with emperor/vassals and nginx
Harry, Now, as far as I can tell, the assumption in the examples is that your > worker will be tied up in a while True: loop handling requests, right? so > the next thing i have to think about is the concurrency model... am taking > a look at https://github.com/unbit/uwsgi/blob/master/tests/ > websockets_chat_async.py. That is correct. We use code modeled off of that same example and so far it has worked very well. Also good find with your loadbalancer issue. Almost every time I had a problem with websockets it seems to have ended up being the loadbalancer. Best of luck, -Andrew Andrew Fischer Apastron Co 903 1st ST N Hopkins, MN 952-373-1024 ___ uWSGI mailing list uWSGI@lists.unbit.it http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
[uWSGI] processes, offload threads and websockets
So we've successfully used the approach outlined in the excellent
"Offloading Websockets and Server-Sent Events" guide:
http://uwsgi-docs.readthedocs.io/en/latest/articles/OffloadingWebsocketsAndSSE.html
But now that we are applying it to a larger django application, I realized
we are a bit unclear about how everything scales when used on an
application with several processes. We're still a bit new to the offloading
subsystem.
Say I run a django app with the following (trimmed) configuration
parameters:
[uwsgi]
process = 8
offload-threads = 1
response-route-if = equal:${WS_OFFLOAD};true disableheaders:
response-route-if = equal:${WS_OFFLOAD};true uwsgi:/tmp/wsapp.sock,0,0
It looks like uWSGI launches 8 processes, as expected, and 8 offload
threads. So the offload_threads argument applies per process.
Now we have a straightforward uGreen-based python websocket comm app. We
launch a single instance with say 1000 green threads:
[uwsgi]
async = 1000
ugreen = true
My 2 questions:
Am I correct in that each process spawns it's own offload thread?
Is it reasonable to have all of the processes offload to the same async
app?
Note that I do understand, in general, that the more cpu-intensive the
async app is the more we would want to run additional apps instead of just
adding green threads. But I didn't know if there was anything wrong with
multiple offload threads pointing at the same async app.
Thanks for any help and thanks for providing such a great tool!
-Andrew
--
Andrew Fischer
Apastron Co
903 1st ST N Hopkins, MN
952-373-1024
___
uWSGI mailing list
uWSGI@lists.unbit.it
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
[uWSGI] Help with the --reaper option for experienced uwsig users?
I've been running uwsgi for about a year and I've run into a situation that I can't seem to sort out. I'm not positive there is a good solution, but maybe someone with far more knowledge than I could shed some light. I'll give some background, please bear with me. I run uwsig behind nginx to run a simple mercurial hgweb server. My uwsgi configuration is pretty basic: -M -p 4 -d /var/log/$daemon_name.log --pidfile /run/$daemon_name.pid --pythonpath $hgwebpath --module $hgwebmodule However, I recently added buildbot to our setup, which is triggered by a commit hook in hgweb. It's all built in stuff, I didn't write any of it. Unfortunately this hook uses fork, and so generates defunct uwsgi instances when it occurs. It appears to be a known issue with the buildbot. I decided uwsgi's --reaper option looked like it might help me out. It did the trick, very handy since I didn't want to wade into the buildbot codebase. Like the manual for --reaper says you should fix your process spawning usage (if you can) ... and I don't think I can. However, after enabling reaper I noticed that very large commit pushes to hgweb over http would cause the process to be killed. It would happen anytime a push of 20MB or larger was pushed up to the server. (This is extremely rare, we just happen to have a project that carries this much baggage). After a lot of reading and testing, I found that by removing the --reaper option from uswgi, the commits would no longer be killed. I could push up as large a bundle as I liked (+100MB). However, without the reaper my buildbot is back to leaving zombies all over the place. Do any of you know more about the --reaper option, and if there is any additional control over how it determines what a zombie process is? Or is there is a different uwsgi option I should use? I fully realize uwsgi is not the problem here; I blame uwsig and buildbot. But since uwsgi is so flexible I wondered if there might be a way to have my cake and eat it too, so to speak. Big thanks for any feedback. -Andrew -- Andrew Fischer ___ uWSGI mailing list uWSGI@lists.unbit.it http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
Re: [uWSGI] Help with the --reaper option for experienced uwsig users?
Sorry, I meant to say at the end I realize uwsgi is not the problem here; I blame *hgweb* and buildbot. -Andrew On Mon, Oct 22, 2012 at 9:14 AM, Andrew Fischer wizzr...@gmail.com wrote: I've been running uwsgi for about a year and I've run into a situation that I can't seem to sort out. I'm not positive there is a good solution, but maybe someone with far more knowledge than I could shed some light. I'll give some background, please bear with me. I run uwsig behind nginx to run a simple mercurial hgweb server. My uwsgi configuration is pretty basic: -M -p 4 -d /var/log/$daemon_name.log --pidfile /run/$daemon_name.pid --pythonpath $hgwebpath --module $hgwebmodule However, I recently added buildbot to our setup, which is triggered by a commit hook in hgweb. It's all built in stuff, I didn't write any of it. Unfortunately this hook uses fork, and so generates defunct uwsgi instances when it occurs. It appears to be a known issue with the buildbot. I decided uwsgi's --reaper option looked like it might help me out. It did the trick, very handy since I didn't want to wade into the buildbot codebase. Like the manual for --reaper says you should fix your process spawning usage (if you can) ... and I don't think I can. However, after enabling reaper I noticed that very large commit pushes to hgweb over http would cause the process to be killed. It would happen anytime a push of 20MB or larger was pushed up to the server. (This is extremely rare, we just happen to have a project that carries this much baggage). After a lot of reading and testing, I found that by removing the --reaper option from uswgi, the commits would no longer be killed. I could push up as large a bundle as I liked (+100MB). However, without the reaper my buildbot is back to leaving zombies all over the place. Do any of you know more about the --reaper option, and if there is any additional control over how it determines what a zombie process is? Or is there is a different uwsgi option I should use? I fully realize uwsgi is not the problem here; I blame uwsig and buildbot. But since uwsgi is so flexible I wondered if there might be a way to have my cake and eat it too, so to speak. Big thanks for any feedback. -Andrew -- Andrew Fischer -- Andrew Fischer LT Engineering Software http://ltengsoft.com ___ uWSGI mailing list uWSGI@lists.unbit.it http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
