【问题标题】:Asp.net mvc SPA app server side rendering for PerformanceAsp.net mvc SPA 应用服务器端渲染性能
【发布时间】:2017-01-23 23:34:30
【问题描述】:

我们正试图从用 asp.net mvc 编写的单页应用程序中挤出尽可能多的性能。目前的布局是:

  • 与 SQL 数据库对话的 Asp.net mvc 服务器端
  • 用 JS/Html5 + requireJS 和 KendoUI 编写的客户端 SPA

我们的主要性能问题似乎是 SPA 方面与服务器非常闲聊,以检索当前页面所需的 JS 和 HTML 文件,并通过 mvc WebApi 从 SQL DB 推送和拉取数据。

我想稍微改变一下我们的架构,以限制客户端浏览器和服务器之间的交流。我正在阅读有关服务器端渲染的所有内容,但目前将其放入成熟的应用程序似乎是一次重大的重写。

只是想知道是否有人对解决此问题的方法和要检查的任何库有任何建议?

【问题讨论】:

  • 恕我直言,您的“重写”应该首先确定它为什么“非常健谈”。如果它最终聊天的数量相同,您只需转移问题(例如,js/html 是通常由浏览器缓存的静态文件,除非___)
  • 性能问题是客户端用户可见/可用性问题(用户说,这个应用程序太慢了!)还是服务器端资源(系统管理员说,它无法处理负载!)有问题吗?

标签: javascript c# asp.net asp.net-mvc server-side-rendering


【解决方案1】:

我在这个答案中假设您的性能问题是可用性问题:用户感觉应用程序很慢。如果是这样,您应该知道人们真正记得的不是,应用程序是否缓慢,以及完成他们尝试做的任务是否困难(抱歉,我无法立即找到该研究/结论的来源) .

但是离。我首先要区分两个完全不同的东西:

  • 静态文件的检索,或者更确切地说,捆绑
  • 对服务端点的 ajax 调用

静态文件问题不是问题。它不应该涉及任何架构更改,而是一个学习曲线。您可以使用 WebGrease (或替代品)和/或使用 BundleConfig 来解决它。这两个都是开箱即用的 aspnet 模板项目的一部分。

api 调用的闲聊是非常不同的。解决这个问题需要审查您的服务和应用程序设计。我可能会

  1. 从后台阅读开始,例如websearch q=reduce+chattiness+of+service+design.
  2. 绘制一些客户端与服务器之间对话的序列图;以及何时触发这些对话的草图。
  3. 根据这些图片,开始思考如何才能减少对话:
    • 能否一键获取静态/可缓存数据?
    • Ajax 数据读取能否一次获得更大的数据块?
  4. 而且,异步模式可以用来表示用户看不到任何延迟吗? Ajax 数据推送应该是异步的,所以不应该对性能造成很大的影响——除非应用程序的结构是这样的,即用户在继续之前等待数据推送完成。
    • 研究应用程序(facebook、trello)的 UI 设计,这些应用程序在后台进行数据推送,以便用户无需等待。

最后,我回到我的开场白,这可能是关于 UX 设计而不是引擎盖下的性能。用户可以相当轻松地完成任务吗?是否有任何实际用户告诉您它很慢,或者您只是假设它是?与用户坐在一起,观察他们是如何工作的;究竟是什么在困扰他们?

【讨论】: