[sho_hn]

I think that's misreading the exchange. He was challenging Musk on the fact that "1000 RPC calls" isn't what's happening and isn't the reason for the slowdown in his opinion, but did not deny that there are performance issues - and even cited other reasons it's slow. I don't see the denial you see.

[viig99]

Said engineer, said 1000 RPC calls are not the issue, and when questioned further on proving a tracepath / perf result casually exited the conversation, to me it looks like they are not ready to do better or listen to valid criticism, leading conversations on semantics is just creating noise instead of acting on signals.

Also 1000 RPC's are a very valid performance bottleneck, 1000 * latency caused by serde+ network can compounds easily based on data locality + container network orchestration, no data was provided otherwise even when asked for.

[fragmede]

Except that you can open the dev console in a browser and load Twitter.com yourself and you won't find 1000's of XHR requests.

[MonkeyMalarky]

Not to defend any of the catastrophe of management that just happened but can't both be true? Eric does say in his tweets that a lot of time is spent waiting on the network. If that is because server side, the endpoint handling a request is spamming other backend services with 100s of RPC calls it would be slow. Now, why you would call out your android dev. on why your backend is not responding fast, I dunno.

[sho_hn]

That's client-side requests. Musk was talking about internal RPC calls to microservices needed to ultimately respond to the client-side requests.

If the internal arch is heavy on microservices and you're putting together, say, 50 tweets you're at 1000 RPC calls with just 20 per tweet. It's not inconceivable.

The developer puts the real number at 200.

[viig99]

RPC generally means server side calls, probably this https://twitter.github.io/finagle/, and XHR is not RPC.