<% if session("name")<>"" then response.write("当前用户:"&session("name")) response.write("  注销") response.write("  修改资料") else if request.cookies("name")<>"" then response.write("当前用户:"&request.cookies("name")) response.write("  注销") response.write("  修改资料") end if end if %>
首页 > 铸锐论坛>应用性能管理 >应用系统"亚健康"现象和原因

应用性能管理

 
  • 在服务器端进行数据库审计的优势
  • 服务器端审计工具与所谓非侵入性审计工具的比较
  • 如何提升运维管理
  • ITIL提升中国电信运维管理系统建设
  • 提高Java性能的几个高效用法
  • 提高J2SE性能的代码技巧(上)
  • 提高J2SE性能的代码技巧(下)
  • 应用管理的概念和流程
  • 应用管理的运营和优化
  • 开源时代:Navicat实现从MS SQL到MySQL的数据迁移
  • 使用Navicat导入数据到MySQL
  • 单元测试中贯彻持续性能管理
  • 单元测试性能分析报告
  • 利用Hyperic HQ管理WebLogic
  • Hyperic HQ监测Linux系统10条最佳成功经验
  • 什么是服务等级管理
  • 服务等级管理的步骤
  • 服务等级管理中的关键控制要素
  • 服务等级管理中需要注意的几个问题
  • 什么是容量管理
  • 容量管理的几个重要环节
  • 容量管理中的关键控制要素
  • 容量管理中需要注意的几个问题
  • 持续性能管理的先决条件
  • SQL Server调优的五个步骤(上)
  • SQL Server调优的五个步骤(下)
  • J2EE性能问题的分析
  • J2EE性能问题的诊断
  • J2EE性能问题的诊断示例
  • 应用性能管理-从操作系统做起
  • SQL Server常见性能问题的优化
  • 应用性能管理(APM)的价值分析
  • Bea WebLogic Portal的性能监测和诊断
  • 数据库性能基准的五个问题
  • Portal的性能挑战
  • 在多种数据库环境下管理业务需求(下)
  • Oracle DBA如何管理DB2(下)
  • 在多种数据库环境下管理业务需求(上)
  • Oracle DBA如何管理DB2(上)
  • SQLServerSQL调优技巧
  • 诊断应用数据库的性能瓶颈
  • Oracle优化的五个方面
  • Microsoft的优化SQL方法
  • 理解SQL Server的SQL查询计划
  • 自动化性能测试
  • 优化应用质量和性能,支持和推动业务发展
  • 从PMO到CIO办公室—PMO的发展趋势
  • 实施自动化功能测试的解决方案
  • 软件自动化测试流程
  • 测试自动化的成功经验
  • 无计划的变化导致的IT风险
  • 降低无计划的变化导致的IT风险
  • 应用性能管理中的价值链分析
  • 应用系统"亚健康"的严重性
  • 应用系统"亚健康"现象和原因
  • 性能测试的准备
  • 性能测试的六个阶段
  • 性能测试的容量评估
  • 优化DB2数据库的十个最佳实践
  • 优化DB2数据库的十个最佳实践(续)
  • 在生产中监测和优化J2EE应用性能
  • 改善J2EE性能和用户体验的管理变革
  • 跟踪数据库性能变化
  • 优化ERP应用
  • 在生产中测量J2EE应用性能
  • Oracle SQL性能优化技巧1
  • Oracle9i查询优化工具初探
  • APM的方法和技术实现
  • J2EE性能问题的症状和优化
  • 构造高性能J2EE应用10个技巧
  • 软件工程与知识管理

     
  • 采用CASE工具管理多个并行应用软件开发项目
  • "软件工程"中的分工有效吗?
  • 实施知识管理软件的几个细节
  • 拯救知识管理
  • 知识管理与知识管理软件
  • IT培训师指要
  • 推荐产品的使用

     
  • Toad快速入门
  • PerformaSure J2EE性能诊断
  • PerformaSure J2EE健康检查示例
  • Spotlight实时诊断WebSphere Server实践
  • Spotlight实时诊断WebLogic Server实践
  • JProbe实践之"性能瓶颈"
  • JProbe实践之"短期对象循环"
  • JProbe实践之"内存泄露"
  • JProbe实践之"代码覆盖"
  • Quest Jprobe最佳实践(上)
  • Quest Jprobe最佳实践(下)
  • Foglight-APM与SLA的有力武器





  • 应用系统"亚健康"现象和原因
               www.InnovateDigital.com 整理

    1. 应用系统的"亚健康"现象

           据国外统计发现,美国的高端计算机都卖到中国来了,国际某知名的计算机厂商的全球供应链系统还运行在90年代初的机器上,硬盘转起来"磁磁"响。是我们的业务的规模和复杂性比国外的大得多呢,还是国外不重视IT投入?两者都不是,而是我们的应用软件有关性能和效率方面不如人意,主要由三方面原因造成的:

           1、应用逻辑写得太差,导致系统运行过程中做的"有用功"太少,"无用功"太多。系统资源要花很大一部分时间来处理这些"无用功"。这是问题产生的根源,也占了问题的"80%"。

           2、负荷(进程或数据)在时间和空间上分布不合理。由于业务流程的问题,导致负荷在某一天内集中爆发,使得系统难以承受,帐务系统的出账就是一个典型的例子,月初集中出账导致缴费、开停机操作都非常集中,再好的机器都难以顶住这个尖峰的冲击,因此目前也有运营商在变固定帐期为灵活帐期,把这些集中的负荷平均分摊到30天内。这一点,银行就早已实现,我们每个人的信用卡的每月还款截止日期就各不相同,从而不会出现短时间内的负荷集中。空间上,负荷都很大的应用不合理地部署在一起,导致忙的忙死,闲的闲死。

          3、系统资源不够或配置不合理,导致过多的系统调用,而没有把资源充分用在用户工作上。这就类似一个组织或部门,把大部分时间用在协调、沟通和调度上,而只有很少的时间来做真正增值的工作;

          一般来说,系统上线之初,经过严格的功能测试和压力测试,系统的功能和性能是达到了功能要求的,但随着时间的推移,系统越来越慢,业务高峰时,过大的负荷导致"交通"拥塞,大量的事务排队等待处理,资源的互相争用导致"死锁",从而出现系统"瘫机",造成业务运营和客户服务的中断,这种情况当你业务越繁忙的时候,越容易发生,道理就象你上下班"堵车"一样简单。

          在国内目前应用系统建设的管理模式和投资模式下,基本上是重建设投入,轻运维和优化投入。在这种模式下,目前的解决办法是通过不断的硬件扩容来暂时解决这个问题,随着数据量的不断增大,这些问题重复出现。最后的结局是换系统,重新一轮建设。因此这几年来,运营商的运营支撑部门一直处于战争状态,筋疲力尽。这些症状表明:过量的负荷导致应用系统和运营支撑部门都处在"亚健康"状态。

    2. 应用系统"亚健康"的原因

          这个道理很简单,为什么经过这么多年还不能解决这个问题呢?主要有以下几方面的原因:

          1、技术原因和专业精神:性能优化是高度技术性的工作,要求研发人员要具有很深的数据库知识和经验。同时开发具有好性能的应用系统,还需要对应用"精益求精"的追求完美的专业精神。开发好的应用系统需要专业的"艺术家",而不是粗糙的"工匠"。这种具有"艺术家"一样高水平和专业精神的设计人员和开发人员少之又少。

          2、产品和质量文化上的原因:由于IT系统大部分是按需求定制的系统,产品化程度不高,在开发阶段还没有成熟的手段来进行性能方面的测试和保证工作,同时由于性能目标的不可衡量性,导致无法对设计人员和开发人员针对系统性能进行考核和激励,因此性能往往是系统的"死角"和"瓶颈"。

          3、竞争和公司生存的压力:创作一件好的"艺术品"需要金钱和时间的投入,做一个性能好的应用系统也是一样。关键是在应标时,这种内在品质的附加价值较难量化,难以被客户接受而导致竞标失败。这就导致两个结果:一、好的系统在价格上竞争不过"差"的系统而根本不能获得应用;二、现实的商家由于前一点原因而倾向开发一个"可用"的系统,而不是"好用"的系统。

          4、甲方的态度和方法:"亚健康"问题的存在,一直以来与满足不断变化的业务需求相比,并没有受客户的重视,一般认为是开发商的责任,或者通过简单办法就可以快速解决,例如增加集群等。即使重视,而往往由于不知道衡量和处理"亚健康"的方法,而导致工作上的被动,无法见效。

          5、利益因素:客观地说,性能差的系统需要更高档的机器和更多的存储,更多的软件License,这就意味着更高的投资,在现有的价值链模式下,这对原厂商和集成商都是"利好"消息。对系统进行优化,阻断了硬件厂商和集成商扩容的需求。从集成商和原厂商的利益角度来说,优化是不受欢迎的。

          6、系统稳定性和性能与应用环境具有密切的关系:对应用系统来说,性能与环境、数据量是密切相关的,因此性能是不可能完全在实验室设计出来的,是根据实际环境,根据目标逐步优化出来的。

          7、风险因素:对于在线系统来讲,应用优化相当于对高速运行的列车换轮胎,在保证系统连续可用的情况下,要对某些"部件"进行更换,更重要的是保证更换的新老"部件"输出完全一样,这是具有一定风险的,如果没有工程化的管理办法和针对性的风险规避措施,不敢贸然对系统进行优化。

          从以上原因看出,应用系统的"亚健康"问题并不是偶然出现的,这些客观原因的长期存在,使得应用系统产生"亚健康"问题是必然的,并不是哪个人或哪个组织"能力低"或"心眼坏"的结果。认清这个必然性和这些客观原因,有利于运营商和开发商能够心平气和和坦然地面对这一问题,然后想办法去解决这一问题。

          国内很多任务关键的应用系统经过第一阶段的建设,解决了"有"和"无"的问题;在"有"的基础上,要解决"好"与"坏"的问题,这是一个渐进的过程。需要深入了解和采用应用性能管理(APM)方法论,对整个项目的生命周期进行全面关照。


    (北京铸锐数码科技有限公司 www.InnovateDigital.com)

     
    北京铸锐数码科技有限公司 版权所有 © 2008
    中国·北京市海淀区大钟寺13号华杰大厦8A9-2室
    邮编 100098 电话 010-62139280 传真 010-62135268    京ICP备05019494