Clik here to view.
Tsung笔记之开篇
前言 有测试驱动的开发模式，目的在于确保业务层面功能是准确的，每一次新增、修改等动作确保都不会影响到现有功能。功能开发完成了，需要部署到线上，系统能够承载多大的用户量呢，这时候就需要借助于性能压测，也称之为压力测试，界定系统能够承载具体容量上限，从容应对业务的运营需要，扩容或缩容，心中有底。...
View ArticleClik here to view.
Tsung笔记之主从模型篇
前言 本篇讲解Tsung大致功能组成、结构，以及主从模型，以便总体上掌握。 总体组成  tsung_controller 和 tsung 这两个模块，负责分布式压测的核心功能。 代码组成 从代码层次梳理一下tsung项目功能组成结构，便于一目了然，方便直接索引。  主从模型一览 设定环境为分布式环境下Tsung集群，下面简单梳理一下主、从节点启动流程。  流程大致说明：...
View ArticleClik here to view.
Tsung笔记之主从资源协调篇
前言 接着上文，tsung一旦启动，主从节点之间需要协调分配资源，完成分布式压测任务。 如何启动Tsung压测从机 Erlang SDK提供了从机启动方式： slave:start(Host, Node, Opts) 启动从机需要借助于免登陆形式远程终端，比如SSH（后续会讨论SSH存在不足，以及全新的替代品），需要自行配置。 <client host="client_100"...
View ArticleClik here to view.
Tsung笔记之压测端资源限制篇
前言 这里汇集一下影响tsung client创建用户数的各项因素。因为Tsung是IO密集型的应用，CPU占用一般不大，为了尽可能的生成更多的用户，需要考虑内存相关事宜。 IP & 端口的影响 1. 系统端口限制 Linux系统端口为short类型表示，数值上限为65535。假设分配压测业务可用端口范围为1024 -...
View ArticleClik here to view.
Tsung笔记之分布式增强跳出SSH羁绊篇
前言 Erlang天生支持分布式环境，Tsung框架的分布式压测受益于此，简单轻松操控子节点生死存亡、派发任务等不费吹灰之力。...
View ArticleClik here to view.
Tsung笔记之IP直连支持篇
前言 前面说到设计一个小型的C/S类型远程终端套件以替换SSH，并且已经应用到线上。这个问题，其实不是Tsung自身的问题，是外部连接依赖问题。...
View ArticleClik here to view.
Tsung笔记之监控数据收集篇
前言 压力测试和监控分不开，监控能够记录压测过程中状态，方便问题跟踪、定位。本篇我们将讨论对压测客户端tsung client的监控，以及对被压测服务器的资源占用监控等。同时，也涉及到Tsung运行时的实时诊断方式，这也是对Tsung一些运行时状态的主动监控。 压测客户端的监控 压测端（指的是tsung...
View ArticleClik here to view.
Tsung笔记之插件编写篇
前言 Tsung对具体协议、通道的支持，一般以插件形式提供接口，接口不是很复杂，插件也很容易编写，支持协议多，也就不足为怪了。 下面首先梳理一下当前Tsung 1.6.0所有内置插件，然后为一个名称为Qmsg的私有二进制协议编写插件, 运行Qmsg服务器端程序，执行压力测试，最后查看测试报告。 已支持插件梳理 Tsung 1.6.0支持的协议很多，简单梳理一下： ...
View ArticleClik here to view.
Tsung笔记之100万用户压测执行步骤篇
前言 总是说细节、理论，会让人不胜其烦。我们使用Tsung来一次100万用户压测的吧，或许能够引起好多人的兴趣 :)) 下面，我根据在公司分享的PPT《分布式百万用户压测你的业务》，贴出其中的关键部分，说明进行一次100W(即1M)用户压测的执行步骤。 如何做分布式百万用户的压测 ？ 假定面向小白用户，因此才有了下面可执行的10个步骤用于开展分布式百万用户。 ...
View ArticleClik here to view.
Tsung笔记之IP地址和端口限制突破篇
前言 在Tsung笔记之压测端资源限制篇中说到单一IP地址的服务器最多能够向外发送64K个连接，这个已算是极限了。 但现在我还想继续深入一下，如何突破这个限制呢 ？ 如何突破限制 这部分就是要从多个方面去讨论如何如何突破限制单个IP的限制。 0. Tsung支持TCP情况 在Tsung 1.6.0 中支持的TCP属性有限，全部特性如下：...
View ArticleClik here to view.
HTTP API设计笔记
前言 最近一段时间，要为一个手机终端APP程序从零开始设计一整套HTTP API，因为面向的用户很固定，一个新的移动端APP。目前还是项目初期，自然要求一切快速、从简，实用性为主。 下面将逐一论述我们是如何设计HTTP API，虽然相对大部分人而言，没有什么新意，但对我来说很新鲜的。避免忘却，趁着空闲尽快记录下来。 技术堆栈的选择 PHP嘛？团队内也没几个人熟悉。...
View ArticleClik here to view.
Apisix 1.5 升级到 2.2 踩坑备忘
零、前言 线上运行的 APISIX 为 1.5 版本，而社区已经发布了 Apisix 2.2，是时候需要升级到最新版了，能够享受最版本带来的大量的BugFix，性能增强，以及新增特性的支持等~ 从Apisix 1.5升级到Apisix...
View ArticleClik here to view.
参与Apisix开源的一次完整提交过程分享
前言 参与开源不是为了证明什么，而是为了更好的配合工作。开源和工作在绝大部分时间，都是可以和谐共处，互相促进，Win-WIn双赢。 本文内容记录了为 apisix 项目提交的一次pull request提交 （访问地址：https://github.com/apache/apisix/pull/3615...
View ArticleClik here to view.
K8S 修改默认 StorageClass
业务需要将默认的K8S存储服务修改NFS，这里记录一下操作记录。 列出当前StorageClass： kubectl get sc NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE local-path (default) rancher.io/local-path Delete...
View ArticleClik here to view.
K8S Service 多种类型 Types 测试手记
前言 这里基于whoami示范服务，部署3个实例，分别一一验证各种类型的K8S Service服务范畴。 大致逐一从下面列表逐一验证每种类型的Service访问方式： Service Name 域名解析结果等 CLUSTER-IP EXTERNAL-IP 一些设定如下： 测试环境K8S版本号为v1.27.3 K8S集群Node节点IP地址段范围：10.0.1.0/24...
View Article