带走： 主持人Eric Kavanagh与Robin Bloor博士，Dez Blanchfield和IDERAs Bill Ellis讨论了应用程序性能以及如何提高效率。
您目前尚未登录。请登录或注册以观看视频。
埃里克·卡瓦纳（Eric Kavanagh）： 女士们，先生们，您好，欢迎再次回到Hot Technologies。确实是的！我的名字叫Eric Kavanagh，今天我们将主持您的另一场网络广播，这是我们对我们的简介室系列的补充。标题是“应用程序加速：最终用户更快的性能。”伙计们，谁不想这样？如果我是那个帮助您的应用程序运行的家伙，我想我是那个下班后在酒吧为我买啤酒的家伙。走进来并加快任何人的应用程序的速度，这绝对是一件很酷的事情。
确实有关于您的幻灯片，请通过@Eric_Kavanagh打我。我总是尝试跟进，如果您提到我，我也会一直转发，所以随时提及我。
该展览的整个目的是着眼于企业技术的各个方面，并且如果您愿意的话，确实可以帮助定义某些学科或某些面孔。很多时候，供应商会接受某些营销术语，并谈论他们如何做到这一点，那件事或其他事情。该节目的设计旨在帮助我们的听众了解软件工具要想成为该领域的领导者，必须具备什么条件。格式为两位分析师。每次都先行，这与供应商先行的简报室不同。每个人都以自己认为重要的方式来了解特定的技术。
今天正在谈论应用程序加速。我们今天将听到Dez Blanchfield和Robin Bloor医生的讲话，然后Bill Ellis从大弗吉尼亚地区拨打电话。有了这些，我将把它交给我们的第一个演示者布洛尔博士。顺便说一下，我们在#podcast的标签上发布了推文，欢迎随时发布。把它拿开。
罗宾·布洛尔博士： 好的，谢谢您的介绍。应用程序性能和服务级别–这是一个领域，多年来，我已经在该领域做了很多工作，从某种意义上说，我实际上在监视性能和以一种或多种方式进行工作方面做了很多工作，如何尝试并计算这些水平。必须说，直到–我们曾经有一个时代，前一段时间人们在仓库中构建系统。基本上，如果在筒仓中，它们实际上要做的工作量相当合理，这实际上并不太难，因为您需要考虑的变量非常少，非常少。一旦我们建立了正确的网络，互动和面向服务便成为了问题。有点困难。性能可以是一维的。如果您只是想一个应用程序反复执行特定的代码路径，那么及时合理地执行它就象一维的事情。一旦您开始谈论服务级别，您实际上就是在谈论争夺计算机资源的多种事物。它很快变成多维的。如果您开始谈论业务流程，则可以从多个应用程序将业务流程连接在一起。如果您谈论面向服务的体系结构，那么给定的应用程序实际上可以访问多个应用程序的功能。然后，这变得非常复杂。
我看着-很久以前，我画了这张图。此图至少有20年的历史。基本上，我将其称为“万物图”，因为它是一种查看IT环境中存在的一切的方式。它实际上只有四个部分：用户，数据，软件和硬件。当然，它们会随着时间而变化，但是当您看到这一点时，您实际上会意识到，每个部分都有层次的爆炸。硬件是的，硬件可以是服务器，但服务器可能包含多个CPU，网络技术和内存，而这恰好是很多控制器。如果您实际看一下，这一切都会分解成碎片。如果您实际上想尝试协调所有这些方面，那么就数据的变化，软件性能的变化，硬件的变化等等等等，您实际上正在面对一个极其困难的多元情况。这就是复杂度曲线。当然，它的复杂性曲线几乎适用于所有事物，但是在谈论计算机时，我一次又一次地看到它的复杂性。基本上，如果将节点放在一个轴上，而重要的连接点放在另一轴上，则最终会形成复杂度曲线。节点和连接是什么几乎无关紧要，如果您想表示电话网络中的流量增长，那会做什么。
实际上，当您谈论计算机环境中的节点时，您是在谈论彼此关心的单个事物。事实证明，复杂性是各种结构和您要遵循的各种约束的问题。还有，数字。当数字上升时，他们会发疯。昨天我进行了一次有趣的聊天，当时我正在与某人交谈–我不能说他是谁，但这并不重要–他们所谈论的站点的站点中有40,000个实例，即四零，40,000个数据库实例。只需考虑一下-40,000个不同的数据库。当然，我们唯一拥有的-他们显然有很多成千上万的应用程序。我们正在谈论的是一个非常大的组织，但我无法命名。您实际上是在看，您实际上是在尝试以一种或另一种方式来获得对于多个用户（如果您愿意，还有多个不同的期望）全面的服务水平。这是一个复杂的情况，而我只是在说，这很复杂。数字总是增加。约束由业务流程和业务目标确定。您将注意到期望的变化。
我记得当Gmail，Yahoo邮件和Hotmail等所有邮件系统问世时，人们开始对组织内部的邮件系统寄予厚望，因为他们希望通过外部庞大的服务器场来提供这些庞大运营的服务水平组织并开始承受使所有此类事情发生的压力。实际上，服务水平协议是一回事，而期望又是另一回事，它们在组织内相互竞争，这很尴尬。这里只是商业角度。在某些系统中，最佳响应时间是人类响应时间的十分之一秒。十分之一秒是眼镜蛇咬你的时间。如果您站在眼镜蛇的前面，而它决定咬您，那太迟了，因为您无法在十分之一秒的时间内做出反应，所以就咬它。十分之一秒大约是球离开投手的手到用球棒触到家伙所花费的时间。基本上，正如他所看到的那样，他必须在那个时间点做出回应。人类的反应，这很有趣。软件到软件，显然可以有更高的期望。
然后您会遇到一些我认为是市场情况的情况，首先是业务价值所在。例如，如果您想在股市中出售特定股票的可能性可能较小，例如，因为您认为股票价格下跌，而很多其他人认为股票价格下跌，那么如果您首先进入市场，则可获得最佳价格。在很多情况下，广告投放以及类似的情况都非常相似。您已经从服务水平期望的角度出发了。您有一件事情就是玻璃天花板可以满足人类的需求。一旦达到了软件到软件的极限，那么就没有最佳的服务水平。比别人快是最好的。
好的，我认为这是我正在做的最后一张幻灯片，但这只是为了让您大致了解复杂性，一旦您实际查看组织的需求即服务。您已经在系统左侧找到了系统管理，这是用于服务管理的一组软件，该软件正在尝试管理服务级别。除此之外，您还可以进行业务绩效管理。然后，如果您在这里查看服务管理自动化区域的底部，就会发现零散的服务会演变成标准化的服务，如果您确实想投资这种东西，则会演变成集成的服务，再演变成优化的服务。人们通常所做的只是在此操作的左下角。也许一点点的服务管理。业务绩效管理，非常罕见。几乎都是零散的。一个完美的世界将填补那个网格。仪表–我提到了次优化问题。您可以优化系统的各个部分，这对整个系统没有好处。如果您使心脏处于最佳状态，那么血液对于其他器官的循环可能会太快。这就是大型组织和服务水平的问题。显然，如果没有复杂的工具，就什么也做不了，因为变量已经得到了–太多的变量需要尝试和优化。
话虽如此，我还是希望病态转嫁给Dez，他会完全谈论其他事情。
Dez Blanchfield： 谢谢你，罗宾。像Robin Bloor博士一样，我花了很多年的时间来思考非常复杂的系统在大规模上的性能。规模可能与Robin并不完全相同，但是性能是日常话题，它是我们想要获得最佳性能以充分利用一切的DNA的一部分。实际上，艾夫（Ive）使用了我在世界上最喜欢的东西之一-一级方程式赛车（F1赛车）的图形，整个星球静止不动了一会儿，看着汽车飞快地转了圈。在每个方面，一级方程式都没有专门针对获得性能的方面。很多人都喜欢这项运动，因为他们认为这是浪费金钱。事实证明，我们每天驾驶的汽车是在基于性能的开发和研究中派出的，这些汽车在周末和学校的其他日子让孩子们踢足球。就像一级方程式赛车一样。日常技术，日常科学通常来自纯粹专注于高性能的事物。
不过，现实是，我们新的“永远在线”的世界（如Robin先前所述）要求100％的正常运行时间，其中包括引入Webmail和我们认为在连续空间中理所当然的其他服务，现在我们希望我们的企业和工作环境。现实情况是，启动并不总是意味着您满足服务水平协议。我认为管理应用程序性能和可用性服务级别协议的需求在过去十年中发生了根本性的变化。不再只是试图担心一个系统的性能了。当世界变得简单一些时，我们可能会遇到这样一种情况：可以实时监视运行多个服务的单个服务器，并且支持起来相对简单。我们可以-而且这还不算很多，例如很多年前我们当系统管理员时曾经担心的事情-我们可以环顾四周，该服务通常是否启动并响应？我可以登录终端吗？操作系统是否响应，我可以键入命令吗？应用程序是否已启动并正在运行？我可以查看网络中的服务和I / O等过程和内存吗？在大型机时代，您会听到磁带从zip-zip-zip滑落而纸张掉出的声音。
这些应用程序是否响应，我们是否可以登录并在它们上执行操作？用户是否可以连接到其中一些服务器？继续他们是相当基本的，你知道。然后是几个有趣的地方-服务台是绿色的吗？因为如果没有，那么一切运转良好，谁来吃甜甜圈？那时的生活真的很简单。即使在那些日子里，然后我在与20-30年前交谈时，复杂性仍然很高。我们可以以相对简单的方式管理服务级别协议，并关注性能。正如罗宾提到的那样，我们不能再手工完成。挑战太大了。事实是，一些优秀的应用程序，管理员，系统网络和数据库管理员可以监视并满足性能SLA。现在，SLA已经不复存在，以至于昨晚我在整理最后的笔记时仍在苦苦挣扎，以至于我想到最后一次看一个非常复杂的堆栈系统的一年，并弄清楚了它，甚至理解了什么在幕后进行，我来自深厚的技术背景。我无法想象现在以管理方式面对每天的情况是什么样的。
发生了什么？好吧，在1996年，随着互联网的繁荣，数据库驱动的应用程序发生了变化。我们很多人都经历过这一过程。即使您不是围绕互联网的繁荣发展，也可以轻松地环顾四周，并意识到在日常生活中，我们现在将所有东西都连接到了互联网。我相信我们有一个烤面包机，显然带有可笑的Wi-Fi选项，因为我不需要将烤面包机连接到互联网。在2000年代，特别是2000年代初期，我们不得不应对复杂性的这种巨大增长，在网络繁荣时期提供服务性能。然后在Web 2.0中又出现了一个荒谬而尴尬的火花，智能手机应运而生，现在应用程序全天候24/7可用，并且始终处于开机模式。
现在的2016年，还面临着云，大数据和移动性的另一种泥潭。这些系统是如此之大，以至于通常很难用简单的英语来理解和使用它们。当我们考虑一个事实时，我们所讨论的一些大型独角兽拥有数十PB的数据。这是整个磁盘空间和存储层，仅用于存放您的图像和社交媒体。或者在某些情况下，在运输和运输物流中，全部在银行中，您的钱所处的位置，您的职位所在的位置或您在eBay上购买的东西的位置。即将面临的下一个大浪潮是物联网的巨大挑战。
如果这还不够糟糕，那么就要将人工智能和认知计算构建到几乎所有事物中。这些天，我们正在与Siri和Google引擎进行交流。我知道亚马逊拥有自己的一个。百度提供了其中一种设备，您可以将其转换为普通系统，数据库进行查询然后返回并逆转该过程。考虑一下其中的复杂性。现实情况是，当今标准应用程序堆栈的复杂性远远超出了人员的能力。当您考虑按智能手机设备或平板电脑上的按钮时发生的所有事情时，您会与之交谈，将其转换为，然后一直运行到互联网到后端系统，前端会收到，将其转换为查询，通过应用程序堆栈运行查询，通过数据库，打磁盘，弹出，中间有一个运营商网络，一个局域网状态中心。复杂性是疯狂的。
我们有效地断言这是超大规模的。超大规模的复杂性和速度让人眼前一亮。应用程序和数据库已经变得如此庞大和复杂，以至于绩效管理本身就是一门科学。许多人将其称为火箭科学。我们拥有现场技术，我们拥有异地技术，我们拥有一系列数据中心选项；物理和虚拟的。现在，我们有了物理和虚拟服务器，有了云，有了基础设施即服务，有了平台即服务，软件即服务已成为我们理所当然的事情。后者，即软件即服务，在几年前变得很恐怖，当时，首席财务官和组织的一部分意识到他们可以拿起信用卡，自己买东西并随身携带CIO，我们有效地将其称为“影子”现在，IT和CIO都在努力解决这个问题，并重新控制。
在基础架构中，我们获得了软件定义的网络，网络功能虚拟化，现在，低于这一水平，也许已经超过了，现在我们有了微服务和活动服务的应用程序。当您单击一个URL时，该URL的末尾会有一堆业务逻辑，描述了实际交付它所需的内容。它不一定具有等待它的预构建逻辑。 Weve在一侧扩展了非常大的传统数据库。 Weve在其他方面拥有Hadoop基础架构和生态系统之类的东西，它们是如此之大，以至于正如我所说，您现在知道，人们正在谈论数百PB的数据。就随身携带的设备，笔记本电脑，手机和平板电脑而言，Weve具有复杂的移动性。
自从Y一代有经验的人都带着自己的设备以来，我们已经在某些封闭环境中获得了BYOD，并且现在越来越多。我们只是让他们与他们谈论Web界面。无论是通过互联网还是通过Wi-Fi，我们楼下的咖啡馆在喝咖啡时都提供免费的Wi-Fi。或我们内部的Wi-Fi。机器对机器现在无处不在。那不直接是物联网的一部分，但也与之相关。物联网是一种令人难以置信的复杂性的全新游戏。人工智能，如果您认为现在正在玩的东西，与我们交谈的所有Siri和其他相关设备都很复杂，请等到遇到一种称为3D ed总线的Olli的情况它大约需要六个人，并且可以在城市中自驾游，您可以说简单的英语，然后它会和您说话。如果交通繁忙，它将决定在有交通的主要区域左转或右转。当它转弯时，您会担心为什么它会在主要道路上向左转或向右转，它将对您说：“别担心，我要向左转。前方有车流，我将绕过它。”
管理那里所有系统的性能和所有复杂性，跟踪数据去向，是否进入数据库，所有互连以及所有相关位，简直令人难以置信。现实情况是，要以当今的速度和规模来管理性能和SLA，就需要工具和系统，并且在默认情况下，您不再会觉得拥有工具会更好-这是前提条件；这是绝对必要的。这里只是一个小例子，它是OpenStack，开源软件定义的云的高级应用程序设计图的列表。这只是很大的一块。这不仅仅是服务器和数据库。这是每个蓝色小斑点代表事物簇的地方。在某些情况下，文件和服务器或数百个数据库，或者当然不超过成千上万个运行的小应用程序逻辑。多数民众赞成在一个小版本。当您开始考虑随之而来的复杂性时，确实令人感到困惑。今天，即使是在大数据空间中，病态也只是放上一些品牌的屏幕截图。当您想到我们在这里需要管理的所有内容时，不仅要谈论一个品牌，这些都是大数据领域和顶级品牌中的所有品牌，而不仅仅是每个小小的品牌或开源。看起来，您认为它的图表令人难以置信。
让我们看几个垂直领域。让我们以市场营销为例。这是一个类似的图表，但仅来自营销技术中可用的技术堆栈。这是2011年的图表。继承人2016年版本。试想一下，这只是您可以针对营销技术运行的技术产品品牌的数量。不是那里的系统的复杂性，不是不同的应用程序和网络，开发和网络以及其他所有东西。只是品牌。以前是五年前，今天是这里。它只会变得更糟。到了现在，现实已经到了，人类根本无法确保所有服务级别的协议。我们无法深入到足够的细节，足够的速度和所需的规模。以下是监视控制台现在的外观示例。这就像将近二十多个屏幕粘合在一起，假装它们是监视每个小块的大屏幕。现在这里很有趣，我不会提及这个品牌，但是这个监视平台可以监视物流和运输环境中的单个应用程序。只需一个应用。如果您考虑一下Robin在谈论什么，那么组织现在可以在生产环境中拥有40,000个数据库。您能直观地看到监视一个应用程序的这个屏幕集合的40,000个版本是什么样的吗？我们生活在一个非常勇敢的世界中。正如罗宾所说，我绝对会百分百地回应说，如果没有合适的工具，没有合适的支持，而使用这些工具的人也无法接受，那么应用程序性能对人类和它必须通过工具和软件来完成。
这样，我将转交给IDERA的朋友。
埃里克·卡瓦纳（Eric Kavanagh）： 好吧，比尔
比尔·埃利斯（Bill Ellis）： 谢谢。在这里分享我的屏幕。我想有人可以确认您可以看到我的屏幕吗？
罗宾·布洛尔博士： 是的
埃里克·卡瓦纳（Eric Kavanagh）： 看起来还好。
比尔·埃利斯（Bill Ellis）： 谢谢。他提到的一件事是，我真的等不及要开自动驾驶汽车了。我没有听到任何人谈论的一件事是，下雪时会发生什么？我想知道加州的工程师是否意识到在美国其他地区下雪了很多。
Dez Blanchfield： 我喜欢，我要记住那个。
埃里克·卡瓦纳（Eric Kavanagh）： 通常每小时一英里。
比尔·埃利斯（Bill Ellis）： 在这里谈论复杂环境中的应用程序性能管理。我想谈的一件事是，很多人在谈论性能时，反应的本质是，更多的服务器，更多的CPU，更多的内存等。另一方面，处理效率也高。确实，多数民众赞成在同一枚硬币的两个侧面，并且将要研究它们两个。最终目标是满足业务交易的服务级别协议。最终，所有这些技术都存在于企业中。我们谈到了拥有业界第一的绩效管理数据库。理想的做法是将理想的性能模型放入应用程序生命周期的开始并对其进行管理。
主题实际上可以归结为四个部分：一是绩效管理过程。我们与所有人交谈，每个人都有工具。如果他们没有工具，那么他们就有脚本或命令，但是缺少的是缺点。 Con只是将各个应用程序堆栈之间的点连接起来。这些应用程序基于–基于浏览器。它们之间紧密耦合在一起。各层之间如何相互作用也至关重要。然后，在谈论业务交易。我们不仅要为技术人员提供可视性，而且还应为应用程序所有者和运营经理提供可视性。
我有一些案例研究，只是与您分享客户如何使用它们。这是此处演示的非常实用的部分。让我们看一下通常会发生什么。我喜欢画图–就像是令人难以置信的技术拼贴。数据中心中的技术数量正在增长，并且正在增长。同时，最终用户并不关心它，而忽略了它。他们只想执行交易，提供交易，快速完成交易。通常情况是，IT专业人员直到自我报告之前，都不知道最终用户甚至遇到了问题。这就开始了一个耗时，缓慢的过程，并且常常令人沮丧。发生的是，人们将打开他们的工具，然后查看应用程序堆栈的一部分。对于该子集，很难回答最简单的问题。您遇到问题通常吗？这是什么交易？瓶颈在应用程序堆栈中的哪个位置？通过花所有这些时间，逐层查看，无法回答这些问题，您最终将花费大量的时间和精力，大量的员工，资金和精力。
为了解决这个问题，为了提供更好的方法，Precise所做的实际上是接受最终用户的跟踪事务，捕获有关它的元数据，通过网络跟踪事务，进入Web服务器，进入业务逻辑层，然后我们在多层应用程序中支持.NET和ABAP以及PeopleCode和电子商务套件，最终所有事务都将与记录系统进行交互。无论其库存查询，报告时间是否有效，它们始终与数据库交互。数据库成为业务绩效的基础。反过来，数据库依赖于存储。有关事务的元数据将回答什么，谁，什么事务，在应用程序堆栈中的什么位置，然后我们具有深入的代码级可见性，以向您显示正在执行什么。这些信息会被连续捕获，并放入绩效管理数据库中，这变成了一张乐曲，每个人都可以看到正在发生的事情。有不同的人和组织关心发生的事情：技术专家，应用程序所有者，最终是业务本身。出现问题时，您希望能够提取有关该事务的信息。
在开始研究投资交易之前，我想向您展示这对于组织中的不同人员可能会如何出现。在管理层，您可能需要概述多个应用程序。您可能想知道由SLA遵从性和可用性计算出的健康状况。健康并不意味着一切都可以100％完美地工作。在这种情况下有空间，您可以看到投资交易处于警告状态。现在，也许在业务范围内，您需要更深入一点，您希望了解有关单个交易的更多详细信息，当它们违反SLA，交易计数等时。运维团队将希望通过一些警报来得到通知。分类。我们内置了性能警报。我们实际上是在最终用户的浏览器中评估性能。我们是否能够检测到它的Internet Explorer，Chrome，Firefox等，都回答了第一个问题：最终用户是否有问题？
让我们潜入水中，看看我们还能展示什么。对性能感兴趣的人将打开“精确”。他们评估交易。他们会查看SLA列，以识别不符合SLA的交易。他们将能够看到受影响的最终用户以及该事务在整个应用程序中的流动情况。解释这些象形文字的方式是浏览器，URL，U代表URL，这就是JVM的入口点。现在，此特定的JVM使Web服务器调出第二个JVM，然后执行该SQL语句。这显然是数据库问题，因为此SQL语句占响应时间的72％。我们专注于时间。时间是绩效的关键。最终用户如何体验事物是否运行缓慢以及资源消耗的度量。它非常方便；这是对评估效果最重要的单个指标。当此问题移交给DBA时，它不仅是数据库问题，而且是此SQL语句。这就是我所说的缺点。
现在有了这些信息，我就可以分析发生了什么。首先，y轴是一天中的时间。打扰一下，y轴是响应时间，x轴是一天中的时间。我可以看到有一个数据库问题，有两次出现，回到该流程，选择该SQL语句并进入专家视图，在该视图中，Precise可以向您显示正在发生的事情，其控件，代码花费多长时间。执行。在数据库层中，其执行计划。您会注意到，Precise挑选了在执行时使用的实际执行计划，这与估计的计划有所区别，后者是在给出计划时而不是在执行期间。它可能反映也可能不反映数据库实际上做了。
现在在这里，是对SQL语句的响应时间分析。 90％的时间用于存储； 10％用于CPU。我可以看到SQL语句的以及结果报告。 SQL语句的实际上开始揭示了一些编码问题。是精选明星；返回所有行–对不起，请返回行中的所有列。正在回退应用程序可能需要或不需要的其他列。这些列占用空间和资源进行处理。如果运行SAP，则最大的变化之一是因为HANA数据库是柱状的，因此基本上是重写SAP而不选择select star，这样它们可以大大减少资源消耗。基本上，无论是Java，.NET等本地开发的应用程序，还是会经常发生这种情况。
在该屏幕上，您可以看到谁，什么，何时，何地以及为什么。原因为何，例如允许您解决问题的SQL语句和执行计划。由于Precise连续运行，因此您实际上可以在SQL语句级别，事务级别之前和之后进行度量，因此您既可以自己衡量，也可以通过应用程序所有者和管理层进行度量，以解决问题。该文档确实很有帮助。这个应用程序栈有很多复杂性。实际上，在许多应用程序中，我们与之交谈的每个人都至少在VMware下运行应用程序堆栈的一部分。在这种情况下，他们查看客户服务应用程序，查看交易时间，并将其与速度下降相关联，这是虚拟化事件。精确跟踪所有虚拟化事件。我们有一个vCenter插件可以接听。
我们也能够检测到争用。竞争与利用率不同。根据客户服务器的应用程序，实际显示出一个嘈杂的邻居何时会影响您的来宾VM。现在，Im能够深入研究并获取信息，实际上，在这种情况下，我可以看到两个正在争用CPU资源的VM。这使我具有可见性，以便可以查看日程安排。我可以将来宾VM放在其他物理服务器上。您可能会响应的所有这些类型的事情，除此之外，我实际上可以查看代码效率以使其使用更少的CPU。我认为我在这个演示文稿中有一个很好的例子，说明有人如何能够将CPU消耗减少几个数量级。
那就是VMware。让我们进入代码本身，即应用程序代码。 Precise可以向您显示Java，.NET，ABAP代码，电子商务，PeopleCode等中发生的情况。在这种情况下，这些都是进入WebLogic的切入点。在这里，有一个发现报告，告诉我您需要查看的这些EJB，并且会告诉您在该系统上也发生了锁定。再一次，在业务逻辑层中进行深入挖掘，以显示发生了什么。在这种情况下，我查看特定实例；我也支持群集。如果您正在运行大量JVM，则可以从整体上看集群，也可以看单个JVM中的瓶颈。
当您进入锁定状态时，我会遇到异常情况。异常与性能问题略有不同。通常，异常的运行速度非常快。由于存在逻辑错误，一旦您遇到该逻辑错误，它将结束。我们能够在发生异常时捕获堆栈跟踪，这可以节省大量时间，因为它试图找出正在发生的情况，您只需在那里就有堆栈跟踪。也能够捕获内存泄漏。解决方案还包括数据库层，我可以进入，我可以评估数据库实例。同样，y轴是花费时间的地方，x轴是一天中的时间。有一份发现报告，它会自动告诉我系统中发生的事情以及我可能会看到的内容。
关于Precises结果报告的事情之一，它不仅查看日志或等待状态-还查看所有执行状态，包括CPU以及从存储中返回信息。存储是应用程序堆栈中非常重要的部分，尤其是在固态存储出现时。沿这些方向收集信息会很有帮助。对于某些存储单元，我们实际上可以向下钻取并显示在单个设备级别发生的情况。这类信息–再次具有深远的知名度；它的范围很广-为您提供足够的信息，以发挥更大的杠杆作用作为应用程序性能专家，以便您可以端到端地优化应用程序以满足这些业务交易。
我想与您分享一些案例研究。我们航行得很快。我希望我能以良好的步伐前进。谈到存储，随着时间的推移，每个人都在更换硬件。有硬件保修。它确实提供了供应商告诉您的内容吗？您可以使用Precise进行评估。您进来后，这里发生的事情基本上是在一个新的存储单元中放置的，但是当存储管理员仅查看存储单元级别时，他们看到了很多争论，他们认为此新存储单元可能存在问题。从端到端的角度看更多内容，以准确显示实际发生的位置。实际上，它们的吞吐量大约是每秒400兆字节，而存储占用了38％的响应时间，因此响应速度非常高。使用新的存储单元，我们实际上将吞吐量提高到了每秒六，七百兆兆，因此基本上翻了一番，并且能够将存储层对事务处理时间的贡献减少一半。我实际上可以先画出来，这是过渡期，然后是之后。
因此，再次有文件证明硬件投资是值得的，并且按特定供应商的预期交付。总而言之，由于事情的复杂性，数量，可能会发生各种各样的事情。在这种情况下，他们实际上遇到了每个人都在责怪DBA的情况，DBA就像“嗯，不是那么快。”实际上，在查看SAP应用程序时，我认为这种情况很普遍。发生的事情是，他们正在为用户开发自定义交易。用户就像，“这太慢了。” ABAP编码器（即SAP中的编程语言）说：“这是一个数据库问题。”他们最终打开了Precise；他们对最终用户进行了60秒的测量，因此效果超过一分钟。在后端花费了53秒。他们钻入后端，实际上他们能够揭示以降序显示的SQL语句。
此顶级SQL语句负责25％的资源消耗，其平均执行时间为2毫秒。您有点不能怪数据库。你知道，嘿，不是那么快，伙计。问题是，为什么会有那么多处决？好吧，他们把它弹回了ABAP，他走进去，查看了循环的嵌套，发现他们在错误的地方调用数据库，他们基本上做了更改，测试了更改，现在新的响应时间是五秒钟。有点慢，但是他们可以忍受。远远超过60秒。有时候，只是发掘出来，是应用程序代码，数据库还是存储空间？在这些领域中，通过进行端到端交易的骗局，Precise发挥了作用。您基本上结束了这些事情。
我正在看时间，看来我们还有一点时间来完成其中的一些工作。我正在通过这些流。此应用程序正在开发中超过一年。当他们进入质量检查时，他们发现Web服务器已达到100％的极限，并且看起来该应用程序无法在VMware下运行。大家首先说的是：“将其放在身体上；实际上，Precise为他们提供了解决问题的其他方法。我们查看了交易，我们看到了一个Web服务器调用，它作为IIS.NET中的ASMX出现。它实际上揭示了底层代码。您看到这个我指着什么？这是23天11个小时。哇，怎么可能？那么每次调用需要9.4秒，因此该事物被调用215,000次。每次调用都使用6秒的CPU。这就是原因，此代码是无法扩展的原因。实际上，它在物理上无法扩展。
他们所做的是，他们回到了开发人员那里，然后他们说：“有人可以做出改变吗？”他们参加了一场竞赛，并测试了不同的建议，并提出了一个可以有效执行的建议。更有效率。新的点仅不到2秒就完成了一点，CPU的速度为百分之一秒。现在可以扩展，并且可以在VMware服务器场上运行。我们基本上可以在代码级别和事务级别上对此进行记录。这是之前的事情，然后是之后的事情。现在您可以在显示Web，.NET和数据库的堆栈条形图中看到，现在您正在与数据库进行交互。对于运行更正常的应用程序，您希望看到此配置文件。
好吧，即时通讯方面我可以向您展示更多其他内容。很多人喜欢这样，因为这使许多商店眼花bed乱。如果您无法满足业务SLA，并且每个人都喜欢“帮助我们”。这家商店的情况是，该业务SLA的订单要在当天下午3点之前收到。他们下订单，仓库很忙，这真的很重要。这个JD Edwards的销售订单屏幕冻结了，您可以很清楚地知道这是一个即时零售库存管理系统。空架子在零售中是不可接受的。在那儿有商品以便出售。在这种情况下，我们要做的就是深入研究SQL Server数据库。无论是SQL，Oracle，DB2还是Sybase，其外观都是相同的。
我们从PS_PROD中识别出选择内容，并能够捕获持续时间，因为它们执行了很多操作。深蓝色匹配的键表示他们没有等待某些等待状态，某些日志记录甚至存储，这是受CPU约束的。我们通过34301跟踪了SQL语句，因此每次执行该语句时，我们都会增加计数器以对其进行跟踪。这意味着我们拥有详细的历史记录，我可以通过单击该调整按钮来访问它。这是历史记录标签。此屏幕显示平均持续时间与变化之间的关系。周三，周四，周五，平均持续时间约为十分之一秒。屏幕冻结很少，它们能够满足业务SLA。到了2月27日，情况发生了变化，突然之间，执行时间到了，实际上那慢到足以导致超时，从而导致屏幕冻结。保留详细的历史记录，包括执行计划和使用该SQL的表索引的一般更改，从而保持精确。我们能够确定访问计划已于2月27日更改。周一至周五糟糕的一周。到3月5日，访问计划再次更改。这是一个美好的一周。这颗粉红色的星星告诉我们更新的音量。
您可以在此处看到基础表中的行数正在增长，这对于企业来说是很典型的。您希望您的桌子增长。关键是语句已解析，SQL语句进来，优化器必须决定执行什么并在执行计划快时选择，在执行速度慢时选择另一个执行计划，从而导致屏幕冻结。在深入的技术基础上，我需要知道执行计划是什么，Precise会为我完整捕获日期和时间戳。这是快速而有效的，这是缓慢而低效的。此过滤器联接只是使用更多的CPU进行协调，以执行此特定的SQL语句。它们仍然具有相同的最终效果，但是从根本上讲，这是传递结果集的较慢，效率较低的方法。因此，我们逐步完成。嘿，我们还有时间再来几个？
埃里克·卡瓦纳（Eric Kavanagh）： 是的，去吧。
比尔·埃利斯（Bill Ellis）： 好吧，我会跳过。我想让您记录一件事，我们谈论硬件，谈论SAP，谈论.NET，谈论JD Edwards和Java-SQL Server环境。这是SAP，在这里查看的是PeopleSoft。精确的支持矩阵是广泛而深刻的。如果您有一个应用程序，那么我们可以对其进行检测以提供这种程度的可见性。当前发生的最大变化之一是移动性。 PeopleSoft的Fluid UI引入了移动性。 Fluid UI使用系统的方式非常不同。这个应用程序正在发展。 Fluid UI –从管理角度来看，它的作用是允许最终用户使用手机，并大大提高了生产率。如果您有数百或数千甚至更多的员工，则可以将他们的生产率提高1-2％，这将对工资和其他所有方面产生巨大影响。发生的是，这家特殊的商店推出了PeopleSoft Fluid UI。现在，谈论复杂性，这就是PeopleSoft堆栈。一个应用程序，至少六种技术，大量最终用户。您如何开始？
再一次，Precise将能够跟踪这些交易。在这里向您显示的是一个堆叠的条形图，显示了客户端，Web服务器，Java，Tuxedo数据库和PeopleSoft应用程序堆栈。绿色映射到J2EE，这是WebLogic表达的一种奇特方式。这是转换。最终用户开始使用Fluid UI，响应时间可能从一个半秒，两秒到大约九，十秒不等。这个屏幕没有显示的是“没有响应”的人数。他们实际上在应用程序中冻结了屏幕。让我们看一下Precise能够为该客户提供的一些可见性。
首先，当我查看PeopleSoft交易时，他们基本上可以看到，我们看到了这种情况。所有交易以及所有地点均受到影响。顺便说一句，当您查看此内容时，实际上可以看到世界各地。从亚太地区到欧洲以及北美。性能问题并非位于整个系统的特定交易或特定地理位置。这是一种表示更改或Fluid UI具有全球影响力的方式。从可伸缩性的角度来看，您可以看到人们正在尝试进行相同类型的活动，但是响应时间基本上只是在降低和降低。您会看到事情没有扩展。事情进展得非常非常糟糕。在这里，当我查看轴数和并发连接时，您会发现在访问数和连接方面非常有趣。这里最多只能扩展到5,000个，而您大约要看一下，最高可达100个并发连接。这是在之后完成的；这是以前。因此，如果可以扩展，我对系统的实际需求在300,000范围内。在过去，使用经典的UI，您需要查看30个并发连接。
现在，这告诉您，Fluid UI至少使用10倍数量的并发连接。我们开始撤消PeopleSoft进行的幕后工作，以便您可以开始看到对Web服务器的影响，即SLA开始受到破坏的事实。不会涉及所有内容，但是最终会发生的事情是，它们基本上依赖于消息传递。他们基本上是在练习WebLogic，并导致Tuxedo内部排队。 Fluid UI实际上出现了一个多层依赖问题，但是Precise能够通过大量不同的事情表明我们可以集中精力解决问题所在。事实证明，数据库本身也存在问题。实际上有一个消息日志文件，由于所有并发用户，该日志文件已锁定。在应用程序堆栈的每个单独的层中，它基本上都有要调整的东西。谈论复杂性，实际上Tuxedo层向您显示了排队，并且您也可以看到该层中的性能下降。我可以看到流程；我可以看到域和服务器。在Tuxedo中，人们可以使用它，通常，您要做的就是打开其他队列，域和服务器，就像在超市中那样以缓解拥塞，以最大程度地减少排队时间。最后一个也是最后一个选项，“精确”显示了很多信息。
正如我之前提到的，每笔重要交易都与记录系统交互。进入数据库的可见性至关重要。 Precise可以显示数据库，WebLogic，Java，.NET和浏览器中发生的事情，但是Precise真正擅长的地方是数据库层。这恰好是我们竞争对手的弱点。让我向您展示Precise可以帮助您完成此任务的方法之一。我不会花时间在数据库优化的三角上，而是基本上在关注低成本，低风险，范围广泛，高风险，高成本的类型更改。如果人们想尝试一下，我实际上将在以后发布此幻灯片。我认为，这是解决问题的相当不错的指南。这是Precise for Oracle专家视图。在结果报告上，此特定的SQL语句影响60％。如果打开此活动屏幕，它将显示在该屏幕上。我可以看一下这个select语句，这里有一个执行计划。每次执行需要一秒钟-48,000次执行。这总共增加了48,000个小时的执行时间。
深蓝色再次是CPU。这件事是受CPU约束的，不是等待状态，不是日志。我强调指出，因为我们的某些竞争者仅查看等待状态和记录事件，但总的来说，CPU是最繁忙的执行状态，并且回购最多。进入这个专家视图–我很快就完成了–我所做的就是看了看表，100,000行，37,000块。正在做一个全表，但我们对此有六个索引。这里发生了什么？好吧，当我查看where子句时，where子句的作用是实际上将一列转换为大写，并说出where等于大写的find变量。发生的事情是每次执行此操作时，Oracle都必须将此列转换为大写。而不是将近五万次，用基于函数的索引的大写字母来构建该索引的效率要高得多，它不仅可以在Oracle企业部门中使用，也可以在标准部门中使用。当您执行此操作时，您可以做的就是验证执行计划，以大写新索引用户的权限，这只是我的事。
然后，通过前后的测量，您看到一秒钟的执行时间，使用完全相同的SQL语句，最多可以聚合9个小时54分钟，但是将索引大写构建为58,000次执行，则响应时间缩短了到亚毫秒，总计在一起，最多需要7秒。我基本上在服务器上节省了十个小时的CPU。这是巨大的。因为如果Im不需要更新服务器，则Im可以驻留在该服务器上。我实际上将服务器使用率降低了20％，您实际上可以看到之前和之后的情况。那就是Precise可以提供的可见性类型。我们还可能会看到一些其他的东西，为什么不使用所有这些索引呢？他们可以跟进。 Theres的体系结构，我将总结一下，因为已经达到了顶峰。我是这个解决方案的忠实拥护者，我们希望您成为忠实拥护者。在IDERA，我们相信试用会吸引客户，因此，如果您有兴趣，我们可以在您的网站中进行评估。
这样，我将信标传回。
埃里克·卡瓦纳（Eric Kavanagh）： 是的，这是您在那里显示的大量细节。它真的很迷人。我想我可能曾经在您身上提到过-我知道我们在IDERA进行的其他一些网络广播中，Ive提到-自从IDERA收购Precise以来，我就一直在跟踪Precise，一直追溯到2008年，或者是2009年。那段时间让我着迷。我很好奇知道要在新版本的应用程序上花费多少精力。您提到了SAP HANA，我认为您可以深入研究HANA架构并在那里进行一些故障排除，这给我留下了深刻的印象。你有几个人？您需要付出多少努力，并且可以动态地完成多少工作，这意味着在部署该工具时，您开始四处爬行并看到不同的事物吗？该工具可以动态确定其中的多少，从而可以帮助人们对复杂环境进行故障排除？
比尔·埃利斯（Bill Ellis）： 你在那里问了很多问题。
埃里克·卡瓦纳（Eric Kavanagh）： 我知道了对不起
比尔·埃利斯（Bill Ellis）： 我确实提供了很多细节，因为对于这些应用程序，看代码，细节就是魔鬼。您必须具有该详细程度，才能真正拥有可行的功能。没有可行的指标，您只会知道症状。您实际上并没有解决问题。 IDERA致力于解决问题。掌握新版本和新内容是一个巨大的挑战。这样做需要做什么的问题，实际上就是产品管理。我对团队的了解不多，基本上无法使我们保持最新状态。就HANA而言，这实际上是IDERA产品线的新成员；这是非常令人兴奋。 HANA的一件事是–让我再谈一下任务。在任务中，SAP工厂将要做的是复制数据库以进行报告。然后，您必须让人们与实际情况保持一致。您拥有这些不同的数据库，并且它们在不同级别上不同步。只需花费大量时间和精力，再加上硬件，软件和人员来维护所有这些内容。
HANA具有高度并行的内存数据库的想法，从根本上避免了重复数据库的需求。我们有一个数据库，一个真理来源，它始终是最新的，因此您无需进行所有对帐。 HANA数据库性能的重要性提高了–我要说的价值是其他所有数据库，硬件和资源可以购买的总和的10倍或至少更有价值。由于能够管理HANA，因此该组件现在实际上已经处于beta测试中，很快它将在GA中使用。因此，这对于IDERA以及我们基本支持SAP平台来说都非常令人兴奋。我不确定我对您的问题还有哪些其他地方有所疑问，但是–
埃里克·卡瓦纳（Eric Kavanagh）： 没错，所有东西都在那里。我一下子扔了一大堆，对此感到抱歉。我只是着迷，真的，我的意思是这不是一个非常简单的应用程序，对吧？您正在深入研究这些工具，并了解它们如何相互影响并达到目的，您必须将故事拼凑起来。您必须结合一些信息来了解实际发生的情况以及造成麻烦的原因，因此您可以进入那里解决这些问题。
一位与会者问，实施“精确”有多困难？另一个人问，是谁（显然是DBA）是谁？但是组织中谁将使用这些工具？
比尔·埃利斯（Bill Ellis）： 精确部署有点复杂。您确实需要了解应用程序环境，例如，该应用程序可以在该数据库上运行，它需要或–中间层Web服务器等。我认为，鉴于其中某些应用程序的复杂性，它实际上相对容易。如果我可以根据您的数据库对Web服务器进行检测，则可以端到端进行操作。您会注意到，我没有对检测最终用户客户端进行任何说明，这是因为我们所做的是，我们实际上是动态包含的，因此您不必更改代码或其他任何内容。 JavaScript进入了应用程序页面框架。无论用户在世界上的任何地方，当他们从您的应用程序访问URL并关闭该页面时，它都会配备Precise。这使我们可以选择用户ID，其IP地址，以及最终用户浏览器中每个页面组件脚本执行时间的第一个字节呈现时间。
就交易而言，您不必绘制交易，因为它们紧密相连。该URL成为JVM的入口点，然后调用它，从而导致从数据库捕获JVC。我们基本上可以捕捉到这些自然的连接点，然后在该交易屏幕中向您展示这些交易点，我向您展示了我们还计算出了每个步骤花费的时间或时间百分比。所有这些都是自动完成的。一般而言，我们分配了90分钟的时间来完成–基本安装Precise核心，然后开始实施该应用程序。根据应用程序的知识，我们可能需要花费一些额外的时间来对整个应用程序进行检测。许多人只使用Precise的数据库组件。没关系。您基本上可以将其分解，分解成您认为需要站点的组件。我们绝对相信，对整个应用程序堆栈进行检测的好处是，您可以看到层对层的依赖性实际上放大了监视单个层的价值。如果有人想进一步研究其应用程序堆栈，请访问我们的网站-我想这是索取更多信息的最简单方法，请对它进行进一步的讨论。
埃里克·卡瓦纳（Eric Kavanagh）： 让我向您提出一两个快速问题。我猜想您正在随着时间的推移收集和建立各种应用程序和各种数据库之间的交互的存储库，无论是对于单个客户还是整个公司实体。换句话说，我想这就是我所暗示的场景建模。是这样吗您实际上是否维护了一些常见方案的存储库，以便在某些事情发生时可以向最终用户提出建议？像此版本的E-Business Suite，此版本的数据库等，您是否做了很多工作？
比尔·埃利斯（Bill Ellis）： 好吧，这种类型的信息已内置在调查结果报告中。调查报告指出了性能瓶颈是什么，以及基于执行时间的性能瓶颈。该发现报告的一部分是了解更多信息以及下一步要做的事情。来自客户的信息或经验等基本上都包含在该建议库中。
埃里克·卡瓦纳（Eric Kavanagh）： 好的，听起来不错。大家好，今天的精彩演讲。比尔，我喜欢你在那里有多少细节。我只是认为这确实是很棒的，坚韧不拔的，精细的信息，显示了如何完成所有这些工作。在某种程度上，它几乎就像黑魔法，但实际上不是。你们聚集在一起的非常特定的技术可以理解非常非常复杂的环境并使人们感到高兴，因为没人喜欢应用程序运行缓慢的情况。
伙计们，我们将存档此网络广播。您可以跳至Techopedia或insideanalysis.com，然后哇，谢谢您的宝贵时间，我们下次再见。保重，再见。