3 ms·

How can Ceasefire be self-supporting?

26 points by sprague 6y ago

PaulHoule 6y ago
That is 0.2 cent per user per month, right?
alfalfasprout 6y ago
Title is wildly inaccurate. From the site author: " Yeah it turned out to be a bit optimistic :) The most traffic we had at once was when we were featured on the front page of the BBC, and there were a few thousand people browsing. We had to scale up briefly but everything ran smooth."
- smnscu 6y ago
  For context, the original title was something like "How can Ceasefire support 500k users with $1,000 per month?". Scaling _from_ $1k per month when a few thousand users hit the page? Yeah, that's not the StackExchange kind of post I was hoping for. edit: wow, @Monkyyy's reply in that thread is simply brutal (you can't link to comments, selecting text is wonky too)
  - mixologic 6y ago
    @Monkyyy is the kind of user you fire.
    - dddddaviddddd 6y ago
      And simultaneously the engineer you hire at the beginning of the project.
warent 6y ago
What is the best way to test load and pricing like this? In my mind, the way I would do it is run the server and then hit it with a load tester (i.e. a number of queries simulating the number of users desired). That will tell us if it can withstand the load. Then I would seeing how much it costs after 5 minutes of this test, and then multiply that by 7200. It just feels kind of primitive and naive. There must be a better way. For example, Google can't simulate real-world service loads like this, so there must be.
connectsnk 6y ago
Please correct me if I am wrong. I think that bulk of the cost must be coming from SQL Server. If the author migrates to MySQL hosted on cloud VM's, then this cost might be reduced by 50 - 70%
- threeseed 6y ago
  Maybe. But often people don't look at the TCO. You are going to need to scale that database up and down, regularly do backups and then test those backups, integrate and manage monitoring, ensure it is highly available across different data centres, ensure you are testing new releases/patches and then managing the upgrades e.g with canary releases etc. Or you can just use the DaaS and get all of that for free as well as 24/7 support when something bad happens.
  - zootboy 6y ago
    Except in no way is that "for free." You're absolutely paying for it, just in the form of a percentage markup forever.
jitl 6y ago
It sounds like most of the separate backend apps could be squeezed together on a single host or into a single service. .Net has good threading, and some quality runtime bits and bobs - cram everything together into a monolith (api, queue, front-end hosting, auth). Use your DB as the queuing service. Gogs/Gitea and Laravel demonstrate this “super cheap all in one” quite well. Make network RPC into in-process function calls. Trim down from 3 SQL dbs to a single DB with multiple namespaces. Forget the redis caching layer - at the 1000 concurrent user mark, you don’t need it; or try materialized views or expression indexes. Not only will this cut the hosting costs in a quarter, but removing many of these DBs and caches will also make the service much easier to develop - so now you can open-source it easier.

26 points by sprague 6y ago

That is 0.2 cent per user per month, right?

Title is wildly inaccurate. From the site author: " Yeah it turned out to be a bit optimistic :) The most traffic we had at once was when we were featured on the front page of the BBC, and there were a few thousand people browsing. We had to scale up briefly but everything ran smooth."

smnscu 6y ago
For context, the original title was something like "How can Ceasefire support 500k users with $1,000 per month?". Scaling _from_ $1k per month when a few thousand users hit the page? Yeah, that's not the StackExchange kind of post I was hoping for. edit: wow, @Monkyyy's reply in that thread is simply brutal (you can't link to comments, selecting text is wonky too)
- mixologic 6y ago
  @Monkyyy is the kind of user you fire.
  - dddddaviddddd 6y ago
    And simultaneously the engineer you hire at the beginning of the project.

warent 6y ago

What is the best way to test load and pricing like this? In my mind, the way I would do it is run the server and then hit it with a load tester (i.e. a number of queries simulating the number of users desired). That will tell us if it can withstand the load. Then I would seeing how much it costs after 5 minutes of this test, and then multiply that by 7200. It just feels kind of primitive and naive. There must be a better way. For example, Google can't simulate real-world service loads like this, so there must be.

connectsnk 6y ago

Please correct me if I am wrong. I think that bulk of the cost must be coming from SQL Server. If the author migrates to MySQL hosted on cloud VM's, then this cost might be reduced by 50 - 70%

threeseed 6y ago
Maybe. But often people don't look at the TCO. You are going to need to scale that database up and down, regularly do backups and then test those backups, integrate and manage monitoring, ensure it is highly available across different data centres, ensure you are testing new releases/patches and then managing the upgrades e.g with canary releases etc. Or you can just use the DaaS and get all of that for free as well as 24/7 support when something bad happens.
- zootboy 6y ago
  Except in no way is that "for free." You're absolutely paying for it, just in the form of a percentage markup forever.

jitl 6y ago

It sounds like most of the separate backend apps could be squeezed together on a single host or into a single service. .Net has good threading, and some quality runtime bits and bobs - cram everything together into a monolith (api, queue, front-end hosting, auth). Use your DB as the queuing service. Gogs/Gitea and Laravel demonstrate this “super cheap all in one” quite well. Make network RPC into in-process function calls. Trim down from 3 SQL dbs to a single DB with multiple namespaces. Forget the redis caching layer - at the 1000 concurrent user mark, you don’t need it; or try materialized views or expression indexes. Not only will this cut the hosting costs in a quarter, but removing many of these DBs and caches will also make the service much easier to develop - so now you can open-source it easier.