首页 > 解决方案 > Go Web 应用程序是否应该在一个模板中包含所有页面?

问题描述

假设一个 Web 应用程序有 100 个页面/模板,一个页眉模板页脚模板,以及 10 个左右的其他帮助模板。将它们全部粉碎并将它们作为一个整体解析成一个巨大的模板对象并将其传递给每个 http 处理程序是否会更好。还是将 100 页解析为单独的模板/对象更好。每个 http 处理程序一个。

我主要从性能的角度感兴趣。但欢迎就这个问题提出任何其他建议。

标签: performancetemplatesgo

解决方案


由于必须“执行”任何模板才能产生结果,因此问题归结为“来自前端的请求模式是否可以同时执行不同的模板(然后组合它们的结果)”。

如果答案是“是”,那么您可能会得到加速,如果“否”,我会说加速不太可能。

另请注意,前端是否可以并行执行多个此类请求也是一个悬而未决的问题,因为它在很大程度上取决于请求的发出方式:例如,如果请求是通过单个 HTTP 1.1 连接发出的,它们将被序列化(第 N 个请求必须等到收到第 N-1 个请求的响应);如果你通过 websocket 请求东西,你可以实现流水线。

另一件需要思考的事情是,如果您实际上是在为单个请求提供服务时询问执行这些多个模板,这一切都归结为渲染的并发性是否会胜过同步执行不同模板的 goroutines 所花费的时间。
基本上它与上述情况相同——只是本地化到服务器的进程。


无论哪种情况,此类问题的正确答案都是“对两种解决方案进行基准测试”。testing后一种情况是最简单的基准测试,因为除了包之外您不需要任何东西。前者更难评估,因为它需要在开发人员工具窗口中查看页面加载统计信息时进行多次试验。


最后但并非最不重要的一点是,虽然您可能会在并行执行多个模板以处理一系列顺序请求到达多核服务器时获得显着的加速,但当多个此类请求并行出现时情况可能会有所不同:这仅仅是因为如果渲染模板对于单个请求会使 N 个 CPU 内核保持忙碌,对 100 个并发请求执行相同操作会使渲染 goroutine 竞争内核。

也就是说,您需要执行实际的负载测试,这完全是另一回事……</p>


推荐阅读