neoblackcap

@Q9K 当然了，腾讯那边是每台是 1000qps 这样子，不过他们是有做分流

@Q9K 一般校园系统，不是什么选课之类的活动，100qps 差不多了。而且很多时候是可以在前端人为控制速率的。还能加队列慢慢处理。
而且 es 也要看索引以及分词做得好不好，不是说你们上了就能做到 10000qps 。腾讯他们自己分享过，他们的 QQ 登录服务器也是 1000qps 这个量级

@oxromantic Azure 的根基，不可能不维护不更新的

Python 什么时候不注重性能了？ Python 是因为注重 C 扩展兼容性以及单线程效率所以很多改动没法做。但是随着这些年大厂的不断投入，Python 也开始动了，新版本已经加入颗粒度更小的子解析器。有利于日后解决 GIL 问题。
至于 Javascript 还不够激进么？ V8 早年都是直接生成机器码执行的。V8 在我看来，都属于 VM 的第一梯队了

@ieesk 其实完全可以很少改动，你把写入的操作放在一个独立的服务，那个服务只有一个进程，开放一个接口。现有的服务在写入的时候就调用这个接口。
上锁，释放锁的速度并不慢。慢是因为锁竞争。单线程写入的话，性能上限应该可以逼近你数据的写入效率极限。

不过这样改的话，运维会多了很多工作。毕竟无缘故就多了一个服务需要运维，还让系统引入了一个单点问题。如果要解决单点问题的话，又要引入分布式锁。

我们以前的做法是尽量让锁前置，不用数据库。比如特定的竞争操作只有 master 进程有写入的权限。这样就去掉了锁竞争

前端项目，建索引的时候，直接 10G 打满。16G 已经不够 IDEA 消耗了，还是上 32G 吧，建议 64G

@lscho 跨文件系统的操作，都一样。如果都是在虚拟机里面的，那么性能还可以接受。

就这样的统计功能都要放在业务系统里面做，那什么系统跑不死啊。登录，登出的事件写日志（进 MQ 再落地也一个道理），直接通过回放日志，简单统计一下当天是否有超过 15 分钟的在线就得了。而且还不会对业务系统产生影响，因为这需求可以做成实时的，也可以做成离线。
OLAP 的活就不要压业务系统了。