亚洲精品tv久久久久久久久久,亚洲不卡av不卡一区二区,亚洲av无码成h人动漫无遮挡

K8S 修改默认 StorageClass

nieyong — Fri, 08 Sep 2023 07:30:00 GMT

业务需要将默认的K8S存储服务修改NFS�Q�这里记录一下操作记录�?/p>

列出当前StorageClass�Q?/p>

kubectl get sc
NAME                   PROVISIONER                                         RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
local-path (default)   rancher.io/local-path                               Delete          WaitForFirstConsumer   false                  17d
nfs                    cluster.local/nfs-nfs-subdir-external-provisioner   Delete          Immediate              true                   6d14h

首先�Q�将默认的名�U�Cؓlocal-path修改�?code>false�Q?/p>

kubectl patch storageclass local-path -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"false"}}}'

然后�Q�将nfs讄��为默认：

kubectl patch storageclass nfs -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'

操作完成之后�Q�校验一下，可以看到已经成功��?code>nfs讄��为默认的StorageClass选项�?/p>

kubectl get sc
NAME            PROVISIONER                                         RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
local-path      rancher.io/local-path                               Delete          WaitForFirstConsumer   false                  17d
nfs (default)   cluster.local/nfs-nfs-subdir-external-provisioner   Delete          Immediate              true                   6d14h

Ref�Q?a >https://kubernetes.io/docs/tasks/administer-cluster/change-default-storage-class/

nieyong 2023-09-08 15:30 发表评论

nieyong — Wed, 10 Mar 2021 03:20:00 GMT

前言

参与开源不是�ؓ了证明什么，而是��Z��更好的配合工作。开源和工作在绝大部分时��_��都是可以和谐共处�Q�互�怿��q�，Win-WIn双赢�?/p>

本文内容记录了�ؓ apisix ��目提交的一�ơpull request提交 �Q�访问地址�Q?a >https://github.com/apache/apisix/pull/3615 �Q�完整过�E�，提交内容��Z��个独立的服务发现模块�Q�本文目的是为团队的其他同学参与�C�֌��目分��n的行为提供一个简单可遵��@、可操作模型�?

概括来讲�Q�简要操作流�E�如下：

首先�Q�确定需要开源的部分
其次�Q�在��目�C�֌�中分享我们的看法和后�l�行为等
然后�Q�准备提交内�?/li>
接着�Q�提交pull request�Q�接受社区审核，反复调整修改
后箋�Q�关注社区的走向�Q�持�l�改�q?/li>

下面为每一步具体操作的��水账�?/p>

提前预警�Q�图多费��量�Q�慎�?:))

首先�Q�我们有一个Consul KV服务发现�l��g

作�ؓNginx用户�Q�我们实际场景��?Nginx Upsync 模块�Q�结合Consul KV作�ؓ服务注册和发现�Ş式�?/p>

我们��Z��Apisix构徏HTTP API服务�|�关�Q�没有发现现成的Consul KV形式服务发现模块�Q�既然实际业务需要，我们需要把它按照接口规范开发出来，以适应我们自己的实际场景�?/p>

当服务发现模块功能开发出来后�Q�也是仅仅能满��基本需求，�q�不够完善，但这时改�q�的思�\�q�不是非常清楚，
既然开源社��Z��有类似的需求，那我们可以考虑分��n开源出去，接收整个�C�֌�的考验�Q�大家一��h��q��?/p>

限于日常思维角度的局限，若是仅仅满��工作需要，那么开源出��M��让你的代码接受到�C�֌��Ҏ��面面的审核，��其是针对代码风根{��功能、执行等有严��D��求的apisix��目。摆正心态，接受代码评审�q�调��_��最�l�结果无疑是让代码更加健壮，好事一桩嘛�?/p>

当然开源出��M��后，该模块的变更以及优化�{�行为就完全归属整个�C�֌�了，��策��力�Q�是一�U�比较期待的演进方式�?/p>

�W�一步，咨询�C�֌�意见

一个优�U�的开源项目，��Z��E�_��健康发展�Q�一般会提供邮�g�l�方便社区参与者咨询、沟通协调等�?/p>

一般来��_��Github会提�?code>issues列表方便��目使用者提交BUG�Q�若我们惛_��C�֌�中表达意图、观点等�Q�就不如发在�C�֌�邮�g�l�中�Q�这栯��够得到更多的��x��。比如，我们想给�C�֌��׃�n一个完整的服务发现模块�Q�就可以直接在邮件组中描�q�大致功能，以及大致处理��程�{�，让社区知道我们的真实意图�?/p>

Apisix开发邮件组地址为：dev@apisix.apache.org�Q�但一般的邮�g�l�都需要注意如下事��：

沟通需要��用英�?
- �q�也是Apisix��目国际化需�?/li>
- 虽然你也知道阅读邮�g的有几个中国的糙老爷们，但也会有来自其他国家的用�?/li>
- 当然在Github上所有的��目沟通都需要��用英文，�q�是一个良好的开源社区沟通习�?/li>
- 推荐一个微软英语在�U�协作辅助工��P��https://aimwriting.mtutor.engkoo.com/ �Q�可以帮助校验语法错误等
无法传递富文本
- 使用�U�文本即�?/li>
- �c�M��我有格式化强�q�症患者，直接�_�脓 markdown 格式文本
无法传递图�?/p>
- 直接传递图片URL地址
- 若需要传递图片，提供一个小技巧：新徏一个issues表单�Q�直接拖拽图片到表单处，然后获得囄��地址卛_��Q�无��L��?code>issues表单
上传囄��

下面是我发送的邮�g截图�Q?/p>

因�ؓapache邮�g�l�不支持富文本和囄��Q�实际看到的效果��没有那么好看了�Q�下面的�q�接包含了该讨论完整的回复内容：

https://lists.apache.org/thread.html/rf9e392dd76e4701935940d22b4b9d9f8ed130cca34a2e951357a4c2a%40%3Cdev.apisix.apache.org%3E

不方便打开的话�Q�下面提供完整邮件讨论截图，很长的截图，呵呵�Q?br/>

maillist

��M��Q�断断箋�l�经�q�三周时间的讨论�Q�这个过�E�需要有些耐心。发完邮件等有了�U�极反馈�Q�下面就可以着手准备提交代码了�?/p>

�W�二步，准备提交

Fork到自�׃��?/h3>

�?https://github.com/apache/apisix Fork到自�׃��库中�Q�然后克隆到自己工作机来�?/p>

注意�Q�需要时��M��持和��d��保持一��_��

git remote add upstream https://github.com/apache/apisix.git

下面��是动手开�q�了�?/p>

按需调整代码

Consul KV服务发现模块文�g�?consul_kv.lua�Q�相对位�|��ؓ�Q?code>apisix/discovery/consul_kv.lua。我们想提交到项目主�qԌ��那么代码��必��遵循已有规范�?/p>

针对apisix的服务发��C��码，需要有配置��，��必��ȝ��Z��套完整的服务配置 schema 定义�Q�如下�?/p>

local schema = {
    type = "object",
    properties = {
        servers = {
            type = "array",
            minItems = 1,
            items = {
                type = "string",
            }
        },
        fetch_interval = {type = "integer", minimum = 1, default = 3},
        keepalive = {
            type = "boolean",
            default = true
        },
        prefix = {type = "string", default = "upstreams"},
        weight = {type = "integer", minimum = 1, default = 1},
        timeout = {
            type = "object",
            properties = {
                connect = {type = "integer", minimum = 1, default = 2000},
                read = {type = "integer", minimum = 1, default = 2000},
                wait = {type = "integer", minimum = 1, default = 60}
            },
            default = {
                connect = 2000,
                read = 2000,
                wait = 60,
            }
        },
        skip_keys = {
            type = "array",
            minItems = 1,
            items = {
                type = "string",
            }
        },
        default_service = {
            type = "object",
            properties = {
                host = {type = "string"},
                port = {type = "integer"},
                metadata = {
                    type = "object",
                    properties = {
                        fail_timeout = {type = "integer", default = 1},
                        weigth = {type = "integer", default = 1},
                        max_fails = {type = "integer", default = 1}
                    },
                    default = {
                        fail_timeout = 1,
                        weigth = 1,
                        max_fails = 1
                    }
                }
            }
        }
    },

    required = {"servers"}
}

当然�Q�你需要区分每一个配�|�项是不是必填项�Q�非必传��w��要具有默认��|��以及上限或下限约束等�?/p>

下面需要在该模块启动时�q�行��用户配�|�是否错误，无法兼容、恢复错误的话，需要直接��用Lua内置错误日志接口输出�Q?/p>

error("Errr MSG")

另外�Q�若要引�?resty.worker.events �l��g�Q�不要提�?code>require�Q�比如在文�g头部提前声明�Ӟ��

loca  events = require("resty.worker.events")

启动后，��有可能在日志文件中出现如下异常�Q?/p>

2021/02/23 02:32:20 [error] 7#7: init_worker_by_lua error: /usr/local/share/lua/5.1/resty/worker/events.lua:175: attempt to index local 'handler_list' (a nil value)
stack traceback:
    /usr/local/share/lua/5.1/resty/worker/events.lua:175: in function 'do_handlerlist'
    /usr/local/share/lua/5.1/resty/worker/events.lua:215: in function 'do_event_json'
    /usr/local/share/lua/5.1/resty/worker/events.lua:361: in function 'post'
    /usr/local/share/lua/5.1/resty/worker/events.lua:614: in function 'configure'
    /usr/local/apisix/apisix/init.lua:94: in function 'http_init_worker'
    init_worker_by_lua:5: in main chunk

推荐做法是�g�q�加载，在该模块被加载时�q�行引用�?/p>

local events
local events_list

......

function _M.init_worker()
        ......
        events = require("resty.worker.events")
        events_list = events.event_list(
                "discovery_consul_update_application",
                "updating"
        )
        if 0 ~= ngx.worker.id() then
                events.register(discovery_consul_callback, events_list._source, events_list.updating)
                return
        end
        ......
end

单元��试依赖

单元��试代码的执行，会在你提交PR代码后自动执行持�l�集成行为内执行�?/p>

首先�Q�需要本机执行单元测试前�Q�需要提前准备好所需Docker��试实例�Q?/p>

docker run --rm --name consul_1 -d -p 8500:8500 consul:1.7 consul agent -server -bootstrap-expect=1 -client 0.0.0.0 -log-level info -data-dir=/consul/data
docker run --rm --name consul_2 -d -p 8600:8500 consul:1.7 consul agent -server -bootstrap-expect=1 -client 0.0.0.0 -log-level info -data-dir=/consul/data

docker run --rm -d \
       -e ETCD_ENABLE_V2=true \
       -e ALLOW_NONE_AUTHENTICATION=yes \
       -e ETCD_ADVERTISE_CLIENT_URLS=http://0.0.0.0:2379 \
       -e ETCD_LISTEN_CLIENT_URLS=http://0.0.0.0:2379 \
       -p 2379:2379 \
    registry.api.weibo.com/wesync/wbgw/etcd:3.4.9

然后�Q�安装项目依赖：

make deps

其次�Q�别忘记在apisix��目持箋集成脚本相应位置��d��相应依赖�?/p>

比如�Q�因为单元测试依赖于端口分别�?500�?600的两个Consul Server实例�Q�需要在执行单元��试之前提前�q�行�Q�因此你需要在对应的持�l�集成文件上��d��所需�q�行实例。比如其中一个位�|�：

无测试不�~�码

仅仅提供服务发现consul_kv.lua�q�一个文�Ӟ��是无法被仓库��理员采�U�的�Q�因为除了你自己以外�Q�别人无法确定你提交的代码所提供功能是否��_��让�h信服�Q�除非你能提供较为完整的 Test::Nginx 单元��试支持�Q�自我证明�?/p>

Test::Nginx 单元��试可能针对很多人来�Ԍ��是一个拦路虎�Q�但其实有些耐心�Q�你会发现它的美妙之处�?/p>

��单入门可参�?https://time.geekbang.org/column/article/109506 �Q�若只需要学习单元测试，其实不需要购买整个专辑的�Q�。在使用�q�程中需要参考在�U�文档：https://metacpan.org/pod/Test::Nginx::Socket �Q�需要一些耐心��p��一�Ҏ��间慢慢消化�?/p>

如何�q�行Nginx单元��试案例�Q�具体参看：
https://github.com/apache/apisix/blob/master/doc/zh-cn/how-to-build.md

至于Apisix定制部分单元��试部分�Q�可以直接参考已有的单元��试文�g卛_��?/p>

Consul KV服务发现的单元测试模块相对�\�?t/discovery/consul_kv.lua�Q�在�U�地址为： https://github.com/apache/apisix/blob/master/t/discovery/consul_kv.t 。该文�g大约500多行�Q�比真正的模�?code>consul_kv.lua代码行数�q�多。但比较完整覆盖了所能想到的所有场景，虽然写�v来虽然有些麻烦，但针对应用到�U�上大量业务的核心代码，无论多认真和谨慎都是不�ؓ�q�的�?/p>

以往针对关键核心模块的每一�ơ�P代，心里面大概有些忐忑七上八下吧�Q�也不太敢直接应用到�U�上。现在有了单元测试各�U�场景的覆盖辅助验证�q�代变更效果�Q�自信心是有了，也可以给别�h拍着胸脯保证修改没问题。当然若后箋发现隐藏的问题，直接��d��上对应的单元��试覆盖上即可�?/p>

我们�q�次只提供一个服务发现模块，因此只需要单独测�?code>consul_kv.t文�g卛_��Q?/p>

# prove -Itest-nginx/lib -I./ t/discovery/consul_kv.t
......
t/discovery/consul_kv.t .. ok
All tests successful.
Files=1, Tests=102, 36 wallclock secs ( 0.05 usr  0.01 sys +  0.78 cusr  0.41 csys =  1.25 CPU)
Result: PASS

出现��试案例��p�|问题�Q�可以去 apisix/t/servroot/logs 路径下查�?error.log 文�g暴露出的异常�{�问题�?/p>

有些一些测试用例需要组合一�l�较为复杂的使用场景�Q�比如我们准备一�l�后端节点：

127.0.0.1:30511�Q�输�?server 1
127.0.0.1:30512�Q�输�?server 2
127.0.0.1:30513�Q�输�?server 3
127.0.0.1:30514�Q�输�?server 4

�q�些节点��被频繁执行注册Consul节点然后再解除注册若�q��@环过�E�：清理注册 -> 注册 -> 解除注册 -> 注册 -> 解除注册 -> 注册 -> 解除注册 -> 注册 �Q�目的检验已解除注册的失效节�Ҏ��否还会存在内存中�{��?/p>

有些操作�Q�比如注册或解除注册节点�q�些操作�Q�网关的consul_kv.lua服务模块在物理层面需要wait一�Ҏ��间等待网��x��化这些变化，因此我们需要额外提供一�?/sleep 接口�Q�请求时需要故意休眠几�U�钟旉��{�待下一�ơ请求生效�?/p>

=== TEST 7: test register & unregister nodes
--- yaml_config eval: $::yaml_config
--- apisix_yaml
routes:
  -
    uri: /*
    upstream:
      service_name: http://127.0.0.1:8500/v1/kv/upstreams/webpages/
      discovery_type: consul_kv
      type: roundrobin
#END
--- config
location /v1/kv {
    proxy_pass http://127.0.0.1:8500;
}
location /sleep {
    content_by_lua_block {
        local args = ngx.req.get_uri_args()
        local sec = args.sec or "2"
        ngx.sleep(tonumber(sec))
        ngx.say("ok")
    }
}
--- timeout: 6
--- request eval
[
    "DELETE /v1/kv/upstreams/webpages/?recurse=true",
    "PUT /v1/kv/upstreams/webpages/127.0.0.1:30511\n" . "{\"weight\": 1, \"max_fails\": 2, \"fail_timeout\": 1}",
    "GET /sleep?sec=5",
    "GET /hello",

    "PUT /v1/kv/upstreams/webpages/127.0.0.1:30512\n" . "{\"weight\": 1, \"max_fails\": 2, \"fail_timeout\": 1}",
    "GET /sleep",
    "GET /hello",
    "GET /hello",

    "DELETE /v1/kv/upstreams/webpages/127.0.0.1:30511",
    "DELETE /v1/kv/upstreams/webpages/127.0.0.1:30512",
    "PUT /v1/kv/upstreams/webpages/127.0.0.1:30513\n" . "{\"weight\": 1, \"max_fails\": 2, \"fail_timeout\": 1}",
    "PUT /v1/kv/upstreams/webpages/127.0.0.1:30514\n" . "{\"weight\": 1, \"max_fails\": 2, \"fail_timeout\": 1}",
    "GET /sleep",

    "GET /hello?random1",
    "GET /hello?random2",
    "GET /hello?random3",
    "GET /hello?random4",

    "DELETE /v1/kv/upstreams/webpages/127.0.0.1:30513",
    "DELETE /v1/kv/upstreams/webpages/127.0.0.1:30514",
    "PUT /v1/kv/upstreams/webpages/127.0.0.1:30511\n" . "{\"weight\": 1, \"max_fails\": 2, \"fail_timeout\": 1}",
    "PUT /v1/kv/upstreams/webpages/127.0.0.1:30512\n" . "{\"weight\": 1, \"max_fails\": 2, \"fail_timeout\": 1}",
    "GET /sleep?sec=5",

    "GET /hello?random1",
    "GET /hello?random2",
    "GET /hello?random3",
    "GET /hello?random4",
]
--- response_body_like eval
[
    qr/true/,
    qr/true/,
    qr/ok\n/,
    qr/server 1\n/,

    qr/true/,
    qr/ok\n/,
    qr/server [1-2]\n/,
    qr/server [1-2]\n/,

    qr/true/,
    qr/true/,
    qr/true/,
    qr/true/,
    qr/ok\n/,

    qr/server [3-4]\n/,
    qr/server [3-4]\n/,
    qr/server [3-4]\n/,
    qr/server [3-4]\n/,

    qr/true/,
    qr/true/,
    qr/true/,
    qr/true/,
    qr/ok\n/,

    qr/server [1-2]\n/,
    qr/server [1-2]\n/,
    qr/server [1-2]\n/,
    qr/server [1-2]\n/
]

准备文档

除了代码能够正常�q��{�Q�我们还需要准备相应的Markdown文档辅助说明如何使用我们的模块，帮助�C�֌�用户更好使用它�?/p>

�C�֌�一般以英文文档为先�Q?只有在精力满��的情况下，可以补充中文文档�?/p>

下面��是要准备Markdown文档了，其文档�\径�ؓ�Q?code>doc/discovery/consul_kv.md�Q�单独的文档需要在其它已有文档挂接上对应链接，方便索引�?/p>

文档路径为：doc/discovery/consul_kv.md�Q�在�U�地址�Q?a >https://github.com/apache/apisix/blob/master/docs/en/latest/discovery/consul_kv.md

一般徏议需要在文档中能够清楚说明模块的使用方式�Q�以及注意事��，��其是配�|�参��C��用方式等。比如下面的配置��说明：

```yaml
discovery:
  consul_kv:
    servers:
      - "http://127.0.0.1:8500"
      - "http://127.0.0.1:8600"
    prefix: "upstreams"
    skip_keys:                    # if you need to skip special keys
      - "upstreams/unused_api/"
    timeout:
      connect: 1000               # default 2000 ms
      read: 1000                  # default 2000 ms
      wait: 60                    # default 60 sec
    weight: 1                     # default 1
    fetch_interval: 5             # default 3 sec, only take effect for keepalive: false way
    keepalive: true               # default true, use the long pull way to query consul servers
    default_server:               # you can define default server when missing hit
      host: "127.0.0.1"
      port: 20999
      metadata:
        fail_timeout: 1           # default 1 ms
        weight: 1                 # default 1
        max_fails: 1              # default 1
 ```
......

The `keepalive` has two optional values:

- `true`, default and recommend value, use the long pull way to query consul servers
- `false`, not recommend, it would use the short pull way to query consul servers, then you can set the `fetch_interval` for fetch interval

每一个文档都不应该成��Z��息孤岛，它需要在其它文档上挂载上一个连接地址�Q�因此我们需要在合适的地方�Q�比如需要在 doc/discovery.md最下面��d��链接地址描述�Q?/p>

## Discovery modules

- eureka
- [Consul KV](discovery/consul_kv.md)

模块代码�Q�测试文�Ӟ��以及文档�{�准备好了之后，下面��是准备提交代码到自�׃��库�?/p>

验证提交语法规范

所有内容准备好之后�Q�徏议执�?make lint �?make license-check 两个命��o��代码、markdown文档�{�是否满��项目规范要求�?/p>

# make lint
./utils/check-lua-code-style.sh
+ luacheck -q apisix t/lib
Total: 0 warnings / 0 errors in 133 files
+ find apisix -name '*.lua' '!' -wholename apisix/cli/ngx_tpl.lua -exec ./utils/lj-releng '{}' +
+ grep -E 'ERROR.*.lua:' /tmp/check.log
+ true
+ '[' -s /tmp/error.log ']'
./utils/check-test-code-style.sh
+ find t -name '*.t' -exec grep -E '\-\-\-\s+(SKIP|ONLY|LAST)$' '{}' +
+ true
+ '[' -s /tmp/error.log ']'
+ find t -name '*.t' -exec ./utils/reindex '{}' +
+ grep done. /tmp/check.log
+ true
+ '[' -s /tmp/error.log ']'
# make license-check
.travis/openwhisk-utilities/scancode/scanCode.py --config .travis/ASF-Release.cfg ./
Reading configuration file [.travis/ASF-Release.cfg]...
Scanning files starting at [./]...
All checks passed.

若检查出语法斚w��问题�Q�认真调��_��直到找不到问题所在�?/p>

�q�次PR提交之前�Q�忘记这回事了，会导致多了若�q�次�ơsubmit提交�?/p>

�W�三步，提交Pull Request

��d��|�：https://github.com/apache/apisix/pulls 新徏一�?code>New pull request�Q�后面将使用PR指代pull request�?/p>

PR标题格式

PR提交标题是规范要求的�Q�模板如下：

{type}: {desc}

其中{type}指代本次PR�c�d��Q�具体值如下，��量不要搞错�Q?/p>

feat�Q�新功能�Q�feature�Q?/li>
fix�Q�修补bug
docs�Q�文档（documentation�Q?/li>
style�Q?格式�Q�不影响代码�q�行的变动）
refactor�Q�重构（即不是新增功能，也不是修改bug的代码变动）
test�Q�增加测�?/li>
chore�Q�构��E�或辅助工具的变�?/li>
……

其中{desc}需要概括本�ơ提交内宏V�?/p>

比如�q�次标题为：feat: add consul kv discovery module�?/p>

填充PR内容

PR内容模板化，为标准的Github Markdown格式�Q�主要目的说明本�ơ提交内容，�C��如下�Q?/p>

### What this PR does / why we need it:



### Pre-submission checklist:

* [ ] Did you explain what problem does this PR solve? Or what new features have been added?
* [ ] Have you added corresponding test cases?
* [ ] Have you modified the corresponding document?
* [ ] Is this PR backward compatible? **If it is not backward compatible, please discuss on the [mailing list](https://github.com/apache/apisix/tree/master#community) first**

按照模板格式填写�Q�省心省力，如下�Q?/p>

### What this PR does / why we need it:

As I  mentioned previously in the mail-list, my team submit our `consul_kv` discovery module now.

More introductions here: 
 https://github.com/yongboy/apisix/blob/consul_kv/doc/discovery/consul_kv.md

### Pre-submission checklist:

* [x] Did you explain what problem does this PR solve? Or what new features have been added?
* [x] Have you added corresponding test cases?
* [x] Have you modified the corresponding document?
* [x] Is this PR backward compatible? **If it is not backward compatible, please discuss on the [mailing list](https://github.com/apache/apisix/tree/master#community) first**

认真接受评审和徏�?/h3>
提交PR之后�Q�才是一个开始，��L��?/p>
Apisix��目会自动针�Ҏ��们所提交内容执行持箋集成�Q?code>apisix��目的检查项很多�Q�比如针对Markdown格式��很严格�Q?/p>

持箋集成不通过�Q�按照要求微调吧�Q�也是标准化的要求�?/p>
我们在PUSH代码之前�Q��? `make lint` �?`make license-check` 两个命��o提前��还是十分有必要的，提前��语法等�?/p>
首先�Q�一定要��保持箋集成不能出错。持�l�集成通不�q�，说明我们的准备还不充分，�l�箋调整修改�Q��l�提交，一直到持箋集成完全执行成功为止�?/p>
保证持箋集成执行成功�Q�这是最基本的要求，否则�C�֌�无法��认我们的代码是否基本合根{�?/p>
放松心态，准备开始改�q�BUG�Q�以及接受社区的各种代码评审和改�q�意见吧�?/p>
其次�Q�就是要虚心接受�C�֌�代码评审和改�q�意见了�Q�这是最关键的一步�?/p>
下面是一些徏议：

真正代码BUG�Q�认真修�?

逻辑处理不合理的地方�Q�思考�ƈ�l�出一些处理思�\�Q�确定好之后开始调整即�?

有些提议可能会超出本�ơ提交范��_��说明原因�Q�给出拒�l�理由，可以婉拒嘛，比如可以攑֜�下一�ơ的提交中�?

若有遇到自己处理不了的问题，�U�极向社区寻求帮助吧�?/li>
针对一�Ҏ��修改再次提交后，会再�ơ执行持�l�集成，一��L��保持�l�集成不能够��p�|�Q�然后��l�等待下一轮的审核

认真对待每一个徏议，有则改之无则加勉�Q�不知不觉之间就�q�步了很多，代码质量也得��C��提升�?/p>
�l�过多次的微调，我们的服务发现核心模块基本上已趋于完善了一版，�q�已�l�和�q�没准备分��n出来之前的原始文件相比已�l�天差地别了 :))

下面是本�ơPR包含的多�ơ提交、代码评审以及答复等完整��程截图�Q?br/>
consul_kv模块一�ơPR完整��程

被合�q�到��d��支之后，有没有感觉到整个�C�֌�都在帮助我们一��h��q�，快不快哉 �Q?/p>

关于依赖��的处理

本次提交的服务发现模块依赖一个组�Ӟ��lua-resty-consul�Q�其仓库地址�Q?a >https://github.com/hamishforbes/lua-resty-consul�Q�最新版本�ؓ�Q�`0.3.2`。因为我们在实际部��v定制�Ӟ��直接下蝲了该文�g�Q�简单直接粗暴�?/a>

�?code>apisix��目针对��目依赖�Q�采用的 LuaRocks ��理�Q�在 2021-2-20 之前该组件托��在 https://luarocks.org/modules/hamish/lua-resty-consul 上面最新版本�ؓ 0.2-0�Q�这��很隑֊�了�?/p>

我的处理步骤如下�Q?/p>

首先我在github上面向作者提交一个求助：https://github.com/hamishforbes/lua-resty-consul/issues/20�Q?/a> 然而�ƈ没有在一两周旉��内没有等��C��者回�?/li>
无奈�Q�只好自己在 LuaRocks 单独提交一个暂时性的解决�Ҏ��Q?a >https://luarocks.org/modules/yongboy/lua-resty-consul-0.3.2�Q�在本次PR中直接包含了该组件��时地址
三周左右�Q�终于等到该�l��g作者提交最新版�?LuaRocks 站点�Q�既然官�Ҏ��C��Q�那��把服务发现模块里面的依赖修改�ؓ官方最新地址吧，再次提�h一个PR�Q?a >https://github.com/apache/apisix/pull/3654

有些一波三�?:))

�W�四步，关于后箋

一旦合�q�到��d��支后�Q�后�l�的演进整个�C�֌�都可以参与进来，可能有�h�?issue�Q�可能有人提 PR 修改�{�，后箋我们想�ؓ该模块��l�提交，那将是另外一个PR的事情�?/p>

我们可以�l�箋做以下事情：

�Ҏ��实际需要重�?/li>
若有人提Issue是，自然是Fixbug�Q�实践中遇到的Bug�Q�修复它
需要添加新的单元测试覆盖到新的�Ҏ�?/li>
若有需要，��需要添加新的文档进行描�q?/li>

毫无疑问�Q�这是一个良性��@环�?/p>

��结

参与�C�֌�开发的其它�c�d��提交�Q�可能会比上面所�q�简单很多，但大都可以看做是以上行�ؓ的一个子集�?/p>

参与开源，也会为我们打开一扇窗��P��去除自��n的狭隘。积极向�C�֌�靠拢�Q�这需要磨��M��些思维或认知的��p��Q�虚心认识到自我的不��I��q�不断调整不断进步�?/p>

加��a�Q?/p>

nieyong 2021-03-10 11:20 发表评论

Apisix 1.5 升��?2.2 �t�坑备忘

nieyong — Tue, 23 Feb 2021 06:57:00 GMT

零、前�a�

�U�上�q�行�?APISIX �?1.5 版本�Q�而社区已�l�发布了 Apisix 2.2�Q�是时候需要升�U�到最新版了，能够享受最版本带来的大量的BugFix�Q�性能增强�Q�以及新增特性的支持�{�~

从Apisix 1.5升��到Apisix 2.2�q�程中，不是一帆风��的�Q�中间踩了不��坑�Q�所谓前车之鉴后事之师，�q�里�l�大家简单梳理一下我们团队所在具体业务环境下�Q�升�U�过�E�中�t�的若干坑，以及一些需要避免的若干注意事项�{��?/p>

下文所说原先版本，皆指Apisix 1.5�Q�新版则是Apisix 2.2版本�?/p>

一、已有服务发现机制无法正常工�?/h2>
针对上游Upstream没有使用服务发现的�\由来�Ԍ��本次升��没有遇到什么问题�?/p>
公司内部�U�上业务大都��Z��Consul KV方式实现服务注册和服务发玎ͼ�因此我们自行实现了一�?`consul_kv.lua` 模块实现服务发现��程�?/p>
�q�在Apisix 1.5下面一切工作正常�?/p>
但在Apisix 2.2下面�Q�就无法直接工作了，原因如下�Q?/p>

服务发现配置指��o变了

上游对象包含服务发现旉��增加字段 `discovery_type` �q�行索引

2.1 服务发现配置指��o变了

原先�q�行中仅支持一�U�服务发现机�Ӟ��需要配�|�在 apisix层��下面�Q?/p>

apisix:
    ......
    discover: consul_kv
    ......

新版需要直接在config*.yaml文�g中顶层层�U�下�q�行配置�Q�可支持多种不同的�\由发现机�Ӟ��如下�Q?/p>

discovery:                      # service discovery center
  eureka:
    host:                       # it's possible to define multiple eureka hosts addresses of the same eureka cluster.
      - "http://127.0.0.1:8761"
    prefix: "/eureka/"
    fetch_interval: 30          # default 30s
    weight: 100                 # default weight for node
    timeout:
      connect: 2000             # default 2000ms
      send: 2000                # default 2000ms
      read: 5000

我们有所变通，直接在配�|�文仉��层配�|�consul_kv多个集群相关参数�Q�避�?discovery 层��q�深�?/p>

 discovery:
    consul_kv: 1
consul_kv:
  servers:
    -
      host: "172.19.5.30"
      port: 8500
    -
      host: "172.19.5.31"
      port: 8500
  prefix: "upstreams"
  timeout:
    connect: 6000
    read: 6000
    wait: 60
  weight: 1
  delay: 5
  connect_type: "long" # long connect
  ......

当然�Q�这仅仅保证了服务发现模块能够在启动时被正常加蝲�?/p>

2.2 upstream对象新增字段discovery_type

Apisix当前同时支持多种服务发现机制�Q�这个很赞。对应的代�h�Q�就是需要额外引�?discovery_type 字段�Q�用于烦引可能同时存在的多个服务发现机制�?/p>

�?Cousul KV方式服务发现��Z��Q�那么需要在已有�?upstream 对象中需要添加该字段�Q?/p>

"discovery_type" : "consul_kv"

原先的一�?code>upstream对象�Q�仅仅需�?service_name 字段属性指定服务发现相兛_��址卛_��Q?/p>

{
    "id": "d6c1d325-9003-4217-808d-249aaf52168e",
    "name": "grpc_upstream_hello",
    ......
    "service_name": "http://172.19.5.30:8500/v1/kv/upstreams/grpc/grpc_hello",
    "create_time": 1610437522,
    "desc": "demo grpc service",
    "type": "roundrobin"
}

而新版的则需要添�?code>discovery_type字段�Q�表明该service_name 字段对应的具体模块名�U�ͼ�效果如下�Q?/p>

{
    "id": "d6c1d325-9003-4217-808d-249aaf52168e",
    "name": "grpc_upstream_hello",
    ......
    "service_name": "http://172.19.5.30:8500/v1/kv/upstreams/grpc/grpc_hello",
    "create_time": 1610437522,
    "desc": "demo grpc service",
    "type": "roundrobin",
    "discovery_type":"consul_kv"
}

后面我们若支持Consul Service或ETCD KV方式服务发现机制�Q�则会非常弹性和清晰�?/p>

调整了配�|�指令，��d��上述字段之后�Q�后端服务发现其实就已经起作用了�?/p>

但gRPC代理路由�q�不会生�?#8230;…

二、gRPC当前不支持upstream_id

在我们的�pȝ��中，上游和�\由是需要单独分开��理的，因此创徏的HTTP或GRPC路由需要处理支�?code>upstream_id的烦引�?/p>

�q�在1.5版本中，grpc路由是没问题的，但到了apisix 2.2版本中，�l�护�?@spacewander 暂时没做支持�Q�原因是规划grpc路由和dubbo路由处理逻辑��于一��_��更�ؓ紧凑。从�l�护角度我是认可的，但作��Z��用者来�Ԍ��q�就有些不合理了�Q�直接丢弃了针对以往数据的支持�?/p>

作�ؓ当前Geek一些方式，�?apisix/init.lua 中，最��成�?�Q�优雅和成本成反比）修改如下�Q�找到如下代码：

    -- todo: support upstream id
    api_ctx.matched_upstream = (route.dns_value and
                                route.dns_value.upstream)
                               or route.value.upstream

直接替换��Z��面代码即可解决燃眉之急：

    local up_id = route.value.upstream_id
    if up_id then
        local upstreams = core.config.fetch_created_obj("/upstreams")
        if upstreams then
            local upstream = upstreams:get(tostring(up_id))
            if not upstream then
                core.log.error("failed to find upstream by id: " .. up_id)
                return core.response.exit(502)
            end
            if upstream.has_domain then
                local err
                upstream, err = lru_resolved_domain(upstream,
                                                    upstream.modifiedIndex,
                                                    parse_domain_in_up,
                                                    upstream)
                if err then
                    core.log.error("failed to get resolved upstream: ", err)
                    return core.response.exit(500)
                end
            end
            if upstream.value.pass_host then
                api_ctx.pass_host = upstream.value.pass_host
                api_ctx.upstream_host = upstream.value.upstream_host
            end
            core.log.info("parsed upstream: ", core.json.delay_encode(upstream))
            api_ctx.matched_upstream = upstream.dns_value or upstream.value
        end
    else
        api_ctx.matched_upstream = (route.dns_value and
                                route.dns_value.upstream)
                               or route.value.upstream  
    end

三、自定义auth插�g需要微�?/h2>

新版的apisix auth授权插�g支持多个授权插�g串行执行�Q�这个功能也很赞�Q�但此�D��D��了先前�ؓ具体业务定制的授权插件无法正常工作，�q�时需要微调一下�?/p>

原先调用方式�Q?/p>

    local consumers = core.lrucache.plugin(plugin_name, "consumers_key",
            consumer_conf.conf_version,
            create_consume_cache, consumer_conf)

因�ؓ新版�?code>lrucache不再提供 plugin 函数�Q�需要微调一下：

local lrucache = core.lrucache.new({
  type = "plugin",
})
......
    local consumers = lrucache("consumers_key", consumer_conf.conf_version,
        create_consume_cache, consumer_conf)

另一处是�Q�顺利授权之后，需要赋�?code>consumer相关信息�Q?/p>

    ctx.consumer = consumer
    ctx.consumer_id = consumer.consumer_id

此时需要替换成如下方式�Q��ؓ�Q�可能存在的�Q�后�l�的授权插�g�l�箋作用�?/p>

consumer_mod.attach_consumer(ctx, consumer, consumer_conf)

更多请参考：apisix/plugins/key-auth.lua 源码�?/p>

四、ETCD V2数据�q�移到V3

�q�移分�ؓ三步�Q?/p>

升��U�上已有ETCD 3.3.*版本�?.4.*�Q�满��x��版Apisix的要求，�q�时ETCD实例同时支持了V2和V3格式数据
�q�移V2数据到V3
- 因�ؓ数据量不是非常多�Q�我采取了一个非常简单和原始的方�?/li>
- 使用 etcdctl 完成V2数据到导�?/li>
- 然后使用文本�~�辑器vim�{�完成数据的替换�Q�生成etcdctl v3格式的数据导入命令脚�?/li>
- �q�行之后V3数据导入脚本�Q�完成V2到V3的数据导�?/li>
修改V3 /apisix/upstreams 中包含服务注册的数据�Q�一一��d�� "discovery_type" : "consul_kv"属�?/li>

��Z��以上操作之后�Q�从而完成了ETCD V2到V3的数据迁�U�R�?/p>

五、启动apisix后发现ETCD V3已有数据无法加蝲

我们在运�l�层面，使用 /usr/local/openresty/bin/openresty -p /usr/local/apisix -g daemon off; 方式�q�行�|�关�E�序�?/p>

�q�也��导��_��自动忽略了官�Ҏ��倡的�Q?code>apisix start 命��o自动提前为ETCD V3初始化的一些键值对内容�?/p>

因此�Q�需要提前�ؓETCD V3建立以下键值对内容�Q?/p>

Key                         Value
/apisix/routes          :   init_dir
/apisix/upstreams       :   init_dir
/apisix/services        :   init_dir
/apisix/plugins         :   init_dir
/apisix/consumers       :   init_dir
/apisix/node_status     :   init_dir
/apisix/ssl             :   init_dir
/apisix/global_rules    :   init_dir
/apisix/stream_routes   :   init_dir
/apisix/proto           :   init_dir
/apisix/plugin_metadata :   init_dir

不提前徏立的话，��׃��D��apisix重启后，无法正常加蝲ETCD中已有数据�?/p>

其实有一个补救措施，需要修�?apisix/init.lua 内容�Q�找到如下代码：

            if not dir_res.nodes then
                dir_res.nodes = {}
            end

比较geek的行为，使用下面代码替换一下即可完成兼容：

                if dir_res.key then
                    dir_res.nodes = { clone_tab(dir_res) }
                else
                    dir_res.nodes = {}
                end

六、apisix-dashboard的支�?/h2>
我们��Z��apisix-dashboard定制开发了大量的针对公司实际业务非常实用的企业�U�特性，但也��D��了无法直接升�U�到最新版的apisix-dashboard�?/p>
因�ؓ非常基础的上游和路由没有发生多大改变�Q�因此这部分升��的需求可以忽略�?/p>
实际上，只是在提交上游表单时�Q�包含服务注册信息JSON字符串中需要增�?`discovery_type` 字段和对应值即可完成支持�?/p>

七、小�l?/h2>
��p��了一些时间完成了从Apisix 1.5升��到Apisix 2.2的行为，虽然有些坑，但整体来�Ԍ��q�算��利。目前已�l�上�U��ƈ全量部��v�q�行�Q�目前运行良好�?/p>
针对�q�停留在Apisix 1.5的用��P��新版增加了Control API以及多种服务发现�{�新�Ҏ��支持，�q�是非常值得升��的�?/p>
升��之前�Q�不妨仔�l�阅��L��一个版本的升��日志�Q�地址�Q?a >https://github.com/apache/apisix/blob/2.2/CHANGELOG.md �Q�，然后需要根据具体业务做好兼�Ҏ��试准备和准备升��步骤�Q�这些都是非常有必要的�?/p>
针对我们团队来讲�Q�升�U�到最新版�Q�一斚w��降低了版本升�U�的压力�Q�另一斚w��也能够辅助我们能参与到开源社��Z��去，挺好~

nieyong 2021-02-23 14:57 发表评论

HTTP API设计�W�记

nieyong — Tue, 02 Jan 2018 12:53:00 GMT

前言

最�q�一�D�|��_��要�ؓ一个手机终端APP�E�序从零开始设计一整套HTTP API�Q�因为面向的用户很固定，一个新的移动端APP。目前还是项目初期，自然要求一切快速、从��Q�实用性�ؓ丅R�?/p>

下面��逐一��我们是如何设计HTTP API�Q�虽然相对大部分��言�Q�没有什么新意，但对我来说很新鲜的。避免忘��_��着�I�闲��快记录下来�?/p>

技术堆栈的选择

PHP嘛？团队内也没几个�h熟悉�?/p>

Java�Q�好几年没有��过了，那么复杂的解��x��案，再加上团队内也没什么�h�?……

团队使用�q�Lua�Q�基于OpenResty构徏�q�TCP、HTTP�|�关�{�，对Lua + Nginx�l�合非常熟悉�Q�能够快速的应用在线上环境。再说Lua语法��y、简单，一个新手半天就可以基本熟悉�Q�马上开工�?/p>

看来�Q�Nginx + Lua是目前最为适合我们的了�?/p>

HTTP API�Q�需要充分利用HTTP具体操作语义�Q�来应对具体的业务操作方法。基于此�Q�没有闭门造�R�Q�我们选择�?http://lor.sumory.com/ �q�么一个小巧的框架�Q�用于辅助HTTP API的开发开发�?/p>

嗯，OpenResty + Lua + Lor�Q�就构成了我们简单技术堆栈�?/p>

HTTP API��要设�?/h2>

HTTP API路径和语�?/h3>

每一具体业务逻辑�Q�直接在URL Path中体现出来。我们要的是��单快速，数据�l�构之间的连接关�p�，��可能的��L�E化。eg�Q?/p>

/resource/video/ID

比如用户反馈�q�一模块�Q�将使用下面比较固定的�\径：

/user/feedback

GET�Q�以用户�l�度查询反馈的历史列表，可分��?
- curl -X GET http://localhost/user/feedback?page=1
POST�Q�提交一个反�?
- curl -X POST http://localhost/user/feedback -d "content=hello"
DELETE�Q�删除一个或多个反馈�Q�参数附加在URL路径中�?
- curl -X DELETE http://localhost/user/feedback?id=1001
PUT�Q�更新评论内�?
- curl -X PUT http://localhost/user/feedback/1234 -d "content=hello2"

用户属性很多，用户�늧�只是其中一个部分，因此更新�늧��q�一行�ؓ�Q�HTTP�?PATCH �Ҏ��可更�_�և�的描�q�部分数据更新的业务需求：

/user/nickname

PATCH�Q�更新用��h��U�ͼ��늧�是用户属性之一�Q�可以��用更轻量�U�的 PATCH 语义
- curl -X PATCH http://localhost/user/nickname -d "nickname=hello2"

嗯，同一�cȝ��资源URL虽然固定了，但HTTP Method呈现了不同的业务逻辑需求�?/p>

HTTP API的访问授�?/h3>

实际业务HTTP API的访问是需要授权的�?/p>

传统的Access Token解决�Ҏ��Q�有session回话机制�Q�一般需要结合Web��览器，需要写入到Cookie中，或生产一个JSessionID用于标识�{�。这针对单纯面向�U�d��l�端的HTTP API后端来讲�Q��ƈ没有义务��d��q�一的兼容，略显冗余�?/p>

另外��是 OAUTH 认证了，有整套的认证�Ҏ��q�已工业化，很是成熟了，但对我们而言�q�是太重�Q�不太适合轻量�U�的HTTP API�Q�不太可能花费太多的�_�֊��d��它的�q�维工作�?/p>

最�l�选择了轻量��?Json Web Token�Q�非常紧凑，开��即用�?/p>

最佛_��法是把JWT Token攑֜�HTTP��h��头部中，不至于和其它参数��h��Q?/p>

curl -H "Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1aWQiOiI2NyIsInV0eXBlIjoxfQ.LjkZYriurTqIpHSMvojNZZ60J0SZHpqN3TNQeEMSPO8" -X GET http://localhost/user/info

下面是一副浏览器�D늚�一般认证流�E�，�q�与HTTP API认证大体一��_��

JWT的Lua实现�Q�推�? https://github.com/SkyLothar/lua-resty-jwt.git�Q�简单够用�?/p>

JWT和Lor的结�?/h3>

jwt需要和业务�q�行�l�定�Q�结�?lor �q�个API开发框架提供的中间件机�Ӟ��可在业务处理之前�Q�在合适位�|�进行权限拦截�?/p>

用户需要请求进行授权接口，比如登陆�{?/li>
服务器端会把用户标识�W�，比如用户id�{�，存入JWT的payload负荷中，然后生成Token字符�Ԍ��发给客户�?/li>
客户端收到JWT生成的Token字符�Ԍ��在后�l�的��h��中需要附加在HTTP��h��的Header�?/li>
完成认证�q�程

不同于OAUTH�Q�JWT协议�?strong>自包�?/strong>�Ҏ��，军_��了后端可以将很多属性信息存攑֜�payload负荷中，其token生成之后后端可以不用存储�Q�下�ơ客��L��发送请求时会发送给服务器端�Q�后端获取之后，直接验证卛_��Q�验证通过�Q�可以直接读取原先保存其中的所有属性�?/p>

下面梳理一下Jwt认证和Lor的结合�?/p>

全局拦截�Q�针�Ҏ��有PATH�Q�所有HTTP Method�Q�这里处理JWT认证�Q�若认证成功�Q�会直接把用户id注入到当前业务处理上下文中，后面的业务可以直接读取当前用��L��id�?/li>

app:use(function(req, res, next)
    local token = ngx.req.get_headers()["Authorization"]
    -- 校验��p�|�Q�err为错误代码，比如 400
    local payload, err = verify_jwt(token)
    if err then
        res:status(err):send("bad access token reqeust")
        return
    end

    -- 注入�q�当前上下文中，避免每次从token中获�?    req.params.uid = payload.uid

    next()
end)

针对具体路径�q�行讑֮�权限拦截�Q�较�_�粒度；比如 /user 只允许已登陆授权用户讉K��

app:use("/user", function(req, res, next)
    if not req.params.uid then
        -- 注意�Q�这里没有调用next()�Ҏ���Q�请求到�q�里���截止了�Q�不在匹配后面的路由
        res:status(403):send("not allowed reqeust")
    else
        next() -- 满��以上条�g�Q�那么���l�匹配下一个�\�?    end
end)

一�U�是较细�_�度�Q�具体到每一个API接口�Q�因��然URL一��_��但不同的HTTP Method有时��h��权限�q�是有区别的

local function check_token(req, res, next)
    if not req.params.uid then
        res:status(403):send("not allowed reqeust")
    else
        next()
    end
end

local function check_master(req, res, next)
    if not req.params.uid ~= master_uid then
        res:status(403):send("not allowed reqeust")
    else
        next()
    end
end

local lor = require("lor.index")
local app = lor()

-- 声明一个group router
local user_router = lor:Router()

-- 假设查看是不需要用��h��限的
user_router:get("/feedback", function(req, res, next)
end)

user_router:put("/feedback", check_token, function(req, res, next)
end)

user_router:post("/feedback", check_token, function(req, res, next)
end)

-- 只有���理员才有权限删�?user_router:delete("/feedback", check_master, function(req, res, next)
end)

-- 以middleware的�Ş式将该group router加蝲�q�来
app:use("/user", user_router())

......

app:run()

��Z��么没有选择GraphQL API �Q?/h2>
我们在上一个项目中对外提供了GraphQL API�Q�其�Q�在��试环境下）自��n提供文档输出自托��机�Ӟ��再结合方便的调试客户端，��实让后端开发和前端APP开发大大降低了频繁交流的频率，节省了若�q�流量，但前期还是需要较多的培训投入�?/p>
但在新项目中�Q�一度想提供GraphQL API�Q�遇到的问题如下�Q?/p>

全新的项目数据结构属性变动太频繁

普遍求快�Q�业务模型快速开发、调�?/li>
大家普遍对GraphQL API有些抵触�Q��用JSON输出格式的HTTP API是约定俗成的习惯选择

毫无疑问�Q�以最低成本快速构��为完整的APP功能�Q�HTTP API + JSON格式是最��服的选择�?/p>
虽然有些担心服务器端的输出，很多时候还是会��费掉一些流量，客户端�ƈ不能够有效的利用�q�回数据的所有字�D�属性。但和进度以及�h们已�l�习惯的HTTP API调用方式相比�Q�又微乎其微了�?/p>

��结

当前�q�一套HTTP API技术堆栈运行的�q�不错，希望能给有同样需要的同学提供一点点的参考�h�? :))

当然没有一成不变的架构模型�Q�随着业务的逐渐发展�Q�后面相信会有很多的变动。但�q�是以后的事情了�Q�谁知道呢，后面有空再次记录吧~

nieyong 2018-01-02 20:53 发表评论

Tsung�W�记之IP地址和端口限制突破篇

nieyong — Tue, 16 Aug 2016 13:17:00 GMT

前言

�?a href="http://www.tkk7.com/yongboy/archive/2016/07/26/431322.html">Tsung�W�记之压��端资源限制��?/a>中说到单一IP地址的服务器最多能够向外发�?4K个连接，�q�个已算是极限了�?/p>

但现在我�q�想�l�箋深入一下，如何�H�破�q�个限制�?�Q?/p>

如何�H�破限制

�q�部分就是要从多个方面去讨论如何如何�H�破限制单个IP的限制�?/p>

0. Tsung支持TCP情况

在Tsung 1.6.0 中支持的TCP属性有限，全部�Ҏ��如下：

protocol_options(#proto_opts{tcp_rcv_size = Rcv, tcp_snd_size = Snd,
                             tcp_reuseaddr = Reuseaddr}) ->
    [binary,
     {active, once},
     {reuseaddr, Reuseaddr},
     {recbuf, Rcv},
     {sndbuf, Snd},
     {keepalive, true} %% FIXME: should be an option
    ].

比如可以配置地址重用�Q?/p>

1. 增加IP地址

�q�是最为现实、最为方便的办法�Q�向�q�维的同事多甌��若干个IP地址��好。在不考虑其它因素前提下，一个IP地址可以对外建立64K个连接，多个IP��是N * 64K了。这个在Tsung中支持的很好�?/p>

增加IP可以有多�U�方式：

增加物理�|�卡方式�Q�一个网卡绑定一个IP地址
- 代�h�?/li>
一个网卡上�l�定多个可用的虚拟IP地址
- 比如 ifconfig eth0:2 10.10.10.102 netmask 255.255.255.0
- 虚拟IP必须是真实可用，否则收不到回包数�?/li>

要是没有��_��的可用虚拟IP地址供你使用�Q�或�怽�需要关注一下后面的IP_TRANSPARENT�Ҏ��描�q?:))

2. 考虑Linux内核新增SO_REUSEPORT端口重用�Ҏ�?/h4>

以被压测的一个TCP服务器�ؓ例，�l�箋拿网�l�四元组说事�?/p>

{SrcIp, SrcPort, TargetIp, TargetPort}

�U�上大部分服务器所使用的系�l��ؓCentOS 6�p�d��Q�所使用�pȝ��内核低于3.9
- {SrcIp, SrcPort} ��定了本地徏立一个连接的唯一性，本地地址的唯一�?/li>
- {TargetIp, TargetPort}的无法确定唯一�Q�仅仅标识了目的地址
Linux Kernel 3.9 支持 SO_REUSEPORT 端口重用�Ҏ�?- �|�络四元�l�中�Q��Q何一个元素值的变化都会成�ؓ一个全新的�q�接
- 真正让网�l�四元组一��L��成了一个网�l�连接的唯一�?/li>
- 理论上可以对外徏立的�q�接��C��赖于四个元素可变数�?/li>
- Total_connections = N_SrcIp * N_SrcPort * N_TargetIp * N_TargetPort

�U�上有部分服务器安装有CentOS 7�Q�其内核�?.10.0�Q�很自然支持端口重用�Ҏ��?/p>

针对只有一个IP地址的压��端服务器而言�Q�端口范围也��q��定了�Q�只能从目标服务器连接地址上去考虑。有两种方式�Q?/p>

目标服务器增加多个可用IP地址�Q�服务程序绑定指定端口即�?
- N个IP地址�Q�可用存�?64K * N
服务�E�序�l�定多个Port�Q�这个针对程序而言隑ֺ�不大
- 针对单个IP�Q�监听了M个端�?/li>
- 可用建立 64K * M 个连�?/li>
可用�q�样梳理 , Total_{1 ip connections} = 64K * N * M

啰嗦了半天，但目前Tsung�q�没有打��要提供支持呢，怎么办，自己动手丰衣��食吧：

https://github.com/weibomobile/tsung/commit/f81288539f8e6b6546cb9e239c36f05fc3e1b874

3. 透明代理模式支持

Linux Kernel 2.6.28提供IP_TRANSPARENT�Ҏ��，支持可以�l�定不是本机的IP地址。这�U�IP地址的绑定不需要显�C�的配置在物理网卡、虚拟网卡上面，避免了很多手动操作的�ȝ��。但是需要主动指定这�U�配�|�，比如下面的C语言版本代码

int opt =1;
setsockopt(server_socket, SOL_IP, IP_TRANSPARENT, &opt, sizeof(opt));

目前在最新即��打包的1.6.1版本中提供了对TCP的支持，也需要翻译成对应的选项�Q�以便在建立�|�络�q�接时��用：
�K?/p>

说明一下：
- IP_TRANSPARENT没有对应专门的宏变量�Q�其具体��gؓ19
- SOL_IP定义宏对应��|��0
- ��d��Socket选项通用格式为：{raw, Protocol, OptionNum, ValueSpec}

那么如何让透明代理模式工作呢？

3.1 启用IP_TRANSPARENT�Ҏ�?/h5>

...

3.2 配置可用的额外IP地址

那么�q�些额外的IP地址如何讄��呢？

可以为client元素手动��d��多个可用的IP地址
```
   
   
   ......
   
```
可以使用新增�?code>iprange�Ҏ�?/p>
```
    
  
```

但是需要确保：

�q�些IP地址目前都没有被已有服务器在使用

�q�且可以被正常绑定到物理/虚拟�|�卡上面

完全可用

3.3 配置路由规则支持

假设我们�?code>tsung_client1�q�台压测端服务器�Q�绑定所有额外IP地址到物理网�?code>eth1上，那么需要手动添加�\��p��则：

ip rule add iif eth1 tab 100
ip route add local 0.0.0.0/0 dev lo tab 100

�q�个支持压测端绑定同一�|�段的可用IP地址�Q�比如压��端IP�?72.16.247.130�Q?72.16.247.201暂时�I�闲的话�Q�那我们��可以��?72.16.89.201�q�个IP地址用于压测。此时不要求被压��的服务器配�|�什么�?/p>

3.4 �q�阶�Q�我们��用一个新的网�D�专用于��试

比如 10.10.10.0 �q�个�D늚�IP机房暂时没有使用�Q�那我们专用于压��用，�q�样一台服务器��有�?50多个可用的IP地址了�?/p>

压测端前面已�l�配�|�好了，现在需要�ؓ被压��的服务器添加�\��p��则，�q�样在响应数据包的时候能够�\由到压测端：

route add -net 10.10.10.0 netmask 255.255.255.0 gw 172.16.247.130

讄��完成�Q�可以通过route -n命��o查看当前所有�\��p��则：

�K?/p>

在不需要时�Q�可以删除掉�Q?/p>

route del -net 10.10.10.0 netmask 255.255.255.0

��结

梳理了以上所能够惛_��的方式，以尽可能�H�破单机的限�Ӟ��核心�q�是��可能找到��够多可用的IP地址�Q�利用Linux内核�Ҏ��支持，�E�序层面�l�定��可能多的IP地址�Q�徏立更多的对外�q�接。当然以上没有考虑�c�M��于CPU、内存等资源限制�Q�实际操作时�Q�还是需要考虑�q�些资源的限制的�?/p>

nieyong 2016-08-16 21:17 发表评论

Tsung�W�记�?00万用户压��执行步骤篇

nieyong — Mon, 08 Aug 2016 13:31:00 GMT

前言

��L��说细节、理论，会让��Z��胜其烦。我们��用Tsung来一��?00万用户压��的吧，或许能够引�v好多人的兴趣 :))

下面�Q�我�Ҏ��在公司分享的PPT《分布式百万用户压测你的业务》，贴出其中的关键部分，说明�q�行一��?00W(�?M)用户压测的执行步骤�?/p>

如何做分布式百万用户的压��?�Q?/h3>
假定面向��白用户�Q�因此才有了下面可执行的10个步骤用于开展分布式百万用户�?/p>
�K?/p>
看着步骤很多�Q�一旦熟悉�ƈ掌握之后�Q�中间可以省却若�q�Ӏ?/p>

1. 阅读Tsung文档

�K?/p>

��大家在��用Tsung之前�Q�花费一�Ҏ��间阅��d��整个用户手册�Q�虽然是英文的，阅读��h��也不复杂。读完之后，我们也就知道如何做测试了�Q�遇到的大部分问题，也能够在里面扑ֈ��{�案�?/p>

官网�Q?a >http://tsung.erlang-projects.org/
在线手册�Q?a >http://tsung.readthedocs.io/en/latest/index.html

2 ��定压测目标

�K?/p>

要对�U�上�pȝ��压测100万用��P��Z��可能降低线上服务器负蝲压力�Q�这里设�|�每�U��?00个用��P��在60分钟内��生完�?/li>
要压��的服务器所填写�|�络讉K��地址可以�Ҏ��需要填写多�?/li>

3. 计算所需要从机数�?/h4>
�K?br/> �K?br/> �K?br/> �K?br/> �K?br/> �K?/p>

Tsung��Z��从模型，我们启动了主节点之后�Q�主节点会按需启动从节�?/li>
讑֮�所用服务器可用内存大于3G�Q��ƈ且都只有一个IP地址

一��C��机可用模�?万用��P��需�?7��C��?/li>
若资源充��I��可以��用几台服务器，配置多个IP地址

扑ֈ�所需要的压测用服务器�Q�在资源层面满��试��试集群需要，�q�个是关�?/li>

4. 部��vTsung

�K?/p>

因�ؓTsung依赖于Erlang�Q�因此需要首先安装：

wget https://packages.erlang-solutions.com/erlang-solutions-1.0-1.noarch.rpm
rpm -Uvh erlang-solutions-1.0-1.noarch.rpm
sudo yum install erlang

然后再是安装Tsung�Q�徏议直接��用Tsung 1.6.0修改版，主要提供IP只连支持�Q�具体细节，可参考这�?http://www.tkk7.com/yongboy/archive/2016/07/28/431354.html �Q�：

git clone https://github.com/weibomobile/tsung-1.6.0.git
./configure --prefix=/usr/local
make install

5. 下蝲SSH替代者－`tsung—rsh`

�K?/p>

��Z��么要替换掉SSH�Q�主要原因：

SSH在一般网�l�机房环境内服务器之间被��止�q�接通信�Q�这会导致主节点无法启动从节点，无法建立分布式压��集��?/li>
��q��是SSH没被��用�Q�主从之间需要设�|�免�U�钥SSH��d��方式�Q�十分麻�?/li>

可进一步参考：Tsung�W�记之分布式增强跛_��SSH��绊��?/a>�?/p>

6. �~�写压测内容

�K?br/> �K?br/> �K?/p>

要把业务定义的所有会话内容完整的整理映射成Tsung的会话内容，因�ؓ用户行�ؓ很复杂，也需要我们想法设法去模拟�?/p>

其实�Q�演�C�所使用的是�U�有协议�Q�可以参�?Tsung�W�记之插件编写篇 �?/p>

当完成压��会话内容之后，users_100w.xml文�g已经填写完毕�Q�我们可以开始压��了�?/p>

7. �q�行Tsung

�K?/p>

-F 10.10.10.10 主节点IP地址�Q�IP直连�Ҏ�?/li>
-rsh rsh_client.sh �q�程�l�端�Q�SSH通道被替�?/li>
-s 压测端启用erlang smp�Ҏ��，按需使用所有CPU核心

我们启动了从节点�Q�然后从节点被启动，开始执行具体压��Q务了�?/p>

8. 压测�q�程中，我们该做什�?/h4>
�K?/p>
紧密��x��服务器服务状态、资源占用等情况��对了，最好还要作��Z��个终端用户参与到产品体验中去�?/p>

9. 压测�l�束�Q�生成Tsung报表

�K?/p>

Tsung压测�l�束之后�Q�不会主动生成压��结果报表的�Q�需要借助�?tsung_stats.pl perl脚本生成�Q�要查阅可借助python生成临Web站点�Q�浏览器打开卛_��?/p>

10. 回顾和�ȝ��

�K?/p>

��结

其实�Q�一旦熟悉�ƈ掌握Tsung之后�Q�步�?-6都可以节省了�Q��@环执行步�?-10�?/p>

你若以�ؓ仅仅只是谈论Tsung如何�?M用户压测�Q�那��错了，只要机器资源够，�q�个目标��很�Ҏ��实现。我们更应该��x��Q�我们压��的目的是什么，我们应该��x��什么，�q�个应该形成一个完整可循环�q�程�Q�驱动着�pȝ��架构健康先前发展�?/p>

nieyong 2016-08-08 21:31 发表评论

Tsung�W�记之插件编写篇

nieyong — Sat, 30 Jul 2016 11:37:00 GMT

前言

Tsung对具体协议、通道的支持，一般以插�g形式提供接口�Q�接口不是很复杂�Q�插件也很容易编写，支持协议多，也就不��为怪了�?/p>

下面首先梳理一下当前Tsung 1.6.0所有内�|�插�Ӟ��然后��Z��个名�U�CؓQmsg的私有二�q�制协议�~�写插�g, �q�行Qmsg服务器端�E�序�Q�执行压力测试，最后查看测试报告�?/p>

已支持插件梳�?/h3>
Tsung 1.6.0支持的协议很多，��单梳理一下：

�K?/p>

压测的协议首先需要支持xml形式配置�Q�配�|�内定w��?`tsung_config_protocolname` 模块解析

存放在tsung_controller目录�?/li>

其次是tsung client端也要插�?`ts_protocolname` 模块支持数据操作

存放在tsung目录�?/li>

同时在tsung��目examples目录下也�l�出了已支持协议配置��单示范xml文�g

已经支持协议��单说明：

amqp�Q�Advanced Message Queuing Protocol�~�写�Q�只要支持高�U�消息队列协议的应用�Q�都可以用来做压��，比如RabbitMQ�Q�ActiveMQ�{?/li>
http�Q�基本协议，构徏于HTTP协议之上的，�q�有�c�M��于BOSH�Q�WebDav�{�上层业务协�?/li>
jabber�Q�也�U�C��为XMPP�Q�支持的相当丰富�Q�除了TCP/SSl�Q�还可以通过Websocekt�q�行传�?/li>
raw�Q�针对原始类型消息，不做�~�解码处理，直接在TCP / UDP / SSL�{�传输层中传递，�q�个寚w��分私有协议，比较友好�Q�不用写单独的编解码处理�Q�直接透传好了

shell�Q�针对LInux/Unix�l�端命��o调用�q�行压测�Q�这�U�场景比较小�?/li>
fs�Q�filesystem�~�写�Q�针�Ҏ��件系�l�的��d��性能�q�行压测

job�Q�针对�Q务调度程序进行的压测�Q�比如PBS/torqueLSF、OAR�{?/li>

Tsung插�g工作机制

�_�一�Ҏ��看Tsung插�g的工作流�E�（点击可以看大图）�Q?/p>

�K?/a>

攑֤�一些（引用 hncscwc 博客囄��Q�相当赞�Q�）�Q?/p>

��Z��么要�~�写插�g

Tsung针对通用协议有支持，若是�U�有或不那么通用的协议，��׃��会有专门的插件支持了�Q�那么可选的有两条�\子：

使用raw模式发送原始消息，需要自行组�?/li>
自己�~�写插�g�Q�灵�z�d��理编解码

既然谈到了插�Ӟ��我们也编写一个插件也体验一下编写插件的�q�程�?/p>

Qmsg协议定义

假设一个虚拟场景，打造一个新的协议Qmsg�Q�二�q�制格式�l�成�Q?/p>

�K?/p>

�q�种随意假象出来的格式，不妨�U�C��?strong>qmsg�Q�Q可爱形式的message�Q�协议，仅作为Demo演示而存在。简单场景：

用户发言�Q�包含用户id和发�a�内容
- User ID�Q?2位自然数�c�d��
- 发言为文字内容，字符串�Ş式，长度不固�?/li>
- �l�装后的��h��体�ؓ二进制协议格�?/li>
- PocketLen:**##UserId + UserComment##**
服务器端�q�回用户ID和一个幸�q�数�?32位表�C?
- PocketLen:**##UserId + RandomCode##**

��Z��卡哇伊一些，多了一些点�~�的�?*####**”符受��?/p>

�~�写一个完整插�?/h3>
�q�里��Z��Tsung 1.6.0版本构徏一个Qmsg插�g�Q�假定你懂一些Erlang代码�Q�以及熟悉Tsung一些基本概��c�?/p>

0. 创徏一个项�?/h4>

要创建Tsung的一个Qmsg插�g��目�Q�虽没有固定规范�Q�但按照已有格式�l�织好代码层�U�也是有必要的�?/p>

├── include
│ �?└── ts_qmsg.hrl
├── src
│ �?├── tsung
│ �?│ �?└── ts_qmsg.erl
│ �?└── tsung_controller
│ �?    └── ts_config_qmsg.erl
└── tsung-1.0.dtd

1. 创徏配置文�g

Tsung的压��以xml文�g驱动�Q�因此需要界定一个Qmsg插�g形式的完整会话的XML呈现�Q�比如：


    
      Hello Tsung Plugin
    

    
      This is a Tsung Plugin

ts_qmsg�Q�会话类型所依赖协议模拟客户端实�?/li>
Text 定义了qmsg会话可配�|��Ş式，内嵌�?code>request元素�?/li>
uid为属�?/li>

此时�Q�你若直接在xml文�g中编辑，会遇到校验错误�?/p>

2. 更新DTD文�g

Tsung的xml文�g依赖tsung-1.0.dtd文�g�q�行校验配置是否有误�Q�需要做对DTD文�g做修改，以支持所��d��新的协议�?/p>

�?code>tsung-1.0.dtd��目中，最��支持：

session元素type属性中��d��?ts_qmsg
request元素处添�?qmsg :
��d��qmsg元素定义�Q?/li>

完整内容�Q�可参�?code>tsung_plugin_demo/tsung-1.0.dtd文�g�?/p>

3. 头文�?`include/ts_qmsg.hrl`

头文�?code>include/ts_qmsg.hrl定义数据保存的结构（也称之�ؓ记录/record�Q�：

-record(qmsg_request, {
          uid,
          data
         }).

-record(qmsg_dyndata, {
          none
         }
       ).

qmsg_request: 存储从xml文�g解析的qmsg��h��数据�Q�用于生成压力请�?/li>
qmsg_dyndata: 存储动态参敎ͼ�当前暂未使用刎ͼ�

4. XML文�g解析

ts_config_qmsg.erl文�g�Q�用于解析和协议Qmsg兌��的配�|�：
- 只需要实�?code>parse_config/2唯一�Ҏ��
- 解析xml文�g中所配置Qmsg协议��h��相关配置
- �?code>ts_config:parse/1在遇到Qmsg协议配置时调�?/p>

备注�Q?/p>

若要支持动态替换，需要的字段以字�W�串形式��d��存储

5. `ts_qmsg.erl`

ts_qmsg.erl模块主要提供Qmsg协议的编解码的完整动�? 以及当前协议界定下的用户会话属性设定�?/p>

首先需要实现接�?code>ts_plugin规范定义的所有需要函敎ͼ�定义了参数值和�q�回倹{�?/p>

-behavior(ts_plugin).

...

-export([add_dynparams/4,
         get_message/2,
         session_defaults/0,
         subst/2,
         parse/2,
         parse_bidi/2,
         dump/2,
         parse_config/2,
         decode_buffer/2,
         new_session/0]).

相对来说�Q�核心�ؓ协议的编解码功能�Q?/p>

get_message/2�Q�构造请求数据，�~�码成二�q�制�Q�上�?code>ts_client模块通过Socket�q�接发送给目标服务�?/li>
parse/2�Q?当对响应作出校验�?从原始Socket上返回的数据�q�行解码�Q�取出协议定义业务内�?/li>

�q�部分代码可以参�?tsung_plugin_demo/src/tsung/ts_client.erl 文�g�?/p>

6. 如何�~�译

虽然理论上可以单独编�Q�生成的beam文�g直接拯��到已�l�安装的tsung对应目录下面�Q�但实际上插件编写过�E�中要依赖多个tsung的hrl文�g�Q�这造成了依赖�\径问题。采用直接和tsung打包一起部�|Ԍ��实际操作上有些麻烦，

��Z��节省体力�Q��用一个shell脚本 - build_plugin.sh�Q�方便快速编译、部�|Ԍ��

# !/bin/bash

cp tsung-1.0.dtd $1/
cp include/ts_qmsg.hrl $1/include/
cp src/tsung_controller/ts_config_qmsg.erl $1/src/tsung_controller/
cp src/tsung/ts_qmsg.erl $1/src/tsung/

cd $1/
make uninstall
./configure --prefix=/usr/local
make install

�q�里指定安装Tsung的指定目录�ؓ/usr/local�Q�可以根据需要修�?/p>

需要提前准备好tsung-1.6.0目录�Q?/p>

wget http://tsung.erlang-projects.org/dist/tsung-1.6.0.tar.gz
tar xf tsung-1.6.0.tar.gz

在编译Qmsg插�g脚本�? 指定一下tsung-1.6.0解压后的路径卛_��Q?/p>

sh build_plugin.sh /your_path/tsung-1.6.0

后面嘛，��q��着自动�~�译和安装呗�?/p>

启动Qmsg协议的压��?/h3>

1. 首先启动Qmsg服务器端�E�序

既然有压��端�Q�就需要一个Qmsg协议处理的后端程�?code>qmsg_server.erl�Q�用于接收客��L��h��Q�获得用户ID��g��后，生成一个随机数字，�l�装成二�q�制协议�Q�然后发�l�客��L��Q�这��是全部功能�?/p>

�q�个�E�序�Q�简单一个文�Ӟ��?tsung_plugin_demo目录下面�Q�编译运�? 默认监听5678端口�Q?/p>

erlc qmsg_server.erl && erl -s qmsg_server start

另外�Q�还提供了一个手动调用接口，方便在Erlang Shell端调试：

%% 下面�?qmsg_server:sendmsg(1001, "�q�里是用户发�a�").

启动之后�Q�监听地址 *: 5678

源码见：tsung_plugin_demo/qmsg_server.erl

2. �~�写Qmsg压测XML配置文�g

因�ؓ是演�C�示范，一台Linxu��L��上就可以�q�行了：

�q�接本机�?127.0.0.1:5678
最多��?0个用��P��每秒产生1个，压力负蝲讄��的很�?/li>
两个不同�c�d��会话�Q�比�?0% + 90% = 100%
qmsg-subst-example会话使用了用户ID个和用户发言内容自动生成机制


  
    
  

  
    
  

  
    
      
    
  

  
    
      
        Hello Tsung Plugin Qmsg!
      
    
    
      
        
      
      
        
      
      
        Haha : %%_random_txt%%
      
      
      
        This is a Tsung Plugin

�q�部分内容，请参�?tsung_plugin_demo/tsung_qmsg.xml 文�g�?/p>

3. 执行压力��试

当Qmsg的压力测试配�|�文件写好之后，可以开始执行压力测试了�Q?/p>

tsung -f tsung_qmsg.xml start

其输出：

tarting Tsung
Log directory is: /root/.tsung/log/20160621-1334
[os_mon] memory supervisor port (memsup): Erlang has closed
[os_mon] cpu supervisor port (cpu_sup): Erlang has closed

其中, 其日志�ؓ�Q?code>/root/.tsung/log/20160621-1334�?/p>

4. 查看压测报告

�q�入其生成压��日志目录，然后生成报表�Q�查看压��结果哈�Q?/p>

cd /root/.tsung/log/20160621-1334

/usr/local/lib/tsung/bin/tsung_stats.pl

echo "open your browser (URL: http://IP:8000/report.html) and vist the report now :))"
/usr/bin/python -m SimpleHTTPServer

嗯，打开你的��览器，输出所在服务器的IP地址�Q�就可以看到压测�l�果了�?/p>

��结

以上代码已经攑օ�github仓库�Q?a >https://github.com/weibomobile/tsung_plugin_demo�?/p>

实际业务的私有协议内容要比上面Demo出来的Qmsg复杂的多�Q�但其私有协议插件编写，如上面所�q�几个步骤，按照规范�~�写�Q�单机测试，然后延��到分布式集群�Q�完整流�E�都是一致的�?/p>

嗯，搞定了插�Ӟ��可以对�pȝ��愉快地进行压��了 :))

nieyong 2016-07-30 19:37 发表评论

Tsung�W�记之监控数据收集篇

nieyong — Fri, 29 Jul 2016 00:49:00 GMT

前言

压力��试和监控分不开�Q�监控能够记录压��过�E�中状态，方便问题跟踪、定位。本��我们将讨论对压��客��L��tsung client的监控，以及对被压测服务器的资源占用监控�{�。同�Ӟ��也涉及到Tsung�q�行时的实时诊断方式�Q�这也是对Tsung一些运行时状态的��d��监控�?/p>

压测客户端的监控

压测端（指的是tsung client�Q�会攉��每一个具体模拟终端用��P��即ts_client模块�Q�行为数据，发送给主节点（tsung_controller�Q�，供后面统计分析��用�?/p>

�K?/p>

ts_client模块调用ts_mon�Q�而ts_mon又直接调用ts_mon_cache�Q�有些绕�Q�不直观�Q�逻辑层面可忽略掉ts_mon�Q?/li>
count��数器�Q�sum表示各项累加��|��sample和sample_counter计算一�ơ统计项的��^均�?amp;标准�?/li>
tsung.dump文�g一般不会创�?amp;写入�Q�除非你在tsung.xml文�g中指定需要dump属性�ؓtrue�Q�压��数据量大时�q�个会媄响性能
match.log仅仅针对HTTP��h��Q�默认不会写入，除非在HTTP压测指定
```
     
     
```
从节点tsung client所记录日志、需要dump的请�?响应数据�Q�都会交由tsung_controller处理
ts_mon_cache�Q�接收到数据�l�计内存计算�Q�每500毫秒周期分发�l�后�l�模块，起到�~�冲作用
ts_stats_mon模块接收数据�q�行内存计算�Q�结果写入由ts_mon触发
ts_mon负责�l�计数据最�?0�U�定时写入各��统计数据到tsung.log文�g�Q�非实时�Q�可避免��盘IO开销�q�大问题
- tsung/src/tsung_controller/tsung_controller.app.in 对应 {dumpstats_interval, 10000}
- 可以在运行时修改
tsung.log文�g汇集了客��L��q�接、请求、完整会话、页面以及每一��的sum操作�l�计的完整记录，后箋perl脚本报表分析��Z��?/p>
ts_mon模块处理tsung.log的最核心模块�Q�全局唯一�q�程�Q�标识�ؓ{global, ts_mon}

比如某次单机50万用户压��tsung.log日志片段�Q?/p>

# stats: dump at 1467620663
stats: users 7215 7215
stats: {freemem,"os_mon@yhg162"} 1 11212.35546875 0.0 11406.32421875 11212.35546875 11346.37109375 2
stats: {load,"tsung_controller@10.10.10.10"} 1 0.0 0.0 0.01171875 0.0 0.01171875 2                                                                                 17,1          Top
stats: {load,"os_mon@yhg162"} 1 2.3203125 0.0 3.96875 0.9609375 2.7558736313868613 411
stats: {recvpackets,"os_mon@yhg162"} 1 5874.0 0.0 604484 5874 319260.6024390246 410
stats: {sentpackets,"os_mon@yhg162"} 1 8134.0 0.0 593421 8134 293347.0707317074 410
stats: {cpu,"os_mon@yhg162"} 1 7.806645016237821 0.0 76.07377357701476 7.806645016237821 48.0447587419309 411
stats: {recvpackets,"tsung_controller@10.10.10.10"} 1 4164.0 0.0 45938 4164 24914.798543689314 412
stats: {sentpackets,"tsung_controller@10.10.10.10"} 1 4182.0 0.0 39888 4182 22939.191747572815 412
stats: {cpu,"tsung_controller@10.10.10.10"} 1 0.575191730576859 0.0 6.217097016796189 0.575191730576859 2.436491628709831 413
stats: session 137 2435928.551725737 197.4558174045777 2456320.3908691406 2435462.9838867188 2436053.875557659 499863
stats: users_count 0 500000
stats: finish_users_count 137 500000
stats: connect 0 0 0 1004.4912109375 0.278076171875 1.480528250488281 500000
stats: page 139 12.500138756182556 1.1243565417115737 2684.760009765625 0.43115234375 16.094989098940804 30499861
stats: request 139 12.500138756182556 1.1243565417115737 2684.760009765625 0.43115234375 16.094989098940804 30499861
stats: size_rcv 3336 3386044720
stats: size_sent 26132 6544251843
stats: connected -139 0
stats: error_connect_timeout 0 11

tsung.log日志文�g可由tsung_stats.pl脚本提取、分析、整理成报表展示�Q�其报表的一个摘要截图：

�K?/p>

异常行�ؓ的收�?/h4>
当模拟终端遇到网�l�连接超时、地址不可辄��异常事�g�Ӟ��最�l�也会发�l�主节点的ts_mon模块�Q�保存到tsung.log文�g中�?/p>
�q�种异常记录�Q�关键词前缀�?`error_`�Q?/p>

比如ts_client模块遇到�q�接��时会汇�?code>error_connect_timeout错误

�pȝ��的可用端口不够用�Ӟ��创徏与压��服务器�q�接数超出可用段限制�Q�上�?code>error_connect_eaddrinuse错误

Errors报表好比客户端出现问题晴雨表�Q�再加上tsung输出log日志文�g�Q�很清楚的呈现压��过�E�中出现的问题汇集，方便问题快速定位�?/p>
�K?/p>

被压��服务器的监�?/h3>
当前tsung提供�?�U�方式进行监控目标服务器资源占用情况�Q?/p>

erlang

snmp

Munin

大致交互功能�Q�粗略��用一张图表示�Q?/p>
�K?/p>

tsung_controller主节点会被强制启用监�?/li>
SNMP方式�Q�客��L��作�ؓ代理��d��注册�q�连接开放SNMP的服务器�Q�SNMP安装针对新手来说比较复杂

Munin采用C/S模式�Q�自�w�要作�ؓ客户端连接被压测服务器上能够安装Munin Server

erlang方式�Q�本�w�代理�Ş式监控服务器资源占用�Q�满��x��件很��单：

需要能够自动登录连�?/li>
�q�且安装有Erlang�q�行时环境，tsung_controller方便启动监控节点

采用�q�程加蝲方式业务代码�Q�省去被监控端部�|�的�ȝ��

现实情况下，我一般采用一个脚本搞定自动部�|�监控部�|�客��L��Q�自动打包可�U�L��的Erlang�Q�简单绿�Ԍ��部��v方便

提供监控采样数据包括 CPU/Memory/Load/Socket Sent&Recv

所有监控数据都会被发送给ts_mon模块�Q��ƈ定时写入到tsung.log文�g�?/li>

看一个最�l�报表部分呈现吧�Q?/p>
�K?/p>
tsung�Ҏ��务器监控采样手机数据不是很丰富，因�ؓ它面向的更�ؓ通用的监控需求�?/p>
更深层次、更�l�粒度资源监控，��需要自行采集、自行分析了�Q�一般在商业产品在这斚w��会有更明��需求�?/p>

日志攉��

和前面讲到的�l�端行�ؓ数据采集和服务器端资源监控行为类��|��tsung�q�行�q�程中所产生日志被存储到主节炏V�?/p>

tsung使用error_logger记录日志�Q�主节点tsung_controller启动之后�Q�会�q�发启动tsung client从节点，换句话来说tsung client从节�Ҏ��׃��节点tsung_controller创徏�Q�这个特性决定了tsung client从节点��用error_logger记录的日志都会被重定向到主节点tsung_controller所在服务器上，�q�个是由Erlang自��n独特机制军_��?/p>

因此�Q�你在主节点log目录下能够看到具体的日志输出文�g�Q�也��水到渠成了。因为Erlang天生分布式基因，从节点error_logger日志输出透明重定向到主节点，不费吹灰之力。这在其他语�a�看来�Q�确实完全不可能��L��实现的�?/p>

��Z��error_logger包装日志记录�Q�需要一个步骤：

讄��输出到文件系�l�中 error_logger:tty(false)
讑֮�输出的文件目�?error_logger:logfile({open, LogFile})
包装日志输出接口 ?DEBUG/?DEBUGF/?LOG/?LOGF/
最�l�调用包装的error_logger接口

debug(From, Message, Args, Level) ->
    Debug_level = ?config(debug_level),
    if
        Level =< Debug_level ->
            error_logger:info_msg("~20s:(~p:~p) "++ Message,
                                  [From, Level, self()] ++ Args);
        true ->
            nodebug
    end.

和大部分日志框架讑֮�的日志等�U�一��_��emergency > critical > error > warning > notice (default) > info > debug�Q�从左到叻I��依次递减�?/p>

需要注意事��，error_logger语义��录错误日志，只适用于真正的异常情况�Q��ƈ不期望过多的消息量的处理�?

若当一般业务调试类型日志量�q�多�Ӟ��不但耗费了大量内存，�|�络/��盘写入速度跟不上生产速度�Ӟ��会导致进�E�堵塞，严重会拖累整个应用僵死，因此需要在tsung.xml文�g中设�|�至��info�U�别�Q�至��默认的notice��很合适�?/p>

Tsung�q�行时诊�?监控

Tsung在运行时�Q�我们可以remote shell方式�q�接��d��q�去�?/p>

��Z��q�接方便�Q�我写了一个脚�?connect_tsung.sh�Q�只需要传入tsung节点名称卛_��Q?/p>

# !/bin/bash
## 讉K���q�程Tsung节点 sh connect\_tsung.sh tsung\_controller@10.10.10.10

HOST=`ifconfig | grep "inet " | grep -v "127.0.0.1" | head -1 | awk '{print $2}' | cut -d / -f 1`
if [ -z $HOST ]; then
    HOST = "127.0.0.1"
fi
erl -name tmp\_$RANDOM@$HOST -setcookie tsung -remsh $1

需要安装有Erlang�q�行时环境支�?/p>

当然�Q�要向运行脚本，你得知道Tsung所有节点名�U��?/p>

如何获得tsung节点名称

其实有两�U�方式获得Tsung节点名称�Q?/p>

直接�q�接tsung_controller节点获得
- 若是IP形式�Q?code>sh connect_tsung.sh tsung_controller@10.10.10.10
- 若是hostname形式�Q�可以这��P��sh connect_tsung.sh tsung_controller@tsung_master_hostname
- 成功�q�入之后�Q�输�?nodes(). 可以获得完整tsung client节点列表
启动tsung时生成日志所在目录，可以看到�c�M��日志文�g�Q?
- tsung client端��生日志单独存放，格式�?code>节点名称.log
- eg: tsung15@10.10.10.113.log�Q�那么节点名�U�Cؓtsung15@10.10.10.113
- 可以直接�q�接�Q?code>sh connect_tsung.sh tsung15@10.10.10.ll3

如何诊断/监控Tsung�q�行�?/h4>

其实�Q�这里仅仅针对��用Erlang�q�且对Tsung感兴��的同学�Q�你都能够进来了�Q�那么如何进行查看、调试运行时tsung�pȝ��q�行情况�Q�那么就很简单了。推荐��?recon 库，包括内存占用�Q�函数运行堆栈，CPU资源分配�{�，一目了然�?/p>

若问�Q�tsung启动时如何添加recon依赖�Q�也不复杂：

每一个运行tsung的服务器拯��已经�~�译完成的recon��目到指定目�?/li>
tsung_controller主节点启动时�Q�指定recon依赖库位�|?/p>
tsung -X /Your_Save_Path/recon/ebin/ ...

说一个用例，修改监控数据�?0�U�写入tsung.log文�g旉��间隔��|��10�U�修改�ؓ5�U�：

application:set_env(tsung_controller, dumpstats_interval, 5000).

执行之后�Q�会立刻生效�?/p>

��结

�ȝ��了Tsung��M��监控�Q�以及服务器端监控部分，以及�q�行时监控等。提供的被压��服务器监控功能很粗�Q�仅攉��CPU、内存、负载、接收数据等�c�d��峰��|��h��一般参考意义。但��Z��Tsung构徏的、或�c�M��商业产品�Q�一般会有提供专门数据收集服务器�Q�但对于开源的应用而言�Q�需要兼��N��用需求，也是能够理解的�?/p>

nieyong 2016-07-29 08:49 发表评论

nieyong — Thu, 28 Jul 2016 00:37:00 GMT

前言

前面说到设计一个小型的C/S�c�d��q�程�l�端套�g以替换SSH�Q��ƈ且已�l�应用到�U�上。这个问题，其实不是Tsung自��n的问题，是外部连接依赖问题�?/p>

Tsung在启动分布式压测�Ӟ��主节�?code>tsung_controller要连接的从机必须要填写主机名�Q�主机名没有内网DNS服务器支持解析的情况�?我所�l�历互联�|�公司很��有提供支持�?�Q�只好费劲在/etc/hosts文�g中填写主机名�U�和IP地址的映��关�p�，颇�ؓ�ȝ��Q�尤其是要添加一�Ҏ��的压��从机或从机变动频率较大时�?/p>

那么如何解决�q�些问题呢，让tsung在复杂的机房内网环境下，完全��Z��IP�q�行直连�Q�这��是本文所讨论的内宏V�?/p>

预备知识

完全限定域名

完全限定域名�Q�羃写�ؓFQDN (fully qualified domain name)�Q?a >赛门铁克�l�出的中文定�?/a>�Q?/p>

一�U�用于指定计��机在域层次�l�构中确切位�|�的明确域名�?br/> 一台特定计��机或主机的完整 Internet 域名。FQDN 包括两部分：��L��名和域名。例�?mycomputer.mydomain.com�?br/> 一�U�包含主机名和域名（包括��域）�?URL。例如，www.symantec.com 是完全限定域名。其�?www 是主机，symantec 是二�U�域�Q?com 是顶�U�域。FQDN ��L��以主机名开始且以顶�U�域名结束，因此 www.sesa.symantec.com 也是一�?FQDN�?/p>

若机器主机名为内�|�域名�Ş式，�q�且支持DNS解析�Q�方便其它服务器可通过该主机名直接扑ֈ�对应IP地址�Q�能�?ping -c 3 机器域名 通，那么机器之间能够�Ҏ��扑ֈ��Ҏ��?/p>

服务器hostname的命名，若不是域名�Ş式，��短名�U��Ş式，比如“yk_mobile_dianxin_001”，一般内�|�的DNS服务器不支持解析�Q�机器之间需要互相在/etc/hosts文�g建立彼此IP地址映射关系才能够互相感知对斏V�?/p>

Erlang节点名称的规�?/h4>
因�ؓTsung使用Erlang�~�写�Q�Erlang关于节点启动名称规定�Q�也是Tsung需要面对的问题�?/p>
Erlang节点名称一般需要遵循两�U�格式：

一般名�U�ͼ�也称之�ؓ短名�U�ͼ�形式�Q�不包含�?”字�W�，比如 `erl -name tsun_node`

完全限定域名形式

域名形式�Q�比�?code>erl -name tsun_node.youdomain.com

IP形式�Q�比�?code>erl -name 10.10.10.103

Tsung处理方式�Q?/p>

若非特别指定�Q�一般默认�ؓ短名�U��Ş�?/li>
启动时可以通过`-F`参数指定使用完全限定域名形式

获得IP地址

��L��名称无论是完全限定域名�Ş式，�q�是��单的短名�U��Ş式，当别的主机需要通过��L��名访问时�Q�系�l�层面需要通过DNS�pȝ��解析成IP地址才能够进行网�l�连接。当内网DNS能够解析出来IP来，没有什么担心的�Q�（短名�U�ͼ�解析不出来时�Q�多半会通过写入到系�l�的 /etc/hosts 文�g中，�q�样也能够解析成功�?/p>

一般机房内�|�环境，��L��名称大都是短名称形式�Q�若需分布式，每一个主��Z��间都要能够互相联通，最�l�济做法��是直接使用IP地址�Q�可避免写入大量映射�?hosts 文�g中，也会避免一些隐患�?/p>

主节点启动增加IP支持

默认情况下，Tsung Master主节点名�U�类��g��tsung_controller@��L��?/code>�Q?/p>


节点名称前缀默认为：tsung_controller �Q�除非在tsung启动旉���过-i指定前缀�Q?/li>
一般主机名都是字符串�Ş式（hostname命��o可设�|�主机名�Q?/li>
可将��L��名称讄���为本机IP�Q�但不符合�h�c�认知惯�?/li>

既然Tsung主节炚w��认对IP节点名称支持不够�Q�改造一�?code>tsung/tsung.sh.in脚本�?/p>

Tsung启动�?code>-F参数为指定��?strong>完全限定域名(FQDN)形式�Q�不支持携带参数。若要直接传逺�P地址�Q�类��g��Q?/p>

-F Your_IP

修改tsung.sh.in�Q�可以传逺�P地址�Q�手动组装节点名�U�ͼ�

F) NAMETYPE="-name"
    SERVER_IP=$OPTARG
    if [ "$SERVER_IP" != "" ]; then
        CONTROLLER_EXTENDS="@$SERVER_IP"
    fi
    ;;

修改不复杂，更多�l�节请参考：https://github.com/weibomobile/tsung/blob/master/tsung.sh.in

启动Tsung�Ӟ��指定本地IP�Q?/p>

tsung -F 10.10.10.10 -f tsung.xml start

tsung_controller目前节点名称已经变�ؓ�Q?/p>

-name tsung_controller@10.10.10.10

嗯，目标达成�?/p>

从节点主机增加IP配置

�l�出一个节点client50配置�Q?/p>

Tsung Master惌��问client50�Q�需要提前徏立client50与IP地址的映��关�p�：

echo "10.10.10.50 client50" >> /etc/hosts

host属性默认情况下只能填写长短名称�Q�无法填写IP地址�Q��ؓ了兼容已有规则，修改tsung-1.0.dtd文�g为client元素新增一�?code>hostip属性：

修改src/tsung_controller/ts_config.erl文�g�Q�增加处理逻辑�Q�只有当主节点主机名为IP时才会取hostip作�ؓ��L��名：

{ok, MasterHostname} = ts_utils:node_to_hostname(node()),
case {ts_utils:is_ip(MasterHostname), ts_utils:is_ip(Host), ts_utils:is_ip(HostIP)} of
   %% must be hostname and not ip:
    {false, true, _} ->
        io:format(standard_error,"ERROR: client config: 'host' attribute must be a hostname, "++ "not an IP ! (was ~p)~n",[Host]),
        exit({error, badhostname});
    {true, true, _} ->
        %% add a new client for each CPU
        lists:duplicate(CPU,#client{host     = Host,
                                    weight   = Weight/CPU,
                                    maxusers = MaxUsers});
    {true, _, true} ->
        %% add a new client for each CPU
        lists:duplicate(CPU,#client{host     = HostIP,
                                    weight   = Weight/CPU,
                                    maxusers = MaxUsers});
    {_, _, _} ->
        %% add a new client for each CPU
        lists:duplicate(CPU,#client{host     = Host,
                                    weight   = Weight/CPU,
                                    maxusers = MaxUsers})
end

嗯，现在可以�q�样配置从节点了�Q�不用担心Tsung启动时是否附�?code>-F参数了：

其实�Q�只要你��定只��用主节点��L��名�ؓIP地址�Q�可以直接设�|�host属性��gؓIP��|��可忽略hostip属性，但这以牺牲兼�Ҏ��ؓ代�h的�?/p>

��Z��减少/etc/hosts大量映射写入�Q�还是推荐全部IP形式�Q�这�U��Ş式适合Tsung分布式集��所依赖服务器的快速租赁模型�?/p>

源码地址

针对Tsung最��C��码增加的IP直连�Ҏ��所有修改，已经攑֜�github上：

https://github.com/weibomobile/tsung �?/p>

�q�且已经递交pull request�Q?https://github.com/processone/tsung/pull/189 �?/p>

比较有意思的是，有这样一条评论：

�K?/p>

针对Tsung 1.6.0修改�?/h4>
最�q�一�ơ发行版是tsung 1.6.0�Q�这个版本比较稳定，我实际压��所使用的就是在此版本上增加IP直连支持�Q�如上所�q�ͼ��Q�已�l�被单独攑օ�到github上：

https://github.com/weibomobile/tsung-1.6.0

至于如何安装�Q?code>git clone到本圎ͼ�后面��是如何�~�译tsung的步骤了�Q�不再篏�q��?/p>

��结

若要让IP直连�Ҏ��生效，再次说明启用步骤一下：

tsung.xml文�g配置从机hostip属性，或host属性，填写正确IP
tsung启动�Ӟ��指定本机可用IP地址�Q?code>tsung -F Your_Available_IP -f tsung.xml ... start

IP直连�Q�再配合前面所写SSH替换�Ҏ��Q�可以让Tsung分布式集��在复杂�|�络机房内网环境下适应性向前迈了一大步�?/p>

2016-08-06 更新此文�Q�增加Tsung 1.6.0修改版描�q?/p>

nieyong 2016-07-28 08:37 发表评论

nieyong — Wed, 27 Jul 2016 01:28:00 GMT

前言

Erlang天生支持分布式环境，Tsung框架的分布式压测受益于此�Q�简单轻松操控子节点生死存亡、派发�Q务等不费吹灰之力�?/p>

Tsung启动分布式压��时�Q�主节点tsung_controller默认情况下需要通过SSH通道�q�接到远�E�机器上启动从节点，那么问题便来了，一般互联网公司��Z��x��/堡垒�?�|�关授权方式讉K��机房服务器，那么SSH机制失效�Q��ƈ且被明��o��止。SSH不通，Tsung��L��启动不了从机�Q�分布式更无从谈赗��?/p>

那么如何解决�q�个问题呢，让tsung在复杂的机房�|�络环境讑֮�下更加如鱼得��_��是本文所讨论的内宏V��?/p>

RSH�Q�Remote Shell

RSH�Q�remote shell�~�写�Q�维基百�U�上英文解释�Q?a >https://en.wikipedia.org/wiki/Remote_Shell。作��Z��个终端工��P��Linux界鸟哥曾�l�写�q?RSH客户端和服务器端搭徏教程�?/p>

在CentOS下安装也��单：

yum install rsh

Erlang借助于rsh命��o行工具通过SSH通道�q�接��C��节点启动Tsung应用�Q�下面可以看到rsh工具本��n失去了原本的含义�Q�类��g��exec命��o功效�?/p>

比如Erlang主节点（假设�q�个服务器名�U�Cؓnode_master�Q��ƈ且已�l�在/etc/hosts文�g建立了IP地址映射�Q�在启动时指定rsh的可选方式�ؓSSH�Q?/p>

erl -rsh ssh -sname foo -setcookie mycookie

启动之后�Q�要启动�q�程��L��节点名称�?code>node_slave的子节点�Q?/p>

slave:start(node_slave, bar, "-setcookie mycookie").

上面Erlang启动从节点函敎ͼ�最�l�被��译为可执行的shell命��o�Q?/p>

ssh node_slave erl -detached -noinput -master foo@node_master -sname bar@node_slave -s slave slave_start foo@node_master slave_waiter_0 -setcookie mycookie

erl命��oErlang的启动命令，要求��L��node_slave自��n也要安装了Erlang的运行时环境才行�?/p>

从节点的启动命��o最�l�依赖于SSH�q�接�q�远�E�执行，光��用一般格式�ؓ�Q?/p>

ssh HOSTNAME/IP Command

�q�就是基于Erlang构徏的Tsung操控从节点启动的最�l�实现机制�?/p>

其它语言中，Master启动Slave也是如此机制

SSH为通用�Ҏ��Q�但不是最好的�Ҏ��

业界选用SSH机制�q�接�q�程Unix/Linux服务器主机，分布式环境下要能够自由免除密码方式启动远�E�主��Z��Q�这里指的是内部Lan环境�Q�应用，一般需要设�|�公钥，需要传递公钥，需要保存到各自机器上，�q�有�l�常遇到权限问题�Q�很是麻烦，�q�是其一。若要取消某台服务器登陆授权�Q�则需要被动修改公钥，也是不够灉|��?/p>

另外一般互联网公司处于安全考虑都会��止公司内部人员直接通过SSH方式��d��到远�E�主��行操作，�q�样��D��SSH通道失效�Q�Tsung��L��通过SSH�q�接��C��机�ƈ执行命��o�Q�也��׃��可能了�?/p>

其实�Q�在��Z��分布式压��环境下�Q�快速租赁、快速借用/归还的模型就很适合。一般公司很��会存在专门用于压测的大量空闲机器，但是�U�上会运行着当前负蝲不高的服务器�Q�可以拿来用作压��客��L��使用�Q�用完就归还。因为压��不会是长时间运行的服务�Q�其为短旉��行�ؓ。这�U�模式下��׃��适合复杂的SSH公钥满天飞，后期忘记删除的情况，在压��端��多的情况下�Q�无疑也��造成�q�维成本�Ȁ增，安全性降低等问题�?/p>

SSH替换�Ҏ��Q�一�U�快速租赁模式远�E�终端方�?/h3>
现在需要寻找一�U�新的代替方案，一�U�适应快速租赁的�q�程�l�端实现机制�?/p>

替换�Ҏ��要求�?/h4>

�c�M��于SSH Server�Q�监听某个端口，能够执行传递过来的命��o

能够�Ҏ��IP地址授权�Q�这样只有Tsung Master才能够访问从节点�Q�从节点之间无法直接对连

需要接受一些操控指令，可以判断是否存活

一��C��个脚�?�E�序搞定�Q�尽量避免安装，开��即�?/li>
��M��配置、操作一定要��单，实际�q�维成本一定要�?/li>

没找到很轻量的实玎ͼ�可以设计�q�实现这样一�U�方案�?/p>

服务器端守护�q�程

轻量�U�服务端守护�q�程 = 一个监控端口的�q�程�Q?code>rsh_daemon.sh�Q?+ 执行命��o�q��o功能(rsh_filter)

rsh_daemon.sh 负责守护�q�程的管理：

��Z��CentOS 6/7默认安装�?code>ncat�E�序
主要用于��理19999端口监听
start/stop/restart 负责监控�q�程启动、关�?/li>
status 查看�q�程状�?/li>
kill 提供手动方式关闭�q�删除掉自��n
rsh_filter用于��远�E�传入命令�ƈ�q�行处理
- 接收ping指��o�Q�返回pong
- 执行Erlang从节点命令，�q�返�?done 字符�?/li>
- 对不合法命��o�Q�直接关�?/li>

rsh_daemon.sh代码很简单：

#!/bin/bash
# the script using for start/stop remote shell daemon server to replace the ssh server
PORT=19999
FILTER=~/tmp/_tmp_rsh_filter.sh
# the tsung master's hostname or ip
tsung_controller=tsung_controller
SPECIAL_PATH=""
PROG=`basename $0`

prepare() {
    cat << EOF > $FILTER
#!/bin/bash

ERL_PREFIX="erl"

while true
do
    read CMD
    case \$CMD in
        ping)
            echo "pong"
            exit 0
            ;;
        *)
            if [[ \$CMD == *"\${ERL_PREFIX}"* ]]; then
                exec $SPECIAL_PATH\${CMD}
            fi
            exit 0
            ;;
    esac
done
EOF
    chmod a+x $FILTER
}

start() {
    NUM=$(ps -ef|grep ncat | grep ${PORT} | grep -v grep | wc -l)

    if [ $NUM -gt 0 ];then
        echo "$PROG already running ..."
        exit 1
    fi

    if [ -x "$(command -v ncat)" ]; then
        echo "$PROG starting now ..."
        ncat -4 -k -l $PORT -e $FILTER --allow $tsung_controller &
    else
        echo "no exists ncat command, please install it ..."
    fi
}

stop() {
    NUM=$(ps -ef|grep ncat | grep rsh | grep -v grep | wc -l)

    if [ $NUM -eq 0 ]; then
        echo "$PROG had already stoped ..."
    else
        echo "$PROG is stopping now ..."
        ps -ef|grep ncat | grep rsh | grep -v grep | awk '{print $2}' | xargs kill
    fi
}

status() {
    NUM=$(ps -ef|grep ncat | grep rsh | grep -v grep | wc -l)

    if [ $NUM -eq 0 ]; then
        echo "$PROG had already stoped ..."
    else
        echo "$PROG is running ..."
    fi
}

usage() {
    echo "Usage: $PROG  start|stop|status|restart"
    echo "Options:"
    echo "    -a   allow only given hosts to connect to the server (default is tsung_controller)"
    echo "    -p          use the special port for listen (default is 19999)"
    echo "    -s  use the special erlang's erts bin path for running erlang (default is blank)"
    echo "    -h                display this help and exit"
    exit
}

while getopts "a:p:s:h" Option
do
    case $Option in
        a) tsung_controller=$OPTARG;;
        p) PORT=$OPTARG;;
        s) TMP_ERL=$OPTARG
            if [ "$OPTARG" != "" ]; then
                if [[ "$OPTARG" == *"/" ]]; then
                    SPECIAL_PATH=$OPTARG
                else
                    SPECIAL_PATH=$OPTARG"/"
                fi
            fi
            ;;
        h) usage;;
        *) usage;;
    esac
done
shift $(($OPTIND - 1))

case $1 in
        start)
            prepare
            start
            ;;
        stop)
            stop
            ;;
        status)
            status
            ;;
        restart)
            stop
            start
            ;;
        *)
            usage
            ;;
esac

�ȝ��一下：

��Z��ncat监听19999端口提供bind shell机制�Q�但限制有限IP可访�?/li>
动态生成命令过滤脚�?code>rsh_filter.sh�Q�执行Erlang从节点命�?/li>

请参考：https://github.com/weibomobile/tsung_rsh/blob/master/rsh_daemon.sh

客户端连接方�?/h3>

服务器端已经提供了端口接入�ƈ准备好了接收指��o�Q�客��L��Q?code>rsh_client.sh�Q�可以进行连接和交互了：

�c�M��SSH客户端接收方式：rsh_client.sh Host/IP Command
完全��Z��nc命��o�Q�连接远�E�主�?/li>
�q�接成功�Q�发送命�?/li>
得到相应�Q�流�E�完�?/li>

一样非常少的代码呈现�?/p>

#!/bin/sh

PORT=19999

if [ $# -lt 2  ]; then
    echo "Invalid number of parameters"
    exit 1
fi

REMOTEHOST="$1"
COMMAND="$2"

if [ "${COMMAND}" != "erl"  ]; then
    echo "Invalid command ${COMMAND}"
    exit 1
fi

shift 2

echo "${COMMAND} $*" | /usr/bin/nc ${REMOTEHOST} ${PORT}

Erlang主节点如何启�?/h3>

有了SSH替换�Ҏ��Q�那主节点就可以�q�样启动了：

erl -rsh ~/.tsung/rsh_client.sh -sname foo -setcookie mycookie

比如当Tsung需要连接到另外一台服务器上启动从节点�Ӟ��它最�l�会��译成下面命令：

/bin/sh /root/.tsung/rsh_client.sh node_slave erl -detached -noinput -master foo@node_master -sname bar@node_slave -s slave slave_start foo@node_master slave_waiter_0 -setcookie mycookie

客户端脚�?code>rsh_client.sh则最�l�需要执行连接到服务器、�ƈ发送命的命令：

echo "erl -detached -noinput -master foo@node_master -sname bar@node_slave -s slave slave_start foo@node_master slave_waiter_0 -setcookie mycookie" | /usr/bin/nc node_slave 19999

�q�样��实��C��和SSH一��L��功能了，很简单吧�?/p>

Tsung如何切换切换�Q?/h3>

为tsung启动��d��-r参数指定卛_��Q?/p>

tsung -r ~/.tsung/rsh_client.sh -f tsung.xml start

�q�阶�Q�可指定�q�行命��o路径

rsh_client.sh脚本最后一行修改一下，指定目标服务器erl�q�行命��o�Q?/p>

#!/bin/sh

PORT=19999

if [ $# -lt 2  ]; then
    echo "Invalid number of parameters"
    exit 1
fi

REMOTEHOST="$1"
COMMAND="$2"

if [ "${COMMAND}" != "erl"  ]; then
    echo "Invalid command ${COMMAND}"
    exit 1
fi

shift 2
exec echo "/root/.tsung/otp_18/bin/erl $*" | /usr/bin/nc ${REMOTEHOST} 19999

上面脚本所依赖的上下文环境可以是这��L��Q�机房服务器操作�pȝ��和版本一��_��我们把Erlang 18.1整个�q�行时环境在一台机器上已经安装的目录（比如目录名�ؓotp_18�Q�，拯��到远�E�主�?code>/root/.tsung/目录�Q�相比于安装而言�Q�可以让Tsung�q�行依赖的Eralng环境完全可以�U�L��化（Portable�Q�，一�ơ安装，多次复制�?/p>

代码托管地址

本文所谈及代码�Q�都已经托管在github�Q?br/> https://github.com/weibomobile/tsung_rsh

后箋代码更新、BUG修复�{�，��L��接参考该仓库�?/p>

��结

��单一套新的替换SSH通道无密钥登陆远�E�主机C/S模型�Q�虽然完整性上无法与SSH相比�Q�但胜在��单够用，完全满��了当前业务需要，�q�且其运�l�成本低�Q�无疑让Tsung在复杂服务器内网环境下适应性又朝前多走了半里�\�?/p>

下一��将介绍为Tsung增加IP直连�Ҏ��支持，使其分布式网�l�环境下适应性更�q�泛一些�?/p>

nieyong 2016-07-27 09:28 发表评论

nieyong — Tue, 26 Jul 2016 00:47:00 GMT

前言

�q�里汇集一下媄响tsung client创徏用户数的各项因素。因为Tsung是IO密集型的应用�Q�CPU占用一般不大，��Z��可能的生成更多的用��P��需要考虑内存相关事宜�?/p>

IP & 端口的媄�?/h3>

1. �pȝ��端口限制

Linux�pȝ��端口为short�c�d��表示�Q�数��g��限�ؓ65535。假讑ֈ�配压��业务可用端口范围�ؓ1024 - 65535�Q�不考虑可能�q�运行着其它对外�q�接的服务，真正可用端口也就�?4000左右�Q�实际上�Q�一般�ؓ了方便计��，一般直接设定�ؓ50000�Q�。换�a�之，卛_��一台机器上一个IP�Q�可用同时对外徏�?4000�|�络�q�接�?/p>

若是N个可用IP�Q�理��Z�� 64000*N�Q�实际上�q�需要满��I��

充��内存支持
- tcp接收/发送缓冲区不要讄��太大�Q�tsung默认分配32K�Q�可以修�Ҏ��16K�Q�一般够用了�Q?/li>
- 一个粗略估��一个连接占�?0K内存�Q�那�?0万用��P��占用约8G内存
为多IP的压��端分配适合的权重，以便承担更多的终端连�?/li>

另外�q�需要考虑端口的快速回收等�Q�可以这样做�Q?/p>

sysctl -w net.ipv4.tcp_syncookies=1
sysctl -w net.ipv4.tcp_tw_reuse=1
sysctl -w net.ipv4.tcp_tw_recycle=1
sysctl -w net.ipv4.tcp_fin_timeout=30
sysctl -w net.ipv4.ip_local_port_range="1024 65535"

sysctl -p

若已�l�在 /etc/sysctl.conf 文�g中有记录�Q�则需要手动修�?/p>

作�ؓ附加�Q�可讄��端口重用�Q?/p>

注意�Q�不要设�|�下面的可用端口范围�Q?/p>

因�ؓ操作�pȝ��会自动蟩�q�已�l�被占用本地端口�Q�而Tsung只能够被动通过错误�q�行可用端口+1�l�箋下一个连接，有些多余�?/p>

2. IP和端口组�?/h4>

每一个client支持多个可用IP地址列表

tsung client从节点开始准备徏立网�l�连接会话时�Q�需要从tsung_controller主节点获取具体的会话信息�Q�其中就包含了客��L��q�接需要��用到来源{LocalIP�Q?LocalPort}二元�l�。由tsung_controller主节点完成�?/p>

get_user_param(Client,Config)->
    {ok, IP} = choose_client_ip(Client),
    {ok, Server} = choose_server(Config#config.servers, Config#config.total_server_weights),
    CPort = choose_port(IP, Config#config.ports_range),
    {{IP, CPort}, Server}.

choose_client_ip(#client{ip = IPList, host=Host}) ->
    choose_rr(IPList, Host, {0,0,0,0}).

......

choose_client_ip(#client{ip = IPList, host=Host}) ->
    choose_rr(IPList, Host, {0,0,0,0}).

choose_rr(List, Key, _) ->
    I = case get({rr,Key}) of
          undefined -> 1 ; % first use of this key, init index to 1
          Val when is_integer(Val) ->
            (Val rem length(List))+1 % round robin
    end,
    put({rr, Key},I),
    {ok, lists:nth(I, List)}.

%% 默认不设�|?ports_range 会直接返�?
%% 不徏议设�|?

从节点徏立到压测服务器连接时�Q�就需要指定从主节点获取到的本机IP地址和端口两元组�Q?/p>

Opts = protocol_options(Protocol, Proto_opts)  ++ [{ip, IP},{port,CPort}],
......
gen_tcp:connect(Server, Port, Opts, ConnectTimeout).

3. IP自动扫描�Ҏ�?/h4>

若从机单个网卡绑定了多个IP�Q�又懒于输入�Q�可以配�|�扫描特�?

本质上��用shell方式获取IP地址�Q��ƈ且支持CentOS 6/7�?/p>

    /sbin/ip -o -f inet addr show dev eth0

因�ؓ扫描比较慢，Tsung 1.6.1推出�?code>ip_range�Ҏ��支持�?/p>

Linux�pȝ��打开文�g句柄限制

�pȝ��打开文�g句柄�Q�直接决定了可以同时打开的网�l�连接数量，�q�个需要设�|�大一些，否则�Q�你可能会在tsung_controller@IP.log文�g中看�?code>error_connect_emfile�c�M��文�g句柄不够使用的警告，��此��D��大于 > N * 64000�?/p>

echo "* soft nofile 300000" >> /etc/security/limits.conf
echo "* hard nofile 300000" >> /etc/security/limits.conf

或者，在Tsung会话启动脚本文�g中明��添加上ulimit -n 300000�?/p>

内存的媄�?/h3>
一个网�l�Socket�q�接占用不多�Q�但上万个或数十万等��׃��容小觑了�Q�设�|�不当会��D��内存直接成�ؓ屏障�?/p>

1. TCP接收、发送缓�?/h4>

Tsung默认讄��的网�l�Socket发送接收缓冲区�?6KB�Q�一般够用了�?/p>

以TCP��Z��Q�某�ơ我手误为Tcp接收�~�存赋��D��?599967字节)�Q�这��h��一个网�l�了解至��占用了0.6M内存�Q�直接导致在16G内存服务上网�l�连接数�?万多�Ӟ��内存告急�?/p>

此��g��覆盖Linux�pȝ��讄��接收、发送缓冲大��?/p>

�_�略的默认��D��，一个网�l�连接发送缓冲区 + 接收�~�冲区，再加上进�E�处理连接堆栈占用，�U?0多K内存�Q��ؓ卌��方便，讑֮�建立一个网�l�连接消�?0K内存�?/p>

先不考虑其它因素�Q�若我们惌��从机模拟10W个用��P��那么当前可用内存臛_��要剩余：50K * 100000 / 1000K = 5000M = 5G内存。针对一般服务器来讲�Q�完全可满��要求�Q�剩下事情就是要有两个可用IP了）�?/p>

2. Erlang函数堆栈内存占用

使用Erlang�E�序写的应用服务器，�q�程要存储堆栈调用信息，�q�程一多久会占用大量内存，惌��服务更多�|�络�q�接/��d��Q�需要将不活动的�q�程讄��Z��眠状态，以便节省内存�Q�Tsung的压��会话信息若包含thinktime旉��Q�也要考虑启用hibernate休眠机制�?/p>

值单位秒�Q�默认thinktime��过10�U�后自动启动�Q�这里修改�ؓ5�U��?/p>

XML文�g讄��需要注意部�?/h3>

1. 日志�{��要调高一�?/h4>
tsung使用error_logger记录日志�Q�其只适用于真正的异常情况�Q�若当一般业务调试类型日志量�q�多�Ӟ��不但耗费了大量内存，�|�络/��盘写入速度跟不上生产速度�Ӟ��会导致进�E�堵塞，严重会拖累整个应用僵死，因此需要在tsung.xml文�g中设�|�日志等�U�要高一些，臛_��默认的notice��很合适�?/p>

2. 不要启用dump

dump是一个耗时的行为，因此默认为false�Q�除非很��的压测用户用于调试�?/p>

3. 动态属性太多，会导致请求超�?/h4>

讑֮�一个有状态的场景�Q�用户ID储存在文件中�Q�每一�ơ会话请求都要从获取到用户ID�Q�压��用户一旦达到百万��别�ƈ且用��h��U��生速率�q�大�Q�比如每�U?000个用��P��Q�会�l�常遇到��时错误�Q?/p>

=ERROR REPORT==== 25-Jul-2016::15:14:11 ===
** Reason for termination =
** {timeout,{gen_server,call,
                        [{global,ts_file_server},{get_next_line,userdb}]}}

�q�是因�ؓ�Q�当tsung client遇到setdynvars指��o�Ӟ��会直接请求主机ts_file_server模块�Q�当一旉��h��量巨大，可能会造成单一模块处理�~�慢�Q�出现超旉��题�?/p>

怎么办：

降低用户每秒产生速率�Q�比�?00�U�用��L��?/li>
不用从文件中存储用户id�{�信息，采用别的方式

如何限流/限�?/h3>

某些时候，要避免tsung client压测端媄响所在服务器�|�络带宽IO太拥挤，需要限制流量，光��用��o牌桶��法�?/p>

��gؓKB单位每秒
目前仅对传入��量生效

阀��D��方式：

{RateConf,SizeThresh} = case RateLimit of
                            Token=#token_bucket{} ->
                                Thresh=lists:min([?size_mon_thresh,Token#token_bucket.burst]),
                                {Token#token_bucket{last_packet_date=StartTime}, Thresh};
                            undefined ->
                                {undefined, ?size_mon_thresh}
           end,

接收传入��量数据�Q�需要计��：

handle_info2({gen_ts_transport, _Socket, Data}, wait_ack, State=#state_rcv{rate_limit=TokenParam}) when is_binary(Data)->
    ?DebugF("data received: size=~p ~n",[size(Data)]),
    NewTokenParam = case TokenParam of
                        undefined ->
                            undefined;
                        #token_bucket{rate=R,burst=Burst,current_size=S0, last_packet_date=T0} ->
                            {S1,_Wait}=token_bucket(R,Burst,S0,T0,size(Data),?NOW,true),
                            TokenParam#token_bucket{current_size=S1, last_packet_date=?NOW}
                    end,
    {NewState, Opts} = handle_data_msg(Data, State),
    NewSocket = (NewState#state_rcv.protocol):set_opts(NewState#state_rcv.socket,
                                                       [{active, once} | Opts]),
    case NewState#state_rcv.ack_done of
        true ->
            handle_next_action(NewState#state_rcv{socket=NewSocket,rate_limit=NewTokenParam,
                                                  ack_done=false});
        false ->
            TimeOut = case (NewState#state_rcv.request)#ts_request.ack of
                global ->
                    (NewState#state_rcv.proto_opts)#proto_opts.global_ack_timeout;
                _ ->
                    (NewState#state_rcv.proto_opts)#proto_opts.idle_timeout
            end,
            {next_state, wait_ack, NewState#state_rcv{socket=NewSocket,rate_limit=NewTokenParam}, TimeOut}
    end;

下面则是具体的��o牌桶��法�Q?/p>

%% @spec token_bucket(R::integer(),Burst::integer(),S0::integer(),T0::tuple(),P1::integer(),
%%                    Now::tuple(),Sleep::boolean()) -> {S1::integer(),Wait::integer()}

%% @doc Implement a token bucket to rate limit the traffic: If the
%%      bucket is full, we wait (if asked) until we can fill the
%%      bucket with the incoming data
%%      R = limit rate in Bytes/millisec, Burst = max burst size in Bytes
%%      T0 arrival date of last packet,
%%      P1 size in bytes of the packet just received
%%      S1: new size of the bucket
%%      Wait: Time to wait
%% @end
token_bucket(R,Burst,S0,T0,P1,Now,Sleep) ->
    S1 = lists:min([S0+R*round(ts_utils:elapsed(T0, Now)),Burst]),
    case P1 < S1 of
        true -> % no need to wait
            {S1-P1,0};
        false -> % the bucket is full, must wait
            Wait=(P1-S1) div R,
            case Sleep of
                true ->
                    timer:sleep(Wait),
                    {0,Wait};
                false->
                    {0,Wait}
            end
    end.

��结

以上��单梳理一下媄响tsung从机创徏用户的各��因素，实际环境其实相当复杂�Q�需要一一对症下药才行�?/p>

nieyong 2016-07-26 08:47 发表评论

Tsung�W�记之主从资源协调篇

nieyong — Mon, 25 Jul 2016 06:02:00 GMT

前言

接着上文�Q�tsung一旦启动，��M��节点之间需要协调分配资源，完成分布式压��Q务�?/p>

如何启动Tsung压测从机

Erlang SDK提供了从机启动方式：

slave:start(Host, Node, Opts)

启动从机需要借助于免登陆形式�q�程�l�端�Q�比如SSH�Q�后�l�会讨论SSH存在不��Q�以及全新的替代品）�Q�需要自行配�|��?/p>

host属性对应value��Z��Z��机名�U�ͼ�client_100
Node节点名称由tsung_controller�l�装�Q�类��g�� tsung10@client_100
Opts表示相关参数
一个物理机器，可以存在多个tsung从机实例
一个tsung从机实例对应一个tsung client

��单翻译一下：slave:start(client_100, 'tsung10@client_100', Opts)

从机需要关闭时�Q�就很简单了�Q?/p>

slave:stop(Node)

当然若主��Z��途挂掉，从机也会自动自杀掉自�w��?/p>

启动tsung client方式

Tsung��L��启动从机成功�Q�从机和��L��可以Erlang节点�q�程之间�q�行�Ҏ��调用和消息传递。潜在要求是�Q�tsung�~�译后beam文�g能够在Erlang�q�行时环境中能够讉K��刎ͼ��q�个和Java Classpath一致原理�?/p>

rpc:multicall(RemoteNodes,tsung,start,[],?RPC_TIMEOUT)

到此为止�Q�一个tsung client实例成功�q�行�?/p>

tsung client实例生命周期�l�束�Q�不会导致从机实例主动关�?/li>
tsung slave提供了运行时环境�Q�tsung client是业�?/li>
tsung slave和tsung client关系�? : 1关系�Q�很多时候�ؓ了理解方便，不会�q�行严格区分

压测目标

明白了主从启动方式，下面讨论压测目标�Q�比�?0万用��L��量，�Ҏ��l�出的压��从机列表，�q�行��d��分配�?/p>

压测目标配置

tsung压测xml配置文�g�Q�load元素可以配置��M��d��生成的信息�?/p>

定义一个最�l�压力��生可以持�l?0分钟压测场景�Q?上限用户量�ؓ50�?/li>
arrivalphase duration属性持�l�时长表�C�生成压��用户可消费��M��旉��60分钟�Q�即为T1
users元素其属性表�C�单位时间内�Q�这里单位时间�ؓ�U�）产生用户��Cؓ250�?/li>
50万用��P��在2000�U?�U?4分钟)内生成，耗时旉��即�ؓT2
T2��于arrivalphase定义的用��L��成阶�D�|��l�时间T1
若T2旉��后（34分钟)后因��Z�生用��h��已经辑ֈ�了上限，��不再��生新的用��P��知道整个压测�l�束
�?T1 ��于 T2�Q�则50万用户很难达刎ͼ�因此T1旉��要设�|�长一�?/li>

从节点信息配�|?/h4>

所说从节点也是压测客户端，需要配�|�clients元素�Q?/p>

单个client支持多个IP�Q�用于突破单个IP对外建立�q�接数的限制(后箋会讲刎ͼ�
xml所定义的一个cliet元素�Q�可能被分裂��q�从机实�?即tsung client)�Q? : N

�Ҏ��CPU数量分裂tsung client实例情况

在《Tsung Documentation》给��Z��Q�一个CPU一个tsung client实例�Q?/p>

Note: Even if an Erlang VM is now able to handle several CPUs (erlang SMP), benchmarks shows that it’s more efficient to use one VM per CPU (with SMP disabled) for tsung clients. Only the controller node is using SMP erlang.
Therefore, cpu should be equal to the number of cores of your nodes. If you prefer to use erlang SMP, add the -s option when starting tsung (and don’t set cpu in the config file).

默认�{�略, 一个tsung client对应一个CPU�Q�若不设�|�CPU属性，默认值就�?
一个cpu对应一个tsung client�Q�N个CPU�Q�N个tsung client
共同分担权重�Q�每一个分裂的tsung client权重 Weight/N
一旦设�|�cpu属性，无论Tsung启动时是否携�?code>-s参数讄��׃�nCPU�Q�都�?
- 自动分裂CPU个tsung client实例
- 每一个实例权重�ؓWeight/CPU

%% add a new client for each CPU
lists:duplicate(CPU,#client{host     = Host,
                            weight   = Weight/CPU,
                            maxusers = MaxUsers})

若要讄��单个tsung client实例�׃�n多个CPU�Q�此时不要设�|�cpu属性啦�Q�，需要在tsung启动时添�?code>-s参数�Q�tsung client被启动时�Q�smp属性被讄��成auto�Q?/p>

-smp auto +A 8

�q�样从机��只有一个tsung client实例了，不会让�h产生困扰。若是��时租借从机，��启动时��?s参数�Q��ƈ且要去除cpu属性设�|�，�q�样才能够自动共享所有CPU核心�?/p>

从机分配用户�q�多�Q�一样会分裂新的tsung client实例

假设client元素配置maxusers数量�?K�Q�那么实际上被分配数量�ؓ10K(压测人数多，压测从机��?�Ӟ��那么tsung_controller会��l�分裂新的tsung client实例�Q�直�?0K用户数量完成�?/p>

tsung client分配的数量超�q�自�w�可服务上限用户�Ӟ��q�里讄��的是1K�Q�时�Q�关闭自�w��?/p>

launcher(_Event, State=#launcher{nusers = 0, phases = [] }) ->
    ?LOG("no more clients to start, stop  ~n",?INFO),
    {stop, normal, State};

launcher(timeout, State=#launcher{nusers        = Users,
                                  phase_nusers  = PhaseUsers,
                                  phases        = Phases,
                                  phase_id      = Id,
                                  started_users = Started,
                                  intensity     = Intensity}) ->
    BeforeLaunch = ?NOW,
    case do_launch({Intensity,State#launcher.myhostname,Id}) of
        {ok, Wait} ->
            case check_max_raised(State) of
                true ->
                    %% let the other beam starts and warns ts_mon
                    timer:sleep(?DIE_DELAY),
                    {stop, normal, State};
                false->
                    ......
            end;
        error ->
            % retry with the next user, wait randomly a few msec
            RndWait = random:uniform(?NEXT_AFTER_FAILED_TIMEOUT),
            {next_state,launcher,State#launcher{nusers = Users-1} , RndWait}
    end.

tsung_controller接收从节炚w��出通知�Q�但分配��L��没有完成�Q�会启动新的tsung client实例�Q�一样先启动从节点，然后再启动tsung client实例�Q�。整个过�E�串行方式��@环，直到10K用户数量完成�Q?/p>

%% start a launcher on a new beam with slave module
handle_cast({newbeam, Host, Arrivals}, State=#state{last_beam_id = NodeId, config=Config, logdir = LogDir}) ->
    Args = set_remote_args(LogDir,Config#config.ports_range),
    Seed = Config#config.seed,
    Node = remote_launcher(Host, NodeId, Args),
    case rpc:call(Node,tsung,start,[],?RPC_TIMEOUT) of
        {badrpc, Reason} ->
            ?LOGF("Fail to start tsung on beam ~p, reason: ~p",[Node,Reason], ?ERR),
            slave:stop(Node),
            {noreply, State};
        _ ->
            ts_launcher_static:stop(Node), % no need for static launcher in this case (already have one)
            ts_launcher:launch({Node, Arrivals, Seed}),
            {noreply, State#state{last_beam_id = NodeId+1}}
    end;

tsung client分配用户�?/h3>

一个tsung client分配的用��h��Q�可以理解�ؓ会话��d��数。Tsung以终端可以模拟的用户为维度进行定义压��?/p>

所有配�|�tsung client元素�Q�设�|�M1�Q�权重相加之和�ؓ��L��重TotalWeight�Q�用��h��L��为MaxMember�Q�一个tsung client实例�Q��L��设�ؓM2�Q�分配的模拟用户数可能�ؓ�Q?/p>

MaxMember*(Weight/TotalWeight)

需要注意：
- M2 >= M1
- 若压��阶�D?code>元素配置duration��D��，��于最�l�用�?0万用��h��照每�U?50速率耗时旉��Q�最�l�分配用��h��小于期望�?/p>

只有一台物理机的tsung master启动方式

没有物理从机�Q�主从节炚w��在一台机器上�Q�需要设�|?code>use_controller_vm="true"。相比tsung集群�Q�单一节点tsung启动��很��单，��M��之间不需要SSH通信�Q�直接内部调用�?/p>

local_launcher([Host],LogDir,Config) ->
    ?LOGF("Start a launcher on the controller beam ~p~n", [Host], ?NOTICE),
    LogDirEnc = encode_filename(LogDir),
    %% set the application spec (read the app file and update some env. var.)
    {ok, {_,_,AppSpec}} = load_app(tsung),
    {value, {env, OldEnv}} = lists:keysearch(env, 1, AppSpec),
    NewEnv = [ {debug_level,?config(debug_level)}, {log_file,LogDirEnc}],
    RepKeyFun = fun(Tuple, List) ->  lists:keyreplace(element(1, Tuple), 1, List, Tuple) end,
    Env = lists:foldl(RepKeyFun, OldEnv, NewEnv),
    NewAppSpec = lists:keyreplace(env, 1, AppSpec, {env, Env}),

    ok = application:load({application, tsung, NewAppSpec}),
    case application:start(tsung) of
        ok ->
            ?LOG("Application started, activate launcher, ~n", ?INFO),
            application:set_env(tsung, debug_level, Config#config.loglevel),
            case Config#config.ports_range of
                {Min, Max} ->
                    application:set_env(tsung, cport_min, Min),
                    application:set_env(tsung, cport_max, Max);
                undefined ->
                    ""
            end,
            ts_launcher_static:launch({node(), Host, []}),
            ts_launcher:launch({node(), Host, [], Config#config.seed}),
            1 ;
        {error, Reason} ->
            ?LOGF("Can't start launcher application (reason: ~p) ! Aborting!~n",[Reason],?EMERG),
            {error, Reason}
    end.

用户生成控制

用户和会话控�?/h4>
每一个tsung client�q�行着一�?code>ts_launch/ts_launch_static本地注册模块�Q�掌控终端模拟用��L��成和会话控制�?/p>

向主节点ts_config_server��h��隶属于当前从��点的会话信息

启动模拟�l�端用户ts_client

控制下一个模拟终端用户ts_client需要等待时��_��也是控制从机用户生成速度

执行是否需要切换到新的阶段会话

控制模拟�l�端用户是否已经辑ֈ�了设�|�的`maxusers`上限

��C��限，自��n使命完成�Q�关闭自�w?/li>

源码位于 tsung-1.6.0/src/tsung 目录�?/li>

��L��按照xml配置生成全局用户产生速率�Q�从机按照自�w�权重分配的速率�q�行单独控制�Q�这也是��d��分解的具体呈现�?/p>

用户生成速度控制

在Tsung中用��L��成速度�U�C��为强度，�Ҏ��所配置的load属性进行配�|?/p>

关键属性：

interarrival�Q�生成压��用��L��旉��间隔
arrivalrate�Q�单位时间内生成用户数量
两者最�l�都会被转换为生成用户强度系数值是0.25
�q�个是�ȝ��强度��|��但需要被各个tsung client分解

parse(Element = #xmlElement{name=users, attributes=Attrs},
      Conf = #config{arrivalphases=[CurA | AList]}) ->

    Max = getAttr(integer,Attrs, maxnumber, infinity),
    ?LOGF("Maximum number of users ~p~n",[Max],?INFO),

    Unit  = getAttr(string,Attrs, unit, "second"),
    Intensity = case {getAttr(float_or_integer,Attrs, interarrival),
                      getAttr(float_or_integer,Attrs, arrivalrate)  } of
                    {[],[]} ->
                        exit({invalid_xml,"arrival or interarrival must be specified"});
                    {[], Rate}  when Rate > 0 ->
                        Rate / to_milliseconds(Unit,1);
                    {InterArrival,[]} when InterArrival > 0 ->
                        1/to_milliseconds(Unit,InterArrival);
                    {_Value, _Value2} ->
                        exit({invalid_xml,"arrivalrate and interarrival can't be defined simultaneously"})
                end,
    lists:foldl(fun parse/2,
        Conf#config{arrivalphases = [CurA#arrivalphase{maxnumber = Max,
                                                        intensity=Intensity}
                               |AList]},
                Element#xmlElement.content);

tsung_controller�Ҏ��一个tsung client生成用户强度分解�?ClientIntensity = PhaseIntensity * Weight / TotalWeight�Q��?code>1000 * ClientIntensity��是易读的每�U�生成用户速率倹{�?/p>

get_client_cfg(Arrival=#arrivalphase{duration = Duration,
                                     intensity= PhaseIntensity,
                                     curnumber= CurNumber,
                                     maxnumber= MaxNumber },
               {TotalWeight,Client,IsLast} ) ->
    Weight = Client#client.weight,
    ClientIntensity = PhaseIntensity * Weight / TotalWeight,
    NUsers = round(case MaxNumber of
                       infinity -> %% only use the duration to set the number of users
                           Duration * ClientIntensity;
                       _ ->
                           TmpMax = case {IsLast,CurNumber == MaxNumber} of
                                        {true,_} ->
                                            MaxNumber-CurNumber;
                                        {false,true} ->
                                            0;
                                        {false,false} ->
                                            lists:max([1,trunc(MaxNumber * Weight / TotalWeight)])
                                    end,
                           lists:min([TmpMax, Duration*ClientIntensity])
                   end),
    ?LOGF("New arrival phase ~p for client ~p (last ? ~p): will start ~p users~n",
          [Arrival#arrivalphase.phase,Client#client.host, IsLast,NUsers],?NOTICE),
    {Arrival#arrivalphase{curnumber=CurNumber+NUsers}, {ClientIntensity, NUsers, Duration}}.

前面讲到每一个tsung client被分配用��h��公式为：min(Duration * ClientIntensity, MaxNumber * Weight / TotalWeight)�Q?/p>

避免��M�h数超出限�?/li>
阶段Phase持箋旉��所产生用户数和tsung client分配用户��C��至于产生冲突�Q�一�U�协调策�?/li>

再看一下launch加蝲一个终端用��h��Q�会自动�Ҏ��当前分配用户生成压力�p�L��获得ts_stats:exponential(Intensity)下一个模拟用户��生等待生成的最长时��_��单位为毫�U��?/p>

do_launch({Intensity, MyHostName, PhaseId})->
    %%Get one client
    %%set the profile of the client
    case catch ts_config_server:get_next_session({MyHostName, PhaseId} ) of
        {'EXIT', {timeout, _ }} ->
            ?LOG("get_next_session failed (timeout), skip this session !~n", ?ERR),
            ts_mon:add({ count, error_next_session }),
            error;
        {ok, Session} ->
            ts_client_sup:start_child(Session),
            X = ts_stats:exponential(Intensity),
            ?DebugF("client launched, wait ~p ms before launching next client~n",[X]),
            {ok, X};
        Error ->
            ?LOGF("get_next_session failed for unexpected reason [~p], abort !~n", [Error],?ERR),
            ts_mon:add({ count, error_next_session }),
            exit(shutdown)
    end.

ts_stats:exponential逻辑引入了指数计��：

exponential(Param) ->
    -math:log(random:uniform())/Param.

�l�箋往下看吧，隐藏了部分无关代码：

launcher(timeout, State=#launcher{nusers        = Users,
                                  phase_nusers  = PhaseUsers,
                                  phases        = Phases,
                                  phase_id      = Id,
                                  started_users = Started,
                                  intensity     = Intensity}) ->
    BeforeLaunch = ?NOW,
    case do_launch({Intensity,State#launcher.myhostname,Id}) of
        {ok, Wait} ->
                            ...
                        {continue} ->
                            Now=?NOW,
                            LaunchDuration = ts_utils:elapsed(BeforeLaunch, Now),
                            %% to keep the rate of new users as expected,
                            %% remove the time to launch a client to the next
                            %% wait.
                            NewWait = case Wait > LaunchDuration of
                                          true -> trunc(Wait - LaunchDuration);
                                          false -> 0
                                      end,
                            ?DebugF("Real Wait = ~p (was ~p)~n", [NewWait,Wait]),
                            {next_state,launcher,State#launcher{nusers = Users-1, started_users=Started+1} , NewWait}
                            ...
        error ->
            % retry with the next user, wait randomly a few msec
            RndWait = random:uniform(?NEXT_AFTER_FAILED_TIMEOUT),
            {next_state,launcher,State#launcher{nusers = Users-1} , RndWait}
    end.

下一个用��L��成需要等�?code>Wait - LaunchDuration毫秒旉��?/p>

�l�出一个采��h��据，只有一个从机，�q�且用户产生速度1�U�一个，�׃��?0个用��P��

采集日志部分�Q�记录了Wait旉��|��其实��M��旉��q�需要加�?code>LaunchDuration�Q�虽然这个值很��）�Q?/p>

ts_launcher:(7:<0.63.0>) client launched, wait 678.5670934164623 ms before launching next client
ts_launcher:(7:<0.63.0>) client launched, wait 810.2982455546687 ms before launching next client
ts_launcher:(7:<0.63.0>) client launched, wait 1469.2208436232288 ms before launching next client
ts_launcher:(7:<0.63.0>) client launched, wait 986.7202548184069 ms before launching next client
ts_launcher:(7:<0.63.0>) client launched, wait 180.7484423006169 ms before launching next client
ts_launcher:(7:<0.63.0>) client launched, wait 1018.9190235965457 ms before launching next client
ts_launcher:(7:<0.63.0>) client launched, wait 1685.0156394273606 ms before launching next client
ts_launcher:(7:<0.63.0>) client launched, wait 408.53992361334065 ms before launching next client
ts_launcher:(7:<0.63.0>) client launched, wait 204.40900996137086 ms before launching next client
ts_launcher:(7:<0.63.0>) client launched, wait 804.6040921461512 ms before launching next client

��M��来说�Q�每一个用��L��成间隔间不是固定��|��是一个大�U��|��有偏差，但接�q�于目标讑֮��Q?000毫秒生成一个用��h��准间隔）�?/p>

执行模拟�l�端用户会话��程

关于会话的说明：

一个session元素中的定义一�p�d��h��-响应�{�交互行为称之�ؓ一�ơ完整会�?/li>
一个模拟用户需要执行一�ơ完整会话，然后生命周期完成�Q�然后结�?/li>

模拟�l�端用户模块�?code>ts_client�Q�状态机�Q�，挂蝲�?code>ts_client_sup下，�?code>ts_launcher/ts_launcher_static调用ts_client_sup:start_child(Session)启动�Q�是压测��d��的最�l�执行者，承包了所有脏累差的活�Q?/p>

所有下一步需要执行的会话指��o都需要向��L��?code>ts_config_server��h��
执行会话指��o
具体协议调用相应协议插�g�Q�比如ts_mqtt�l�装会话消息
建立�|�络Socket�q�接�Q�封装众多网�l�通道
发送请求数据，处理响应
记录�q�发送监控数据和日志

�K?/p>

��结

��单梳理主从之间启动方式，从机数量分配�{�略�Q�以具体压测��d��如何在从��Z��分配和运行等内容�?/p>

nieyong 2016-07-25 14:02 发表评论

Tsung�W�记之主从模型篇

nieyong — Sat, 23 Jul 2016 03:56:00 GMT

前言

本篇讲解Tsung大致功能�l�成、结构，以及��M��模型�Q�以便��M��上掌握�?/p>

��M��l�成

�K?/p>

tsung_controller �?tsung �q�两个模块，负责分布式压��的核心功能�?/p>

代码�l�成

从代码层�ơ梳理一下tsung��目功能�l�成�l�构�Q�便于一目了�Ӟ��方便直接索引�?/p>

�K?/p>

��M��模型一�?/h3>
讑֮�环境为分布式环境下Tsung集群�Q�下面简单梳理一下主、从节点启动��程�?/p>
�K?/p>
��程大致说明�Q?/p>

主节点（tsung_controller�Q�通过SSH或其它远�E�终端（后面会讲到操作更��量的完全替代SSH方式�Q�连接到从服务器启动tsung从节点运行时环境

主节点RPC扚w��启动tsung client�q�程

主节点�ؓ每一个从节点启动会话监控�Q�控制会话速度�Q�开启ts_client模拟�l�端

从节点请求主节点具体业务�q�程�Q�获取会话指令以及会话具体内�?/li>
从节点徏立到目标压测服务器的SOCKET�|�络�q�接�Q�开始会�?/li>
主节点可以通过SSH/其它�l�端方式�q�接到目标压��服务器�Q�启动从节点�Q�然后收集数据（可选，具体�l�节�Q�后�l�文字会讲到�Q?/li>

�q�种模型下：

全局严格控制模拟�l�端用户生成总量和生成速度

主节点动态管理从节点生命周期�Q�从生到死，�q�且掌握着所有会话细节，全局掌控

从节点很轻，所有需要的会话指��o�Q�都必须��h��主节点获�?/li>

��M��之间交互��程

下面一张图��单说明了��M��之间核心模块交互��程�Q�虽然粗略，核心点也��是涉及��C��?/p>

�K?/p>

后面会对具体协议部分有更��l�论�q��?/p>

一�ơ压��回话（ts_client�Q�工作流�E?/h4>
其实是承接上一个流�E�图�Q�已�l�启动了一个ts_client模块�Q�即执行一个完整生命周期会话模拟终端。它的开启依赖于Tsung Controller启动ts_launch/ts_launch_static模块�?/p>
大致��程囑֦�下：

�K?/p>

会话什么时候结�?/h4>

针对从节点上�Q�（一个终端用��L��Q�一�ơ完整会话（session�Q�：

��h��主节点ts_config模块�Q�获取会话Session信息�Q�包含一�ơ会话需要完成�Q务��L��Count

从节点ts_client 每执行一�ơ事�Ӟ��d��L��Count�?

当Count��gؓ0�Ӟ��说明��d��执行完毕�Q�ts_client生命周期圆满�Q�一�ơ完整会话结�?/li>

从节�Ҏ��分配的所有会话都�l�束了，表示从节点生命周期也会结�?/li>
主节�Ҏ��制的所有从节点都结束了�Q�即所有会话都一一完成�Q�那么整体压��也�l�束了，整个压测��程�l�束

��结

��Z��Erlang天生分布式基因支持，从节点的生死存亡完全受Tsung主节点的控制�Q�按需创徏�Q��Q务完成结束，��M��协调行云��水般顺畅�?/p>

嗯，后面��介�l�主从实现的一些细节�?/p>

nieyong 2016-07-23 11:56 发表评论

nieyong — Fri, 22 Jul 2016 07:36:00 GMT

前言

有测试驱动的开发模式，目的在于��保业务层面功能是准��的�Q�每一�ơ新增、修改等动作��保都不会媄响到现有功能。功能开发完成了�Q�需要部�|�到�U�上�Q�系�l�能够承载多大的用户量呢�Q�这时候就需要借助于性能压测�Q�也�U�C��为压力测试，界定�pȝ��能够承蝲具体定w��上限�Q�从容应对业务的�q�营需要，扩容或羃容，心中有底�?/p>

工欲善其事，必先利其器。掌握一�U�压��工��P��q�切实应用到实践环境中，�q�以此不断�P代，压力��试驱动推动所开发后端应用处理性能逐渐完善�?/p>

目前成熟的支持支持TCP、HTTP�{�连接通道的压��工具不��，以前接触�q�Apache JMeter�Q�后面又接触�q?a href="tsung.erlang-projects.org">Tsung�Q�因为在实际环境下��用比较多�Q�支持丰富的业务场景定义�Q��ƈ且可扩展性强�Q�因此Tsung强力推荐之�?/p>

��Z��么要选择Tsung

��Z��Erlang�Q��ƈ发处理性能好，可以模拟��_��多�v量用��P��只要你有��_��多的机器
受益于Erlang�Q�天然支持分布式�Q�很�Ƣ快的运行在一个集��中
支持协议众多 WebDAV/WebScoket/MQTT/MySQL/PGSQL/Shell/AQMP/JABBER/XMPP/LDAP �{?/li>
传输通道支持 TCP/UDP/SSL�Q�更底层支持IPv4/IPv6
支持单机�l�定多个IP�Q�无论是虚拟IP�Q�还是物理网卡绑定IP�Q�可以突破单机端�?5535的限�Ӟ��扩展��可能多的网�l�连接出口地址
支持监控被压��的服务器，通过Erlang Agent/SNMP/Munin
压测�l�节XML可配�|�，�q�是一个完全基于情景的压力��试行�ؓ清单�Q�依赖于你的惌��Q�呈现完整业务的表达
- 场景可以是动态的�Q�来自于文�g、代码或者服务器响应可以构成下一个请求的参数�Q�这��是可编�E�的��h��?/li>
- 行�ؓ可以��h��Q�回话可以在不同场景中，按照不同的行��范各自��^行进�?/li>
- 休眠�Q�或暂停机制�Q�是可以随机的，�?/li>
- 压测用户产生方式�Q�动态有序或随机

��M��Q�Tsung是一�Ƒּ�源的高性能分布式压力测试工��P��支持可编�E�的情景化测试方案，要向发挥它的�Ҏ��，依赖于�h们的惌��力和创造性�?/p>

��Z��么要压力��试驱动�?�Q?/h3>
软�g/�pȝ��架构往往着��g��M��l�构�Q�这个可以是一个逐渐完善的过�E�。这�U�自我的不断完善的驱动往往来自于实��c��线上考验。而压力测试可以提供一�U�推动，��心��力暴露着架构在性能定w��存在的一些不��_��~�陷�Q�促使着向着更好的方向发展�?/p>
�pȝ��的构��Z��赖于具体参与执行的�h�Q�就��是一��资��q��工程师，业务上每一�ơ功能的快速更�q�、�Q何潜在局部修攚w��会导致媄响、拖垮整体性能�Q�这��是��Z��常说�?�?a >蝴蝶效应“，牵一发而动全��n�?/p>
如何提早感知�q�且提早修复�Q�这��需要压力测试的驱动�Q��ƈ且压力测试应该成��Z��个常规化的例行行为，日常化的动作。在每一�ơ修改之后，都要�q�一轮的压测的碾压之后，提供当前后端应用处理的性能、容量等具体指标�Q�用于指导后�l�业务上�U�业务的开展�?/p>

实际操作上的��

在一般互联网公司�Q�一般线上程序修改后之后�Q�需要经�q�QA团队/部门全部功能回归、校验之后才能够上线�Q�往往�~�少压测环节�Q�因��Z��/她们�q�不保证�pȝ��处理性能和容量是否恶化，�pȝ��的性能建立在系�l��M��的功能上�Q�如何避免在性能上出现”牵一发而动全��n“，��有条件的QA同学/团队考虑增加性能压测环节�Q�功�?+ 性能双重回归�Q�修改媄响点清晰、透明化�?/p>

�W�记列表

本系列笔讎ͼ��Z��tsung-1.6.0源码基础上分析，�q�行环境为Linux Centos 6�?/p>

�W�记列表�Q?/p>

Tsung�W�记之分布式增强跛_��SSH��绊��?/a>

Tsung�W�记之IP直连支持��?/a>

��Z��方便理解�Q�一些用词说明：

主节点，也称之�ؓMaster Node�Q�指的是�q�行tsung_controller的应用服务实例，�q�行tsung启动应用自动产生“tsung_controller@机器�?IP”节点名�U�ͼ�一般��用过Erlang的同学会很明�?/li>
从节点，即tsung client应用实例�Q�对�?tsung/src/tsung ��目代码�Q�由tsung_controller主节�Ҏ��制启动、关闭、�Q务分配等

��结

参与一个实时性交互强的项目，从一开始单机支撑不�?万用戗��^均请求响应时间约900毫秒�Q�到目前混合部��v的单机支�?0万用戗��^均响应时间�ؓ16毫秒�Q�这个过�E�中Tsung不断的压��推动着架构逐渐�E�_��、系�l�承载容量、QPS优化�{�完全达标。这是一个压力测试驱动性能改进的流�E�，每一步的改进能够得到正向反馈�?/p>

�q�一�p�d��W�记�Q�所谈核心是Tsung�Q�无论是认知�q�是改进�Q�最�l�都是�ؓ了理解利器的�Ҏ��面面�Q�方便着手于实践环境中，压测所带来的能量能够驱动我们的�E�序/服务性能提升、稳定运行，�q�而更好方便我们进行容量规划、线上部�|�等�?/p>

nieyong 2016-07-22 15:36 发表评论

亚洲精品tv久久久久久久久久,亚洲不卡av不卡一区二区,亚洲av无码成h人动漫无遮挡

K8S 修改默认 StorageClass

前言

首先�Q�我们有一个Consul KV服务发现�l��g

�W�一步，咨询�C�֌�意见

�W�二步，准备提交

按需调整代码

单元���试依赖

无测试不�~�码

准备文档

验证提交语法规范

�W�三步，提交Pull Request

PR标题格式

填充PR内容

关于依赖��的处理

�W�四步，关于后箋

���结

Apisix 1.5 升���?2.2 �t�坑备忘

零、前�a�

2.1 服务发现配置指��o变了

2.2 upstream对象新增字段discovery_type

二、gRPC当前不支持upstream_id

四、ETCD V2数据�q�移到V3

五、启动apisix后发现ETCD V3已有数据无法加蝲

HTTP API设计�W�记

前言

技术堆栈的选择

HTTP API���要设�?/h2>

���结

Tsung�W�记之IP地址和端口限制突破篇

前言

如何�H�破限制

0. Tsung支持TCP情况

1. 增加IP地址

3. 透明代理模式支持

3.1 启用IP_TRANSPARENT�Ҏ�?/h5> ... ...

3.2 配置可用的额外IP地址

3.3 配置路由规则支持

3.4 �q�阶�Q�我们��用一个新的网�D�专用于���试

���结

Tsung�W�记�?00万用户压���执行步骤篇

前言

如何做分布式百万用户的压��?�Q?/h3> 假定面向���白用户�Q�因此才有了下面可执行的10个步骤用于开展分布式百万用户�?/p> �K?/p> 看着步骤很多�Q�一旦熟悉�ƈ掌握之后�Q�中间可以省却若�q�Ӏ?/p>

1. 阅读Tsung文档

2 ���定压测目标

4. 部��vTsung

5. 下蝲SSH替代者－tsung—rsh

6. �~�写压测内容

7. �q�行Tsung

8. 压测�q�程中，我们该做什�?/h4> �K?/p> 紧密��x��服务器服务状态、资源占用等情况���对了，最好还要作��Z��个终端用户参与到产品体验中去�?/p>

9. 压测�l�束�Q�生成Tsung报表

10. 回顾和�ȝ��

���结

Tsung�W�记之插件编写篇

前言

Tsung插�g工作机制

��Z��么要�~�写插�g

Qmsg协议定义

�~�写一个完整插�?/h3> �q�里��Z��Tsung 1.6.0版本构徏一个Qmsg插�g�Q�假定你懂一些Erlang代码�Q�以及熟悉Tsung一些基本概��c�?/p>

1. 创徏配置文�g

2. 更新DTD文�g

3. 头文�?include/ts_qmsg.hrl

4. XML文�g解析

5. ts_qmsg.erl

6. 如何�~�译

启动Qmsg协议的压��?/h3>

1. 首先启动Qmsg服务器端�E�序

2. �~�写Qmsg压测XML配置文�g

3. 执行压力���试

4. 查看压测报告

���结

Tsung�W�记之监控数据收集篇

前言

压测客户端的监控

日志攉���

Tsung�q�行时诊�?监控

如何获得tsung节点名称

���结

前言

预备知识

单元��试依赖

��结

Apisix 1.5 升��?2.2 �t�坑备忘

HTTP API��要设�?/h2>

��结

3.1 启用`IP_TRANSPARENT`�Ҏ�?/h5>
`...`

3.4 �q�阶�Q�我们��用一个新的网�D�专用于��试

��结

Tsung�W�记�?00万用户压��执行步骤篇

如何做分布式百万用户的压��?�Q?/h3>
假定面向��白用户�Q�因此才有了下面可执行的10个步骤用于开展分布式百万用户�?/p>
�K?/p>
看着步骤很多�Q�一旦熟悉�ƈ掌握之后�Q�中间可以省却若�q�Ӏ?/p>

2 ��定压测目标

5. 下蝲SSH替代者－`tsung—rsh`

8. 压测�q�程中，我们该做什�?/h4>
�K?/p>
紧密��x��服务器服务状态、资源占用等情况��对了，最好还要作��Z��个终端用户参与到产品体验中去�?/p>

��结

�~�写一个完整插�?/h3>
�q�里��Z��Tsung 1.6.0版本构徏一个Qmsg插�g�Q�假定你懂一些Erlang代码�Q�以及熟悉Tsung一些基本概��c�?/p>

3. 头文�?`include/ts_qmsg.hrl`

5. `ts_qmsg.erl`

3. 执行压力��试

��结

日志攉��

��结

��结

SSH为通用�Ҏ��Q�但不是最好的�Ҏ��

SSH替换�Ҏ��Q�一�U�快速租赁模式远�E�终端方�?/h3>
现在需要寻找一�U�新的代替方案，一�U�适应快速租赁的�q�程�l�端实现机制�?/p>

Tsung如何切换切换�Q?/h3>
为tsung启动��d��`-r`参数指定卛_��Q?/p>
`tsung -r ~/.tsung/rsh_client.sh -f tsung.xml start`

��结

内存的媄�?/h3>
一个网�l�Socket�q�接占用不多�Q�但上万个或数十万等��׃��容小觑了�Q�设�|�不当会��D��内存直接成�ؓ屏障�?/p>

XML文�g讄��需要注意部�?/h3>

��结

执行模拟�l�端用户会话��程

��结