471–480 of 500 posts
He will be up for surprise. HTTP with connection: keep-open can serve 100k req/sec. But that's for one client being served repeatedly over 1 connection. And this is the inflated number that's published in webserver benchmark tests. For more practical down to earth test, you need to measure performance w/o keep-alive. Request per second will drop to 12k / sec then. And that's for HTTP without encryption or ssl handsha…
using what ? That numbers are on low side even for my old desktop
Earlier quoted context omitted.
Your point makes sense if you have no idea how Twitter works. It needs to assemble tweets internally, sort them with an ML model, add in relevant ads and present a single response to the user because end-user latency matters. And each of these systems eg. ads has their own features, complexities, development lifecycle and scaling requirements. And of course deploying them continuously without downtime. That is how yo…
> I know you think you’re smarter than everyone at Twitter. But those who really know what they are doing have a lot more respect for the engineers who built this insanity. There are always good intentions. You ignored one possibility - that twitter engineers, or people managing them might be just incompetent and all of that might just be overly complex POS There is that weird disgusting trend to assume just because…
They wrote Finagle which is a very well written and highly regarded Scala micro-service framework that is used by other companies such as LinkedIn, Soundcloud etc. Likewise Pelikan is an excellent caching service.
We know that Scala is a proven, high-performance, type-safe language that is optimised for concurrency and stability. So it's not like their tech stack is written in Ruby and needs to be re-written in Rust or Go. It's already performant.
Earlier quoted context omitted.
It's less "short memory" than the fact that you can be a "senior software engineer" after just 5 years or so experience. There is a significant cohort of (particularly web-tech) developers who were young children in the 90s, and whose professional careers started in the 2010s and have only ever known "the cloud", big-tech and big-tech tech (k8s, etc). It's a similar phenomenon to the observation that tech "innovation…
I'm a CS undergrad, do you have any recommendations for effectively combating this?
Forcing yourself to use barebones languages and environments is good too. Hacking on ancient machines or targeting embedded hardware is another good way to get a better intuition on the order of magnitude performance differences of various approaches.
Reading about promising tech of the past is also useful: prolog, Smalltalk, etc. Lots of inspiring and fruitful lessons to mine there.
Earlier quoted context omitted.
No approach is a silver bullet here, but what I've found effective is to seek out friendships with / mentorship from senior and staff-level engineers. They'll have tons of war stories from 10-20 years ago, and may even have some snarky opinions on what "new technologies" are just re-inventions of something that the industry had already solved decades ago. As a current undergrad, you can also look to your professors f…
It’s gotta be tough though for young devs to tell the difference between old fogeys just dismissing new tech because it’s new, vs because it’s a recapitulation of an old mistake. And the thing is that what was a bad idea in 2000 might now be an idea whose time has come, because the surrounding context has changed - be it browser technology or the size of machine memory or the capabilities of programming languages. So…
Earlier quoted context omitted.
I'm always reminded of that tweet from @SwiftOnSecurity https://mobile.twitter.com/SwiftOnSecurity/status/1485822027... > Once you understand your computer has 16 cores running at 3GHz and yet doesn't boot up in .2 nanoseconds you understand everything they have taken from you. With their infinite VC money at their disposal, and with their programmers having 100 GHz machines with thousands of cores, 128 TB of RAM and…
Booting has fundamental hardware limits, though. Will that harddrive or whatever really reply all in 0.2 ns?
Earlier quoted context omitted.
> just shuffling tweet sized buffers to network offload cards Except that's not what it is doing at all. It assembles all the Tweets internally, applies an ML model to produce a finalised response to the user.
Great, staple a few ML accelerators to your NIC. Nvidia sells them! You could build an entire supercomputer style setup 100% optimized for Twitter data movement and computation with COTS hardware IMO. I strongly doubt that entire datacenters need to be used if and only if Twitter obsessively optimized for hardware usage efficiency over everything else. In reality they don't and make some pretty big compromises to act…
b) No one has said Twitter operates entire data centres.
c) You need more than just NICs and ML accelerators to built a Twitter timeline. You need to rank the content, determine appropriate ads and combine them together. You can't do that in your network card.
(Disclaimer: ex-Twitter SRE) > There’s a bunch of other basic features of Twitter like user timelines, DMs, likes and replies to a tweet, which I’m not investigating because I’m guessing they won’t be the bottlenecks. Each of these can, in fact, become their own bottlenecks. Likes in particular are tricky because they change the nature of the tweet struct (at least in the manner OP has implemented it) from WORM to wr…
What do you think about his interesting comment on the possibility of a mainframe? "I also didn’t try to investigate configuring an IBM mainframe, which stands a chance of being the one type of “machine” where you might be able to attach enough storage to fit historical images." It seems theoretically possible it could accomodate the entirety of Twitter in 'one machine'.
There was a HPC cluster at Princeton when I worked there (which, looking at their website, has since been retired) that was assembled by SGI and outfitted with a customized Linux unikernel that presented itself as a single OS image, despite being comprised several disparate racks of individual 2-4u servers. You might be able to metaphorically duct-tape enough machines together with a similar technique to be able to run the author's pared-down scope within a single OS image.
With respect to the IBM z-series specifically - if the goal of the exercise is to save money on hardware costs, I'm imagining purchasing an IBM mainframe is in direct opposition to that goal. :) I'm not familiar enough with its capabilities to say one way or the other.
Earlier quoted context omitted.
It’s gotta be tough though for young devs to tell the difference between old fogeys just dismissing new tech because it’s new, vs because it’s a recapitulation of an old mistake. And the thing is that what was a bad idea in 2000 might now be an idea whose time has come, because the surrounding context has changed - be it browser technology or the size of machine memory or the capabilities of programming languages. So…
Wouldn't DCOM be more akin to Corba or RMI? I'm failing to see the analogy to Kubernetes.
Earlier quoted context omitted.
Great, staple a few ML accelerators to your NIC. Nvidia sells them! You could build an entire supercomputer style setup 100% optimized for Twitter data movement and computation with COTS hardware IMO. I strongly doubt that entire datacenters need to be used if and only if Twitter obsessively optimized for hardware usage efficiency over everything else. In reality they don't and make some pretty big compromises to act…
a) No one has said that Twitter doesn't use ML accelerators. b) No one has said Twitter operates entire data centres. c) You need more than just NICs and ML accelerators to built a Twitter timeline. You need to rank the content, determine appropriate ads and combine them together. You can't do that in your network card.
They do though. 3 in the US alone (https://www.datacenterdynamics.com/en/news/report-elon-musk-...).
Earlier quoted context omitted.
Twitter doesn't allow 280 of any codepoint. The more complicated ones count double against your limit.
Ah, so Twitter’s Unicode implementation is fucked.
If it counted UTF-16 code units that would be dumb. It doesn't. The cutoff was deliberately set to keep the 140 character limit for CJK but increase it to 280 for the rest. And they did that based on observational data.
https://cdn.cms-twdigitalassets.com/content/dam/blog-twitter...
https://blog.twitter.com/en_us/topics/product/2017/Giving-yo...
