通过Techopedia Staff，2016年11月2日
总结：主持人Eric Kavanagh与Robin Bloor博士，Dez Blanchfield和IDERA的Bill Ellis讨论了应用程序性能以及如何提高效率。
您目前尚未登录。请登录或注册以观看视频。
埃里克·卡瓦纳（Eric Kavanagh）：女士们，先生们，您好，欢迎再次回到Hot Technologies。 确实是的！ 我叫Eric Kavanagh，今天我将主持您的另一场网络直播，这是我们对我们的简介室系列的一个非常有趣，令人兴奋的系列。 标题是“应用程序加速：最终用户更快的性能。”伙计们，谁不想这么做？ 如果我是帮助您的应用程序运行更快的人，那么我想我是下班后在酒吧为我买啤酒的人。 走进来并加快任何人的应用程序的速度，绝对是一件很酷的事情。
确实有一张关于您的幻灯片，请在Twitter @Eric_Kavanagh上打我。 我总是尝试跟进，如果您提到我，我也会一直转发，所以随时提及我。
该展览的整个目的是着眼于企业技术的各个方面，并且如果您愿意的话，确实可以帮助定义某些学科或某些面孔。 很多时候，供应商会接受某些营销术语，并谈论他们如何做到这一点，那件事或其他事情。 该节目的设计旨在帮助我们的听众了解软件工具要想成为该领域的领导者，必须具备什么条件。 格式为两位分析师。 每次都先行，这与供应商先行的简报室不同。 每个人都以自己认为重要的方式来了解特定的技术。
今天，我们谈论的是应用程序加速。 我们将听到Dez Blanchfield和Robin Bloor医生的消息-今天我们遍布世界各地-然后Bill Bill Ellis从大弗吉尼亚地区拨打电话。 这样，我将把它交给我们的第一个演示者Bloor博士。 顺便说一下，我们在#podcast的标签上发布了推文，欢迎随时发布。 把它拿开。
Robin Bloor博士：好的，非常感谢您的介绍。 应用程序性能和服务级别–这是一个领域，多年来，我在该领域已经做了很多工作，从某种意义上说，我实际上在监视性能和整合工作方面做了很多工作或另一种方式，如何尝试计算这些水平。 必须说，直到–我们曾经有一个时代，前一段时间人们在仓库中构建系统。 基本上，如果要使系统处于筒仓中，他们实际上必须要做的工作实际上并不太困难，因为您需要考虑的变量非常少。 一旦我们建立了正确的网络，互动和面向服务便成为了问题。 有点困难。 性能可以是一维的。 如果您只是想一个应用程序反复执行特定的代码路径，那么及时合理地执行它就象一维的事情。 一旦您开始谈论服务级别，您实际上是在谈论争夺计算机资源的多种事物。 它很快变成多维的。 如果您开始谈论业务流程，则可以从多个应用程序将业务流程连接在一起。 如果您在谈论面向服务的体系结构，那么给定的应用程序实际上可以访问多个应用程序的功能。 然后，这变得非常复杂。
我看着-很久以前，我画了这张图。 此图至少有20年的历史。 基本上，我将其称为“万物图”，因为它是查看IT环境中所有事物的一种方式。 实际上只有四部分：用户，数据，软件和硬件。 当然，它们会随着时间而变化，但是当您看到这一点时，您实际上会意识到，每个部分都有层次的爆炸。 硬件是的，硬件可以是服务器，但服务器可能包含多个CPU，网络技术和内存，而这恰好是很多控制器。 如果您实际看一下，这一切都会分解成碎片。 如果您实际上想尝试协调所有这些方面，那么就变化的数据，软件的性能，硬件的变化等等等等而言，您实际上正在面对一个极其困难的多元情况。 这就是复杂度曲线。 当然，它几乎涵盖了所有方面的复杂性曲线，但是在谈论计算机时，我一次又一次地看到它。 基本上，如果将节点放在一个轴上，而重要的连接点放在另一轴上，则最终会形成复杂度曲线。 节点和连接是什么几乎无关紧要，如果您想表示电话网络中的流量增长，那会做什么。
实际上，当谈论计算机环境中的节点时，您是在谈论彼此关心的单个事物。 事实证明，复杂性是各种结构和您要遵循的各种约束的问题。 还有，数字。 当数字上升时，他们会发疯。 昨天我进行了一次有趣的聊天，当时我正在与某人交谈–我无法提及他是谁，但这并不重要–他们所谈论的站点中有40, 000个实例，即四个零，40, 000个数据库实例在网站上。 只需考虑一下-40, 000个不同的数据库。 当然，我们唯一拥有的-他们显然有很多成千上万的应用程序。 我们正在谈论的是一个非常大的组织，但我无法命名。 您实际上是在看，并且实际上是在尝试以一种或另一种方式来获得对于某些多个用户来说全面合适的服务水平，如果您愿意，可以有多个不同的期望。 这是一个复杂的情况，我真正要说的是，这些东西很复杂。 数字总是增加。 约束由业务流程和业务目标确定。 您将注意到期望的变化。
我记得当Gmail，Yahoo邮件和Hotmail等所有邮件系统问世时，人们开始对组织内部的邮件系统寄予厚望，因为他们希望通过外部庞大的服务器场来提供这些庞大运营的服务水平组织并开始承受使所有此类事情发生的压力。 实际上，服务水平协议是一回事，而期望又是另一回事，它们在组织内相互竞争，这很尴尬。 这只是业务角度。 在某些系统中，最佳响应时间是人类响应时间的十分之一秒。 十分之一秒是眼镜蛇咬你的时间。 如果您站在眼镜蛇的前面并且决定咬你，那就太迟了，这是因为您无法在十分之一秒内做出回应。 十分之一秒大约是球离开投手的手到用球棒触到家伙所花费的时间。 基本上，正如他所看到的那样，他必须在那个时间点做出回应。 人类的反应，这很有趣。 软件到软件，显然可以有更高的期望。
然后您会遇到一些我认为是市场情况的情况，首先是业务价值所在。 这就好比说，如果您想在股票市场中卖出特定股票的可能性可能较小，例如，因为您认为该股票正在下跌，而很多其他人认为它正在下跌，那么如果您首先进入市场，则可以获得最佳价格。 在很多情况下，广告投放都会发生类似的情况。 您已经从服务水平期望的角度出发了。 您有一件事就是一种玻璃天花板，可以满足人类的需求。 一旦软件到软件，如果您遇到这种情况，就没有最佳的服务水平。 比别人快是最好的。
好的，我认为这是我正在做的最后一张幻灯片，但这只是为了让您大致了解一下组织的需求即服务的复杂性。 您已经在这里的左侧走了，系统管理是一组服务于服务管理的软件，该软件正在尝试管理服务级别。 除此之外，您还具有业务绩效管理。 然后，如果您在这里查看服务管理自动化区域的底部，就会发现零散的服务会演变为标准化的服务，如果您真的想投资这种东西，则会演变为集成的服务，然后演变为优化的服务。 。 人们通常所做的只是在此操作的左下角。 也许一点点的服务管理。 业务绩效管理，非常罕见。 几乎都是零散的。 一个完美的世界将填补那个网格。 仪表–我提到了次优化问题。 您可以优化系统的各个部分，这对整个系统没有好处。 如果您使心脏处于最佳状态，那么血液对于其他器官的循环可能会太快。 这是大型组织和服务水平的问题。 显然，如果没有复杂的工具，就什么也做不了，因为变量已经得到了–太多的变量需要尝试和优化。
话虽如此，我将转给Dez，希望他会完全谈论其他事情。
Dez Blanchfield：谢谢Robin。 像Robin Bloor博士一样，我花了很多年的时间来思考非常复杂的系统在大规模上的性能。 规模可能与Robin并不完全相同，但性能是日常话题，想要获得性能，以充分利用一切是我们DNA的一部分。 实际上，我使用的是世界上我最喜欢的东西之一的图形，即一级方程式赛车，整个星球静止不动一会儿，看着汽车飞快地转了一圈。 在每个方面，一级方程式都没有专门针对获得性能的方面。 很多人都喜欢这项运动，因为他们认为这是浪费金钱。 事实证明，我们每天驾驶的汽车是在基于性能的开发和研究中派出的，这些汽车在周末和学校的其他日子让孩子们踢足球。 这是一级方程式赛车的生活。 日常技术，日常科学通常来自纯粹专注于高性能的事物。
不过，现实是，我们新的“永远在线”的世界（如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的末尾会有一堆业务逻辑，描述了实际交付它所需的内容。 它不一定具有等待它的预构建逻辑。 我们在一侧可以扩展非常大的传统数据库。 在其他方面，我们拥有Hadoop基础架构和生态系统之类的东西，它们是如此之大，以至于正如我所说，您现在知道，人们正在谈论数百PB的数据。 就随身携带的设备，笔记本电脑，手机和平板电脑而言，我们拥有复杂的移动性。
自从Y一代有经验的人带着自己的设备以来，我们已经在某些封闭环境中使用BYOD，并且现在越来越多。 我们只是让他们与他们谈论Web界面。 无论是通过互联网还是通过Wi-Fi，我们楼下的咖啡馆在喝咖啡时都提供免费的Wi-Fi。 或我们内部的Wi-Fi。 机器对机器现在无处不在。 那不是物联网的直接一部分，但是也有关系。 物联网是一种令人难以置信的复杂性的全新游戏。 人工智能，如果您认为我们现在正在玩的东西，与我们交谈的所有Siri和其他相关设备都很复杂，请等到遇到一种称为3-D的Olli现象印刷的巴士大约需要六人，并且可以在城市中自驾游，您可以说简单的英语，然后它会告诉您。 如果交通繁忙，它将决定在有交通的主要区域左转或右转。 当它转弯时，您会担心为什么它会在主要道路上向左转或向右转，它会对您说：“不用担心，我将向左转。 前方有交通，我要绕过它。”
管理那里所有系统的性能和所有复杂性，跟踪数据去向，是否进入数据库，所有互连以及所有相关位，简直令人难以置信。 现实情况是，以当今的速度和规模来管理性能和SLA需要工具和系统，默认情况下，这不再是您认为拥有工具会很好的东西–这是前提条件； 这是绝对必要的。 这只是一个小例子，它是OpenStack，开源软件定义的云的高级应用程序设计图的列表。 这只是很大的一块。 这不仅仅是服务器和数据库。 这是每个蓝色小斑点代表事物簇的地方。 在某些情况下，文件和服务器或数百个数据库，或者当然不超过成千上万个运行的小应用程序逻辑。 那是一个小版本。 当您开始考虑随之而来的复杂性时，确实令人感到困惑。 今天，即使是在大数据空间中，我也会放一些品牌截图。 当您考虑到我们必须在此处管理的所有内容时，我们并不仅在谈论一个品牌，这些都是大数据领域和顶级品牌中的所有品牌，而不仅仅是每个小小的品牌或开源。 你看，你认为这是一个令人难以置信的图表。
让我们看几个垂直领域。 让我们以市场营销为例。 这是一个类似的图表，但仅来自营销技术中可用的技术堆栈。 这是2011年的图表。 这是2016版。 试想一下，这只是您可以针对营销技术运行的技术产品品牌的数量。 不是那里的系统的复杂性，不是不同的应用程序和网络，开发和网络以及其他所有东西。 只是品牌。 以前是五年前，现在是今天。 只会变得更糟。 现在我们处于现实，人类根本无法确保所有服务级别协议。 我们无法深入到足够的细节，足够的速度和所需的规模。 这是一个监视控制台现在的外观示例。 这就像将近二十多个屏幕粘合在一起，假装它们是监视每个小块的大屏幕。 现在在这里很有趣，我不会提及这个品牌，但是这个监视平台可以监视物流和运输环境中的单个应用程序。 只需一个应用。 如果您考虑一下Robin在谈论什么，那么组织现在可以在生产环境中拥有40, 000个数据库。 您能直观地看到监视一个应用程序的这个屏幕集合的40, 000个版本是什么样的吗？ 我们生活在一个非常勇敢的世界中。正如罗宾所说，我绝对会百分百地回应说，如果没有合适的工具，没有合适的支持，而使用这些工具的人也无法幸免，应用程序性能对人类和它必须通过工具和软件来完成。
这样，我将转交给IDERA的朋友。
埃里克·卡瓦纳（Eric Kavanagh）：好，比尔。
比尔·埃利斯：谢谢。 在这里分享我的屏幕。 我想有人可以确认您可以看到我的屏幕吗？
罗宾·布洛尔博士：是的。
埃里克·卡瓦纳（Eric Kavanagh）：看起来不错 。
比尔·埃利斯：谢谢。 他提到的一件事是，我真的等不及了自动驾驶汽车。 我没有听到任何人谈论的一件事是，下雪时会发生什么？ 我想知道加州的工程师是否意识到在美国其他地区下雪了很多。
Dez Blanchfield：我喜欢，我要记住那个。
埃里克·卡瓦纳（Eric Kavanagh）：通常每小时一英里。
Bill Ellis：我们在这里谈论的是复杂环境中的应用程序性能管理。 我想谈的一件事是，很多人在谈论性能时，反应的本质是，更多的服务器，更多的CPU，更多的内存等。另一方面，处理效率也高。 确实，这是同一枚硬币的两个方面，我们将对它们进行研究。 最终目标是满足业务交易的服务级别协议。 最终，所有这些技术都存在于企业中。 我们谈到了拥有业界第一的绩效管理数据库。 理想的做法是将理想的性能模型放入应用程序生命周期的开始并对其进行管理。
主题实际上可以归结为四个部分： 一是绩效管理过程。 我们与所有人交谈，每个人都有工具。 如果他们没有工具，那么他们就有脚本或命令，但是缺少的是上下文。 上下文只是将各个应用程序堆栈之间的点连接起来。 这些应用程序基于–基于浏览器。 它们之间紧密地耦合在一起。 各层之间如何相互作用也至关重要。 然后，我们在谈论业务交易。 我们将不仅为技术人员提供可视性，而且还为应用程序所有者和运营经理提供可视性。
我有一些案例研究，只是与您分享客户如何使用它们。 这是此处演示的非常实用的部分。 让我们看看通常会发生什么。 我喜欢画图–就像是令人难以置信的技术拼贴。 数据中心中的技术数量正在增长，并且正在增长。 同时，最终用户并不关心它，而忽略了它。 他们只想执行交易，提供交易，快速完成交易。 通常情况是，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。 现在，我可以深入研究并获取信息，实际上，可以看到在这种情况下，争用CPU资源的两个VM。 这使我具有可见性，以便可以查看日程安排。 我可以将访客VM放置在其他物理服务器上。 您可能会响应的所有这些类型的事情，除此之外，我实际上可以查看代码效率以使其使用更少的CPU。 我认为我在这个演示文稿中有一个很好的例子，说明有人如何能够将CPU消耗减少几个数量级。
那就是VMware。 让我们进入代码本身，即应用程序代码。 Precise可以向您展示Java，.NET，ABAP代码，电子商务，PeopleCode等内部的情况。在这种情况下，这些都是进入WebLogic的切入点。 在这里，有一个发现报告，告诉我这些是您需要查看的EJB，并且会告诉您在该系统上也发生了锁定。 再次，在业务逻辑层中进行深入挖掘，以显示发生了什么情况。 在这种情况下，我正在查看特定实例； 我也支持群集。 如果您正在运行大量JVM，则可以从整体上看集群，也可以看单个JVM中的瓶颈。
当您进入锁定状态时，我会遇到异常情况。 异常与性能问题略有不同。 通常，异常的运行速度非常快。 因为存在逻辑错误，一旦遇到该逻辑错误，它就会结束。 我们能够在异常发生时捕获堆栈跟踪，这可以节省大量时间，因为它正在试图弄清楚发生了什么，您只需在那里就有堆栈跟踪即可。 我们也能够捕获内存泄漏。 解决方案还包括数据库层，我可以进入，我可以评估数据库实例。 同样，y轴是花费时间的地方，x轴是一天中的时间。 有一份发现报告，它会自动告诉我系统中正在发生的事情以及我可能会看到的内容。
关于Precise调查结果报告的一件事，它不仅查看日志或等待状态-还查看所有执行状态，包括CPU以及从存储中返回信息。 存储是应用程序堆栈中非常重要的部分，尤其是在固态存储出现时。 沿这些方向收集信息会很有帮助。 对于某些存储单元，我们实际上可以向下钻取并显示单个设备级别上发生的情况。 这类信息–再次是深层的可见性； 它的范围很广-为您提供足够的信息，以发挥更大的杠杆作用作为应用程序性能专家，以便您可以端到端地优化应用程序以满足这些业务交易。
我想与您分享一些案例研究。 我们航行得很快。 我希望我的步伐还可以。 谈到存储，随着时间的推移，每个人都在改变硬件。 有硬件保修。 它确实提供了供应商告诉您的内容吗？ 您可以使用Precise进行评估。 您进来后，这里发生的事情基本上是在一个新的存储单元中放置的，但是当存储管理员仅查看存储单元级别时，他们看到了很多争论，他们认为此新存储单元可能存在问题。 从端到端的角度看更多内容，以准确显示实际发生的位置。 实际上，它们的吞吐量大约是每秒400兆字节，而存储占用了38％的响应时间，因此相当高。 使用新的存储单元，我们实际上将吞吐量提高到了每秒六，七百兆兆，因此基本上翻了一番，而且我们能够将存储层对事务处理时间的贡献减少一半。 我实际上可以在此之前得出图，这是过渡期，然后是之后。
因此，再次有文件证明硬件投资是值得的，并且按特定供应商的预期交付。 总而言之，由于事情的复杂性，数量，可能会发生各种各样的事情。 在这种情况下，他们实际上遇到了每个人都在责怪DBA的情况，DBA就像“嗯，不是那么快。”在这里，我们实际上是在看一个SAP应用程序，我认为这种情况很普遍。 发生的事情是，他们正在为用户开发自定义交易。 用户就像，“这太慢了。” ABAP编码器（这是SAP中的编程语言）说：“这是数据库问题。”他们最终打开了Precise；然后打开了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，并且每个人都喜欢“帮助我们”。这家商店的情况是下午3时之前已收到业务SLA，则当天发货。 他们下订单，仓库很忙，这真的很重要。 这个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交易时，他们基本上可以看到，我们看到了这种情况。 所有交易以及所有地点均受到影响。 顺便说一句，当您查看此内容时，实际上可以看到世界各地。 从亚太地区到欧洲以及北美。 性能问题并不存在于整个系统范围内的特定交易或特定地理位置。 这是一种表达方式，即流体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子句在做什么，实际上是在将列转换为大写，并说它等于大写的位置，请找到变量。 发生的事情是每次执行此操作时，Oracle都必须将此列转换为大写。 而不是将近五万次，以基于函数的索引的大写字母来构建该索引的效率要高得多，并且不仅在Oracle企业部门中也可以在标准部门中使用。 当您执行此操作时，您可以做的就是验证执行计划，以大写新索引用户的权限，这只是我的事。
然后，通过前后测量，您将看到一秒钟的执行时间，使用相同的完全相同的SQL语句，最多可聚合9个小时54分钟，但该索引以大写形式构建，可进行58, 000次执行，响应时间降到亚毫秒以下，加在一起，总共需要7秒钟。 我基本上在服务器上节省了十个小时的CPU。 这是巨大的。 因为如果我不打算刷新服务器，则可以在该服务器上运行。 我实际上将服务器使用率降低了20％，您实际上可以看到之前和之后的情况。 这就是Precise可以提供的可见性类型。 我们可能还会看到其他一些东西，为什么不使用所有这些索引呢？ 他们可以跟进。 有体系结构，由于我们正在忙碌中，所以我将总结一下。 我是这个解决方案的忠实拥护者，我们希望您成为忠实拥护者。 在IDERA，我们相信试用会吸引客户，因此，如果您有兴趣，我们可以在您的网站中进行评估。
这样，我将信标传回。
埃里克·卡瓦纳（Eric Kavanagh）：是的，这是您在此处显示的大量细节。 真的很有趣。 我想我可能在过去曾向您提到过-在我们与IDERA进行的其他一些网络广播中，我也提到过-自从IDERA收购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，然后哇，谢谢您的宝贵时间，我们下次再见。 保重，再见。
