没有合适的资源?快使用搜索试试~ 我知道了~
可在www.sciencedirect.com在线获取理论计算机科学电子笔记275(2011)123-142www.elsevier.com/locate/entcs基于分层嵌套网络的Web应用性能建模Yasir Shoaib 奥利维亚达斯2电气和计算机工程Ryerson加拿大多伦多大学摘要本文采用分层嵌套网络(LQN)性能模型,对一个使用PostgreSQL后台数据库的Apache-PHP Web应用程序进行了研究。性能评估是通过获得负载测试测量和解决LQN模型。通过将模型结果与负载测试结果进行比较来执行模型验证。吞吐量的平均误差为3.77%,响应时间的平均误差为12.15%,该模型被证明可以捕获Web应用程序的性能。 此外,还进行了性能分析,以确定可缓解已识别瓶颈资源的系统配置关键词:性能建模与验证,分层嵌套网络,软件性能工程,性能度量,负载测试,PHP1介绍Web应用程序的复杂性和性质要求其开发遵循软件开发生命周期(SDLC)。由于用户希望Web应用程序快速响应,从早期软件开发阶段开始关注系统作为SPE过程的一部分,可以使用测量和性能建模来研究系统。为了根据可用资源直接评估应用程序是否满足所需的性能目标,出于容量规划的目的[24],采用了基于测量的方法。系统在给定客户工作负载下的行为可以提供有助于识别性能瓶颈的结果[25]。使用性能模型的性能建模也发现了使用1电子邮件:yasir. ryerson.ca2电子邮件:odas@ee.ryerson.ca1571-0661 © 2011 Elsevier B. V.在CC BY-NC-ND许可下开放访问。doi:10.1016/j.entcs.2011.09.009124Y. 绍艾卜岛Das/Electronic Notes in Theoretical Computer Science 275(2011)123通过预测系统性能和查明系统瓶颈来进行容量规划建模的其他用途包括容量配置,即分配和准备资源以处理需求并找到满足预期目标的应用程序配置参数[8]。对于性能建模,使用众所周知的嵌入式网络(QN)模型是非常常见的。 然而,基本的QN模型在能够解释软件服务器中的软件争用[28]。QN仅将软件描述为客户,而软件服务器在服务客户端请求时有时表现为服务器,在从其他服务器(如数据库)请求服务时表现为客户端本身[28]。如果忽略了由于软件争用而导致的延迟,则响应时间被低估,从而导致不准确的结果。此外,通过从现有进程(fork)创建子进程来观察的并行软件执行等方面无法直接表示[29]。分层嵌套网络(LQN)[3]分析模型基于扩展的QN,旨在消除QN的上述缺点在远程过程调用(RPC)的情况下,由于软件争用而在较低层发生的延迟包含在LQN模型的上层响应时间中[3]。 此外,它们还可以对嵌套RPC进行建模[9]。 并行执行软件和服务器发送它们非常适合描述复杂的软件应用程序和这些软件实体运行的硬件资源[3]。由于能够在模型中包含不同程度的细节,LQN性能建模可以很容易地与SDLC集成。LQN对于表示多层应用程序的交互和复杂性是理想的,因此本工作使用LQN进行性能建模。本文提出了一个基于PostgreSQL后台数据库的Linux Apache-PHP Web应用程序的LQN性能模型。该模型的解决方案提供了性能指标,如稳态吞吐量和响应时间。将模型结果与来自系统负载测试的测量结果进行比较,提供了模型结果的分析,包括识别瓶颈资源,并提到一种方法,该方法可以通过避免瓶颈资源饱和来扩展系统。本文的结构安排如下:第二部分列举了该领域的相关工作Web性能建模第3节简要概述了LQN。第四部分给出了Web应用程序的设计细节第5节描述了负载测试设置。第6节介绍了应用程序的LQN模型。第7节给出了度量和模型评估结果,并进一步分析以缓解瓶颈资源。第8节提出了结论和未来的工作。Y. 绍艾卜岛Das/Electronic Notes in Theoretical Computer Science 275(2011)1231252相关工作完成了与Web系统性能分析有关的早期工作之一Slothouber [26]提出并分析了一个由客户端、Web服务器和简单文件Web服务器的网络组成的Kounev Buchmann [10]描述了SPEC-jAppServer 2002(J2EE)基准测试的一个封闭的嵌入式模型,该模型由客户端、应用服务器集群、数据库服务器和生产线工作站组成。本文解释了如何通过使用QN的运算法则来获得服务需求,服务需求代表了请求对计算资源的需求,并作为模型的输入。模型的验证表明,性能预测的平均误差为2%的吞吐量,6%的CPU利用率和18%的响应时间的高精度。Urgaonkar等人。 [8]提出了一个多层互联网应用程序的封闭QN模型,该模型考虑了缓存,并发限制和多个基于会话的类请求。通过两个J2EE应用程序RUBiS和RUB-BoS对模型进行了验证。Liu等人 [27]描述了一个3层Web应用程序的封闭QN模型,该模型包括ApacheWeb服务器、Tomcat应用程序服务器和MySQL数据库服务器。为了对Apache和MySQL服务器的并发限制(例如并发运行的线程/进程的最大数量)进行建模,使用了多站队列。上述工作是Web系统建模及其测量的非常有用的表示;然而,在建模方面,它们遇到了与QN相同的缺点,LQN通过轻松表示大型软件和硬件系统,同时还结合了影响性能的软件争用等方面来克服这些缺点在此之前,LQN性能模型已被用于研究软件和Web系统[3,4,5,6,7,18,19,20,21]。Tiwari和Mynampati [7]将SPECjAppServer2001 EJB基准建模为一个简单的LQN模型,并通过从Kounev和Buchmann [17]早期工作中获得的测量结果进行了验证。Ufimtsev和Murphy [6]基于LQN EJB模板[5]对JavaEE ECPerf基准进行建模。Xu等人 [21]使用LQN模板对J2EE银行应用程序建模并执行模型验证。在上述工作中,用于测量的测试系统包括客户端负载生成器、EJB应用服务器和数据库服务器。JProbe和sar等工具用于分析和获取CPU、网络和磁盘等资源的使用信息。对于测试,bean要么按顺序访问,要么按随机顺序访问。较高客户端数量的验证结果报告的误差范围为6.2%至23.9%(顺序)和2.1%至24.5%(随机)。然而,正如Urgaonkar等人 [8]指出的那样,这些工作大多集中在Java企业应用程序上。在这项工作中,我们利用LQN的多功能性来研究PHP Web应用程序。有趣的是,人们已经做了许多关于建模的工作与126Y. 绍艾卜岛Das/Electronic Notes in Theoretical Computer Science 275(2011)123互动100}[1.0,0]Z =7客户端pClient无限的}3解析器readDB答读parseWwriteDB写服务器(二)pServergetDatasetDataDBPDBLQN建模,只有Tiwari和Mynampati [7]和Xu等人 [21]来自上述使用测量来进行模型验证,这些被认为是与我们类似的作品。与我们的工作类似,Dilley等人 [22]和Pastsyak等人 [2]分别使用LQN来建模CGIWeb服务器和Apache-PHP-MySQL系统。CGI Web服务器模型[22]包含服务器提供的动态和静态内容,但在研究中没有考虑数据库层。从模型评估的响应时间被发现匹配密切的响应时间测量超过两个月的时间。通过自定义仪器收集的测量数据作为LQN模型的输入参数,也用于模型验证。Pastsyak等人 [2]的Web系统LQN模型针对40个用户进行了评估,并与负载测试结果进行了比较,结果表明该模型成功地预测了性能该系统由两个Web服务器、一个负载均衡器和一个数据库服务器组成本文还对随机进程代数(SPA)和随机Petri网(SPN)等其他性能建模方法进行了评价然而,与上述两篇论文([22,2])相反,我们的工作使用LQN活动来详细定义Web软件实体以及它们之间交互的优先级。3分层网络Fig. 1. LQN模型示例LQN模型示例如图1所示。最外面的平行四边形代表任务,任务中的任务对应于任务。QN类似于QN的客户类[9]。此外,每个条目可以细分为更小的工作单元,称为活动[9],由矩形表示。处理器显示为椭圆形。任务的多重性表示软件进程的多个线程,如图中括号内所示任务组之间的通信可以有三种类型:同步、异步和转发。在同步通信中,Y. 绍艾卜岛Das/Electronic Notes in Theoretical Computer Science 275(2011)123127请求任务(客户端)阻塞,直到从服务器任务接收到响应。在异步交互中,客户端任务在发送请求后不会阻塞在转发通信中,接收到请求的服务器(任务A)将请求转发给另一个任务(任务B)。此时任务A开始在阶段2中执行,当任务B完成处理其请求时,它将响应发送回客户端,之后任务B将在阶段2中开始执行。在图1中,同步调用用“normal”箭头表示图1表示一个系统,其中有100个客户端与一个单处理器、双线程的服务器进程交互。客户端启动执行交互操作的请求。数据存储在DB数据库中,客户端的数据访问和操作通过服务器上的三个同步读取和异步写入操作进行。一旦客户端从服务器接收到响应,它会思考7秒(Z=7),然后初始化另一组读取和写入请求,无限重复此过程。每个条目具有每个阶段的相关联的服务时间。由于空间不足,仅在方括号内显示Client任务的服务时间。箭头表示请求的方向。除非另有说明,否则相互作用的频率为1。LQN模型的输入是硬件资源的调度规则、客户工作负载强度和客户在每个阶段对模型组件的服务需求LQN模型评估的主要性能指标是稳态吞吐量、响应时间和建模组件的利用率。4Web应用程序在本节中,将介绍通过测量和LQN性能建模对其性能进行研究的Web应用程序。还提出了应用程序的过程流程图,这将有助于理解系统的建模目的。4.1概述正在研究的Web应用程序MyBikeRoutes-OSM是一个自行车路线库,允许用户从世界任何地方创建和共享自行车路线。用户可以搜索给定的源和目的地之间的最佳自行车路线,即。 最佳路径搜索 最佳路径搜索功能 是目前的一个原型,其中搜索基本上是使用道路而不是自行车路线来执行的。然而,这并不妨碍我们的研究,因为我们的主要重点是对系统的性能。该应用程序使用OpenLayers JavaScript API来显示OpenStreetMap3(OSM)地图[11]。在本应用程序的特定情况下,地图是通过以下命令在浏览器上生成的3http://www.openstreetmap.org/128Y. 绍艾卜岛Das/Electronic Notes in Theoretical Computer Science 275(2011)123预渲染的地图瓦片/图像驻留在服务器上。PostgreSQL数据库用作自行车路线数据的存储设施,并提供最佳路径路由功能,其中路由功能由pgRouting4项目提供[12]。为了显示自行车路线数据或进行路线搜索,客户端的OpenLayers基本上通过Apache-PHP服务器与PostgreSQL后端数据库进行通信MyBikeRoutes-OSM源自MyBikeRoutes5 Web应用程序[13],其功能相似,但其衍生项目的在线Web副本明显的区别是使用Google Maps API6的地图服务[14]来显示Google Maps和MyBikeRoutes 网站的路线 信息,其中自行车路 线数据位于MySQL后端数据库中。 此外,MyBikeRoutes网站上的最佳路径搜索实际上使用自行 车 路 线 进 行 搜 索 。 这 里 客 户 端 JavaScript 与 Google Maps API 交 互 , 而MyBikeRoutes-OSM项目在数据库服务器层使用pgRouting来提供搜索功能。MyBikeRoutes和MyBikeRoutes-OSM项目都是最近的开发工作,并且已经设想了未来这些应用程序的后续增强但是,在进行相关的开发工作之前,最好了解系统瓶 颈 , 并 在 SPE 过 程 之 后 找 到 性 能 指 标 。 因 此 , 我 们 在 这 项 工 作 中 分 析 了MyBikeRoutes-OSM应用程序的性能。4.2过程流程图图2显示了Web应用程序的流程图当用户从他们的浏览器访问网站时,自行车路线显示在OSM地图上。接下来,用户可以绘制自行车路线或在其选择的源位置和目的地位置之间执行最佳路径搜索。 如果执行搜索,则最佳路径算法并在地图上显示最佳路径,并可选择保存结果。另一方面,用户可以绘制和存储自行车路线以与其他用户共享它们。5负载测试负载测试是一种基于测量的方法,其中研究不同工作负载下的系统下测试(SUT)的行为输出包括实际吞吐量和响应时间。在我们的例子中,负载测试被用来研究系统在这项工作中,使用了免费的开源负载测试仪JMeter7 [15]进行负载测试。4http://www.pgrouting.org/5http://www.mybikeroutes.com6http://code.google.com/apis/maps/index.html7http://jakarta.apache.org/jmeter/Y. 绍艾卜岛Das/Electronic Notes in Theoretical Computer Science 275(2011)123129服务器(Apache +DB)LANJmeter-Master客户端(Jmeter-Visit Website显示的路线画绘制路线搜索还是绘搜索执行最佳路径搜索没有显示的最佳路径商店?是存储的路线图二. 流程图:MyBikeRoutes-OSM5.1配置和拓扑图3概述了测量的远程测试设置(主-从配置),其中Jmeter-Master机器启动测试,而Jmeter- Slave是模拟虚拟用户向被测服务器这些机器中的每一个都具有相同的物理配置。服务器运行Apache-PHP应用程序服务器和PostgreSQL数据库。图三. 负载测试拓扑以下是机器配置和所用软件的详细信息:Pentium 4 3.4 GHz(32位),993MB RAM,Ubuntu 10.04,1000 Mb/s Net-work,Apache Prefork 2.2.14,PHP 5.32,PostgreSQL 8.4,JMeter 2.3.4.5.2测试计划作为SPE过程的一部分,必须尽早确定应用程序的性能密集型场景[23]。为了实现这一点,首先,Mozilla Firefox浏览器在浏览MyBikeRoutes-OSM应用程序时生成的所有HTTP请求都记录在JMeter中。对单个用户运行负载测试,以确定性能密集型请求,即具有高响应时间的请求。从上一步开始,通过删除非关键请求创建了基本场景(或JMeter中的基本测试计划)。图4显示了一个用户会话的场景该图表示用户发起的操作-130Y. 绍艾卜岛Das/Electronic Notes in Theoretical Computer Science 275(2011)123图四、基本方案序列图支持Web通信。为了清楚起见,这里显示了用户操作,但是实际的负载测试计划只包含客户端/浏览器的HTTP请求。 AppServer或Application Server代表Apache-PHP服务器,DB对应于后端数据库。根据图4,在一个完整的用户会话中,总共有九个请求类发送到应用服务器,最初的五个请求包括一个HTML文件、三个JavaScript文件和自行车路线数据,代表访问网站时发送的请求。在第一组中,除了最后一个自行车路线数据请求也与数据库交互外,所有其他请求都与应用程序服务器交互在此之后,运行一个最佳路径搜索请求和另一个保存最佳路径结果的请求。对于第二条自行车路线搜索再次提出了非常相似的请求这个最终的请求集与应用服务器和数据库进行通信对于负载测试,在调用reqHTML之前添加了7秒的思考时间。从这一点开始,包括7秒思考时间的该场景将被称为基本场景。负载测试针对每N个虚拟用户运行1800秒的持续时间,其中N= 1、2、4、6、10、20、30、40、50、80、120。 为了确保客户机可以模拟用户而不是瓶颈,JMeter测试以命令行模式运行,并提供摘要报告。Y. 绍艾卜岛Das/Electronic Notes in Theoretical Computer Science 275(2011)123131负载请求请求请求HTML JS1 JS2要求请求请求请求请求请航线路由1ADD1路由2 ADD2浏览器1至120个浏览n1c n2c n3c n4c n5c n6c n7c n8c n9cpClient(无限)网络客户端(无限)(150)phpViewRoutesphpAdding1phpAdding2phpAdd2发送HTML JS1JS2 JS3phpNS5查看路线phpNS6装饰1phpNS7Add1phpNS8phpNS9装饰2添加2AppServeDBDBdb dbDB查看路线添加1添加2DB(100)pApache磁盘1磁盘2磁盘3磁盘4磁盘5磁盘6磁盘7磁盘8磁盘9磁盘pDisk(无限)N1sN2sN3sn4s n5sn6sN7SN8sN9S网络服务器此外,通过将Little从负载测试中获得的结果是会话吞吐量和平均会话响应时间。这些结果见第7节。6LQN性能建模前面在图4中描述的序列图用于创建LQN模型下一节解释LQN模型。6.1基本情景模型图五. 基本情景LQN模型图5显示了负载测试中基本场景的LQN模型回复活动并没有显示出来,以便于理解该图。有N个浏览器运行在无限服务器(pClient)上。 该模型分别评估每个值N.这是一个封闭的模型,一旦一个请求会话被完全处理,在等待给定的思考时间后,客户将被送回开始一组新的请求。由于客户端计算机上的处理不包括负载测试中的浏览器呈现或页面生成,因此模型中Browser条目的服务需求设置为0。每个浏览器都通过NetworkClient的条目向AppServer任务发送请求,NetworkClient表示 通 过 LAN 从 浏 览 器 向 AppServer 发 送 消 息 时 发 生 的 延 迟 。 类 似 地 ,NetworkServer表示由于从AppServer发送回复而导致的延迟。两132Y. 绍艾卜岛Das/Electronic Notes in Theoretical Computer Science 275(2011)123网络 任务被 建模 为在无 限服务 器上 运行的 无限线 程。 根据Apache 服务 器的MaxClients[31]指令,该指令对可用于并发处理客户端请求的最大进程数设置了限制 , AppServer 多 重 性 设 置 为 150 。 类 似 地 , 基 于 PostgreSQL 数 据 库 的 maxconnections[16]参数,它指定了PostgreSQL数据库的最大并发连接,DB任务的多重性被设置为100。AppServer和DB任务都在同一个单处理器(pApache)上执行,它具有处理器共享(PS)调度规则。磁盘由磁盘任务建模,该任务有9个条目。每个条目都与联合国秘书处发出的9项请求有关。浏览器,即第一个请求(reqHTML)的磁盘服务需求由disk1条目提供,然后reqJS 1的磁盘服务需求由disk2提供,其他请求也遵循相同的模式在模型中对磁盘条目进行了假设。对于一个请求,假设只有一个与磁盘条目的交互,即如果AppServer和DB任务都为特定请求执行一定数量的磁盘I/O,则在模型中描述了嵌套交互结束时只有一个对磁盘的在这种情况下,各个磁盘条目的服务时间是通过将磁盘I/O的数量乘以磁盘上的平均服务时间而仅找到的一次访问。为了确定磁盘I/O的数量,使用了强制流定律(参见第6.2节),其中系统吞吐量和磁盘I/O吞吐量都是通过测量得出的Liu等人 [27]和Kounev Buchmann [10]在他们的作品中使用了类似的想法类似地,这项工作也做出了与DB条目的磁盘条目相同的假设。有 五 个 请 求 类 需 要 访 问 数 据 库 , 即 reqViewRoutes , reqROUTING1 ,reqROUTING2,reqADD 1和reqADD 2。有一个针对reqViewRoutes执行的SQL查询,它只涉及检索路由数据。两个路由请求(reqROUTING1和reqROUTING2)都需要运行三个与起点和终点相关的查询,最后是路由搜索。执行一个查询来为reqADD 1和reqADD 2请求插入路由。然而,如前所述,DB任务的每个条目在模型中只有一次访问,即 dbViewRoutes、dbViewing1、dbAdd1、dbViewing2和dbAdd2 只 能 从 上 层 AppServer 任 务 层 进 行 一 次 访 问 。 在 此 基 础 上 , 考 虑 到dbViewRoutes,为dbViewRoutes执行的每个SQL查询的服务时间被求和,并最终表示为dbViewRoutes条目的服务时间。类似地,已经找到DB任务的其他条目的服务时间读者可参考第6.2节,了解有关计算条目服务需求的更多详细信息。在下面的段落中,将详细解释模型表示的执行顺序在该模型中,reqHTML活动启动浏览器请求,AppServer在执行sendHTML后响应这些请求。sendHTML的任何磁盘操作都使用pDisk上的disk1条目进行。当请求从reqHTML通过n1c条目到达sendHTML条目时,NetworkClient的网络延迟也会被合并reqHTML之后有三个JavaScriptY. 绍艾卜岛Das/Electronic Notes in Theoretical Computer Science 275(2011)123133(reqJS 1,reqJS 2,reqJS 3)和reqRoutes请求,这些请求按顺序发送完成网站访问的操作。在类似的模式中,其他四个剩余的请求也按顺序发送和处理。一些AppServer活动需要重新检索或修改数据库上的数据,形成嵌套交互,其中AppServer仅在AppServer每个AppServer回复还通过在发送任何回复之前直接或间接地通过磁盘与NetworkServer这对应用程序的基本场景的完整会话进行建模。基本场景模型的服务需求是通过应用利用率定律发现的,其详细信息将在以下部分中介绍6.2发现服务需求如果系统资源的利用率和吞吐量是可用的此前,Kounev Buchmann在[10]中使用了利用率定律来寻找服务需求,这项工作使用了相同的方法。对于Linux,iostat和sar等实用程序是完成此工作的有用监视工具。以下段落简要概述了与使用上述思想确定服务需求的计算相关的考虑一个排队系统中的一个站i和一个请求类c,由于c的请求,该站的平均利用率为Uc, i,平均系统吞吐量为Xc,站i处的吞吐量为Xc, i,则由于请求类,该站处的服务需求(Dc, i)可以通过应用利用率定律计算如下,Dc, i=Uc, i/Xc[29]。服务需求也是访问次数(Vc,i)和每次访问的平均服务时间(Sc, i)的乘积,即Dc,i=Vc,i<$Sc, i。在这里,Vc, i表示针对类请求的每个请求对站进行的访问次数[29,32]。如果Xc, i和Xc已知,则Vc, i=Xc, i/Xc(强制流动定律)[29]。因此,给定Xc和Uc, i,则可以导出Dc, i。然后,如果从强迫流定律中找到Vc,i,则可以计算Sc,i,其中Vc,i和Sc,i都用作LQN模型的输入。对于这项工作,Xc是使用JMeter找到的,Uc, i是从sar实用程序找到的。Xc, i是磁盘I/O服务需求所必需的,也可以从运行的sar中找到。为了确定服务需求,第一步是创建单独的JMeter测试,其中一个用户负载对于Base-Scenario的每个请求类都没有思考时间,从而创建了9个测试。由于只有一个用户,因此由于排队引起的争用最低。每次测试持续900秒,同时使用sar监测SUT。sar的Utilization输出包括iowait%和idle%,它们分别指定CPU等待IO处理的时间百分比和CPU不处理的时间百分比。然后,CPU利用率可以通过从100中减去空闲百分比从JMeter获得的每个测试的吞吐量和从sar获得的CPU利用率用于确定SUT处理器上每个请求的总服务时间,包括磁盘I/O的服务时间此外,使用sar来确定平均磁盘服务时间和磁盘tps(吞吐量134Y. 绍艾卜岛Das/Electronic Notes in Theoretical Computer Science 275(2011)123每秒)。磁盘I/O的数量是通过将磁盘tps除以JMeter吞吐量得到的,从而使用强制流动定律。正如前面在6.1节中提到的,模型中假设从上层到磁盘条目只有一次访问,因此,平均磁盘服务时间乘以磁盘I/O的数量,以获得一个磁盘I/O的标准化服务时间,这是pDisk上磁盘条目的输入。从SUT处理器的总服务时间中减去请求的磁盘I/O的服务时间注意,如果CPU利用率是通过减去空闲%和Iowait%,则不需要从SUT处的总服务时间中减去请求的盘I/O。总网络延迟是通过将SUT的总服务时间 减 去 请 求 的 JMeter 响 应 时 间 得 到 的 。 注 意 , 要 获 得 NetworkClient 和NetworkServer服务时间,网络延迟除以2。上面的例子如下。示 例 1 : 对 于 第 一 个 请 求 类 ( reqHTML ) 负 载 测 试 , 平 均 CPU 利 用 率 为59.18%,即CPU不空闲的时间百分比。JMeter的吞吐量为61.44请求/秒,平均响应时间为11 ms。应用利用率定律,SUT处理器和磁盘的总服务需求将为0.5918/61.44= 9.63 ms。磁盘I/O服务时间为0.36 ms,磁盘tps为1.69。使用强制流动定律,磁盘访问的平均次数为1.69/61.44 = 0.02751。因此,disk 1条目的标准化服务时间为0.02751 * 0.36 = 0.01 ms。sendHTML条目的服务时间为9.63 - 0.01 = 0.01 ms。9.62基于此,总网络延迟为11 - 9.63 = 1.37 ms,因此n1 c和n1s条目的服务时间为1.37/2 = 0.685 ms。对于涉及数据库调用的请求,采用以下方法。对于在DB任务中具有大约1 ms的非常小的服务时间的请求类,例如路由搜索的起始点和停止点查询(总共4个这样的查询),使用PostgreSQL的EXPLAIN ANALYZE [16]查询命令。后一个命令提供要计算的查询的运行时详细信息。对于每个启动和停止查询,EXPLAIN ANALYZE命令执行五次,平均运行时间用作服务时间。对于其他较长的查询,即两个路由搜索、查看路由查询和两个插入新路由查询,具有一个用户负载且没有思考时间的JMeter测试运行了900秒的持续时间。应用利用率定律,并遵循与示例1类似的计算,找到服务需求请注意,AppServer层条目/活动中仅进行一次访问基于web应用程序访问相应的数据库查询,因此对于“数据库查询”,访问计数为1,服务需求等于服务时间。然而,关键是要认识到,基于web应用,应用服务器可以为特定的请求类调用多个数据库查询即,对于reqROUTING1请求,对起点进行一次访问,对终点进行一次访问,最后对路由进行一次访问,从而总共调用三次查询。 在这 在这种情况下,关于模型的假设已在第6.1节中明确概述。对于刚刚考虑的reqROUTING1请求示例,服务Y. 绍艾卜岛Das/Electronic Notes in Theoretical Computer Science 275(2011)123135请求类AppServer(毫秒)DB(ms)磁盘(毫秒)网络(ms)reqHTML9.62-0.011.37reqJS 10.85-0.010.14reqJS 24.8-0.011.19reqJS30.64-0.020.34reqViewRoutes95.5529.380.062.01请求路由1211.67252.720.280.0002*reqADD 153.420.430.320.0002*请求路由2186.1652.090.230.0002*reqADD 253.430.410.330.0002*表1基本情景模型的服务需求参数将三个查询的时间相加以形成一个条目,dbblog ing1。基于上述方法和计算,基本情景模型中每个条目的服务时间如表1所示。这里,AppServer上的reqHTML服务时间为9.62 ms,对应于sendHTML入口服务时间。类 似 地 , 磁 盘 上 的 reqHTML 服 务 时 间 是 0.01ms , 对 应 于 disk1 条 目 。 由 于reqHTML,网络条目(n1 c和n2 c)的服务时间分别为1.37/2 =0.685ms类似的模式也适用于其他请求类。请注意,带有(*)的网络条目的服务时间被发现具有负服务时间。reqROUTING 1、reqADD 1、reqROUTING 2和reqADD 2类的网络服务时间分别为-0.00067、-0.00117、-0.00048和-0.00117(ms)。这被认为是一种异常,因此,这些网络服务时间中的每一个都已更改为0.0002 ms,即n1c和n1s各自具有0.0001 ms的服务时间。未来的工作将包括识别这种异常的原因。7结果在本节中,从模型评估中获得的性能指标以表格和图形格式与模型验证的测量结果一起呈现根据结果,确定了基本情景的绩效目标此外,性能分析是为了实现性能目标。7.1基本方案性能结果该模型已为多达150个用户进行了评估。之所以选择这个数字,是因为AppServer任务多样性设置为150,这表示正在运行的Apache进程的最大数量。该模型在启用超线程的双Intel Xeon 3.0 Ghz CPU上进行了评估,运行在2 GB RAM上。以120个用户平均运行10次为例,Base Scenario模型在376ms内求解,同时利用47%的CPU。表2显示了基本场景模型评估的吞吐量和响应时间,并将它们与测量结果进行了比较。该模型的吞吐量的相对误差%与实际结果非常接近,平均误差为3.77%。响应时间结果显示,对于6个用户,136Y. 绍艾卜岛Das/Electronic Notes in Theoretical Computer Science 275(2011)123响应时间(s)响应时间(s)用户负载测试LQN误差%负载测试LQN误差%10.125580.125670.07%0.9510.9570.63%20.248440.24864百分之零点零八0.9511.0449.78%40.498970.480273.75%0.9871.32934.65%60.739300.684347.43%1.0771.76864.16%100.928380.968714.34%3.7193.323百分之十点六五201.032781.094545.98%12.15611.2737.26%301.051491.084063.10%21.18220.6722.41%401.026871.077214.90%31.20530.1353.43%501.041901.071762.87%39.62939.649百分之零点零五801.019351.065074.49%68.31768.1180.29%1201.014701.060174.48%105.873106.1820.29%1501.05922134.623平均误差3.77%百分之十二点一五表2LQN模型结果-基本场景1.2Put vs. 用户10.80.60.40.200 5 10 15 20 25 30 35 40用户图第六章LQN基本场景(用户与用户)-40个用户高于其他用户计数,然而,如还看到的,对于1和2个用户的低数量以及对于10-120个用户的较高数量,误差%非常接近准确。对于响应时间,平均误差为12.15%。图6和图7分别显示了最多40个用户的吞吐量与用户的关系图和响应时间与用户的关系图,这些结果来自上表2中的结果。从这两个图中可以看出,该模型密切关注系统性能的行为,并且在用户数量更高时也会继续这样做。图8显示了来自LQN评估的pApacheCPU利用率,对于超过20个用户,该利用率接近100%。这是硬件瓶颈,在其他资源之前饱和。在5到20个用户之间进行了进一步的模型分析,以确定吞吐量饱和点,并在此范围内密切观察系统行为图9和图10显示了最多20个用户的吞吐量和响应时间图。 从模型分析来看,虽然随着时间的推移,在19个用户处发生的最大吞吐量为约1.1会话/s的稳定速率增加,之后吞吐量继续保持稳定,LQN-基础测量基准提交(会话/秒)Y. 绍艾卜岛Das/Electronic Notes in Theoretical Computer Science 275(2011)123137响应时间与用户353025201510500 5 10 15 20 25 30 35 40用户图第七章LQN基本场景(响应时间与用户)-40个用户pApache Util. vs. 用户百分百百分之八十百分之六十百分之四十百分之二十0%的百分比0 5 10 15 20 25 30 35 40用户图八、LQN基本场景(pApache利用率)-40个用户如图6所示,对于增加的用户,非常轻微地增加。响应时间最初保持稳定,直到它增加,并继续稳步上升,为越来越多的用户。与测量结果相比,该模型显示出更高的响应时间,直到7个用户,之后该模型继续并行地跟踪测量结果,只是稍微低估了响应时间。Lazowska等人。 [29]提供了模型验证的粗略误差百分比。对于多个类别,吞吐量误差在5%和10%之间,响应时间误差在10%和30%之间,这是可以接受的。对于我们的模型结果,所有的吞吐量都非常准确,平均误差低于5%。考虑到响应时间,例外情况是4和6个用户具有高错误%,但在实际情况下,系统可能会见证更多的用户。造成这一缺陷的一个可能原因是CPU缓存命中率较高,用户数较低,并且模型中没有考虑CPU缓存,基于约12%的平均响应时间误差,模型表示测量结果。模型验证后,下一步将确定改进措施LQN-Base测量库LQN-基础会话响应时间(s)pApache利用率138Y. 绍艾卜岛Das/Electronic Notes in Theoretical Computer Science 275(2011)1231.2Put vs. 用户10.80.60.40.200 2 4 6 8 10 12 14 16 18 20用户图第九章LQN基本场景(用户与用户)-20个用户响应时间与用户1210864200 2 4 6 8 10 12 14 16 18 20用户图10. LQN基本场景(响应时间与用户)-20个用户到系统.上述结果是有帮助的,但它们表明Web应用程序将无法在令人满意的响应时间内支持大量用户,表现出较差的性能。基于Web应用程序提供的功能,合理的性能目标是在没有思考时间的情况下,以12秒的会话响应时间支持40到50个用户考虑到这一目标,Web应用的性能必须得到改善。通过前面的分析,瓶颈资源已经被确定为pApacheCPU。接下来,我们对模型进行直观的修改,以满足性能目标7.2实现绩效目标在本小节中,对可能实现前面定义的性能目标的不同配置进行了评估,并列出了评估结果,以确定如何成功实现目标。LQN-基础测量基准LQN-Base测
下载后可阅读完整内容,剩余1页未读,立即下载
cpongm
- 粉丝: 4
- 资源: 2万+
上传资源 快速赚钱
- 我的内容管理 收起
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
会员权益专享
最新资源
- 京瓷TASKalfa系列维修手册:安全与操作指南
- 小波变换在视频压缩中的应用
- Microsoft OfficeXP详解:WordXP、ExcelXP和PowerPointXP
- 雀巢在线媒介投放策划:门户网站与广告效果分析
- 用友NC-V56供应链功能升级详解(84页)
- 计算机病毒与防御策略探索
- 企业网NAT技术实践:2022年部署互联网出口策略
- 软件测试面试必备:概念、原则与常见问题解析
- 2022年Windows IIS服务器内外网配置详解与Serv-U FTP服务器安装
- 中国联通:企业级ICT转型与创新实践
- C#图形图像编程深入解析:GDI+与多媒体应用
- Xilinx AXI Interconnect v2.1用户指南
- DIY编程电缆全攻略:接口类型与自制指南
- 电脑维护与硬盘数据恢复指南
- 计算机网络技术专业剖析:人才培养与改革
- 量化多因子指数增强策略:微观视角的实证分析
资源上传下载、课程学习等过程中有任何疑问或建议,欢迎提出宝贵意见哦~我们会及时处理!
点击此处反馈
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功