Note that they were running Postgres on a 32 CPU box with 256GB of ram.
I'm actually surprised that it handled that many connections. The data implies that they have 4000 new connections/sec...but is it 4000 connections handled/sec?
32 vCPU, meaning an undetermined slice of a CPU that varies depending on what else is running on the box (and the provider has an incentive to run as many VMs on the box as possible).
It’s likely an actual CPU would’ve handled this load just fine.
The race is to make Bank’s culture a reality doesn’t have to depend entirely on human ability. It’s a race to create the minds before we’re too dumb to do so.
I have GE and haven't even talked to an agent in the last four entries. The last time I didn't have to claim my baggage which was really strange (YVR).
To be fair, GNU/Linux distros like Debian lean very heavily on the GNU part. They owe a lot to the GSF and its work is highly praised.
Just their kernel somehow seems to be stuck in vaporware status. Probably because a lot of developers would think "why work on this when we already have Linux" which is a fair point too.
I wonder if microkernels more relevant now than ever given their reduced attack surface, and also the recent availability of more cores.
One big criticism from decades ago was the loss in efficiency. But what's changed since microkernels were conceived is how many processor cores are available to offload userspace drivers from the kernel.
Is this a valid viewpoint? Is it time for microkernels to overtake monolithic kernels?
You are misunderstanding how HA works with DNS TTLs.
Now there are multiple kinds of HA, so we'll go over a bunch of them here.
Case 1: You have one host (host A) on the internet and it dies, and you have another server somewhere (host B) that's a mirror but with a different IP. When host A dies you update DNS so clients can still connect, but now they connect to host B. In that case the client will not connect to the new IP until their DNS resolver gets the new IP. This was "failover" back in the day. That is dependent on the DNS TTL (and the resolver, because many resolvers and aches ignore the TTL and used their own).
In this case a high TTL is bad, because the user won't be able to connect to your site for TTL seconds + some other amount of time. This is how everyone learned it worked, because this is the way it worked when the inter webs were new.
Case 2: instead of one DNS record with one host you have a DNS record with both hosts. The clients will theoretically choose one host or the other (round robin). In reality it's unclear if that actually do that. Anecdotal evidence shows that it worked until it didn't, usually during a demo to the CEO. But even if it did that means that 50% of your requests will hit a X second timeout as the clients try to connect to a dead host. That's bad, which is why nobody in their right minds did it. And some clients always picked the first host because that's how DNS clients are sometimes.
Putting a load balancer in front of your hosts solves this. Do load balancers die? Yeah, they do. So you need two load balancers...which brings you back to case 1.
These are the basic scenarios that a low DNS TTL fixes. There are other, more complicated solutions, but they're really specialized and require more control of the network infrastructure...which most people don't have.
This isn't an "urban legend" as the author states. These are hard-won lessons from the early days of the internet. You can also not have high availability, which is totally fine.
reply