精华内容
下载资源
问答
  • 1.既然是session的问题,首选更改tomcat项目的web.xml中的tomcat session的超时间 更改后,重新压测,还是没有回收正常 2.通过查看源码: 发现代码中在不断的创建session对象,这个是tomcat本身大量创建的...

    性能问题:老年代一直处于占满状态,为什么没有发生内存溢出

    以HotSpot VM的分代式GC为例,普通对象分配都是在young gen进行的,具体是从在位于young gen中的eden space中分配的TLAB里分配的。

    就算old gen已经接近占满其最大capacity,由于新对象的分配都在young gen而如果young GC总是能回收足够空间来避免进一步有对象需要晋升到old gen的话,那就可以一直运行下去而不OOME。

    另外一种情况就是其实程序已经进入了不断full GC来试图回收空间的状态,碰巧每次full GC都能回收刚好够用的空间,而GC占用的时间未超过98%的话,那程序也还会继续拖着拖着向前爬而不抛OOME。

    还有其它各种情况,不看具体日志无从分析起。
     
    压测接口如下:

    其实就是app里面的一个图片轮播图

    现象如下:

    发现高并发下,配置的1g的jvm很快就会涨到600-900M,即使通过fullgc也无法回收到低位

    通过手动触发fullgc也是无法回到低位

    现象1:

    现象2:

    tps极其不稳定,波动范围较大

     根据自己性能测试经验判断,这里肯定存在对象释放缓慢,导致内存释放不彻底的性能问题

    解决问题的思路:

    既然内存释放不彻底,那就看内存中有啥呗

    通过java命令jmap查看当前存活的对象

    jmap -dump:live,format=b,file=/tmp/heap20434.hprof 20434

    通过MAT分析工具查看内存热点

     分析2:

     由以上知道,org.apache.catalina.session.StandardManager类产生大量的对象

    原来有那么session霸占这map对象,api根本就没有使用tomcat的session,这么单纯的网站和session有啥关系呢,我以前还一直以为只有动态存放session内容的时候,才会创建session对象

    4.解决问题

    1.既然是session的问题,首选更改tomcat项目的web.xml中的tomcat session的超时间

    更改后,重新压测,还是没有回收正常

    2.通过查看源码:

    发现代码中在不断的创建session对象,这个是tomcat本身大量创建的

     

    request.getSession().invalidate(); //通过这句,清空session对象

    修改后,重新压测如下:

    第一轮优化后

     

     

    展开全文
  •  个web系统,前端使用nginx做为反向代理,处理https,并将请求转发给后端的tomcat服务。  压力测试工具选择了jmeter。 首先简单介绍一下jmeter。 它是apache的个开源项目,基于java swing开发的GUI界面。...

    原文地址:还在寻找....

      一个web系统,前端使用nginx做为反向代理,处理https,并将请求转发给后端的tomcat服务。

      压力测试工具选择了jmeter。 首先简单介绍一下jmeter。 它是apache的一个开源项目,基于java swing开发的GUI界面。 jmeter提供了许多高级的功能,但我们仅仅使用了jmeter最简单的功能。在简单的jmeter使用中,我们涉及到这么几个概念:测试计划,线程组,测试任务,和Listener。看下面的图: 

     

    在一个名为“测试”的测试计划下, 我们建立了一个线程组。 这个线程组可以设置线程数,创建时间(在多长时间内创建出这么多个线程),每个线程任务循环执行次数。 然后为这个线程组指派了一个http请求任务。 这个任务可以指定协议(http或https),服务器, url,参数等。

    接下来为这个http请求任务添加了一个aggregate graph类型的listener。 我们需要看最终的测试结果, 这个listener就是为我们记录并展示结果的。

    一切设置就绪之后,点击主界面上边的“启动”按钮,就可以在aggregate graph中观看测试结果了。 
    我们所测试的后端tomcat,执行了一次mysql数据库的查询请求,并执行了一次通过http协议请求内网其它服务器的远程请求。

    尝试着调整并发压力测试的线程数,发现QPS留在600/sec,始终无法提升, 而此时cpu的消耗只有40%左右,显然cpu还未到瓶颈。 而https处理和这样的web server,根据经验瓶颈一般出现在cpu上,为什么cpu还未到达瓶颈,qps就上不去了呢。

    接下来我们在nginx的access log中增加了 $request_time这一项, 在tomcat服务中也打了日志观测执行时间。 发现nginx的时间远大于tomcat的处理时间。 原来瓶颈点在nginx这里。 
    尝试优化一下nginx的参数,第一个看到的是,由于这是一台测试机,nginx采用的大部分配置都是默认设置,worker_processes参数被设置为1. 把这个数字调整为4的时候, QPS提升到了 1200, cpu利用率达到了99%. 看来这个就是这台测试机硬件配置的极限了。

    那么单个worker_processes的时候,为什么cpu利用率上不去,java进程尚未充分利用硬件资源,而nginx先到达瓶颈呢? 对比测试一下, 当访问硬盘上一个静态html页面的时候, 单个worker进程qps可以达到9000+。静态资源和proxy_pass的差别在于读取本地磁盘文件(可能有内存缓存),和向后端建立socket连接。团队里的技术大牛通过strace跟踪了一下,也未找出明显的问题根源,推测是在向后端建立连接的地方会出现排队等待现象。

    在我们压测的过程中, 通过netstat命令可以看到有很多nginx向tomcat发起的连接。 这些连接都是短连接,每次用完即关闭。于是想到nginx向后端源服务器能否建立长连接的问题。查看了一下文档,nginx从1.1.4版本开始,支持proxy_pass的时候向后端源服务器建立长连接。

    根据官网的描述,若采用长连接,必须在proxy_pass的时候使用upstream的方式, 直接把后端源写在proxy_pass后边是不行的。 具体的配置方式如下: 
    定义upstream: 
    upstream lich { 
    server 127.0.0.1:8081; 
    keepalive 128; 
    }

    proxy_pass的地方: 
    proxy_pass http://lich; 
    proxy_http_version 1.1; 
    proxy_set_header Connection "";

    官方文档在这里:http://nginx.org/en/docs/http/ngx_http_upstream_module.html 
    官方文档中说:proxy_http_version和proxy_set_header这两个配置是需要加上的。
    不建议使用http 1.0通过Connection:Keep-Alive的方式。

    配置完成之后重新测试,qps略微有一点提升。 但并不明显。 为了验证长连接是否生效, 同样通过 netstat命令查看连接。 发现连接到后端8081端口的nginx开启的临时端口不停的发生变化, 这证明了仍然是在采用短链接的方式。 那么是谁先关闭连接的呢。 

    通过tcpdump抓包发现, 首先发出 Fin 包的是tomcat。 也就是说, tomcat主动关闭的连接。

     

    原来在tomcat的配置文件中, 有关于keepalive的几个参数。 包括每一个连接完成多少个http请求之后就关闭等。 详细的参数可以参见tomcat的文档。详细的文档应该看这里:https://tomcat.apache.org/tomcat-7.0-doc/config/http.html

    对tomcat的connector进行了一些调整(包括maxKeepAliveRequests和keepAliveTimeout两个参数,都设置成-1)之后, 再看连接,已经不会频繁断开并重建了。 QPS也提升到了900+.

    尽管如此, nginx仍然是瓶颈,worker_processes设置为4个的时候,cpu可以利用到100%, QPS可以达到1200.

    最后再做一个对比, 当jmeter绕过nginx,不走https而直接访问http的端口8081时,qps可以达到1500+。对比一下,对https的开销大概有个概念。

    转载于:https://www.cnblogs.com/zichuan/p/9057038.html

    展开全文
  • 一次tomcat web应用压测调优

    千次阅读 2015-10-24 22:35:35
    tomcat web应用承担集团登录注册页面功能,对性能有一定要求,由于先前没有太多相关经验(只压测个dubbo服务),这次调得比较艰辛,便做个记录。 调优过程 由于该部署是两个不同团队的初次合作,起初没有给...

    1. 前言

    该tomcat web应用承担集团登录注册页面功能,对性能有一定要求,由于先前没有太多相关经验(只压测过一个dubbo服务),这次调得比较艰辛,便做个记录。

    2. 调优过程

    由于该次部署是两个不同团队的初次合作,起初没有给运维任何tomcat配置要求,同时也没留意去确认tomcat配置,这个导致了后续压测过程各种诡异的问题。

    a.在压测初期,持续请求10分钟左右出现无请求进来,netstat查看的tomcat所在服务器存在大量CLOSE_WAIT的连接。
    CLOSE_WAIT的连接一般是自己程序中缺少关闭连接等引起,但是查看程序也没发现哪里没有关闭,而且大多CLOSE_WAIT是与浏览器端的http协议下的tcp连接。后经运维排查是centos自身的BUG引起,升级到centos-release-6-6.el6.centos.12.2.x86_64后解决。

    其中对于CLOSE_WAIT和TIME_WAIT的TCP连接起初一直不太理解是怎么出现,怎么解决,后查看TCP四次挥手断开连接了解了整个过程。
    TCP四次挥手
    比如客户端应用程序发起CLOSE信息,服务端接收到后进入CLOSE_WAIT状态并做ACK,之后服务端程序发起CLOSE信息,客户端接收到之后进入TIME_WAIT,服务端收到客户端的ACK之后进入CLOSED状态,客户端TIME_WAIT需要等待到超时才进入CLOSED状态。

    基于此,服务器端出现大量CLOSE_WAIT不是一个正常的状态,首先需要确认CLOSE_WAIT状态对方的IP,再查看这个IP对应的代码是否缺少关闭连接。
    但是如果出现大量TIME_WAIT,不是太要紧,只要不占满句柄就行,如果真的占满了可以尝试修改内核TCP超时时间和TCP的TIME_WAIT重用。

    b.然后压测500个并发出现connection timeout和read timeout,这种情况基本是在请求数超过了配置的最大值,一开始找运维排除nginx和vm的限流,然后再查看tomcat的限制,发现tomcat未配置最大线程数,默认情况最大线程数是200,最大等待队列100,然后修改tomcat的server.xml配置

    <Connector port="8080" protocol="org.apache.coyote.http11.Http11NioProtocol" connectionTimeout="30000"
            enableLookups="false" maxThreads="2048" minSpareThreads="100" acceptCount="512" URIEncoding="UTF-8"/>

    调整protocol使用nio的,调整最大线程(maxThreads)为2048用于压测,最小空闲线程数(minSpareThreads)100,接收请求队列最大(acceptCount)为512
    ,到这里压1000或者2000并发都不会出现拒绝请求的情况。

    这里再细化下connection timeout和read timeout,connection timeout处于连接还没建立就超时的状态,如果不是网络问题,多半是maxThreads+acceptCount不够处理并发请求,可以尝试增加这两个值;read timeout是建立连接后,一种是等待在队列太久没处理导致超时、一种是程序自身执行时间太久,可通过access log记录请求执行时长排查。

    c.再压一段时间后,出现请求响应慢,请求进不来,此时大多是connection refused(由于先前调整的线程池,一直还在排查线程池问题),后来查看gc日志发现一直在做full gc并且老年代内存无法释放,由于没有指定过gc方式,当时以为是gc引起,所以先调整了gc配置为cms
    记录gc日志和服务挂掉时dump内存配置

    -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/vol/logs/heap.bin -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:/vol/logs/gc.log

    修改为cms的gc方式的配置

    -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=10 -XX:+CMSClassUnloadingEnabled -XX:+CMSParallelRemarkEnabled -XX:MaxTenuringThreshold=15 -XX:CMSInitiatingOccupancyFraction=70 

    对CMS的GC理解不深,大致知道默认的gc方式是阻塞应用,CMS采用并发标记清理的方式,后续再翻书学习下。TODO

    d.通过修改gc方式得到了一定的缓解,在压测不到30分钟左右时发现又出现吞吐量降低,响应非常慢的问题;
    大致知道是有很多对象没释放,通过jmap查看前20个占用最大的对象(./jmap -histo pid | head -n 20 ),好像都还好,最大的是session不过也才300多M(估计是当时刚好不在压力期间已经被释放完了);
    然后在出现慢的时候dump了全部内存下来,但是实在太大了(5G),下载太久;
    之后把堆内存调整为1G并压到出现慢,查看dump也是session最大,占百分之八十左右,这时候还没意识到是session的问题,以为1G太小看不出根本问题;
    再把堆内存调整为2G并压到出现慢,查看dump发现session占了1.5G,突然灵光一闪,我这边request session是封装放到redis的,本地的tomcat session占这么大是不对的。。。(闪得也太迟了点吧),然后把tomcat的session超时时间设置成一分钟果然不会再出现频繁FULL GC的问题。再查看代码,原来是封装的session的地方脑抽的写了个super.getSession(true)。默认配置下每次请求来都会生成新的session,并且超时时间是30分钟,在内存中占30分钟才被销毁!!

    看起来上面的问题都非常明显。。。但是在一个压测环境下去找这些问题源头是什么真是麻烦死了。。

    e.好了,最后一步,光明就在不远的前方。压测结果不算太理想,tps在4800左右,不过最起码长时间压下来算是稳定了。之后通过jprofile工具查看cpu的消耗在哪来分析单次请求耗时点。
    这里写图片描述
    jprofile去连接远程机器时需要在远程机器开启agent,执行bin/jpenable后选择是给gui访问然后填写端口即可。

    f.这里再记录下稳定压测后想做一些优化遇到的问题:
    这边在尝试提高TPS的时候,发现查看所有的压测指标资源貌似都未被占满,但是吞吐量始终上不去(应该是哪个未留意到的资源被占满了),tomcat线程池一半不到,cpu百分之70左右浮动,堆内存1G不到,磁盘IO在百分之八左右,带宽占用很低(速度在80k/s)tcp连接数在1W+
    排查这个问题时首先怀疑到可能是使用到的一个后端http服务跟不上,通过mock掉该服务后无明显提升
    后怀疑是tomcat没配置正确,然后空压一个test.jsp,tps在2W+
    再怀疑是redis没使用正确,在空test.jsp前使用一个redis session filter,相当于只压redis,tps也在1W8到2W+
    这个时候已排除了所有的外围服务,确认了是自身程序的问题,通过jprofile去查看耗时较大的一个函数,发现ua解析较慢,通过将解析结果放到threadlocal,tps得到小幅增长,从4800到5000+
    然后发现log4j的block较多,通过将log4j的级别调整到ERROR后,tps一下能到7000+,但是还是不能理解,后有同事说可能是磁盘IO次数的限制,这个当时没有关注到的点,但是环境已被撤除。

    3. tips

    3.1 压测开始前准备
    设定压测业务场景:比如用户从加载登录页面到使用账号密码登录完成
    准备压测环境:与线上同等配置的服务器以及数据量,资源无共享的纯净环境
    根据线上需求制定压测目标:比如TPS>1000,平均响应时间<100ms,错误率<0.01%,稳定运行,CPU<80%,无内存溢出,Full GC间隔时长>30分钟,gc时长<150ms
    配置资源数:各线程池、连接池大小,内存分配大小,tomcat连接数

    3.2 制定压测目标
    TPS >= (80% * 单日访问量) / (40% * 24 * 60 * 60),线上80%的请求量几种在40%的时间,根据线上情况进行调整

    3.3 如何配置资源数
    根据平均响应时间和TPS计算tomcat线程池大小,TPS/(1/RT),比如TPS>=5000,平均响应时间<=100ms,线程池大小配置5000/10,再往上调整CPU数目的整数比例(这种计算方式不一定好,主要响应时间这个不太好定,上下会相差较大,)
    数据库连接池或其他线程池大小可先设定为tomcat线程大小的一半,根据压测结果再进行调优

    3.4 压测指标及对应查看工具
    CPU,top/visualvm
    内存,free查看系统内存使用情况/jmap可查看最大使用的内存对象以及dump全部堆/visualvm/mat查看dump分析内存泄露对象及其引用
    磁盘IO,iostat
    磁盘空间,df -hl
    网络带宽,iptraf
    连接数,netstat
    线程,top -Hp pid/jstack pid/visualvm/tda查看线程dump/jprofile监控实时线程block情况
    FULL GC,-Xloggc:/path/gc.log开启gclog后查看gclog、jstat -gc
    响应时长,jprofile查看耗时较大的函数

    3.5 定位瓶颈分三步走
    检查压测端瓶颈,可通过压一个恒定标准测试(比如压空的test.jsp),基本就在压测初期检查一次就差不多
    通过查看压测指标变化情况定位资源瓶颈,再根据资源瓶颈定位程序瓶颈
    比如根据监控显示每次GC后堆内存呈上涨趋势,可在两次GC之后分别查看占用内存较大的对象,对比这些对象的数目和大小,如果有明显上涨较厉害的,可特别查看下
    TODO图片
    在第二步查看问题中,可能出现影响因素较多的情况,这样可通过mock掉部分怀疑的因素或者单压某怀疑因素
    比如系统中使用的外围服务包括数据库、redis,现在怀疑可能是查数据库或者在查redis的时候导致吞吐量上不去,此时可通过mock掉数据库的查询查看下吞吐量是否有提升,如果有提升则说明多半是数据库查询导致

    3.6 优化
    在定位到瓶颈点之后,相对来说优化就没那么复杂,无外乎对瓶颈资源的少用、复用和交换资源。
    比如在程序中一个请求下来会查询N次账号信息,可以考虑把该账号信息放置到缓存或者内存之类的。
    可以从业务角度去考虑优化,比如某个扩展业务直接影响到主业务的性能,且该扩展业务本身不是那么重要,可以考虑通过缩减该扩展业务的方式做到优化。

    展开全文
  • 、问题描述 项目现场压测登陆接口,说并发30左右服务就会卡死。由于现场不能通过外网远程连接,只能本地复现下(配置文件、项目版本、启动参数等都保持一致)。 压测工具:jemeter 压测功能:登陆接口 问题简述:...

    一、问题描述

    项目现场压测登陆接口,说并发30左右服务就会卡死。由于现场不能通过外网远程连接,只能本地复现下(配置文件、项目版本、启动参数等都保持一致)。
    压测工具:jemeter
    压测功能:登陆接口
    问题简述:并发30,后端出现OOM。
    在这里插入图片描述

    二、解决思路

    没想到居然真的复现了,既然是排查OOM,就用java自带的VisualVM工具吧,需要初步排查是哪些对象占用了堆内存。

    1、使用VisualVM排查jvm内存:

    (1)目录在C:\Program Files\Java\jdk1.8.0_144\bin下,有个jvisualvm.exe。
    (2)启动后,选择本地连接,连上自己的测试项目。
    示例图一个是jemeter,一个是测试项目
    在这里插入图片描述
    连上后的效果,可以看到cpu、堆内存、元空间、类加载数量、线程等信息(jemeter为例):
    在这里插入图片描述
    (4)使用jemeter压测30个线程并发(测试项目为例):
    在这里插入图片描述
    可以看到,压测开始的那一瞬间,cpu直接飙升,而且堆空间的使用空间也飙升。点击右上角,看堆信息:
    堆空间内存
    点击 类 -> 大小排序,发现byte[]数组实例只有0.5%,但是却占用了91%的内存空间!!!那说明每个byte[]对象都是大对象!查看下大对象:
    在这里插入图片描述

    找重复的对象,然后看下,发现一点端倪
    大对象属性

    ①后端报错的是http-nio连接;
    ②堆信息显示的大对象也是http相关的:
    ③后端效果,接口并没有打印相关执行日志且有full gc发生;
    可以大胆猜测是tomcat的问题

    2、检查配置文件

    配置文件:
    在这里插入图片描述

    看到配置文件发现4、6行居然和大对象的size一样?!测试后发现,max-http-header-size才是罪魁祸首,将该参数调小至实际情况即可。

    三、解决方案

    配置文件max-http-header-size属性,根据项目实际情况配置。

    四、小结

    1、max-http-header-size是请求头参数大小,tomcat会创建预留空间,即使header实际参数没那么大,也会创建那么大的空间。
    2、从二.1.(4)最后的大对象属性图能看出来,tomcat会按照max-http-header-size的配置属性创建两个对象,这也解释了为什么2G内存的JVM在30并发左右就OOM+FULL GC了(2048 / 60 =34.13 )
    3、max-http-header-size默认配置,tomcat 5是4kb,tomcat 8是8kb
    在这里插入图片描述

    萌新发言,不喜勿喷,欢迎大佬指出不当之处!

    展开全文
  • 楼主今年手上有个项目,上线后,每天大概15w的访问量,单台pod(公司用的docker),TPS在6-7之间,第一次压测的时候,最好的情况是5个pod,TPS达到了36。楼主当时有点绝望,因为跟我们其他的服务上千的qps差距太大了,...
  • 次压测时物理内存被用光 Tomcat 被 Kernel kill 掉的案例
  • 并发测试: 第一次,并发100,10分钟,执行6分钟,丢失6次,CPU在3% 内存占用100M左右,系统框架无压力。 第二次,并发500,10分钟,执行完毕,丢失2次 CPU在3%,内存占用150M左右,系统框架无压力。 目前在增加...
  • tomcat8压测监控调优

    千次阅读 2017-11-03 09:26:03
    配置用户修改conf/tomcat-users.xml ,manager,manager-gui"/>同时还需要修改,如无新建co
  • 文章目录、创建虚拟主机二、Tomcat配置优化及压测 、创建虚拟主机 可能有时候公司会有多个项目需要运行,那么肯定不可能是台服务器上运行多个Tomcat服务,这样会消耗太多的系统资源,此时就需要用到Tomcat...
  • 文章目录tomcat部署及优化(Tomcat部署和优化、压测 虚拟主机配置)tomcat安装部署1.1:Tomcat介绍1.2:Tomcat核心组件1.3:Tomcat处理请求大致流程1.4:Tomcat Servlet容器处理流程1.5:Tomcat 系统总体架构二...
  • 对线上服务进行性能压力测试的一次优化...对线上的两台服务器做性能压测时,发现单台Tomcat的QPS达到600左右处理业务就明显变慢,一次请求处理时间大约上升到七秒左右(正常情况下一秒内就处理完成),给人的感觉就...
  • 公司需要台测试服务器来做测试用,所以花了几天时间把服务全部部署好,在部署好war包之后,发现Tomcat访问超级慢。 1、进入Tomcat的bin目录下,运行 ./catalina.sh run命令,在前台打印运行信息,首先看其有没有...
  • 最近一直在搞性能压测,断断续续的搞了个月了,中间遇到各种问题,这里将这些问题分享下,以后大家踩坑时可以参考~ 俗话说,工欲善其事,必先利其器。拿到机器,先检查CPU、内存、网卡、磁盘四大件。咋知道这第...
  • 一次使用Jmeter的性能压测过程

    千次阅读 2020-03-04 12:46:40
    最近在搞个小项目,也是为春招准备准备,在写完基本的webserver后,部署到了阿里云服务器上,决定玩压测,我的阿里云主机配置为学生机配置,顺便帮推波女票的博客,分享一下webServer端部署操作的一些配置...
  • maxKeepAliveRequests:多少请求后keepalive断开失效 使用WebServerFactoryCustomizer<ConfigurableServletWebServerFactory>定制化内嵌tomcat配置 //当Spring容器内没有...
  • springboot默认servlet框架为tomcat,可通过pom文件配置undertow或jetty容器。考虑到网络对QPS的影响...压测配置:3台压测机,500并发,0.1秒请求一次,3台受压机,压测时间20分钟。压测记录: 容器 负载(min、m...
  • 一次:排查Tomcat跑死问题

    千次阅读 多人点赞 2018-11-08 02:21:06
    上周末,我个朋友来到我家,抛给我个“Tomcat无缘故跑死”的问题,场景即是: 早上启动Tomcat,到了下午8点左右,Tomcat突然崩溃死掉,并且这段时间也没有做一些额外的操作。 这种事情,连续出现了好几。 ...
  • 官方说:For servlet stack applications, the spring-boot-starter-web includes Tomcat by including spring-boot-starter-tomcat, but you can use spring-boot-starter-jetty or spring-boot-starter-undertow ...
  • 几周前的个周五,帮朋友忙,需要给个软件做压力测试,花了晚的时间学习了下,然后就赶鸭子上架去做这个事了。 想着有时间把学习过程整理下,结果忘掉了。 今天欢哥问到我上次压测用了什么软件,才想起这个事,...
  • Jmeter工具使用: 下载地址:jmeter.apache.org 常用命令设置: 查看服务进程:ps -ef | ...上图表示在10s中开启100个线程,每个线程调用10接口。 Http请求: 在线程组下设置Http请求。 上图表示使用h...
  • 今早对Tomcat7.0.5、Netty3.2.3、Jetty-hightide-7.2.2做了个简单的压测, 测试方案我想肯定是不太严谨的,但是对于快速评估还是有点价值的,测试结果出乎意外。   压测工具: ApacheBench(简称ab), Version ...
  • 参考tomcat的文档,调用tomcat的连接数,压测时对CPU没有多大的影响 <Connector port="8086" protocol="HTTP/1.1" connectionTimeout="20000" redir...
  •  这篇博客的目的,不是复述上一篇博客,而是尽量规范的去做一次压测对比,并且能够清晰的描述出过程和结果。 二、准备  1、服务器  为了保证尽量少的干扰,这里不再在虚拟机上运行服务,而是直接在...
  • 测试在进行一次性能测试的时候发现并发300个请求时出现了下面的异常: HTTP Status 500 - Handler processing failed; nested exception is java.lang.OutOfMemoryError: unable to create new native thread 看到...
  • 前言 旨在分享工作中遇到的各种问题及解决思路与方案,与大家一起学习.学无止境, 加油 ! Just do it !问题描述 运行环境描述tomcat-8.5单节点(该应用集群20个节点)...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 3,475
精华内容 1,390
关键字:

一次压测tomcat