我的 .NET Core 博客性能优化经验补充

导语

去年年底我写了一篇《我的 .NET Core 博客性能优化经验总结》，但后来还发现有一处遗漏需要补充。我们一起来看看~

牺牲空间换时间

我们知道软件设计只有高手才能做到又小又快，像我这种普通程序员通常只有两种方案：牺牲时间换空间、牺牲空间换时间。那么在需要追求性能的情况下，可以做一些空间上的牺牲。例如，数据库可以保存冗余数据。

牺牲数据库空间

在我博客中，我需要在文章列表页面显示内容摘要，这个摘要来源于整篇文章的前400字。在我的旧版 .NET Framework 博客里，这个操作每次都是 SELECT 完整文章内容后用 Substring() 截取前400字，由于用了 EF，很难在 SQL 里完成这个截取，因此白白消耗了很多时间和网络传输成本。而在 .NET Core 重写的博客中，我调整了这个设计，在文章表里新加了一列，专门用于存储前400字的文章摘要，而摘要的内容会在新写文章或者编辑文章的时候计算完成并存储到数据库，这样我显示文章列表的时候就不需要去 SELECT 完整的文章内容。虽然这样的设计严格来说肯定不满足数据库的那些个范式，但充分提高了此处的性能。

在企业系统里，这种做法也比较常见。如果有开销比较大的计算才能得出的结果，并且结果不会变，那么不需要每次都去算，而设计成算完就存储在数据库里，以提高性能。

牺牲文件系统空间

我博客中，RSS/ATOM/OPML 等订阅源在以前也需要每次都去数据库取数据计算完成后，输出到客户端。然而这类数据也有个特性，就是几乎不会变。于是我就设计成第一次用户访问的时候，将计算结果生成 XML 文件缓存到临时目录，那么后续用户访问的时候就不需要 hit 数据库了。仅当文章内容有修改的时候，drop 掉缓存的文件，让用户下次请求时重新生成。

本文小结

1. 在系统设计中，不要过分遵守理论，比如数据库范式，要具体分析自己遇到的业务情况，并做调整，世界上没有可以完美复制的“最佳实践”，只有适合自己业务的才是最佳实践。
2. 懒，越懒越好！充分分析业务，明确哪些数据不容易变，可以缓存就缓存，文件也好，内存也好，根据需要自己设计。能不要去调用数据库的就尽量不要去用，因为通常系统最慢的环节就是在调用不同的API和数据库通讯上。