还未发布过话题
  • @ruohanc 我非常想帮助别人,但你这样的说法真让人寒心。

    如果你觉得我的位置太高,会不会因为你的位置太低?如果你觉得每个人都在教育我,会不会因为你太敏感了,为不存在的事情替我着急?如果你觉得我的反应有些偏激,会不会因为你承受别人指出(别人的)错误的压力阀太低了?

    ETag 应该前置校验,这样除了减少网络传输外,(基本)不会产生性能下降。另外,你不要偷换概念,这不是 “这点”,不进行前置校验,绝不会是 “这点”。

    当然,如果我设计一个 WebFrame,应该也会引入类似Rack::ETag的中间件,作为通用组件,它的局限性是可以被容忍的。

    对于动态请求来说,etag 和 last modified 都是需要后置校验

    @ruohanc 我非常希望你也能明白,@quakewang 类似的说法是错误的,这并不是基础知识,而是错误的知识。

    @quakewang 进行分享,这是好的事情,分享的意义,并不单纯帮助了别人,也给了别人帮助自己的机会。

    另外,需要请教下的:实际上 last_modified 就是字符串,并非一定要时间戳或者其它什么格式,因为 HTTP 处理的是超文本;真有限制,也是各种 WebFrame 内建的限制。我这样的理解是不是错误的?

    貌似没有人能帮助我,为了回复 @ruohanc 你的这个帖子,我仔细翻阅了http://www.ietf.org/rfc/rfc2616.txt的协议,这个论述,我估计会在某些浏览器中不支持。好吧,也算你帮助了我。

    我已经到了俯首而为孺子牛的年纪,所以,并不太容易有类似生气的过激反应,倒是高中时,同学跑过来问问题,然后辅导之,然后她开心地说自己就应该不耻下问,这不是耍流氓么……

    我在文前的反问,并非 troll 行为,只是当年自己跟下属说类似的话时,那时没有人告诉我,这样是错的。


    @aptx4869 测试的前提比结果更重要些,比如确保 status 回来的都是 200,确保 GZip 压缩的 level 是一致的,比如 text 类型的 js/css/html 几个分开比对一下;另外,结果还是感觉不科学,再看看 Rails 对 Gzip 的实现是纯 Ruby 还是用了 C。如果,结果还是不科学(这就真的太不科学了),哈哈,欢迎来笑话我。


    一说真话,就遭人嫌,继续感受下吧。

    @luikore

    nginx 只用 gzip_static on 发送静态资源就够啦, 绝大部分动态内容都是不压缩的比较快

    gzip_static 是预压缩,就是 Nginx 会检测.gz 的对应已经压缩好的文件是否存在……

    gzip on 的话也可以配置哪些内容 gzip 哪些不 gzip

    这个是必须要配置的。

    像压缩过的 js, png 图片, gzip 对瘦身效果很不明显, 但是耗费很多服务器和客户端的 CPU, 还是不 gzip 的好

    压缩过的 js如果是指自己下面这句话的,呃,有效果才奇怪…… png 图片怎么敢用 GZip?不,不,没有特殊情况下,text 类的都应该开启 GZip,它的效率还是很高的。

    用 gzip_static 还有个好处: 在编译 asset 时就比较压缩效果, 压缩比少于一定量就不 gzip

    唉,Nginx 有个gzip_min_length参数可以设置……


    还是那句话,希望对大家有所帮助。 但坦率地说,有点后悔参合进来。

  • Rack::ETag 不是累赘,对于非性能瓶颈的请求,没必要手工加 fresh_when/stale 等判断,就算多生成一次 response body,浪费一些服务器资源也无所谓,客户端还是能够享受到 304 带来的好处.

    是如此,我当然知道……

    相信看到这里的朋友对 304 有了更好的理解。

    如果真要做优化,这种通用的 MiddleWare,确实非常鸡肋。我保留这个看法,因为这是正确的。

    但多数的产品用通用的就可以了,因为性能问题不会如此突出;如果要针对自己产品做类似Rack::ETag的处理,就需要确定自己的规则,当然,代码并不会增加太多,估计就 10 行内的事情。

    好了,我该说的都说完了。希望对诸位有所帮助。

  • #61 楼 @quakewang

    不仅仅是 markdown 转 html,就是单纯的 rails helper 生成 html,或者复杂页面 view template 渲染,也需要花费 10ms 级别的时间(没办法,ruby 不够快),对于访问量大的页面,片段缓存能够节约掉这部分时间也是相当可观的

    评论可以修改的,所以刚才没有看到这段。其它方式生成 HTML,这个怎么做缓存都不过分,脚本语言,没有办法的;我特指 Markdown 转 HTML,这个真的没有必要。

    对于动态请求来说,etag 和 last modified 都是需要后置校验,没办法提前到 nginx 这层面校验.我不选择用 last modified 是因为 etag 更加灵活,可以用更新时间+其他参数,比如我文章中提到过的当前用户 id,评论数等来做.

    前置校验,不是指放在 Nginx 中处理,而是指 request 过来的时候,先校验头部信息,如果 match cache 的,直接 status=304,并且返回空内容;而不需要再继续运算完整的 response

    我总感觉有些奇怪的,是动态请求来说这样的前提把自己画地为牢了?

    我不选择用 last modified 是因为 etag 更加灵活

    另外,需要请教下的:实际上 last_modified 就是字符串,并非一定要时间戳或者其它什么格式,因为 HTTP 处理的是超文本;真有限制,也是各种 WebFrame 内建的限制。我这样的理解是不是错误的?

    我始终觉得,因为 ETag 跑去改 Nginx 的源码,太草率了。当然,实际自己遇到这样的问题,可能也会类似的做法,dirty but quick. 但当做知识进行分享,感觉不是很好。

  • #62 楼 @aptx4869 你要把我搞疯掉了。

    你这个不用做测试就知道什么结果了呀,我没有说refresh_when的问题呀,我是说Rack::ETag这种 ETag 的 MiddleWare 的逻辑就是累赘。

    是不是我的表达能力太弱了?还是已经冒犯到了你?

  • 我可能表达不够清楚,ETag 本身的作用是节省带宽(就是下载时间),但是校验 ETag 如果是这种后置的算法,那这个就很难算上优化的手段。 但是很多人会有这样的误解(304意味着)直接用客户端的缓存,而无需在服务器端再生成一次内容,程序没有特殊处理,不是这样的。

    @quakewang 所以我才说在知道可以用last_modified的前提下,实在没有必要去修改Nginx源码;再则,Nginx处理Gzip的性能高很多,不是么?

    in 查询一般都是主键查询,或者是有 index,不会有全表查询问题.

    这个你是对的,不过建议还是说明下,因为 ORM 的调用还是很容易进入子查询的逻辑,这个时候,对于那些还没有完全理解索引概念的朋友们,优化优化,结果越来越糟。

    @huacnlee @quakewang 提个建议,应该能看出我并不是一名新手或者不知所以的人,所以,一些基本的概念,不用说明的。

  • #53 楼 @aptx4869 我们不是 “试”,而是实践了很久,复杂程度远超过本文的。

    但你这个问法很奇怪,知识本身没有那么强烈的感情色彩,多数时候,对的就是对的,错的就是错的。如果我说错了,请告诉我;如果自己没有能力分辨什么是对什么是错,可能最好的办法,就不要用这样的态度去『随便问问』(希望没有冒犯到你)。

  • #54 楼 @huacnlee 是的,ETag 在 request 过来的时候就进行校验,这样基本上执行的时间就接近于 0 了;但rails框架默认使用Rack::ETag middleware,它会自动给无etag的response加上etag这样的 MiddleWare,很令人费解,如果是后置计算,response 都已经得到了(完整得运行了一次),hash 虽然效率很高,但这个逻辑就很鸡肋。

    在这方面来说,ETag 和 last_modified 扮演的角色是一样的。

  • 楼主是在传播错误的知识,为什么没有人指出呢?

    (304)直接用客户端的缓存,而无需在服务器端再生成一次内容。

    这个表述不严谨,如程序内没有特殊处理,照样会生成一次内容(楼主自己后面也举了用例,但未说明原因),只是 status=304 而非 200,这个区别。而 HTTP 在传输的时候,是先给状态,再传内容的,304 的则是空内容,从而节约网络传输的时间。

    Gzip 之后,etag 就变了,这个 Nginx 处理得是复合逻辑的,并且在知道可以用last_modified的前提下,实在没有必要去修改 Nginx 源码;再则,Nginx 处理 Gzip 的性能高很多,不是么?

    自动 etag 能够节省的只是客户端时间,服务器端还是一样会执行所有的代码

    如果 etag 是这样被中间件处理的,实是累赘至极,它或许为某些特殊场景设计的吧,如果通用场景这样使用,实际上必然带来性能的下降。

    HTTP 本身的协议允许各种 Headers 的定制,etag 和 last_modified 能起到缓存校验的作用,是因为它们属于默认的 Headers,浏览器基本上都是支持的。


    节约了生成 markdown 语法转换到 html 时间,这里用文章最后更新时间作为 cache key 的一部分

    Markdown 转 HTML,这种结果接近固定值的逻辑,为什么要用 cache?


    另外数据查询缓存这段,传统的 SQL,如果用 IN 查询,会不会有潜在的全表扫描的可能?

    个人意见:ORM 的缓存应该信任 ORM 本身,因为本来比较难处理,通过外部调用的缓存颗粒度控制,可控性反倒更高。比如下面所言,在多 Unicorn 同时运行的前提下,如果请求周期过长(不知道你们实际场景下是多久),那么数据的不一致性会十分离谱... 如果请求周期是偏短的,那应该是 ORM 设计的一个标配,短时缓存,实在不算是应用场景下优化的手段。

    rails 内置了 query cache ( https://github.com/rails/rails/blob/master/activerecord/lib/active_record/connection_adapters/abstract/query_cache.rb ),在同一个请求周期内,如果没有 update/delete/insert 的操作,会对相同的 sql 查询进行缓存,如果文章类别都是相同的话,真正去查询数据库只会有 1 次。