压测和性能分析方法论性能测试基础性能测试的常见分类性能测试。用来验证系统的性能是否满足设计的预期,一般来说对系统的压力会比较小,不会压垮系统,只是进行简单的验证负载测试。通过不断施加负载压力,寻找系统最优的处理能力,最好的性能状态,达到最大的性能指标。通常说来,负载测试的结果比性能测试的结果高一点。
一、QPS,每秒查询QPS:QueriesPerSecond意思是“每秒查询率”,是一台服务器每秒能够相应的查询次数,是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。互联网中,作为域名系统服务器的机器的性能经常用每秒查询率来衡量。二、TPS,每秒事务TPS:是Transactions
前言在家休息的的时候,突然小勇打电话过来,问农哥,你知道Sentinel吗?我(清了清嗓子):知道啊,怎么了?小勇(带着低落的声音):最近面试了一个,问我Sentinel是什么,具体的用法和项目中使用的。没有复习,记得不太清楚,dan疼。我(是时候开始装杯了):没事,先揉揉,(Sentinel)不就
最近几年,随着微服务的流行,服务和服务之间的依赖越来越强,调用关系越来越复杂,服务和服务之间的稳定性越来越重要。在遇到突发的请求量激增,恶意的用户访问,亦或请求频率过高给下游服务带来较大压力时,我们常常需要通过缓存、限流、熔断降级、负载均衡等多种方式保证服务的稳定性。其中限流是不可或缺的一环,这篇文
偶然看到了《扛住100亿次请求——如何做一个“有把握”的春晚红包系统》一文,看完以后,感慨良多,收益很多。图片来自Pexels正所谓他山之石,可以攻玉,虽然此文发表于2015年,我看到时已经过去良久,但是其中的思想仍然可以为很多后端设计借鉴。同时作为一名微信后端工程师,看完以后又会思考,学习了这样的
TL;DR(toolongdon'tread)限流算法:计数器、滑动窗口、漏桶、令牌桶。限流方案:Guava的RateLimiter、AlibabaSentinel大家都知道,对于高并发的业务场景,我们为了保障服务的稳定,经常会祭出三大利器:缓存、熔断降级和服务限流。服务限流作为一个核心
一,需求缘起互联网公司,这样的场景是否似曾相识:场景一:pm要做一个很大的运营活动,技术老大杀过来,问了两个问题:(1)机器能抗住么?(2)如果扛不住,需要加多少台机器?场景二:系统设计阶段,技术老大杀过来,又问了两个问题:(1)数据库需要分库么?(2)如果需要分库,需要分几个库?技术上