Web应用程序的页面应该集中在一个模板中吗？

golang学习网今天将给大家带来《Web应用程序的页面应该集中在一个模板中吗？》，感兴趣的朋友请继续看下去吧！以下内容将会涉及到等等知识点，如果你是正在学习Golang或者已经是大佬级别了，都非常欢迎也希望大家都能给我建议评论哈~希望能帮助到大家！

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

我主要是从性能的角度感兴趣。但欢迎有关此问题的任何其他建议。

解决方案

由于任何模板都必须“执行”才能产生结果，因此问题归结为“前端的请求模式是否可以使不同的模板同时执行（然后组装它们的结果）” ”。

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

另请注意，前端是否能够并行执行多个此类请求也是一个悬而未决的问题，因为它在很大程度上取决于请求的发出方式：例如，如果请求是通过单个 HTTP 1.1 发出的连接时，它们将被序列化（第 N 个请求必须等待，直到收到第 N-1 个请求的响应）；如果您通过 Websocket 请求内容，则可以实现管道传输。

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

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

最后但并非最不重要的一点是，虽然您可能会在针对命中多核服务器的一系列顺序请求并行执行多个模板时获得显着的加速，但当出现多个此类请求时，情况可能会有所不同并行：这只是因为如果为单个请求渲染模板会使 N 个 CPU 核心忙碌，那么对 100 个并发请求执行相同的操作将使渲染 goroutine 竞争核心。

也就是说，您需要执行实际的负载测试，这完全是另一个故事......

好了，本文到此结束，带大家了解了《Web应用程序的页面应该集中在一个模板中吗？》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多Golang知识！