Exactly. Here we crunch loads of data, and by a lot, I mean our production databases run on a three digit cluster of four digit terabytes of data. Good luck having that scale in preproduction environments.
We have loads of redundancy, and dedicated "test in production" machines/datacenters to test actual production loads in actual production-scale sets machines.
Now, tests in production usually involves a pair of hands and 2 other people looking behind (dev + ops + dba), and requires a well defined rollback procedure and post-mortem. We still have absurdly high SLA (99.999%).
It's not significantly faster (or slower), it's the author that doesn't know how to run a benchmark. You can read my take on his take [0].
Leaving that aside, async is very advisable (even a must) if your backend throws requests against external and potentially blocking services and you want to keep answering your own clients without scaling for no reason.
Yeah, but this scale of documentation production is unprecedented.
A lot of cash was dumped into fast and extensive R&D, trials and production scaling because of the urgency of the situation, and along comes an insane documentation backlog.
To put in perspective, the original HPV vaccine R&D and trial spanned over 7 years with 25,000 patients (of which only 20,000 women), and assuming the documentation was provided to the FDA as it was produced, it could be FOIA'd relatively quickly.
Pfizer/BioNTech did the same, with almost double the patients, in just over 6 months.
Ironically, if the FDA could deliver those documents "in time" it would be a sign of a pretty limited trial, and people would be complaining about that instead.
Critical mass. FB groups are a dumpster fire for topic discussions, but the fact that they're just there means loads of communities end up there anyway.
Reviewing/analysing data and filtering it are dramatically different tasks. With raw data, most of the heavy lifting is done by your data analysis stack, you don't crunch numbers yourself. Complying with FOIA requests though, is largely manual work.
The FDA has 14,000 employees; its FOIA office has 10, and they go at roughly 80,000 pages per month, meaning each employee does 8,000 pages per month, or roughly 400 per working day per employee, less than a minute per page. That to my non expert opinion sounds pretty fast.
That speed has been appropriate until now that the plaintiffs want 4 months' worth of FDA FOIA work for yesterday.
I agree that there should be a solution for these cases, but it's this particular FOIA request that's the anomaly, not the FDA way of work.
The only justified situation I can find is when you are working on two (or more) independent components at the same time.
My pain point in particular with PYTHONPATH (or playing with sys.path) is that people tend to use it with the only purpose of making import lines shorter, which brings naming collisions of all sorts when you aren't creative enough.
For small scale energy production small VAWTs [0] are relatively cheap, they offer more W/m2, and they are much more easily serviceable and installable.
For large scale production it's orders of magnitude less efficient, plus having multiple kites on the same plane brings in the wake effect [1] in full force. That's why regular turbines are generally laid in lines rather than wide surfaces, or with significant separation between them.
I hate Gitter with a passion. It's indexed, but it's chat after all, meaning it's painful to read as there are multiple conversations going on, and whatever you're looking for needs to be extracted from below the noise floor.
It always keeps coming up in my search results but it's absolutely never been useful to me.
> It was slower with the fewer threads, and giving it more threads made it even slower. Celebrating this as awesome efficiency is..."interesting".
With 1 to 4 process increase in 4 cores there's basically no granularity, at 3 there's not enough concurrency, and at 4 there's too much, choking the PostgreSQL process.
Whereas 1 to 16 blocking process increase allow for more granularity ramp up and leave the (almost) exact room for the PSQL process to do its thing before performance degrades.
That would be solved having the DB on a separate host to isolate this effect, and what happens in literally any non-dev environment.
And that's leaving asid the fact that 16 processes use roughly 4 times as much memory as 4, meaning async is cheaper to scale horizontally overall.
Personally we don't use it in my org, and the mix of on-prem Kubernetes and GKE is just a shitshow.
I recently started learning Nomad, and Nomad (+ Terraform for cloud) is the only thing that makes sense (for our use cases). That said, I think higher management is too highly invested in K8s and they won't backtrack on this.
Not a design/advertising guy, but often times I think it's to be able to display an ad at the bottom without the user to fully read the article, and without putting it ahead of the article (which is ugly IMO).
Without giving much detail, where I work many accounts from different businesses aren't linked... in customer facing systems. But internally everything is linked, and well linked (for good reasons). FB will profile you even more even though you can use a different email.