终端用户总在抱怨应用迟钝,老板也为此苦恼。而这种压力,恰恰成为运维部门彻底修复应用的动力。可从哪儿着手呢?让我们先来分析一下最常见的五种导致应用缓慢的原因,然后再对症下药,找到并修复它们吧!
#1 客户端缓慢
问题:当今基于web的应用倾向于将用户交互工作(通常伴随大量数据)推送到客户端工作站。从那里,JavaScript代码会处理成百上千行的数据,而这些数据,在客户端显示更新前会导致数秒的停顿。 解决方案:借助高质量的应用性能管理(APM)系统,比如SteelCentral AppResponse,可以很轻松地发现具有此类内部处理延迟的客户端,并区分是应用暂停还是人类“思考时间”延迟。
#2 服务器缓慢
问题:服务器团队不喜欢听到应用性能缓慢是由服务器缓慢引起的这类指责,但是引起应用性能缓慢的最常见原因就是应用或服务器本身,而不是网络。
现代应用通常部署在多层基础设施上:
当这种情况发生时,只有一个薄弱环节会使整个应用变慢。
解决方案:为了发现问题的根源,我们必须了解一个应用中多个组件之间的交互情况。这一过程被称作应用依赖关系映射(ADM),用已有的监测解决方案所提供的信息作为APM集成方案的一部分。
幸运的是,网络为ADM提供了一个非常有利的位置,这意味着网络团队在很大程度上为应用和服务器团队提供帮助。但需要记住一点,借助数据包捕获工具来确定是网络还是应用的问题可能需要花费很多时间。
为了节省时间,某些领先的应用性能管理系统可以快速方便地找出导致应用性能迟缓的根源。一旦建立起适当的监测点和基本配置,就能即刻带来投资回报且便于使用。此外,收集到的信息还可以为APM软件提供了自动绘制关键应用依赖关系图所需的输入。
#3 小型数据库
问题:在带有小数据集的快速局域网上开发的应用在实验室中似乎运行得很顺利。然而,一旦投入生产网络,一切就都不复存在了。而且,随着数据库的不断增长,宕机时间也会不断加长。
解决方案:在此情况下,使用新型APM解决方案进行快速分析,可能会看到一个关键的中间件服务器正在多次向数据库服务器发出请求。实际上,只有一个客户端请求就可能会引发多个数据库请求或传输大量的数据。更简单高效的数据库查询通常能够解决这个问题。
在另一个实例中,数据库服务器可能需要花费几秒钟的时间才能将数据返回到中间件或应用服务器中。然后,应用团队可以使用APM系统来识别违规查询。
#4 频繁对话
问题:应用迟缓的另一个常见原因是频繁对话:一个应用服务器,或是客户端本身,会代表运行该应用的人员发出很多小的请求来执行一次交易。
然而,随着虚拟化技术的出现,服务器团队可能已经将服务器映像自动迁移到轻载主机。这可能会将服务器映像移动到远离其他服务器或磁盘存储系统几毫秒的位置。而且毫秒可以快速堆积。
解决方案:要解决此问题,需要掌握系统之间和系统连接到网络的请求数量,以及请求之间的延迟情况。
#5 网络服务迟缓
问题:最后,网络服务迟缓会降低应用性能,但这并不涉及到网络本身,而是大多数基于网络的应用所依赖的服务。
想象一个对不存在的主DNS服务器进行查询的应用。在没有响应的情况下,应用在尝试查询第二个DNS服务器之前必须超时第一个请求。在这种情况下,应用会周期性变慢,但却在其他时间运行良好。
解决方案:像这样的间歇性问题通常会很难诊断,但这却是像SteelCentral AppResponse这样的APM系统的用武之地,它能持续监测和记录所有交易。只需确定性能缓慢的时间,并找出数据中问题的根源,接下来修复它们只是分分钟的事。
好文章,需要你的鼓励
工业升级的关键,或许在于智能本身。“工业+机器人”将成为通向下一阶段工业体系的核心抓手。——黄仁勋。
浙江大学等联合研究发现,AI强化学习效果取决于"模型-任务对齐"程度。当AI擅长某任务时,单样本训练、错误奖励等非常规方法也有效;但面对陌生任务时,这些方法失效,只有标准训练有用。研究团队通过大量实验证实,这种"舒适圈"现象比数据污染更能解释训练差异,为AI训练策略优化提供了新思路。
瑞士政府正式发布了自主研发的人工智能模型,该模型完全基于公共数据进行训练。这一举措标志着瑞士在AI技术自主化方面迈出重要一步,旨在减少对外国AI技术的依赖,同时确保数据安全和隐私保护。该模型的推出体现了瑞士对发展本土AI能力的战略重视。
巴赫切希尔大学研究团队通过对五种不同规模YOLO模型的量化鲁棒性测试发现,静态INT8量化虽能带来1.5-3.3倍速度提升,但会显著降低模型对噪音等图像损伤的抵抗能力。他们提出的混合校准策略仅在大型模型处理噪音时有限改善,揭示了效率与鲁棒性平衡的复杂挑战。