PAAS平台的web应用性能测试与分析

引言

为什么我会写这一篇博客,因为最近很多京东云擎jae的用户反应一个问题就是他们部署在jae上面的应用访问很慢,有极少数应用甚至经常出现504超时现象,当然大家首先想到的是jae性能太差,这也是人之常情,往往出现什么错误的时候首先想到是别人的不好,工作中很多同事也是这样,如果软件系统出现一个bug首先怀疑的肯定不是自己写的代码。今天花时间写这一篇博客主要就是告诉大家怎样确定我们部署在PAAS平台(不仅仅是JAE哦)web应用为什么慢?慢在哪儿了?有什么方法可以解决?

原因分析

出现访问自己web应用慢从宏观上可以总结为下面三点:

(1)网络慢:具体来说就是访问者同部署web应用的PAAS平台之间的网络慢;

(2)PAAS平台性能出现问题:具体来说就是由于各种原因导致PAAS平台不能很好服务部署在它上面的应用;

(3)web应用本身慢:由于各种原因(频繁读写磁盘,大量耗时的计算,资源竞争等)导致web应用不能很快的响应访问者的请求。

上面三点主要总结于web应用的访问路径,因为访问PAAS平台的web应用首先需要经过网络,然后经过PAAS平台的过滤和转发等处理,最后才到达web应用本身处理。这三个环节任何一个出现问题都会导致web应用访问变慢。知道原因了,我们还需要判断到底是哪一个环节出现了问题,下面就说说怎样定位具体的环节。

定位具体原因

上面分析的三个原因除了第二个原因以外,大家都可以自己定位和排除,首先检查网络,为了更加准确我们可以从一下方面进行排除:

(1)首先检查访问其他网站是否出现很慢的现象,如果很快,那么说明你的网络肯定大体上是正常的;

(2)访问对应PAAS平台提供的相关网站和PAAS平台所属公司的网站,例如JAE,你可以访问京东商城主站和京东云平台首页等,BAE可以访问百度相关网站,SAE可以访问新浪相关网站,因为这些关联网站一般部署在同一个机房或者同一个城市,如果这些网站也很慢,那多半说明这些网站相关机房网络出现问题或者访问量很大,导致这些网站对外出口流量和访问速度变慢,也就是对外提供服务的能力扛不住了,如果没有问题,那么可以排除大的网络环境是没有问题的;

排除了网络因素,我们就可以排除后面两个原因了,由于PAAS平台的性能对用户基本上是透明的,就是用户基本上无从得知,所以可以直接跳过这个原因的排除,当然其实是有手段的,只是稍微复杂,所以不方便所有用户,如果是这种原因最好还是交给PAAS平台的开发人员去处理。

最后一个原因当然就是web应用自身的实现了,我发现很多用户反馈的网站访问慢的原因都是由于自己代码实现的问题。

首先出现问题的网站大多数是有一定访问量的,特别是某一个时间段出现访问量巨大,而且频繁读写磁盘。为了定位这种原因希望大家把应用部署在自己本地使用web性能测试工具做验证即可,例如比较常用的web性能测试工具ab,这个事apache自带的测试工具,ubuntu下安装和使用都非常方便,例如我们直接在控制台中输入ab,如果没有安装,ubuntu系统会如下提示:

The program 'ab' is currently not installed.  You can install it by typing:

sudo apt-get install apache2-utils

然后安装提示安装即可,安装成功以后我们就可以使用ab软件对我们部署在本地的web应用进行性能测试评估了,命令如下:

ab -n1000 -c10 http://localhost/

上面命令的意思是总共发送1000次请求,每次10各并发请求,访问的路径就是本地web服务器的根路径,结果如下:

This is ApacheBench, Version 2.3 <$Revision: 1430300 $>

Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/

Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking localhost (be patient)

Completed 100 requests

Completed 200 requests

Completed 300 requests

Completed 400 requests

Completed 500 requests

Completed 600 requests

Completed 700 requests

Completed 800 requests

Completed 900 requests

Completed 1000 requests

Finished 1000 requests

Server Software:        Apache/2.4.6

Server Hostname:        localhost

Server Port:            80

Document Path:          /

Document Length:        177 bytes

Concurrency Level:      10

Time taken for tests:   0.075 seconds

Complete requests:      1000

Failed requests:        0

Write errors:           0

Total transferred:      446000 bytes

HTML transferred:       177000 bytes

Requests per second:    13283.74 [#/sec] (mean)

Time per request:       0.753 [ms] (mean)

Time per request:       0.075 [ms] (mean, across all concurrent requests)

Transfer rate:          5785.69 [Kbytes/sec] received

Connection Times (ms)

            min  mean[+/-sd] median   max

Connect:        0    0   0.1      0       1

Processing:     0    1   0.2      0       2

Waiting:        0    0   0.2      0       2

Total:          0    1   0.1      1       2

ERROR: The median and mean for the processing time are more than twice the standard

     deviation apart. These results are NOT reliable.

Percentage of the requests served within a certain time (ms)

50%      1

66%      1

75%      1

80%      1

90%      1

95%      1

98%      1

99%      1

100%      2 (longest request)

本栏目更多精彩内容:http://www.bianceng.cnhttp://www.bianceng.cn/webkf/tools/

时间: 2024-09-07 14:46:35

PAAS平台的web应用性能测试与分析的相关文章

网上银行等电子支付平台的WEB登陆安全性简要分析

前言:本文还是去年年初写的,当时出于安全考虑没放出来.现在部分 网上银行已大幅度降低了无高级别安全措施情况下的转账限额,并建议用户使用动态口令卡或者USB Key,总体安全系数有所提高.随着子商务的普及,网上银行以及在线电子支付等方式逐渐被网民所接受和喜爱. 但是网上银行以及电子商务支付平台的安全性不容乐观.尽管各网上银行采取SSL加密 防止通过嗅探网络封包的方式截取密码:对于防止WEB登陆时密码被窃取,网上银行采取了安全控件或者动态软键盘的方法,但考虑的仍不全面,我们还是能采取相应的方法截获用

基于Docker开发的PaaS平台 DINP

基于Docker开发的PaaS平台 DINP DINP是又一个基于Docker开发的PaaS平台. DINP 包含如下组件: dinp-server master组件,控制集群中所有计算节点 dinp-agent Agent,部署在所有计算节点,收集各个节点运行状态和container列表 dinp-builder 编配平台,负责把用户代码打包为Docker image dinp-dash Dashboard,用户操作的入口 dinp-router 负责请求的路由等功能 dinp-hm Heal

DevOps转型的柳暗花明:开发运维一体化PaaS平台建设

本文根据陈能技老师在[2016 Gdevops全球敏捷运维峰会广州站]现场演讲内容整理而成.   (点击底部"阅读原文"获取陈能技演讲完整PPT)    讲师介绍 陈能技,DBAplus社群原创专家,新炬网络首席DevOps专家.14年开发测试与质量架构经验,擅长DevOps及APM.Docker.持续集成.持续交付在企业中的落地实施.著有<软件性能测试诊断分析与优化>.<软件自动化测试成功之道>.<深入浅出性能测试与LoadRunner实战>等书.

让PaaS平台成为整合智能交通系统的利器

随着物联网和大数据应用的不断深入,通过各类设备获取的感知数据的价值变得越来越被人们所重视.对体现物理世界实时运行状况的感知数据的集成利用,可以充分挖掘数据的价值,在解决很多诸如交通拥堵.环境污染和路网布局等热点问题起到很大的帮助. 由北方工业大学云计算研究中心的李响.丁维龙.赵卓峰组成的团队"漫步云端",充分利用微软Windows Server 2012在基础设施虚拟化方面的技术优势和成熟的一揽子解决方案,搭建了感知数据托管与应用服务平台,达到让租户快速.简便地开发和部署应用,实现交通

国内外PaaS平台大盘点

PaaS(平台即服务),是把计算环境.开发环境等平台作为一种服务提供的商业模式.云计算服务提供商可以将操作系统.应用开发环境等平台级产品通过Web以服务的方式提供给用户.PaaS介于IaaS和SaaS之间一种模式.PaaS改变了传统的应用交付模式,促进了分工的进一步专业化,解耦了开发团队和运维团队,将极大地提高未来软件交付的效率.下面本文分别带大家了解国外PaaS平台以及国内PaaS平台. 国外PaaS平台 1.Google App Engine GAE(Google App Engine)是一

基于linux的Web服务器性能测试

一.基于linux的Web服务器性能测试的重要性 linux作为一种免费的开源操作系统,正越来越受到人们的重视.随着稳定的Linux 2.4内核发布日期的临近和Intel IA-64构架的推出,Linux在服务器操作系统市场所占的份额会继续扩大,那么基于Linux的应用也就会日益丰富.而在Internet时代,操作系统最广阔的市场空间就是Web服务器,正是遍布全球的千千万万的Web服务器才构成了因特网信息资源的基础,而Web服务器性能的优劣直接关系到人们对信息资源的利用效率,因此对Web服务器性

Linux操作系统线程库性能测试与分析

NPTL 成为 glibc "正选" 线程库后,它的性能如何受到很多人的关注.本文就针对 NPTL 与 LinuxThreads 的性能比较,以及超线程.内核可抢占等特性对线程性能的影响进行了全面评测. 一. 前言 在 Linux 2.6.x 内核中,调度性能的改进是其中最引人注目的一部分 [1].NPTL(Native Posix Thread Library)[2] 使用内核的新特性重写了 Linux 的线程库,取代历史悠久而备受争议的 LinuxThreads [3] 成为 gl

优云,新一代运维PaaS平台

如果需要了解优云全线产品,可登陆官方网站(www.uyun.cn)进行注册,--免费试用SAAS版. 北京广通信达软件股份有限公司创立于2003年,是国内创新型的IT运维软件开发商和运维服务提供商,公司于2015年在全国中小企业股转系统挂牌上市(简称"广通软件",股票代码:833322). 2016年,广通软件率先在业内传播"双态运维"的理念,推出全新一代运维品牌-优云,针对企业级运维市场,创新化的的提出 "软件定义运维"与"运维Paa

DockOne微信分享(一零六):乐视云基于Kubernetes的PaaS平台建设

本文讲的是DockOne微信分享(一零六):乐视云基于Kubernetes的PaaS平台建设[编者的话]本次分享主要介绍乐视云两代PaaS平台的变迁过程,着重介绍第二代PaaS平台LeEngine的架构设计和遇到的问题. 背景 2014年乐视云开始尝试Docker的推广和使用,我们的团队开始开发第一代容器云平台Harbor (分享网址:http://dockone.io/article/1091 ).(在这里提醒一下,这与VMware公司中国团队为企业用户设计的Docker Registry e