4 ms·
I think one valid fear is that a web application might, for multiple reasons, scale beyond a single process on a single server. This is common enough that usin
by dbattaglia 6y ago
I think one valid fear is that a web application might, for multiple reasons, scale beyond a single process on a single server. This is common enough that using an embedded database can be problematic, compared to a separate RDBMS process that can be shared between processes. Some web applications are just never going to scale out for any reason, and for those SQLite might be appropriate.
- danenania 6y agoAgreed, but it’s not only a question of scaling. Any app with high uptime requirements will need more than a single process from day 1.
- benbjohnson 6y agoIt depends on what you consider high uptime. You can achieve 99.95% uptime with 4h of downtime a year. A lot of downtime occurs because of overly complicated systems so running a single process on a single server can give you relatively high uptime.
- TheCoelacanth 6y agoI just want to be able to deploy updates during business hours without downtime. Hard to do with a single process.
- asalahli 6y agoMost web servers support greaceful restarts, i.e. reloading code and configuration without downtime. Usually you just send a pre-specified and documented signal to the process to do it.
- lmm 6y agoFor a web server serving from the filesystem, sure. That doesn't help you deploy a new version of a web application you're making code changes to (which is the kind of thing that would need a database).
- asalahli 6y agoI was actually talking about both. For example for python, which is what I usually use, both uwsgi and gunicorn support graceful restarts. Admittedly I don't have much experience with other languages, but it's technically possible. If your application doesn't support it out of the box, you can still achieve it with something like systemd's socket activation.