パフォーマンスの圧力測定は、プロセスの保証サービスの可用性と安定性の不可欠な部分であるが、性能の関連指標の体系的な共有は、多くの圧力ではありません。この問題から始めて、私たちは紹介します「一緒にテスト・パフォーマンス」のパフォーマンスを測定し、アプリケーションのシナリオ、設計、実装、実行、監視、障害の場所と分析を感知するパフォーマンスの圧力から、より多くの緯度圧力を話題のシリーズを共有する（PTTと呼ばれます）あなたは助けるために、解体のプロセス全体を測定完全な理論的なシステム性能の圧力を構築し、例をフォローする実地体験を提供します。
フェーズI：「環境設計と建設の圧力測定」、話題のプロデューサー|アリババPTSチーム
一般的に、性能テスト環境と本番環境の実現を確実にする圧力は、第一原理の効果的な性能測定圧力の高度に一貫した実装です。時には、それは圧力テスト環境と本番環境とみなされ、微妙な違いがあり、結果が正確でないことを評価を通じて圧力テスト活動につながる可能性があります。
環境性能を考慮すべき要素
1.システム論理アーキテクチャ
システムを構成するシステム・ロジックアーキテクチャは、抽象的構造、アプリケーション間の相互作用を設定されています。最も簡単なのは、最も基本的な3層アーキテクチャです。
図の三層論理構造。
- クライアント層：エンドユーザーに要求します。
- ウェブ層：すべてのサービス論理とサービスデータ側に対するクライアント要求を処理します。
- データベース層：データサービスシステムを維持します。
より複雑なロジック構造
以下は、説明です：
- 任意の層内の論理アーキテクチャは、そこに複数の物理マシンが同じ物理クラスタを共有SPANまたは他の論理層でもよく、別のマシン上の物理クラスタが存在してもよいです
- 論理データ・フロー・アーキテクチャ間の矢印ではなく、物理的なネットワーク接続。
2.物理アーキテクチャ
物理アーキテクチャ
3.ハードウェア、ソフトウェア、およびネットワーク
- ソフトウェア：それは基本ソフトウェア、ミドルウェアになる環境。
- ハードウェア：物理マシン/仮想マシン、スタンドアロン構成（CPU、メモリ、ハードディスクのサイズ）、クラスタサイズ。
- ネットワーク：ネットワークまたはネットワーク外の、ネットワーク帯域幅、クロスセグメントかどうか分離の問題があるかどうか。
唯一のより多くの圧力シミュレーションテスト環境の設計を支援しませミドルウェアの理解を持っているだけでなく、プロセスで測定された圧力に貢献し、ボトルネックをスピードアップ、検索し、問題を解決するためにシステムが使用するソフトウェア。
異なる特性測定された圧力環境比較長所と短所
比較表
| 環境プログラムを測定する圧力 | 該当シーン | 利点 | 短所 | 費用 | アリアリクラウドとクライアントアプリケーション |
|---|---|---|---|---|---|
| 本番環境のサブセット、サーバ少量の、ロープロファイル | 项目开发交付初期,对应用本身进行性能问题探测 | 1.基于已有的测试环境搭建,相对难度小 2.成本较低 | 1.不完全仿真,无法压到全链路的问题,基础设施的瓶颈问题 | 低 | 阿里内部有一套独立完整的线下性能压测环境,与应用发布管理系统打通,被大量应用于项目开发前期的性能瓶颈探测场景 |
| 生产环境子集,少量服务器,同配置 | 服务器规模按照生产环境规模缩放,适用于容量探测 | 相比第一种压测结果更可信 | 1.按比例缩放的环境,压测结果也不能完全可信 2.底层基础设施的问题可能遗漏 | 较低 | 阿里内部智能容量规划系统所依赖的环境就是这种,按比例缩放的同配置压测环境 |
| 生产环境完全复制版 | 最理想的压测环境 | 1.压测效果能够保证 2.不受时间限制,随时可压 3.完全不影响生产环境的数据以及用户访问 | 1.成本相对高 2.单凭压测人员搭建,复杂度高 3.存在后续维护成本 | 高 | 阿里云上,PTS已有客户使用该复制环境进行全仿真的性能压测。阿里云上快速复制系统一样的环境用于压测,操作简单快捷 |
| 生产环境 | 评测生产环境性能的最直接真实的 | 1.压测结果易于被认可。2.节约成本 3.压测基础设施易于部署 | 1.影响线上真实的用户访问,所以需要在业务低谷进行 2.数据写入需要想办法进行隔离 | 较低 | 电商系的全链路压测,基于真实的线上生产环境进行 |
不管哪种压测环境方案，在落地成本，满足需求程度上都有区别，接下来对几种压测环境结合在阿里的应用进行介绍。
1、低配生产环境子集-研发阶段性能瓶颈发现
既然是低配环境,压出来的数据似乎完全不能用作生产环境运行的参考,但实际上,这种环境下的压测,也是非常重要的一环。主要体现在项目研发阶段的价值上。
方案价值
- 新应用上线前,应用代码本身的瓶颈发现。代码本身的性能问题,例如连接未释放,线程数过多,通过低配的环境,一定时长的压测完全可以提前发现很多。
- 应用维度基线数据。跑出来的数据不能给线上做参考,但是如果每次迭代,发布前,都在同一套低配环境运行性能压测,跟低配基线数据进行对比,也能起到衡量系统迭代的时候,性能是否有提升或者下降的参考。
- 帮助研发进行快速的性能调优。系统越复杂的时候,发生性能问题后定位的难度会指数增加。进行过性能调优的研发都有体会,有时候调优,就是改一个配置,然后重新部署,跑压测,看结果是不是改善了,直到找到最佳的配置。这个过程如果不能轻量起来,对于研发调优就是噩梦。
存在的问题
构建低配环境,可以是普通的测试环境,跟线上完全隔离。但是要解决以下问题
- 压测会影响测试环境的功能测试。这一点很容易理解。压力大了,可能影响同一套测试环境的功能测试结果,所以性能压测环境最好独立。
- 依赖的基础应用在性能测试中没有。例如要压测的目标业务是发贴,肯定会依赖到用户相关的业务,用户中心就是一个基础应用(当然很多小型公司可能没独立这块业务)。
- 研发阶段无法快速部署要压的分支。有一点规模的互联网公司,一周的迭代,同一个应用可能会有多个分支,需要支持快速部署指定的分支到性能环境。
如何解决
阿里内部有一套完整的系统用于支撑阿里内部每日成千上万的研发阶段的性能压测需求。
2、同配生产环境子集-容量规划
方案的挑战
- 容量规划是一个持续的过程,如何减少人力投入,如何才能“无人值守”。
- 成本和效果平衡:尽量贴近线上运行环境,同时容量规划的数据对线上容量布置有很好的指导作用。
- 完全独立不影响线上。
- 随时可运行,结果可跟踪。
存在的问题
容量规划不是直接在生产环境进行的,因为生产环境的最终容量配比,是参考自容量规划产出的数据。在生产环境进行的压测,是最后的验收阶段,在容量规划完成之后。
提供一套独立的的生产环境子集-隔离环境,用于容量规划要解决的问题：
- 构建的环境集如何定义,规模和架构如何贴近线上。
- 流量如何走到隔离环境。
- 隔离环境写的数据是否需要清理，如何清理?
解决方案
想详细了解,阿里容量规划的技术演进可参考这里。
现在隔离环境就是最新容量规划生态中的重要基础。隔离环境的支持，才能支撑常态化的容量规划运行，持续不断的改进。
- 首先,提炼机器比例。基于线上核心应用的现有规模情况,提炼出一个缩小版的完全模型。即线上机器之间的比可能是5000:2000:1000,整体比例缩放100倍,在隔离环境的机器比是50:20:10。使用这种方式,有效的保证了同线上机器同比例,同时成本上做了很好的控制。
- 其次,确定隔离目标流量。根据接下来线上的目标流量大小,同比例计算出隔离环境应该支撑的流量,作为隔离环境打压测流量时的目标流量。
- 然后,通过压测流量从小到目标流量探索,边压边弹。
- 最后,收集隔离环境达到目标流量后,新的机器比例及数据。应用间的比例关系很可能已经有了改变,有的应用可能缩容,有的应用可能扩容,作为线上机器关系的参考。
当然这里面的涉及的技术细节还有很多:
- 全链路压测新应用：整个压测流量其实是沿用了线上压测的全链路压测机制,带流量标,数据落影子库的方式, 所以隔离环境写的数据不需要特殊的处理。
- 环境标隔离环境：流量同时会带上一个“环境标”,通过环境标的识别,接入层会把流量导到隔离环境,从而做到流量的环境隔离。
- PTS首创"RPS"模式施压：在系统整体的流量数据获取上,我们摒弃了一直依赖备受追捧的"并发量"的方式。众所周知,业务提出来的目标一般会是,"希望峰值支持xxxx个用户登陆"这种,进行容量规划的时候需要将并发的用户数跟系统能承受的QPS,进行一个映射关系。我们容量规划就直接使用阿里云压测平台(PTS)的"RPS"模式,压出来拿到的QPS数据,直接是系统维度的数据,不用转换,这样也更减少了转换过程中的失真。
- 边压边弹技术：在隔离环境压测中,何时弹新机器,弹多少机器,整个过程如何控制,这里面包含了一整套完整精密的算法。整个过程示意图如下。
3、生产环境复制版-云时代的优势
面临的挑战
生产环境复制版面临的挑战非常多：
其中,如果要对生产环境进行完全的复制,将要面临以下挑战
- 复制生产环境服务器的架构
- 复制生产环境网络基础环境
- 复制生产环境的所有应用分层
- 网络带宽
- 数据库以及所有的基础数据集
- 负载均衡
- ......
存在的问题
对于传统时代的压测工程师来说,这样一系列的操作,就是新搭建一套“影子系统”了,看起来有点像不可能完成的任务。要完成上述任务，压测工程师面临巨大的挑战：
- 沟通协调几乎所有的技术部门(开发、运维、网络、IT...);
- 如果即用即销毁,那么劳民损财只用个一两次,成本太大;
- 如果持续维护，那么维护成本显然同样不可忽略;
所以我们很少看到有公司进行这样的“生产环境复制”操作。小型公司可能没那么多人力实现,大中型公司，成本就更加难以接受了。但是现在云化趋势的潮流中,这种方案开始体现出优其越性了。
解决方案
我们先看一下阿里云的产品架构图
产品服务非常丰富,但是不太利于我们理解和复制线上环境用于压测这个主题。具体到某一个场景的系统在阿里云的落地:
图片出处：https://rensanning.iteye.com/blog/2303440
搭建一个云上应用的最小集应该需要用到：
- SLB-用来负载均衡；
- ECS-用来部署业务应用；
- RDS-用来存储业务数据；
あなたは、オンライン上のアリの雲システム以上のものをコピーしたい場合。
STEP1購入ECSの同一構成のクラスタのサイズに合わせ、アプリケーションの展開、
STEP2コピーオンラインRDS;
STEP3 SLBは、新しいエントリを設定し、レプリケーション環境をポイントし、
STEP4スタートラインの圧力測定、
アリの雲のコピーで本番環境には次の利点があります。
- 簡単操作。ビジュアルインターフェース、システムがインストール構成をセットアップする必要があります。アリクラウド上の圧力測定PTSサービスに関するスポットは、性能と環境破壊、圧力エンジニアの完全な解放を構築するためのファンクションキーを提供する機会を持つことになります。
- クリア情報アーキテクチャ。アリクラウド上の「アーキテクチャ対応」機能は、あなたが視覚的にアリ雲、正確かつ直感的に全体的なビジネスシステムアーキテクチャに加えて描くことができ、圧力テストエンジニアはまた、システムをコーミングアーキテクチャに長い時間を費やす不正確な問題の可能性に直面する必要はありません。
- これは、使用してコスト削減に破壊されます。それは十分に複雑なシステムであればコピーオンライン環境は、多成分、大量の使用は、コストは確かに考慮されます。伝統的な時代の建物自体のコストは、維持・再構築も高いし続けるためにコスト高です。しかし、クラウドの時代には、いくつかのボタンを構築する点である、従量課金、完全な検証が非常によく、廃棄物の制御リソースコストのためにリリースされ、いくつかのボタンの破壊過程を指します。
- 状況に応じて比例機は自由に調節することができます。もちろん、すぐにレプリケーションのサブセットと同じ本番環境とクラウドに低くすることができ、非クラウドベースのシステムに比べても、明らかな利点があります。
本番環境 - 決まり文句
分散型圧力測定の性能に、圧力測定は、完全なリンク技術なしで行うことはできません。現在、多くのインターネット企業が、独自のフルリンク圧力測定システムを構築が開始され、我々は完全なリンク電圧測定モデル図にアリの練習を集中します。
もっと練習、あなたがクリックすることができ、ここで
概要
- 性能圧力測定環境のシミュレーションは、圧力の効果的な性能測定を実施するための前提条件です。
- 別の圧力測定環境は異なるアプリケーションシナリオを持って、企業が自らの状況に応じて選択する必要があります。
- 中小規模の企業は、コストと保守性を測定孤立独立した環境圧力のセットを構築します。
- 圧力測定パフォーマンスのクラウドの時代には、アリクラウド上のPTSは、効果的な圧力測定大きな可能性をもたらすために。
著者：
翔玲（ニックネーム）：アリババ技術専門家は、組織とクラウド時代の最近のパフォーマンスは、アイデアや圧力測定基準、性能試験GBクラウドコンピューティングプロジェクトチームのメンバー、担当予熱システムにおける人物の支援システムの内部安定性を促進するためにつながる研究開発をPTS 。