主题：【原创】网站，没有缓存怎么行，520码 -- 铁手
家园 【原创】网站，没有缓存怎么行，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 则会导致刷新。
大致就这样。欢迎补充。
家园 建议设一个镜像服务器做压力测试用。网站调优是个长期的工作。 家园 这个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的话，两者是有联系的，应该可以看出来。
不了解具体情况，泛泛而谈，希望抛砖引玉吧。
通宝推：铁手,家园 数据库现在是mysql吗 总数据量大概是多少？
页面生成为什么不放在浏览器做呢？生成的页面会缓存吗？
如果是速度慢的话，瓶颈在哪里呢？最好针对瓶颈做优化。
家园 现在最头痛的是不知道到底哪里出问题 520的出现比较随机，LOG里我也没怎么看到错误，现在最大的可能就是cloudflare认为从我这里取内容太慢。也许是个别功能慢吧，但不管怎样，缓存的优化都要做一下。
页面的生成，目前主要在服务器实现，有一部分由浏览器通过 VUE 来实现，以后会更多一些。主要的顾虑是搜索引擎的检索，所以VUE照顾那些不影响检索内容的地方。
家园 每次请求的响应时间由日志记录吗 或者可视化监控的系统，最好看看平均响应时间和P99时间。
如果能确定是响应时间很慢的话，要分析下子模块（比如数据查询模块，页面生成模块，或者更细分）耗时，找到最慢的模块来优化。
不太了解西西河后台的具体业务逻辑，盲猜的话，如果只有数据查询+页面生成，整体响应时间不应该超过200ms。