A unix timestamp does not have different timezones. It is a counter.
No matter where u are in the world a timestamp call should give you the same numeric value at the same instant. It is not time zone adjusted. Store that number, unadjusted as the source of truth.
You can get to any local time after that.
Internet related would be, back in the early 2000s when I was building out infrastructure of pinkbike/trailforks I was optimizing things and discovered that this initcwnd parameter was hardcoded to something like 2 or 3 packets in the linux kernels. This was causing the initial page to require multiple RTTs to load so I figured I would change that and recompile the kernel to make sure all out pages would be transmitted in one go. This made out site perform a lot better compared to most sites at the time.
Funny at the time I was a bit worried that the IETF would discover this and shut us down or something.
These days that parameter is default to something like 10 and you can increase it with a config parameter.
I think this article is cherry picking here trying to make Canada look good compared to say the USA and other countries. ( im canadain btw )
I think it's easy to take in 28K refuges when the illegal load is very small in Canada, of something like 20K per year [1]
Compare that to the USA that needs to deal with an illegal load of 20X that. [2]
And for 2019 the USA load seems to be twice that of 2018. [3]
If you agree that using a CDN for static content is a good idea, then it would seem HTTP/2 Push is useless.
The website is served from your servers while the static content is served from a CDN so you can't "push" it in the same stream as you webpage content.
Am I missing something here?
I'm not sure if I never understood this right, but it seemed server push was not an ideal overall solution. It seemed it was targeted to push needed css/js/image in the stream of the page result. But most assets that one would want loaded are coming via an external CDN so doing a push of that does not make sense. Yeah, I guess if you are proxying your whole site via the CDN.
Am I missing something here?
I hear ya...of the two bolded feature headings in the story we get:
1. Supersonic speed
( always welcome )
2. League of extraordinary emojis
( the last thing I would care about in a new os release )
You can get centimeter accuracy with gps. http://swift-nav.com/piksi.html
Even with cheaper modules and phones that dont carrier phase rtk, you can get meter which would be plenty for this application.
Very rare data access is disjoint, unless you're only doing key/value put/get. I think the interest of Redis is that it has many other features than simply put/get, and all those sorts, diff, etc typically would work a set of data that is being written in.
For sure having multiple instances will help some of this, but adds more complexity. Do you have your app write to multiple instances, and then read low latency from one, and read high latency from another? Is that data now consistent? Do you setup Redis replication and make sure that works right and then read from different replicas? Or perhaps you engineer some queue that does not block writes, groups them together and writes to Redis in a separate thread. Then you have to maintain all this and make sure it's correct, back it up, what are the corner cases, failure modes, etc.
From my experience, if you want to engineer things well, you end up essentially building out the same sub systems that a larger db engine has. Say Innodb.
I'm smart enough to know that I'm not smart enough to build a one off complex system more correctly than really smart people that have been iterating over many years and improving things on something like innodb.
There are very rare, very specific cases where I would use redis over something else if I was building something realtime, large and important.
Last time I used Redis I was surprised to determine to my surprise that Redis was single threaded. Of course I could have just RTFM but I assumed incorrectly.
This means that if you have part of your application that requires fast consistent GETs, and then another application does a slower SORT, UNION, DIFF, etc, on the same db or even other dbs on the same Redis server, EVERY other client request has to wait for this slower command to finish.
http://redis.io/topics/latency
This is something that one really has to engineer around in order to use it in an environment that requires performance and consistent latency. In our case of 1000s req/s it was just unacceptable to have the latency be affected, sometimes by 10 times, by a slower command.
A unix timestamp does not have different timezones. It is a counter. No matter where u are in the world a timestamp call should give you the same numeric value at the same instant. It is not time zone adjusted. Store that number, unadjusted as the source of truth. You can get to any local time after that.