Graceful reloading with zero downtime for web apps | Hacker News Reader

Graceful reloading with zero downtime for web apps

daniellombrana.es

19 pointsteleyinex13 comments

> The documentation from uWSGI is really great

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.

Sounds like Twisted all over again. A powerful framework with a steep learning curve.

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

https://github.com/unbit/uwsgi/issues/296

Note that the bug is closed because it will be fixed in an as-yet unreleased version!

Yes, you are right. But, IMHO the solution is really simple. In your supervisor config you ony add this option and everything works as expected:

stopsignal=QUIT

We're using it and no problems so far. Simple!

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

Thanks! I'll have a look again :-)

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.

Hi,

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

But I'm not running a zerg server right now (I don't think!) so it would be a new daemon even if it's part of an existing package, right?

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.

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.

That visual effect when hovering over a link is really bad.

Reply on news.ycombinator.com