首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

记5.28的性能优化—线程池相关问题

目录: 1.环境介绍 2.症状 3.诊断 4.结论 5.解决 6.对比java实现 废话就不多说了,本文分享下博主在5.28期间解决的一个性能问题,觉得这个还是比较有意思的,值得总结拿出来分享下...每次业务方进行期间平台都要进行一次常规,做到心里有底。 在的上半场,陆续的解决一些不是太奇怪的问题,定位到问题时间都在计划内。下单服务、查单服务、结算页都顺利通过。...但是到了支付回调服务的时候,有个奇怪的问题出现了。 1.环境介绍 我们每年基本两次大,5.28、双12。两次大期间相隔时间也就只有半年左右,所以每次大都会心里有点低,基本就是摸底检查下。...性能指标其实在平时就关注了,而不是才来临时抱佛脚,那样其实为时已晚,只能拆东墙补西墙。...由于这篇文章不是讲怎么做性能的,所以其他跟本篇文章关系的不大的情况就不介绍了。包括网络隔离、机器的配置和节点数等。

1.3K70

保障难?失真?看看中通在性能测试上的探索与实践!

受双11、618等活动影响,井喷式的业务流量对中通的系统稳定性提出了更高的要求,过去的方案已经无法满足业务发展的需求。...测试环境等比缩放导致失真、庞大且复杂的系统链路梳理等都是棘手的问题,让我们一起看看中通是如何利用系统稳定性保障利器Takin来完成这项艰巨的任务的。...接下来详细说一下,链路梳理的目的步骤与需要拿到的关键信息 链路图 首先需要梳理出链路调用图,刚开始不需要太细,但需要对入口/出口/应用名/数据库/缓存/中间件/资金影响/邮件/短信等,类似这样的一些关键信息能梳理到...详细信息收集操作手册 根据上面梳理的梳路图,进一步明确具体细节,需要收集如下信息: 应用基础信息与部署信息 [在这里插入图片描述] 链路模块-指的是这次需求所确定的链路 应用名-应用名称,在jvm...,运单,面单等多个业务共62个应用中进行了接入,成功支持了双11&618与淘宝&拼多多等大流量联合线上的场景,虽然初步能解决原来中存在的问题,但也引入了一些新的问题。

1.3K20
您找到你想要的搜索结果了吗?
是的
没有找到

京东618测时自研中间件暴露出的问题总结,数值40ws

前天618演练进行了全链路,在此之前刚好我的热key探测框架也已经上线灰度一周了,小范围上线了2500台服务器,每秒大概接收几千个key探测,每天大概2-4亿左右,因为量很小,所以框架表现稳定。...导致实际期间表现有点惨淡。 框架的架构如下: ? 大概0点多开始,初始量比较小,从10w/s开始,当然都是的APP的后台,我的框架只是被动的接收后台发来的热key探测请求而已。...从开始的一瞬间,那台4核8G的机器就cpu100%,16核的cpu在90%以上,4核的100%即便在暂停的间隙也没有恢复,一直都是100%,无论是10w/s,还是后期40多w/s(废话,10万都凉了...当然后来我自我感觉找到问题点了,又修改了一些,有待下次检验。 这一篇就是针对各个发现的问题进行总结,包括期间的和之前灰度期间发现的一些。...发现的问题列表 前面发现的多是代码逻辑和配置问题,期间主要是cpu100%的问题,也列一下。

74610

Elasticsearch之Esrally标准

工具部署:Elasticsearch工具esrally部署指南 - 云+社区 本文另有延伸:大数据生态关于压力测试的内容 - 云+社区 背景 在大数据时代的今天,业务量越来越大,每天动辄都会产生上百...track: 即赛道的意思,这里指压用到的样本数据和策略,使用 esrally list tracks 列出。...,可以通过 esrally list pipeline 查看,其中有一个 benchmark-only 的流程,就是将 es 的管理交给用户来操作,rally 只用来做,如果你想针对已有的 es 进行...,则使用该模式; track-params:对默认的参数进行覆盖; user-tag:本次的 tag 标记; client-options:指定一些客户端连接选项,比如用户名和密码。...标准 在的过程中,需要了解到各个指标的含义。但是网络上没有完整的文档,所以这里做一个详细的总结。

3.4K2114

场景设计和方案制定

本章内容根据《分布式服务架构》整理 1.业务模型分析 2.执行 3.工具 4.小结 业务模型分析 对业务模型进行分析,选择日常请求量大且路径覆盖范围广的典型交易,建立测试业务模型,确定各接口请求量的对比...加压方式 1.瞬间加压:通过测试工具模拟大量并发请求 2.逐渐加压:一定周期内为抛物线的趋势 3.梯度加压:逐渐增加用户并发量 4.确定延时方式 执行 观察系统的资源占用情况 /系统层面:CPU,...打开的文件句柄,线程切换,和打开的Socket数量 /接口的吞吐量,响应时间,超时情况等 /数据库的慢 SQL,SQL行读,锁等待,死锁,缓冲区命中,索引命中等 /消息队列的吞吐变化,响应时间,超时情况 /过程中记录记录.../分析是否满足既定压目标 /指出系统存在的瓶颈点 工具:ab,jmeter,mysqlslap.sysbench,dd,LoadRunner,Hprof 我记得我整理了ab,jmeter的文章,...但ab在哪忘记了,贴一下jmeter的链接Jmeter系统入门教程(安装、组件使用、Demo展示、连接数据库、测报告) 现在根据书上hprof 测试环境windows,4CPU,8G内存 java

4.4K20

京东618测时自研中间件暴露出的问题总结,级别数十万秒

前天618演练进行了全链路,在此之前刚好我的热key探测框架(点击可跳转到开源地址)也已经上线灰度一周了,小范围上线了几千台服务器,每秒大概接收几千个key探测,每天大概几亿左右,因为量很小,所以框架表现稳定...导致实际期间表现有点惨淡。 框架的架构如下: 大概0点多开始,初始量比较小,从10w/s开始,当然都是的APP的后台,我的框架只是被动的接收后台发来的热key探测请求而已。...从开始的一瞬间,那台4核8G的机器就cpu100%,16核的cpu在90%以上,4核的100%即便在暂停的间隙也没有恢复,一直都是100%,无论是10w/s,还是后期到几十万/s。...当然后来我自我感觉找到问题点了,又修改了一些,有待下次检验。 这一篇就是针对各个发现的问题进行总结,包括期间的和之前灰度期间发现的一些。...发现的问题列表 前面发现的多是代码逻辑和配置问题,期间主要是cpu100%的问题,也列一下。

49410

怎么做服务关注什么?

背景 在业务新上线,或者业务做活动,成为必不可少的一步。...但是很多开发对如何做好服务并没有特别系统的了解,这篇文章的目的是为了解释清楚单机服务的目的、做法、误区,帮助大家更好地达成的目的 的目的是什么?...我们并不总是对自己的服务这么自信,能够帮我们了解清楚在高压情况下的表现,发现隐藏的问题。...双11等场景需要准备多少机器,既能保障系统稳定性、又能节约成本 缺少经验的开发,经常无法很好达成三个目标中的任何一个。...流量预估:通过历史数据(或者结合业务和时间)预估业务流量会有多大的系统调用量 容量评估:根据预估结果,计算服务需要分配多少机器 场景:针对重点业务场景,进行全局性的,根据结果再次调整。

1.4K30

JMeter笔记

【前文从理论角度对比了lock锁(Monitor)与读写锁(ReadWriteLockSlim)的差异和使用场景,尝试用Jmeter对lock、ReadWriteLockSlim】 启动Jmeter...请求次数= 线程数 * 循环次数 Duration:整个的时长 添加采样器 此次我们主要测试 [多读少写]的场景,故我们添加http请求采样器。...Listener>[****], 这里添加几个有效常见的侦听器:View Results Tree、Summary Report、Aggregate Report、Aggregate Graph 过程...在一个线程组内的线程是依次执行的,我们建立两个线程组分别测试 (读写比1:1) 测时长:4分钟 每秒尝试启动300线程不断循环 http://localhost:5000/rwlock?...这个中没有争用,_dict.TryGetValue 是o(1)的复杂度,速度很块,多个线程在某时刻命中这个方法的概率极小,整个api代码块耗时几纳秒,结果12ms,绝大部分都是在网络上, 貌似要写代码测试了

1.6K30

网站工具

在日常售后工作中,常常需要对一些网站进行简单的,以判断网站的可用性。...此时通过源站就能够发现源站性能异常。 本文提供两种简单的网站脚本,能够快速的针对源站进行HTTP或HTTPS请求的。...HTTPStressTesting.git 下载后会有两个脚本文件: simple_stresstesting.sh 该脚本为一个简单的脚本测试工具,效率相对来说比较高 stresstesting.sh 该脚本为较为复杂的网站工具...simple_stresstesting.sh运行指南 image.png 运行该脚本后面跟多个变量,第一个变量需要输入请求的次数,后面的变量需要填写网站的url以及proxy等代理请求。...image.png 结束后会展示返回的状态码等统计信息。

6.2K970

性能总结

;二 UTgolang-sdk、java-sdk都提供了很好的工具三 组件1 工具http: abgrpc: ghz go get github.com/bojand/ghz2 环境对象...4 记录数据5 分析结论通过go-pprof,jstat等工具分析测时,接口质量,优化代码go tool pprof http://xxxgo tool pprof -http=:8080 pprof.xxxgo...,系统可观测性,监控打点)1 链路确定,指定输入+输出2 系统环境准备链路上组件资源+依赖3 设计用例复杂度+压力大小(请求数、请求大小)4 记录数据5 分析结论比如关注就是系统的qps...、带宽用例组件1组件2组件3QPS入带宽xxx4C16G*24C8G*24C8G*22.5k/s160MB/s6 总结性能基线7 根据性能基线估算成本五 持续化测流程工具化,测报告自动化,用例集成到...CI六 价值1 性能优化的依据2 组件、系统性能能力的量化参考,进一步得出性能基线,对外交付的sla依据3 成本参考,性价比

1.1K70

PHP优化

概述 一个产品的编码完成,并不能代表产品能够给用户体验,其中还必须包含测试、分析等,而往往我们的产品上线前却忽略掉分析。既然分析很重要那么我们应该如何进行呢?...分析 前需要注意以下几点: 1、前必须要保证去除登录逻辑,并能够进入正常的数据请求; 2、将接口分析以便同一类接口,可以避免修改逻辑一起; 3、数据表格设计,尽量能够设计分析出系统的极限处理能力...这部分需要注意的一点是必须要等被服务器的负载降低时才能进行下一次,避免未达到最佳性能。...数据分析 1、数据分析 如果前期压数据都已经完成后,再将表格数据做成一个折线图(绘制折线图的方法,可以使用execl)。...优化点 在进行后发现,mongodb的连接和读取都会对系统产生一个非常的影响,因此我记录下了其优化方案(加大缓存时间,并整改代码,在拥有缓存数据时则不加载mongodb类库,如果没有缓存则加载类库

1.7K30

聊聊传统和全链路的区别

提升对系统架构和业务逻辑的了解; 提升测试工程师在职场和求职市场的竞争力; 提前发现系统潜在的不稳定因素,提高线上系统稳定性; 更精准的流量评估和容量规划,降低系统的硬件成本和维护成本; 保障系统在秒杀等场景和峰值流量冲击下的稳定性...传统和全链路的区别 相比于传统的方式,全链路在性能测试领域,有其独到的特殊性: 类型 传统 全链路 工具 Jmeter、Locust、Loadrunner 集群、流量引擎...每次上线特别是阶段,还是提心吊胆的怕出问题。 全链路落地过程中的挑战 虽然全链路解决了传统过程中的种种痛点,可以为线上性能评估提供更多详实的参考建议。...业内常见的做法有如下两点: 数据写入正式库表,然后通过特殊的字段进行清理(业务改造成本,清理风险高,耗时久) 采用影子库表,测流量数据进行影子库表,在不对生产数据造成污染的情况下进行; 全链路监控...,可以对写类型接口进行直接的性能测试; 安全性能:在生产环境进行性能,对业务不会造成影响; 性能瓶颈快速定位:性能测试结果直接展现业务链路中性能瓶颈的节点; Takin的接入难度么?

1.4K10
领券