五千年(敝帚自珍)

主题:【原创】网站,没有缓存怎么行,520码 -- 铁手

共:💬12 🌺29 新:
分页树展主题 · 全看
  • 家园 【原创】网站,没有缓存怎么行,520码

    最近一段时间网站出现大量520错误返回。目前我用 cloudflare 来加速内容访问。基本原理是用户访问西西河,实际上是到 cloudflare 要内容,cloudflare 作为中间人在必要时到我的服务器要内容。这个520错误返回,是我服务器和 cloudflare 之间的问题。经过大量排查,特别是各种试图,也没法在 web server 的 log里找到对应的错误信息后,现在基本确定是因为 cloudflare 程序认为我的服务器响应太慢有关。正好我一直想找时间把西西河的缓存机制理清一下,现在问题找上门来,就赶紧抓紧完善一下。

    欢迎帮忙质疑,并帮忙改进实施方案。我是三脚猫的功夫,所以特别希望来点实锤。

    每个网页的内容生成,在后台基本上涉及到数据库、程序计算、缓存机制设定。

    数据库方面的优化,这里暂时略过。将来可能转到 pgsql(是好注意么?),准备专注到那里。

    后台程序根据内容生成网页。程序里对一些局部操作的内容做了缓存,可以减轻数据库和程序计算的负担。

    在此基础上,希望通过访问缓存机制来尽可能减少对服务器的直接需求。尽可能让内容从本地或者是代理缓存那里获得,而不是每次都要从服务器那里取。

    对返回给浏览器的内容设定缓冲控制,要考虑两个方面:一是缓存时间,要考虑静态和动态内容,二是缓存所在,要考虑用户终点(私缓)和中间代理CDN(公缓)。

    象 Javascript 或 CSS,及一些图片,原则上一旦确定基本上不变,缓存时间可以长一些,这个在 Web server 中可以设定。

    在后台程序生成的内容页面中,一部分内容中长期不变化,一部分内容短期变化频繁,还有一部分和用户是否在线有关。以看一个帖为例,帖内容中长期不变,帖得花变化会比较频繁,对作者的屏蔽或趋订则和用户在线有关。缓存策略可以分别为公缓长、公缓短、私缓,必要时通过ETAG到后台验证。

    随着技术的发展和应用,考虑以后每个页面都根据上述分析分为三个访问请求,对每个请求采用不同的缓存策略。

    Cache-Control 的一些参数和解释。

    缓存控制有关。

    public:能被所有缓存使用,包括代理CDN

    private:只能由终点用户缓存。

    no-store:不做缓存

    no-cache:缓存,但下次访问,则必须先到源服务器去验证是否有变。

    缓存时间有关

    max-age=seconds 秒钟计算。

    s-maxage=seconds 代理缓存时间,和终点用户无关。似乎没道理需要和max-age不一致。可不用。

    缓存验证有关

    must-revalidate 如果缓存过期,需要到源服务器确认之后,才能使用。

    proxy-revalidate 同上,但只和代理有关。

    immutable 在期限内不会改变,因此不用到源头验证。

    no-cache 和 max-age=0, must-revalidate 等效,每次都需要去源服务器去验证。

    在只有 max-age=0 时,如果网络不通,则缓存可用。

    另外需要注意,如果内容返回带有 cookie,代理基本上应该不会缓存。

    则,对于公缓,如果有效期限比较确定的,可类似

    Cache-Control: public, max-age=86400

    对于公缓,如果有效期限不确定,需要到源服务器确认

    Cache-Control: public, no-cache

    Cache-Control: public, no-cache, must-revalidate (must-revalidate 这里不需要吧?保险起见?)

    对于私缓,根据上述两种情况,用 private 替换 public 就可以。

    对于一些特殊情况,完全不缓存的

    Cache-Control: no-store, max-age=0

    比如:之前有缓存,但是改成不缓存,硬刷新后,如果没有 max-age=0,则内容还可以从旧的缓存来,有 max-age=0 则会导致刷新。

    大致就这样。欢迎补充。

    关键词(Tags): #网站缓存#拓宽河道通宝推:海峰,桥上,
    • 家园 建议设一个镜像服务器做压力测试用。网站调优是个长期的工作。
      • 家园 这个520是最近突然出现的比较多

        到cloudflare上看了一下,似乎有不少用户也是最近出现类似问题。我在error log里面找,似乎也找不到什么关联的。也许是cloudflare减小了timeout时间(我觉得并不慢啊)。

        你说的镜像压力测试,是完全独立,但是程序相同,还是说网站本身的镜像?我对这方面不熟悉。

        眼下大部分西西河的内容并没有被 cloudflare 所缓存,多一些被缓存也许能改善一些。

        • 家园 一些比较关键的技术问题,不知道是否方便说一下

          西西河整体的qps是多少?

          单机系统还是集群?如果是,集群规模多大?硬件配置如何?

          后台编程语言是什么?

          存储用的什么系统?

          数据量多大?

          • 家园 问题解决了,是CDN的问题

            大致和 Cloudflare 对源服务器的 keepalive timeout 的响应有关。具体细节不知道,猜测是每次到 timeout Cloudflare 就返回 520 所以源头没有错误记录。如果 keepalive off 就不会有这个问题。

            Cloudflare 的这个软件问题,影响了很多人,持续了几个星期,好在现在终于彻底搞定了。

            关于网站本身,具体不好说,但用 Cloudflare 以后,负载是小很多,当然现在各种因素下,访问量本身也比以前小不少。

            目前存储用 MYSQL,但考虑转到 PGSQL。主要考虑mysql, mariadb这些纠结,mysql变成oracle一部分,而且pgsql看上去也不差,就算支持开源吧。不知道你对此有没有看法?

            • 家园 商业上的事情不好说

              也说不清楚。技术上用mysql是完全没有问题的,数据量太大分库分表就行了,查询量大就用缓存。

        • 家园 程序相同,硬件最好是配置一致,完全独立,至少也是相对独立。

          具体细节很多,要看西西河整体的架构来定,这里只能一般性的随便说说供你参考。比如说我们现在给客户维护的生产系统,至少要有一个Staging系统,端到端软硬件环境和生产系统完全一致,生产数据定期复制到Staging系统。这样生产系统有问题可以尽量试着在Staging系统测试和调试。可以考虑在Cloud上建一个Staging系统,根据Cloud定价,平时可以不启动或者保持一个最小系统来节省费用,测试时再按需增加CPU,RAM,网络等系统资源。

          另外,不知道西西河有没有enable access log,如果有的话而且time-taken也配置了的话,可以统计一下520错误时访问的time-taken时间,如果真是cloudflare timeout的话,两者是有联系的,应该可以看出来。

          不了解具体情况,泛泛而谈,希望抛砖引玉吧。

          通宝推:铁手,
          • 家园 自己在家的系统不知道算不算

            基本上系统设置相同,数据基本上也类似。Cloud上建一个Staging系统是个好主意,最接近实际情况。

            520现在几乎绝迹了。是cloudflare的软件问题,具体机制不清楚,估计是对服务器设定的 keepalive timeout 有关,在timeout的时候直接返回520所以源头没有任何错误记录。

            • 家园 其他都还好,不过自己家的系统网络这一块就很难模拟真实系统了

              比如带宽,延时,负载均衡等。另一方面存储设备也会有些不同。

              这些因素在网站访问量大时都会有一定影响。

        • 家园 数据库现在是mysql吗

          总数据量大概是多少?

          页面生成为什么不放在浏览器做呢?生成的页面会缓存吗?

          如果是速度慢的话,瓶颈在哪里呢?最好针对瓶颈做优化。

          • 家园 现在最头痛的是不知道到底哪里出问题

            520的出现比较随机,LOG里我也没怎么看到错误,现在最大的可能就是cloudflare认为从我这里取内容太慢。也许是个别功能慢吧,但不管怎样,缓存的优化都要做一下。

            页面的生成,目前主要在服务器实现,有一部分由浏览器通过 VUE 来实现,以后会更多一些。主要的顾虑是搜索引擎的检索,所以VUE照顾那些不影响检索内容的地方。

            • 家园 每次请求的响应时间由日志记录吗

              或者可视化监控的系统,最好看看平均响应时间和P99时间。

              如果能确定是响应时间很慢的话,要分析下子模块(比如数据查询模块,页面生成模块,或者更细分)耗时,找到最慢的模块来优化。

              不太了解西西河后台的具体业务逻辑,盲猜的话,如果只有数据查询+页面生成,整体响应时间不应该超过200ms。

分页树展主题 · 全看


有趣有益,互惠互利;开阔视野,博采众长。
虚拟的网络,真实的人。天南地北客,相逢皆朋友

Copyright © cchere 西西河