论答系统万人大课高并发性能测试方案2018.10.30

性能测试目的:通过高并发压力测试找到目前服务器瓶颈在哪。

性能测试范围:(根据业务高峰期的日志分析)

  1.socket相关(教师端网络监测、白板、分配解析卡、练习卡,学生端网络监测、学生做题)

  2.Http接口(教师端备课添加多个教学点、获取课堂信息接口、定制测评、智能练习卡)

性能测试方案:

  1.模拟测试在线10万用户下,系统服务器运行情况。

  2.并发量=在线用户/10

  3.使用Jmeter 发送每秒1w并发量,检查此时系统是否达到瓶颈

  4.瓶颈的判断依据:1.服务器资源超过性能测试指标。2.吞吐量开始下降。3.响应时间开始上升。

性能测试指标:

  1.所有请求的响应时间不超过3秒.

  2.被测服务器资源CPU不超过70%.

  3.被测服务器资源内存不超过70%.

  4.被测服务器资源磁盘IO不能跑满

  5.被测服务器带宽占用率不超过70%

性能测试计划:

  1.测试脚本准备包括测试账号生成-11月6日

  2.测试服务器部署-11月6日

  3.分布式测试服务器构建-11月13日

  4.测试环境预演-11月26日

  5.测试前被测服务器各项指标监控,数据库备份,通知客服系统维护-11月28日

  6.性能测试报告总节-11月30日

  7.测试后数据清理-11月29日

  8.功能回归测试验证系统恢复-11月29日

  9.通知客服,系统恢复-11月29日

性能测试准备:

  1.新建一个测试机构-论答性能测试

  2.教师端测试账号,学生端测试账号

  3.生成1w个有效长token

被测服务器架构:

  websocket服务器1台,前端服务器1台,mongoDB缓存服务器1台,redis缓存服务器1台,后端服务器1台,数据库服务器1台,其他云服务(CDN七牛、音视频声网)

测试服务器配置:

  5台window server2008 R2系统,CPU Inter E5-2682 2.5GHz,内存8G

性能测试工具:

  1.工具选型Jmeter

  2.安装部署java

  3.安装部署jmeter,注意jmeter要安装在D盘第一层级

  4.在lib文件添加ext扩展文件保证可以使用websocket

  5.全局参数token配置

  6.http head配置

  7.逻辑控制器-循环控制器

  8.json提取器

  9.分布式部署

性能测试报告:

  

原文地址:https://www.cnblogs.com/Ootori/p/9876674.html

时间: 2024-07-30 14:08:20

论答系统万人大课高并发性能测试方案2018.10.30的相关文章

从宜人贷系统架构看互联网高并发对金融系统架构的挑战

原文:http://www.p2pquan.com/article-740-1.html 一.简介 随着互联网金融的持续火热,越来越多的银行纷纷发布了各自的互联网金融产品.但是互联网产品“高并发.大数据量”的特点却对于银行传统的核心系统架构带来了新的挑战. 1.互联网的核心技术特征 当前互联网的核心技术特征主要可以概括为:分布式,易扩展,大量低端设备,底层开源软件.分布式结构可以通过平行扩展来支撑互联网上蜂拥而至的访问客户.同时,基于客户行为分析的大数据平台也需要分布式系统来完成,其中最典型的就

高并发大流量网站 10 个解决方法

高并发大流量网站 10 个解决方法1.硬件升级 普通的P4服务器一般最多能支持每天10万独立IP,如果访问量比这个还要大, 那么必须首先配置一台更高性能的专用服务器才能解决问题 ,否则怎么优化都不可能彻底解决性能问题. 2.负载均衡 它是根据某种负载策略把请求分发到集群中的每一台服务器上,让整个服务器群来处理网站的请求.公司比较有钱的,可以购买专门负责负载均衡的硬件(如:F5),效果肯定会很好.对于大部分公司,会选择廉价有效的方法扩展整个系统的架构,来增加服务器的吞吐量和处理能力,以及承载能力.

海量数据、高并发优化方案

一.应用服务器负载均衡 1.链路负载均衡 通过DNS解析域名时,将客户端的访问解析成不同的IP,分配到不同的入口,同时尽可能保证所访问的入口是所有入口中可能较快的一个. 2.软件负载均衡 访问时生成页面的任务会被分配给其中一台服务器完成,这个过程要保证公正.公平.平均. 3.硬件负载均衡 二.页面优化 1.减少请求次数 通过合并CSS和Javascript文件来减少请求次数或是将资源文件分布在多个域名下来绕过浏览器并发加载的限制. 2.压缩CSS和Javascript代码. 通过对文件代码内容删

面试官绝杀:系统是如何支撑高并发的?

很多人面试的时候被问到一个让人特别手足无措的问题:你的系统如何支撑高并发? 大多数同学被问到这个问题压根儿没什么思路去回答,不知道从什么地方说起,其实本质就是没经历过一些真正有高并发系统的锤炼罢了. 因为没有过相关的项目经历,所以就没法从真实的自身体会和经验中提炼出一套回答,然后系统地阐述出来自己复杂过的系统如何支撑高并发的. 所以,这篇文章就从这个角度切入来简单说说这个问题,教你用一个最简单的思路来如何应对的. 当然这里首先说清楚一个前提:高并发系统各不相同.比如每秒百万并发的中间件系统.每日

asp.net解决高并发的方案

那啥,最近见了一人叨叨叨的神侃如何处理高并发.居然聊到服务器矩阵.我当时还没回过神,过后细想,服务器矩阵我也知道口里说说,但是中小企业能玩得起?作为一个程序员很多时候只能用手头资源来制定优化方案.(人生哲理:要警惕夸夸其谈者) 我收集了下网上提供的处理方式列在这里.虽然我不会无聊到背下来去唬新人,但加深下映象,有个纲目还是好的. 两大点: 通过服务器处理高并发  调整服务器应用程序池中的最大连接数. 1. 调整IIS 7应用程序池队列长度 由原来的默认1000改为65535. IIS Manag

asp.net解决高并发的方案.[转]

最近几天一直在读代震军的博客,他是Discuz!NT的设计者,读了他的一系列关于Discuz!NT的架构设计文章,大呼过瘾,特别是Discuz!NT在解决高访问高并发时所设计的一系列方案,本人尤其感兴趣.写这篇文章的目的,算是对初次阅读之后的总结备忘吧,以便以后有时间亲自测试,如果能在生产环境中得到应用,那就更有参考价值了. 测试方法:本地模拟测试网站高访问高并发采用的测试工具是大名鼎鼎的Loadrunner,这个工具做测试的一般都知道.在代震军的博客中,有以下几篇介绍了通过Loadrunner

解决高并发的方案

对于我们开发的网站,如果网站的访问量非常大的话,那么我们就需要考虑相关的并发访问问题了.而并发问题是绝大部分的程序员头疼的问题, 但话又说回来了,既然逃避不掉,那我们就坦然面对吧~今天就让我们一起来研究一下常见的并发和同步吧. 为了更好的理解并发和同步,我们需要先明白两个重要的概念:同步和异步    1.同步和异步的区别和联系 所谓同步,可以理解为在执行完一个函数或方法之后,一直等待系统返回值或消息,这时程序是出于阻塞的,只有接收到 返回的值或消息后才往下执行其它的命令. 异步,执行完函数或方法

asp.net解决高并发的方案. (转自网络)

最近几天一直在读代震军的博客,他是Discuz!NT的设计者,读了他的一系列关于Discuz!NT的架构设计文章,大呼过瘾,特别是Discuz!NT在解决高访问高并发时所设计的一系列方案,本人尤其感兴趣.写这篇文章的目的,算是对初次阅读之后的总结备忘吧,以便以后有时间亲自测试,如果能在生产环境中得到应用,那就更有参考价值了. 测试方法:本地模拟测试网站高访问高并发采用的测试工具是大名鼎鼎的Loadrunner,这个工具做测试的一般都知道.在代震军的博客中,有以下几篇介绍了通过Loadrunner

[日常] 高并发抢购方案的思考

经常在面试中被问到如何设计一个高并发环境下的抢购方案,虽然网上的资料已经很多了,但是都是很简单的说了一些用队列之类的套话,没有更详细的细节考虑.被问的实在是太多了,不得已我也仔细想想这些该怎么设计.抛开运维阶段的多层负载均衡,直接只说PHP的业务层面的逻辑. 整个流程如下:web界面点击抢购==>弹出答题弹窗==>答对判定当前队列长度==>队列未满就进入队列,显示排队中(状态),使用wbsocker实时关注用户状态 ==>答错再答基本就没戏了返回失败 ==>队列满了,返回失败