4 ms·
This isn't a valid comparison. You don't know how many (and the hardware of) instances WhatsApp was running to support those 2M connections. And you're not comp
by bastawhiz 6y ago
This isn't a valid comparison. You don't know how many (and the hardware of) instances WhatsApp was running to support those 2M connections. And you're not comparing apples-to-apples: WhatsApp is not the same software that the OP is running.
Moreover, the 250K limit is an artificial limit imposed by Google for a generic cloud service. If you controlled _that_ software and tuned it for your specific application, you probably could squeeze an order of magnitude (or two or three) more connections out of it. Whether that's a worthwhile tradeoff is a function of whether the time required to rewrite the functionality of Cloud Run yourself (and run it, and maintain it) is lower than the cost of simply spinning up more boxes. If you're building a product and have the cash, it really doesn't matter whether you can run 250k connections or 2M connections if one could exist this week and suit your needs and the other could exist in 6-8 months when you build/scale/deploy it.
- Tepix 6y agoTo me it seems like it's directly comparable and the efficiency demonstrated here seems truly abysmal.
- bastawhiz 6y agoBeing able to handle 250K connections versus sustaining 250K connections are two different things. If you have a chat application used by mostly north american users, your usage is going to vary wildly between day and night. Cloud Run allows you to scale this up and down with ~zero ops work. Engineering for highly variable capacity and engineering for extreme scales are two entirely different problem spaces. If a managed platform like Cloud Run makes your business more efficient and you can save on compute costs, the "efficiency" that you're talking about is completely moot. Being able to handle bursty loads when you need to and being able to consistently handle large volumes of traffic are two separate and unrelated problem spaces.