backbone 路由 react 渲染,是个挺踏实的方案
如果是新的 Rails 5 项目,可以试试去 SPA 化,turbolinks 加 jquery 处理下 cable 就完了
我也写个 Ruby 版,1 文件带测试:
https://gist.github.com/luikore/0c99af986ae99d2626e601de6ae1e09a
#31 楼 @jarorwar 它的 GC 的确还比较原始,不过这个延时不一定是 GC 造成的,也有可能是 IO 事件没处理好 #35 楼 @scriptfans 取而代之有一套宏编程的奇技淫巧... 不过运行时反射应该是比 Ruby 差不少
是不错的语言啊,目测用 kemal 比 ngx_mruby 或者 h2o mruby 更靠谱,至少有 redis / pg / websocket 的完整支持
一年前答了一发现在都没填完坑... https://www.zhihu.com/question/33311554
#11 楼 @flowerwrong 你可否举几个 python 的栗子,然后我告诉你怎么写代码
libuv 的 Ruby 绑定有,但是效果应该很差
Ruby 中的文件 IO 操作不会阻塞其他线程
最初的 YARV 可以预编译的,但是由于字节码的设计还没成熟,而且从源码到字节码的编译其实速度很快,就没开放。
现在的 Ruby 2.3 又可以预编译到字节码啦
File.write 'foo.rbc', RubyVM::InstructionSequence.compile(File.read 'foo.rb').to_binary
载入
RubyVM::InstructionSequence.load_from_binary(File.binread 'foo.rbc').eval
如果你有很多代码 (例如 10M 那么多), 觉得载入太慢,或者你不想别人容易的看到源代码,可以把它预编译到字节码。
执行速度是没有差别的
Rails 其实早就支持各 model 连不同的数据库啦,还支持单 model sharding 到不同的数据库 (mysql 和 pg 混合都可以)
#2 楼 @onenewlife 你把 Gemfile 的依赖改成 1.8.3 应该没问题的
升级到 json 1.8.3 或者用更新的 2.0.1
比 jbuilder 好多啦!
phoenix 比 rails 简单直接的一点是可以针对不同的 request route 设置不同的 pipeline, rails 至少应该把 mount middleware 这段生成到 initializer 中去...
再扯扯对 HTTP/2 的一些思考...
其实单连接多请求好处是每个请求的 overhead 减少了,一些场景已经不需要 sprite 打包图片了 反正 Rails 的 asset pipeline 生成 sprite 和 font 又复杂又有点问题,那干脆就用 HTTP/2 serve image / svg, 的确是 nginx 换一下就能得到好处...
但如果有很多特别小的图片例如图标,http2 也没有 sprite 性能好,但为了技术栈简洁起见,把图标 base64 inline 到 CSS 里更简单。
在 html 中生成 svg 元素即可
<svg width=200 height=200>
<path d="M 20 20 L 20 120 L 120 120 L 120 20 z" stroke="black" fill="white"/>
</svg>
不写 js 没这个烦恼
很多都是 trade off, Lua 为了实现简单容易优化,实际用起来很多限制,例如最多 512 个变量。而由于 Lua 设计统一 list 和 map 为一个 table 数据结构,LuaJIT 还会猜 table 实际是当成什么用的而作特化优化。
我觉得 Rack 中一些可能影响性能的问题:
Rails 的一些可能影响性能的问题:
redirect_to :back
改成了 redirect_back
HTTP/2 也不是万能药,连接断了或者中间有 proxy 就不行了... 实际上 websocket 甚至退化成 long polling 做 server push 更实用。在资源加载上,HTTP/2 也不一定比简单粗暴的 asset 打包快。HTTP/2 还有一个作用是 multiplexing, 一个 TCP 连接完成多个连接,但其实传输层已经有 multiplexing 了,就是新开 TCP 连接比较慢而已,现在 TFO(TCP Fast Open) 已经标准化,HTTP/2 对比开 TFO 的机器应该也没明显的优势。
应不应该 Fiber 化呢?其实 Ruby 的 Fiber 在很多地方都像线程... 预分配的栈也比较大。但是基于线程的话兼容性无疑是更好的,调用很多 C-library 不会有线程安全问题。基于线程实现上万连接的服务器也有... 就看操作系统的线程调度了。
在 eventmachine 和 goroutine 的发展过程中也暴露了不少坑。例如一个 coroutine 花时间很久没交出控制权怎么办... 得用一个定时器过一段时间去打断一下它,保证不会因为某个 routine 而卡住。而 coroutine 和操作系统的事件队列配合也是有坑的,例如你收到一个事件但处理延后了,这个事件过时了怎么办... 那都是要处理的。
服务器的优化不完全是 Rails 的锅,例如操作系统改个内核什么的往往有奇效... 但现在各种用 docker 之类的就是在牺牲操作系统调优的可能性哇...
Rails/Rack 发展到现在功能已经太多,而做个简单的服务往往用不到很多功能,这也是 trade off...
文中的 benchmark 有点问题,事实上通过 Python/Rails 和通过 SQL 查询的区别达不到 10 倍,快查询 2 到 3 倍的差别是应该有的,慢查询大头还是在 SQL
openresty 啊我试过,感觉啥都干不了... 我是被宠坏了
#29 楼 @small_fish__ 消息放到 redis 的队列里
删掉 Makefile 中的 -Werror=shorten-64-to-32
, 然后 make install
试试?
话说有考虑过 git lfs 吗?https://github.com/github/git-lfs
终于在大文件上也不输 perforce 了
#6 楼 @michael_roshen 不知道你这个是 xh 还是 hx ...
嵌套查在 pg 不一定慢
select *, (
select array(
select id from "B"
where "B".internalname = "A".internalname and "B".worktime = "A".worktime
order by random()
limit "A".xh
)
) from "A"
更快的取样可以上 tablesample clause, 不过限制是只能用于 table 和 materialized views
不过这些功能 iTerm 都有...
iTerm 可以开多个 tab, 而且新开 tab 会转到之前 tab 的目录 可以分屏 可以定义 profile 设置一系列初始化命令,例如连水木 bbs 用 gb2312 编码并输入用户名密码 有命令给 tab 设置 title, 颜色和图标 cmd + option + b 可以查看历史屏幕快照
iTerm 还能显示图片 cmd 点击出错栈可以打开编辑器并转到对应行,cmd 点击链接可以打开浏览器 可以添加 trigger 监控屏幕是否输出匹配正则的字符串,然后触发 action 例如发 notification 可以复制带颜色的屏幕输出
#10 楼 @jiyinyiyong 哦... 总觉得是你...
#5 楼 @liyuan462 域名应该在 @jiyinyiyong 的手里...
其实现在机器处理数据能力很强,小系统可以不分词,只拆字,然后自己调整匹配度就行了