目的:测试Haproxy压测情况 环境: Ha服务器:8核16G虚机,后端6个2核4G,压测客户端3个2核4G 安装和优化: 一.Haproxy #cd /opt/soft #wget http://www.haproxy.org/download/1.8/src/haproxy-1.8.14.tar.gz #tar zxvf haproxy-1.8.14.tar.gz #cd haproxy-1.8.14 安装: #make TARGET=linux2628 ARCH=X86_64 PREFI

前段时间搞优化,最后瓶颈发现都在数据库单点上. 问DBA,给我的写入答案是在1W(机械硬盘)左右. 联想起前几天infoQ上一篇文章说他们最好的硬件写入速度在2W后也无法提高(SSD硬盘) 但这东西感觉从来没证实过,故一时兴起,弄台虚拟机压测起来.   想搞清下面的问题:   1,mysql支撑多少连接数? 2,写入瓶颈到底是多少? 3,求QPS   畅想:  足够的CPU, load>远小于核数*2 足够的内存, 基本只用到物理内存 瓶颈在硬盘,写入速度应该能到90-100M/S(机械硬盘,7

背景 小米容器云平台,在构建云厂商集群时,需要通过HAProxy将云厂商LB流量从宿主机转到容器中,但对于HAProxy的性能没有把握.参考网上的一篇HAProxy压测文章,文章中提到HAProxy establish状态连接可以达到 400w,所以以此为目标,进行压测. 参考文章:文章地址 关键点 TCP计数器ListenOverflows大量增加 查看方法 cat /proc/net/netstat | awk '/TcpExt/ { print $21,$22 }' 原因 系统调用list

压测方案 准备多个文件大小分别为 1k 10k 100k 300k 使用ab分别按 [50,2000](按50逐渐叠加)压测服务,每次请求10W次 硬件信息:CPU:Intel(R) Xeon(R) CPU 1.86GHz ×4 4G 统计脚本:grep "Requests per second:" 300k_* | awk -F':' '{print substr($1,6),$3}'|sort -n 1k 10k 压测的时候load维持在3左右,100k 300k的load飙升到5

nginx调优方向: 1.所用事件处理模型 2.进程数 3.每个进程的连接数 4.压缩 5.缓存 tomcat调优方向: 1.内存 2.总内存 3.初始申请内存 4.线程内存 5.GC方面 tomcat和nginx往往不会是瓶颈的所在,瓶颈一般跟后端数据处理及代码逻辑方面有关系,并且在项目中如何利用好缓存是非常重要的. 压测一个网站的大概步骤: 1.如果是从互联网上压测过来的,出口带宽要提前跟IDC方沟通好暂时提升带宽 2.考虑1台nginx的配置是否能满足压测量,如内存/CPU能够满足则对ng

原文地址:还在寻找.... 一个web系统,前端使用nginx做为反向代理,处理https,并将请求转发给后端的tomcat服务. 压力测试工具选择了jmeter. 首先简单介绍一下jmeter. 它是apache的一个开源项目,基于java swing开发的GUI界面. jmeter提供了许多高级的功能,但我们仅仅使用了jmeter最简单的功能.在简单的jmeter使用中,我们涉及到这么几个概念:测试计划,线程组,测试任务,和Listener.看下面的图: 在一个名为“测试”的测试计划下, 我

1.本次对比基础环境信息如下: springboot版本1.5.10 centos虚机4c6G,版本7.4 centos实机2u16c40G,版本7.4,虚机运行在实机上 ab版本2.3 jprofiler版本9.1.1 2.压测接口说明 天花板:指的是一个空接口,没有任何实现,直接返回,如 @RequestMapping(value = "/test", method = RequestMethod.GET) public void test() { } 服务接口:指的是具有一定业务

性能问题:老年代一直处于占满状态,为什么没有发生内存溢出 以HotSpot VM的分代式GC为例,普通对象分配都是在young gen进行的,具体是从在位于young gen中的eden space中分配的TLAB里分配的. 就算old gen已经接近占满其最大capacity,由于新对象的分配都在young gen而如果young GC总是能回收足够空间来避免进一步有对象需要晋升到old gen的话,那就可以一直运行下去而不OOME. 另外一种情况就是其实程序已经进入了不断full GC来试图

[测试所用服务器8核,16G内存]压测接口:很简单,从一张表里根据主键随机查询出一条数据[数据库服务器和WEB服务器分开的].表数据量大概:910000+条. 这个测试结果很有趣:tp5.0和3.2性能没有体现出较大的区别,不知道是不是因为测试太片面.相比原始PHP,性能确实下降得厉害.JAVA的性能和原生PHP比,还差得不少.谁对JAVA很熟悉的能不能说说,是不是我的测试方法有什么没对,或者说太片面.swoole有点牛逼. 测试: ab -n -c http://127.0.0.1:xxxx/

文章目录 前言 一:Tomcat安装部署 1.1:Tomcat简介 1.2:Tomcat核心组件 1.3:Tomcat处理请求的过程 1.3.1:请求过程基本解释 1.3.2:请求过程详细解释 1.4:Tomcat部署步骤 1.4.1:下载并安装jdk 1.4.2:安装并启动Tomcat 1.4.3:缩短Tomcat启动时间 1.4.4:Tomcat目录结构 二:虚拟主机配置 2.1:虚拟主机概述 2.2:举例:通过两个域名访问到不同的项目内容 2.2.1:步骤 2.2.2:创建erbao和sa

一直运行的docker容器显示内存已经耗尽,并且容器内存耗尽也没出现重启情况,通过后台查看发现进程没有占用多少内存.内存的监控使用的是cadvisor,计算方式也是使用cadvisor的页面计算方式,所以决定对docker的内存计算做下研究. docker version: Client: Version: 1.12.6 API version: 1.24 Go version: go1.6.4 Git commit: 78d1802 Built: Tue Jan 10 20:20:01 201

背景:公司为了满足大并发的情况,需要测试组配合,就需要分布式压测,这里我把我踩过坑都记录下来: 环境:Linux + jmeter-v.5.1.1;使用3台2核4G的压力机: Q1: Server failed to start: java.rmi.server.ExportException: Listen failed on port: 0; nested exception is: java.io.FileNotFoundException: rmi_keystore.jks A1:解决思

1.JMH简介 JMH即Java Microbenchmark Harness,是Java用来做基准测试的一个工具,该工具由OpenJDK提供并维护,测试结果可信度高. 相对于 Jmeter.ab ,它通过编写代码的方式进行压测,在特定场景下会更能评估某项性能. 本次通过使用JMH来压测Dubbo的性能(官方也是使用JMH压测) 2.使用 只需要引用两个jar即可: <dependency> <groupId>org.openjdk.jmh</groupId> <

一.(测试时间:20151220 - 下午14:00-17:00) windows环境 第一次测试,运行中发现在eclipse环境下.4w个连接耗尽了约1G的内存. 另外:服务本来可用的,压测客户端强制关闭,造成大量的session需要清理,这时候会造成拒绝服务现象,新连接无法建立.. session Close是锁住进行的? 二.(测试时间:20151223 - 晚上18:00-19:20) linux 64位虚拟机 - 开集群(每秒15个连接) 压测5W,小卡顿,但是能用,到5.9w,突然完

支付宝压力测试报告 时间:2016-03-23                                             测试人员:XXX 目录 支付宝压力测试报告 1 目录 1 一  测试内容 2 二  测试方法 2 三  测试目标 2 四  测试环境 2 五  系统部署 3 5.1 网络访问 3 六  性能测试结果与分析 3 6.1 LR集群压测(1) 3 6.2 LR集群压测(10) 6 6.3 LR集群压测(20) 9 6.4 LR集群压测(30) 12 6.5 LR集群压

不久前参与开发了一个基于dubbo分布式框架的底层账单系统,并实现了其中的一部分业务接口,目前需对这些接口进行压测,以评估生产环境所能承受的最大吞吐量.笔者以其中一个查询接口为例来回顾此次压测的整体流程. 压测准备: 1.调用查询接口的测试jar包,作为dubbo-consumer,依赖了查询服务的api,测试module基于maven开发,执行maven clean package即可通过编译得到jar包 2.JMeter:Apache组织开发的基于Java的压力测试工具 方案: 无限次请求查

NewLife.Net压力测试,峰值4.2Gbps,50万pps,消息大小24字节,消息处理速度1.88亿tps! 共集合20台高配ECS参与测试,主服务器带宽6Gbps.100万pps,16核心64G内存.另外19台共模拟400个用户连接,13*16+6*32=400,每用户发送2000万个消息,服务端收到后原样返回. 有些同学比较着急,觉得前面两篇有点小儿科,群友就说,上数字吧! 我们在2017.4.1做了一个极限并发测试,奔着单机100万并发,实际上只得到了84.5万,这次补一个吞吐量的压

当前项目中重构了消息服务,需要对消息服务接口做性能压测,评估消息服务的性能情况 通过和开发对接,目前消息服务是通过dubbo接口对内提供服务,所以才有了这边文章的记录 最初的压测这个dubbo接口有三种思路: 1.第一种就是基于业务,比如注册业务,注册成功后,会发送短信消息到用户手机,通过业务调用消息服务,最容易实现,但是业务瓶颈最大导致测试结果不准 2.第二种是通过将dubbo接口上面做一层包装,提供一个http接口访问dubbo接口,需要提供二次开发,需要时间,而且高并发下,需要部署在tom

在工作上的需要接触道路运输车辆卫星定位系统相关应用,由于自己对网络服务的编写比较感兴趣,所以利用空闲时间实现了JT/T808的一些协议和相关服务(不得不说这种协议的设计在解释的确导致性能上的损耗,特别针地托管语言的C#来说就更加容易导致性能问题,不过对于现有硬件资源来说一台简配的PC支撑上几万个终端那还是没什么压力的).主要基于兴趣来写所以JT/T808只实现了几个常用的协议:0x0002,0x0200,0x0100等. 为了更好地进行模拟测试还实现了一个简单的JT/T808模拟器方便进行一些简

都说hello world 很简单,应该能承受很大的请求压力,那么到底有多大?你知道吗?如果知道,那咱们就不继续了.如果不知道,我们来看一下! 1. 准备工作,快速建立一个基于springmvc的helloworld 1.1. 在pom.xml引入spring必须的包级日志组件 <?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/PO