I don't think the documentation is really great. I think it is terrible. Every page seems to assume you understand the internals and the documentation attaches fancy names to concepts that are difficult to understand from the documentation.
For example, "workers' mercy", "zerg mode", "emperor mode", "the zeeg problem", "uwsgi mules", "harakiri mode".
I for one would like uwsgi a lot more if it focused on a few simple patterns that worked for the majority of cases and explained them thoroughly, including their tradeoffs.
Sort of. You can definitely be up and running relatively easily, it's just there are so many different knobs and switches and ways to set things up, you never know if you are doing things the right way. I also agree that the documentation is not particularly helpful and sometimes it's contradictory. The software itself is rock solid though, gives me very little trouble (other than logrotate & emperor mode being a pain)
It's theoretically rock solid. In practice there are many common scenarios where uwsgi goes wrong. Here's one where a seemingly normal configuration of supervisor and uwsgi doesn't work because uwsgi attached a special meaning to SIGTERM
Read the thread I linked - multiple commenters say that using SIGQUIT does not solve the problem for them and eventually unbit states that he recommends using --die-on-term.
You are using the wrong workaround, so if you haven't had problems yet, it could only be a matter of time.
And this is only one aspect of uwsgi that is buggy/unclear
The basics are really well covered. Then, the more advance stuff is "a bit more complicated". In any case, that's why I've written some blog posts about advance uwsgi configurations that we use in production systems like Crowdcrafting.org
Adding a zerg server still feels a little like adding another layer to my stack. Or do I misunderstand? I guess it's not literally a new package to install, but it definitely feels like one more thing that can go sideways.
Not really. That's why we love so much uwsgi. All you have to do is to add a new config file for your zerg server, and you are done. This is handled without problems by supervisor and we've never experienced an issue with it.
I've another blog post about our full infrastructure, explaining specifically why we love uwsgi + supervisor. Because we don't need extra software within our stack and everything is pretty simple and runs on Python :D
You only have to add a new daemon/process. Then you'll have this graceful reloading feature ;-) From my point of view is has less impact than booting a new container.
13 comments
[ 4.4 ms ] story [ 48.2 ms ] threadI don't think the documentation is really great. I think it is terrible. Every page seems to assume you understand the internals and the documentation attaches fancy names to concepts that are difficult to understand from the documentation.
For example, "workers' mercy", "zerg mode", "emperor mode", "the zeeg problem", "uwsgi mules", "harakiri mode".
I for one would like uwsgi a lot more if it focused on a few simple patterns that worked for the majority of cases and explained them thoroughly, including their tradeoffs.
https://github.com/unbit/uwsgi/issues/296
Note that the bug is closed because it will be fixed in an as-yet unreleased version!
stopsignal=QUIT
We're using it and no problems so far. Simple!
You are using the wrong workaround, so if you haven't had problems yet, it could only be a matter of time.
And this is only one aspect of uwsgi that is buggy/unclear
Not really. That's why we love so much uwsgi. All you have to do is to add a new config file for your zerg server, and you are done. This is handled without problems by supervisor and we've never experienced an issue with it.
I've another blog post about our full infrastructure, explaining specifically why we love uwsgi + supervisor. Because we don't need extra software within our stack and everything is pretty simple and runs on Python :D
Looking forward to more blog posts. Uwsgi is new to me, but so far I've been very pleased with it.
I've been considering solving deploys at a higher level by spinning up a new docker container and moving traffic from one to the other.