我有一个复杂的仪表板,我想每分钟更新一次。它是一个Angularjs SPA应用程序,在Azure中运行IIS后端。
仪表板上显示大约30-40个小面板小部件。每个小部件需要大约10个数据实体集合。每个集合大约有3-5个新数据点每分钟
我想确保浏览器的应用程序运行良好并且可以互动(这非常重要)并且我的Web服务器是可扩展的(这是次要的,因为我宁愿添加比sacrafice速度更多的Web服务器和浏览器的互动性)
我应该立即更新整个信息中心吗? (1个非常大的呼叫,可能会下载1200-1600个数据实体......对于某些用户来说可能要多得多,而对其他用户则要少得多)。这一点给Web服务器带来了最大的压力,从Web服务器的角度来看,可扩展性较差。但我不确定浏览器的影响是什么。
一次更新一个dashlet小部件? (30-40个大块的电话,每个大约返回40条信息)
分别更新信息中心内的每个数据实体集合? (大约300-400个微小的呼叫,每个返回〜3-5条信息)
可以假设为1次大型更新和300-400个别数据点生成数据的总服务器时间非常相似。
更新的及时性不是/超级/重要...如果某些小部件在10秒后更新并且某些按时更新,那很好。浏览器和网站的响应性一般很重要,因此如果用户决定与小面板进行交互,那么事情应该是非常敏感的
欣赏任何建议
答案 0 :(得分:2)
AngularJS优化的全部内容是:
但在开始修复\优化任何上述部分之前,了解Angular数据绑定的工作原理以及摘要周期是很重要的。这个SO post应该在这方面帮助你。
回到可能的优化。
修复第一个问题是确定您是否在绑定表达式中使用函数,它们快速评估并且不执行任何计算密集型或远程操作。只是因为在多个摘要周期中多次评估绑定表达式。
其次,尽量减少手表的数量。这需要您分析视图绑定行为:
::
语法进行一次时间绑定。最后减少摘要周期的数量有助于减少在应用程序生命周期内执行的脏检查次数。 Angular将在应用程序执行期间的不同时间执行这些摘要周期。
每个远程调用也会导致完整的摘要周期,因此减少远程调用将会有所帮助。
如果您使用scope.$digest
代替scope.$apply
,还有一些进一步的优化可能性。 scope.$apply
触发app广泛的摘要周期,而scope.$digest
仅触发子范围。
要实际优化摘要周期,请查看Brian Ford的Building Huuuuuge Apps with AngularJS
但在使用Batarang之类的工具测量事物的工作方式之前,请确保需要进行此类优化。