ssi优化

[chenchongqi]

现状

• 总SSI请求量(pv x ssi平均数)：终端页3600万 + 索引页1200万，按流量集中时间12小时算，大致正常服务时间内每秒ssi请求达到1000次/秒，分摊到6台服务器上每台160+次/秒。
• 索引查询非常快，基本内存没有泄漏现象，但是压力过大导致应用的内存使用和负载上升，带来不稳定因素，重启和各种情况出现比较多。

思路

• 索引页一些豆腐块加上mc缓存，减少r系统调用频率，访问量大但是绝对数量很少，mc的命中率可以很高
• 考虑以类似电脑下载的方式发布非实时（除价格相关外的）的豆腐块
• 发布的地方作为独立应用分开，并调用正常r系统生成，考虑放在后台服务器
• 热门产品（三大类）、通用豆腐块每天发
• 其他产品线可以考虑暂时保留原来方式

需要考虑

• 发布效率
• 兼容目前的静态页面发布机制，避免另起炉灶

---

9.4分割线

• 经过检查目前squid缓存命中率只有30%，因此后端压力比原来增大不少，目前计划在整个产品报价库前端增加终端页的页面squid缓存资源，之所以在前面增加是因为，完整页面命中一次，后端的squid、resin请求可以减少10次，资源利用率相对更大。

---

1.15分割线

• 使用netty服务器专门提供ssi接口服务，readintf.jsp的请求将分批转移

---

8.6分割线

• netty ssi服务器上线后分担了索引页的ssi接口服务，终端页的ssi暂时没有切过去。
• 考虑到后面将引入架构部的硬缓存架构，暂停ssi接口服务器的迁移。