大家怎么看马斯克rpc1000+事件？？？

说Eric不该上来公开怼elon的 摆脱 明明elon自己先发到public上把twitter团队说的跟shit一样 从一周5小时论/浪费食堂论/大裁员/软件加载过慢 放你自己的project和团队被从work ethics到technical skills被踩成shit 你忍了又忍这下实在忍不了了还不能公开应对下？
elon这么做无非就是：第一 我才是twitter的再生父母（你们之前做的都是💩）之前都是有名无实；第二 我就是这种asshole老板 别以后不爽了又来怼我 渣男第一天就是渣哦；第三 我什么都懂 我就是know-it-all 围观的一看elon真牛掰啊 上知天文（SpaceX）下知地理（地上跑Tesla）现在连计算机细节点的都知道 光环再加一层

匿名用户 发表于 2022-11-17 13:45
》 说twitter的复杂度比微信低一个数量级不夸张。
这个的确，微信比twitter复杂很多。

慢的归因需要具体数据分析，你说多半是对的。

但1000+RPC真的还是匪夷所思，这会对基础架构方面很多部分带来不合理的负载。
这里想了下，如果twitter的timeline是通过数据预处理获得的一个id序列，以及通过id去渲染具体的每一个单独内容。这里就算序列需要考虑混合推荐、时间序列以及插广告，再怎么多也不太可能是rpc膨胀的根源；而单个内容里都是些读多写少可以接受少许delay的数据，不应该造成请求进一步膨胀，再怎么batching，你首页默认加载的内容块才多少个...
然后加载的图片、视频等静态资源的加载则是合并加载CDN的部分，应该跟后台部分就没啥关联了。
而且我稍微算了下按10B用户设计指标算，完全内存化的id序列以及容灾备份占用的机器资源也还好。

fabulousz 发表于 2022-11-17 02:03
慢的归因需要具体数据分析，你说多半是对的。

但1000+RPC真的还是匪夷所思，这会对基础架构方面很多部 ...

是的。这些RPC肯定存在很多优化空间，被开除那哥们也说了，很多feature其实没什么用，但是现在也在execution path上。

还有一点额外补充一下，就是加载一个首页单凭有多少内容块来估算其实不够。除了内容块的加载外，还有一些invisible的业务需要处理。比如content moderation（确保timeline里面的内容是健康的，align with both user preference & ads brand safety）。所以一个系统复杂到一定程度，naturely需要这种细致粒度的rpc支持。从性能优化角度而言，优化rpc的effort投入大（需要重组业务逻辑，这个非常messy），回报少（rpc batching不是主要bottleneck）。这也是为什么大家对1000+rpc这个指责反应比较强烈 -- 如果tech lead不站出来反对，按照老马的一贯作风，道歉完的下一步就是要工程团队去优化这些rpc了，这个大方向是错的，受苦受难的还是底层的工程团队。

匿名用户 发表于 2022-11-17 09:10:51
是的。这些RPC肯定存在很多优化空间，被开除那哥们也说了，很多feature其实没什么用，但是现在也在execution path上。

还有一点额外补充一下，就是加载一个首页单凭有多少内容块来估

我理解你说还有额外的那部分应该在merge出timeline序列之前，一旦决定了timeline序列，同一个消息块对2个不同用户展示会不同么？应该不需要那么多刚给访问时才决定，用点空间换时间了。

不过说到底还是不同技术体系下偏好和选择路径的不同吧，在我们这如果是高读写比的场景下不预处理，去述职答辩估计会被人挑战到自闭。还可能被review机器资源的时候被人拿其他业务的业务量和机器资源投入来横向对比，要求解释为啥你需要的更多…

微信用户_2652432 发表于 2022-11-15 11:28
裁员的前兆吧，唉，看到meta的裁员名单，地里的朋友也说亚麻裁员实锤，希望一切都会好起来

这关我刚裁过一波的推特何事