看来有些接口可以向上替换来提高速度。

加机器 加内存效果更佳，两台服务器换成 8 台服务器，2g 内存换成 16g 内存

这个结果对实际项目感觉没什么意义，毕竟线上项目可不是运行的 hello world 想像一下复杂的线上项目基于 rack，用纯净 ruby 编写，酸爽程度不论，其实还是要写出另一个不会比 rails 更好的框架来。

基于 rack 写的不会比 rails 更好，但是可以做分布式事务处理，公司业务有新的需求讨论完了就直接写代码，不会跟老板硬杠 rails 这个版本还暂不支持这个功能，下个版本要等到 6 个月以后才发布，也不会看到一堆“warning @rails/webpacker > postcss-preset-env > postcss-color-gray > postcss-values-parser”心烦意燥

个人观点，其实没必要比 rails 更好。

只需要在当前业务下可用即可。

我好奇这个分布式事务实现是在哪一层实施，需要框架层面支持？

事务实现一般放在在 service 层

关于 rails 的分层 可以参考 https://ruby-china.org/topics/41603

当然 rails 框架不需要支持 因为标配的 rails 是类似 20 年前 struts/ Webwork 那样处理 form 表单的，配置一下表单验证和跳转流程 XXmodel.save 然后数据库里就有记录了 地铁终点站就是到 M 就下车了

如果是面向服务的应用，发现需要的没有 (或者跟老板硬杠耐心等待 6 个月以后的下一版，一切都完美了)，不需要的一大堆，去掉不需要的一要花时间，二是提心吊担上线以后不知道什么地方会出幺蛾子。

Rails 增加一个 service 层就是新建一个文件夹那么容易。Rails 的底层就是 Rack，所以我很好奇有什么是 Rack 能做 Rails 不能做的。

Rails 汇聚了大半个 Ruby 社区的智慧，因为一点点问题就自建框架在熟悉 Rails 的人看来只是因小失大，不过这也是个人自由了。