Looking forward to the monetization post.
Has the developer thought about using donations instead of ads?
Costs of running a Python webapp for 55k monthly users
71–80 of 264 posts
Re: Costs of running a Python webapp for 55k monthly users
#72I've grown fond of Caprover for this kind of small project. I would probably shove the metabase instance and both of the production instances into a single smaller instance (but I have been known to increase swap and put off upsizing resources in the past because cheapskate)
Can fully agree with this. Caprover has been a joy and makes it easy to run a small scale setup where you can deploy those service dependencies easily yourself without paying for a cloud provider for the hosted alternative.
Re: Costs of running a Python webapp for 55k monthly users
#73It always makes my head dizzle when I read and hear how much people manage to bloat their stack because they think they need to "scale". I have web applications running that reliably serve 50k users per day and cost me $10/month, running on a single, cheap VPS.
What's your stack?
Re: Costs of running a Python webapp for 55k monthly users
#74I wonder how much it would cost for the same app, if developed in Java or dotnet core. They could save a good chunk of the 69 USD they spend on Digital Ocean servers. edit : To clarify, What I meant was that to serve 55k users, perhaps using more efficient languages like C# or Java, would allow them to run on lesser spec machines. And as those users scale up, to say a million users a month, perhaps savings would also…
I don't disagree that another language/runtime could reduce the cost. But why do you value developer time at 0 USD? Unless this is a hobby, the hourly rate of a developer is higher than that monthly Digital Ocean bill.
I never said anything about developer value.
Re: Costs of running a Python webapp for 55k monthly users
#75Earlier quoted context omitted.
If you want to provide uninterrupted service to your clients you’ll have to spend some $. You want to have redundancy, machines hosted in different different locations, backup prod servers, monitoring, analysis tools. Even if it is for 1k monthly users, if you want reliability - it will increase the costs.
I beg to differ. In my experience, the complicated setups that are justified by the argument of "reliability" have more downtime then a single VPS. The reason is probably that there are more moving parts and more has to be maintained / can go wrong. These days, a single VPS in the right datacenter has excellent uptime.
> I beg to differ.
> In my experience, the complicated setups that are justified by the argument of "reliability" have more downtime then a single VPS. The reason is probably that there are more moving parts and more has to be maintained / can go wrong.
> These days, a single VPS in the right datacenter has excellent uptime.
Again, maybe in your experience but that's not universal. There's literally no redundancy with running everything off a single VPS and if that datacenter has network or hardware problems, then your service is down.
Is redundancy necessary for the scale of OP's app considering it provides 0 income? Most likely not, but that's a decision they've decided on and there's nothing wrong with that.
What does excellent uptime mean in your book? With Digital Ocean's AM2 region I had regular downtime every few weeks and while I'm alright with it, if I had another VPS in another datacenter it would've had next to no effect on the customer experience. But an hour or more of downtime every two weeks isn't excellent.
Re: Costs of running a Python webapp for 55k monthly users
#76This is not clear at all - 55k monthly users means nothing, what's the average number of requests per second? 99th percentile? What's the same stats for CPU and memory usage? 3.4k users per day is actually not that large a number, even assuming each user is going to bombard your server with thousands of requests in 20 minutes, it's well within what optimised flask with wsgi can handle with a very mediocre compute instance.
Further,Are you absolutely sure that you have optimised your configuration and code for performance without changing the stack? (Serving static components directly via ngninx, caching responses using flask, caching other resources using memcached, optimizing gunicorn worker counts for the instance type, profiling which endpoints take the most amount of time and trying to optimize them, see if the bottleneck is webserver or the db, considering pypy, and probably 50 other ideas).
Are you also absolutely sure that bluegreen deployments are what you want to use given your cost constraint? Further, if you have bluegreen it should be straightforward to downgrade your instances to smaller ones fairly easily,why not do that first before discussing costs?
We run production webservers on t2.small ec2 instances in elastic beanstalk and (with some assumptions) handle comparable loads during work hours. We have two redundant instances and can easily scale up or down even on schedule with zero extra code. There's not even a need to minimize costs here because our application costs 100x more on data lake costs than the webservers, but it really helps keep the engineers grounded and ensuring they don't write outrageously inefficient code that's covered up by excessive server sizes.
Re: Costs of running a Python webapp for 55k monthly users
#77Nice writeup! Always appreciate transparency with these sorts of things, as someone who writes a lot of tiny personal projects and sometimes wonders how much I'd have to invest if they ever actually gained any traction. Congrats on having so many users, and good luck on monetization. For the server instances, I can't imagine 4 CPUs/8 gigs RAM is really needed 24/7, but can imagine it being needed in bursts, and I ass…
Thanks for the compliments! Yes, the server instances are definitely too large. I was previously running on 2 instances that were half the size and ran into some problems which I thought I could fix by increasing specs. Turns out the problems were not related to specs and now I'm stuck with the instance size (on DigitalOcean you can only up-size not down-size) I use Postico too, but don't have enough SQL chops to get…
You’re already using blue/green for deployments, so why not:
* replace the currently inactive server with a smaller instance
* swap to the new instance and test the load
* replace the second server
For such a small app I’d drop the blue/green (most deploys will likely only take a few seconds?) and host Postgres on the same server.
Also, I’d move metabase onto a DO instance.
Any reason you’re using DNSSimple over a cheaper provider (or free in the case of DO)?
Re: Costs of running a Python webapp for 55k monthly users
#78It's disappointing (and expensive) that you have no caching strategy. I would bet that 99% of your scoreboards are updated very infrequently, these pages could be re-generated into static html pages via cron job every 30 minutes / 2 hours / once per day, whatever frequency you choose. It's a free service, make people pay to have real-time updates.
My gosh, you are polling each leaderboard for changes every 15 seconds. Again, I would bet perhaps 1 in 1000 mature boards (i.e. online for more than a day) change in any 15 second period. You could severely reduce your server load by utilizing a CDN and statically-generating any board which hasn't changed in say, the past 6 hours.
Re: Costs of running a Python webapp for 55k monthly users
#79> Note: the servers are oversized for the load we’re currently seeing. The reason for that is that we tried to solve a production issue by increasing the server specs. It didn’t solve the problem, and now we can’t down-size the servers without re-provisioning them.
Too late for them, but if you find yourself similarly needing to increase the capacity to solve a produciton issue on DO: you can upgrade CPU/RAM without increasing disk size. This allows you to downgrade later if you end up over-provisioning.
Re: Costs of running a Python webapp for 55k monthly users
#80Earlier quoted context omitted.
Not to sound mean, but if there aren't posts/blogs/whatever explicitly telling people how to minimize costs... then they'll continue to follow the ones that make them pay $100+.
Ok, here is a quick tutorial: Step 1: Copy Peter Levels stack: https://www.nocsdegree.com/pieter-levels-learn-coding/ If he serves hundreds of thousands of monthly users and makes a million a month with a single VPS, you certainly won't have scaling issues when you start out or just have tens of thousands of users. Step 2: If you really scale beyond that, resist the urge to bloat your stack. Think long and hard about…
> PHP (He doesn't use any frameworks like Laravel)
I wouldn't want to read (or write) that code, but thanks for the article.