👩🏼‍🏭 🔪 🙈 数十万人の仮想ユーザーによるゲームの負荷テスト 🚧 🛍️ 🧙🏻

こんにちは、Habr！

私は、オンラインゲームを開発するゲーム会社で働いています。現在、私たちのゲームはすべて多くの「市場」（国ごとに1つの「市場」）に分割されており、各「市場」には、登録時にプレーヤーが分散される（まあ、時には自分で選択できる）世界があります。各世界には、1つのデータベースと1つ以上のWeb /アプリサーバーがあります。したがって、負荷は世界/サーバー間でほぼ均等に分割および分散され、その結果、1つの世界の「プライム」時間ごとに6K-8Kプレーヤーの最大オンライン（これが最大で、ほとんどの場合数倍少ない）と200-300のリクエストを取得します。

プレーヤーを市場と世界に分割するこのような構造は時代遅れになりつつあり、プレーヤーはグローバルなものを求めています。最後のゲームでは、国ごとに人を分けるのをやめて、1つまたは2つの市場（アメリカとヨーロッパ）だけを残しましたが、それぞれに多くの世界がありました。次のステップは、新しいアーキテクチャを備えたゲームの開発と、 1つのデータベースで1つの世界のすべてのプレイヤーを統合することです。

今日、私たちの人気ゲームのオンライン全体（一度に5万から20万人のユーザー）が新しいアーキテクチャで構築された次のゲームをプレイするために「送信」するかどうかを確認するタスクについて、少しお話ししたかったのです。システム全体、特にデータベース（ PostgreSQL 11 ）は、このような負荷に実際に耐えることができ、もしそれができない場合は、最大値を見つけます。発生した問題と、非常に多くのユーザーをテストするための準備、プロセス自体、および結果について少し説明します。

イントロ

過去には、 InnoGames GmbHで、各ゲームチームは好みや色に合わせてゲームプロジェクトを作成し、多くの場合、さまざまなテクノロジー、プログラミング言語、データベースを使用していました。さらに、支払い、プッシュ通知の送信、マーケティングなどを担当する多くの外部システムがあります。これらのシステムを使用するために、開発者は独自のインターフェイスをできる限り作成しました。

現在、モバイルゲームビジネスでは多額のお金があり、それに応じて多くの競争があります。ここでは、マーケティングに費やした各ドルとそれ以上の金額からそれを取り戻すことが非常に重要です。したがって、すべてのゲーム会社は、分析の期待を満たしていない場合、クローズドテストの段階でもゲームを「クローズ」することが非常に多くあります。したがって、次の車輪の発明に時間を費やすことは不採算であるため、すべての外部システム、レプリケーションを備えたデータベース、すべてのベストプラクティスと統合するためのターンキーソリューションを開発者に提供する統合プラットフォームを作成することが決定されました。開発者が必要とするのは、この上に良いゲームを開発して「置く」ことであり、ゲーム自体に関係しない開発に時間を浪費しないことです。

このプラットフォームはGameStarterと呼ばれます：

だから、ポイントに。今後のInnoGamesゲームはすべて、このプラットフォーム上に構築されます。このプラットフォームには、マスターとゲームの2つのデータベースがあります（PostgreSQL 11）。マスターは、プレーヤーに関する基本情報（ログイン、パスワードなど）を保存し、主にゲーム自体のログイン/登録のプロセスでのみ参加します。ゲーム-ゲーム自体のデータベース。それに応じて、すべてのゲームデータとエンティティが保存されます。これは、ロード全体が行われるゲームのコアです。

したがって、このデザイン全体が、最も人気のあるゲームの最大オンラインに匹敵する潜在的なユーザー数に耐えられるかどうかという疑問が生じました。

挑戦する

タスク自体は次のとおりです：レプリケーションが有効になっているデータベース（PostgreSQL 11）が、最も負荷の高いゲームで現在持っているすべての負荷に耐えることができるかどうかを確認し、PowerEdge M630ハイパーバイザー（HV）全体を自由に使います。

現時点でのタスクは、ベストプラクティスと私たち自身の経験を考慮して作成した既存のデータベース構成を使用して確認することだけであることを明確にします。

データベースをすぐに言うと、いくつかの点を除いて、システム全体がうまく表示されています。しかし、この特定のゲームプロジェクトはプロトタイプ段階であり、将来、ゲームメカニクスの複雑化により、データベースへのリクエストはより複雑になり、負荷自体が大幅に増加し、その性質が変わる可能性があります。これを防ぐには、多かれ少なかれ重要なマイルストーンごとにプロジェクトを繰り返しテストする必要があります。この種のテストを数十万人のユーザーで実行する機能を自動化することが、この段階の主なタスクになりました。

プロフィール

負荷テストと同様に、すべて負荷プロファイルから始まります。

潜在的な値CCU60（CCUは特定の期間、この場合は60分間の最大ユーザー数）は250,000ユーザーと見なされます。競争力のある仮想ユーザー（VU）の数はCCU60よりも少なく、アナリストは安全に2つに分割できることを示唆しています。 150,000の競合VUを切り上げて受け入れます。

1秒あたりのリクエストの総数は、ロードされた1つのゲームから取得されました。

したがって、目標負荷は150,000 VUで最大20,000リクエスト/秒です。

構造

「スタンド」の特徴

前回の記事で、負荷テストのプロセス全体の自動化について既に説明しました。さらに、少し繰り返しますが、いくつかのポイントについて詳しく説明します。

図では、青い四角がハイパーバイザー（HV）であり、多数のサーバー（Dell M620-M640）で構成されるクラウドです。各HVで、KVMを介して多数の仮想マシン（VM）が起動されます（web / appおよびdbが混在）。新しいVMを作成すると、適切なHVのパラメーターセットのバランス調整と検索が行われ、最初にどのサーバーに接続するかが不明です。

データベース（ゲームDB）：

しかし、db1の目的のために、 M630に基づいて別のHV targer_hypervisorを予約しました。

targer_hypervisorの簡単な特徴：

デルM_630

モデル名：Intel®Xeon®CPU E5-2680 v3 @ 2.50GHz

CPU（s）：48

コアあたりのスレッド：2

ソケットあたりのコア：12

ソケット：2

RAM：128 GB

Debian GNU / Linux 9（ストレッチ）

4.9.0-8-amd64＃1 SMP Debian 4.9.130-2（2018-10-27）

詳細仕様

Debian GNU / Linux 9（ストレッチ）

4.9.0-8-amd64＃1 SMP Debian 4.9.130-2（2018-10-27）

lscpu

アーキテクチャ：x86_64

CPU op-mode（s）：32ビット、64ビット

バイト順：リトルエンディアン

CPU（秒）：48

オンラインCPU（s）リスト：0-47

コアあたりのスレッド：2

ソケットあたりのコア：12

ソケット：2

NUMAノード：2

ベンダーID：GenuineIntel

CPUファミリー：6

モデル：63

モデル名：Intel®Xeon®CPU E5-2680 v3 @ 2.50GHz

ステッピング：2

CPU MHz：1309.356

CPU最大MHz：3300.0000

CPU最小MHz：1200.0000

BogoMIPS：4988.42

仮想化：VT-x

L1dキャッシュ：32K

L1iキャッシュ：32K

L2キャッシュ：256K

L3キャッシュ：30720K

NUMA node0 CPU（s）：0,2,4,6,8,10,12,14,16,18,20,22,24,26,28,30,32,34,36,38,40,42 44.46

NUMA node1 CPU（s）：1,3,5,7,9,11,13,15,17,19,21,23,25,27,29,31,33,35,37,39,41,43 、45.47

フラグ：fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lpcpqpqpcpc bpcpc bpcpc bpcpc bpcpc bppc bppc SMX EST TM2 SSSE3 SDBG FMA cx16 xtpr PDCM PCID DCA sse4_1 sse4_2 x2apicにMOVBE POPCNT tsc_deadline_timer AES xsave AVX f16c rdrand lahf_lm ABM EPB invpcid_single SSBD IBRS ibpb stibpカイザーtpr_shadow vnmi flexpriority EPT VPID fsgsbase tsc_adjust BMI1 AVX2 SMEP bmi2 ERMS invpcid CQM xsaveopt cqm_llc cqm_occup_llc dtherm IDA arat pln pts flush_l1d

/ usr / bin / qemu-system-x86_64 --version

QEMUエミュレーターバージョン2.8.1（Debian 1：2.8 + dfsg-6 + deb9u5）

Copyright©2003-2016 Fabrice BellardおよびQEMUプロジェクト開発者

db1の簡単な特徴：

アーキテクチャ：x86_64

CPU（s）：48

RAM：64 GB

4.9.0-8-amd64＃1 SMP Debian 4.9.144-3.1（2019-02-19）x86_64 GNU / Linux

Debian GNU / Linux 9（ストレッチ）

psql（PostgreSQL）11.2（Debian 11.2-1.pgdg90 + 1）

いくつかの説明付きのPostgreSQL設定

seq_page_cost = 1.0

random_page_cost = 1.1＃SSDがあります

「/etc/postgresql/11/main/extension.conf」を含める

log_line_prefix = '％t [％p-％l]％q％u @％h'

log_checkpoints = on

log_lock_waits = on

log_statement = ddl

log_min_duration_statement = 100

log_temp_files = 0

autovacuum_max_workers = 5

autovacuum_naptime = 10s

autovacuum_vacuum_cost_delay = 20ms

vacuum_cost_limit = 2000

maintenance_work_mem = 128MB

synchronous_commit = off

checkpoint_timeout = 30分

listen_addresses = '*'

work_mem = 32MB

effective_cache_size = 26214MB＃利用可能なメモリの50％

shared_buffers = 16384MB＃使用可能なメモリの25％

max_wal_size = 15GB

min_wal_size = 80MB

wal_level = hot_standby

max_wal_senders = 10

wal_compression = on

archive_mode = on

archive_command = '/ bin / true'

archive_timeout = 1800

hot_standby = on

wal_log_hints = on

hot_standby_feedback = on

hot_standby_feedbackはデフォルトでオフになっており、オンにしましたが、テストを成功させるにはオフにする必要がありました。理由は後で説明します。

データベースの主要なアクティブテーブル（construction、production、game_entity、building、core_inventory_player_resource、survivor）には、bashスクリプトを使用してデータ（約80GB）が事前に入力されています。

db-fill-script.sh

#!/bin/bash --clean TRUNCATE TABLE production CASCADE; TRUNCATE TABLE construction CASCADE; TRUNCATE TABLE building CASCADE; TRUNCATE TABLE grid CASCADE; TRUNCATE TABLE core_inventory_player_resource CASCADE; TRUNCATE TABLE survivor CASCADE; TRUNCATE TABLE city CASCADE; TRUNCATE TABLE game_entity CASCADE; TRUNCATE TABLE player CASCADE; TRUNCATE TABLE core_player CASCADE; TRUNCATE TABLE core_client_device CASCADE; --core_client_device INSERT INTO core_client_device (id, creation_date, modification_date, device_model, device_name, locale, platform, user_agent, os_type, os_version, network_type, device_type) SELECT (1000000000+generate_series(0,999999)) AS id, now(), now(), 'device model', 'device name', 'en_DK', 'ios', 'ios user agent', 'android', '8.1', 'wlan', 'browser'; --core_player INSERT INTO core_player (id, guest, name, nickname, premium_points, soft_deleted, session_id, tracking_device_data_id) SELECT (1000000000+generate_series(0,999999)) AS id, true, 'guest0000000000000000000', null, 100, false, '00000000-0000-0000-0000-000000000000', (1000000000+generate_series(0,999999)) ; --player INSERT INTO player (id, creation_date, modification_date, core_player_id) SELECT (1000000000+generate_series(0,999999)) , now(), now(), (1000000000+generate_series(0,999999)) ; --city INSERT INTO game_entity (id, type, creation_date, modification_date) SELECT (1000000000+generate_series(0,999999)) , 'city', now(), now(); INSERT INTO city (id, game_design, player_id) SELECT (1000000000+generate_series(0,999999)) , 'city.default', (1000000000+generate_series(0,999999)) ; --survivor INSERT INTO game_entity (id, type, creation_date, modification_date) SELECT (1001000000+generate_series(0,999999)) , 'survivor', now(), now(); INSERT INTO survivor (id, game_design, owning_entity_id, type) SELECT (1001000000+generate_series(0,999999)) , 'survivor.prod_1', (1000000000+generate_series(0,999999)) , 'survivor'; --core_inventory_player_resource INSERT INTO core_inventory_player_resource (id, creation_date, modification_date, amount, player_id, resource_key) SELECT (1000000000+generate_series(0,1999999)) , NOW(), NOW(), 1000, (1000000000+generate_series(0,1999999)/2) , CONCAT('resource_', (1000000000+generate_series(0,1999999)) % 2); --grid DROP INDEX grid_area_idx; INSERT INTO grid (id, creation_date, modification_date, area, city_id) SELECT (1000000000+generate_series(0,19999999)) , NOW(), NOW(), BOX '0,0,4,4', (1000000000+generate_series(0,19999999)/20) ; create index on grid using gist (area box_ops); --building INSERT INTO game_entity (id, type, creation_date, modification_date) SELECT (1002000000+generate_series(0,99999999)) , 'building', now(), now(); INSERT INTO building (id, game_design, owning_entity_id, x, y, rotation, type) SELECT (1002000000+generate_series(0,99999999)) , 'building.building_prod_1', (1000000000+generate_series(0,99999999)/100) , 0, 0, 'DEGREES_0', 'building'; --construction INSERT INTO construction (id, creation_date, modification_date, definition, entity_id, start) SELECT (1000000000+generate_series(0,1999999)) , NOW(), NOW(), 'construction.building_prod_1-construction', (1002000000+generate_series(0,1999999)*50) , NOW(); --production INSERT INTO production (id, creation_date, modification_date, active, definition, entity_id, start_time) SELECT (1000000000+generate_series(0,49999999)) , NOW(), NOW(), true, 'production.building_prod_1_production_1', (1002000000+generate_series(0,49999999)*2) , NOW();

複製：

 SELECT * FROM pg_stat_replication; pid | usesysid | usename | application_name | client_addr | client_hostname | client_port | backend_start | backend_xmin | state | sent_lsn | write_lsn | flush_lsn | replay_lsn | write_lag | flush_lag | replay_lag | sync_priority | sync_state -----+----------+---------+---------------------+--------------+---------------------+-------------+-------------------------------+--------------+-----------+------------+------------+------------+------------+-----------------+-----------------+-----------------+---------------+------------ 759 | 17035 | repmgr | xl1db2 | xxxx | xl1db2 | 51142 | 2019-01-27 08:56:44.581758+00 | | streaming | 18/424A9F0 | 18/424A9F0 | 18/424A9F0 | 18/424A9F0 | 00:00:00.000393 | 00:00:00.001159 | 00:00:00.001313 | 0 | async 977 | 17035 | repmgr | xl1db3 |xxxxx | xl1db3 | 42888 | 2019-01-27 08:57:03.232969+00 | | streaming | 18/424A9F0 | 18/424A9F0 | 18/424A9F0 | 18/424A9F0 | 00:00:00.000373 | 00:00:00.000798 | 00:00:00.000919 | 0 | async

アプリケーションサーバー

次に、さまざまな構成と容量の生産性の高いHV（prod_hypervisors）で、15個のアプリサーバー（8コア、4GB）が起動されました。主に言えることは、openjdk 11.0.1 2018-10-16、春、 hikari （hikari.maximum-pool-size：50）を介したデータベースとの相互作用です

ストレステスト環境

負荷テスト環境全体は、1つのメインサーバーadmin.loadtestと複数のgeneratorN.loadtestサーバーで構成されています（この場合は14個ありました）。

generatorN.loadtest- 「裸の」VM Debian Linux 9、Java 8がインストール済み。32カーネル/ 32ギガ。重要なVMのパフォーマンスを誤って殺さないように、非生産的なHVに配置されています。

admin.loadtest -Debian Linux 9 仮想マシン 、16コア/ 16ギグ、Jenkins、JLTC、およびその他の重要でない追加ソフトウェアが動作します。

JLTC- jmeter負荷テストセンター。テストの起動と結果の分析を制御および自動化するPy / Djangoのシステム。

テスト起動スキーム

テストを実行するプロセスは次のようになります。

テストはJenkinsから開始されます。必要なジョブを選択してから、目的のテストパラメーターを入力する必要があります。
- DURATION-テスト期間
- RAMPUP- 「ウォームアップ」時間
- THREAD_COUNT_TOTAL-仮想ユーザー（VU）またはスレッドの希望数
- TARGET_RESPONSE_TIMEは重要なパラメーターです。これにより、システム全体が過負荷にならないように、希望する応答時間を設定します。したがって、テストでは、システム全体の応答時間が指定された時間を超えないレベルで負荷を維持します。
打ち上げ
JenkinsはGitlabからテスト計画を複製し、JLTCに送信します。
JLTCは、テスト計画で少し動作します（たとえば、CSVシンプルライターを挿入します）。
JLTCは、必要な数のVU（THREAD_COUNT_TOTAL）を実行するために必要なJmeterサーバーの数を計算します。
JLTCは各loadgeneratorNジェネレーターに接続し、jmeterサーバーを起動します。

テスト中に、 JMeterクライアントは結果を含むCSVファイルを生成します。そのため、テスト中にデータの量とこのファイルのサイズは途方もないペースで増加し、テスト後の分析には使用できません-Daemonが （実験として）発明され、 「オンザフライ」で解析されます。

テスト計画

ここからテスト計画をダウンロードできます。

登録/ログイン後、ユーザーは特定のゲーム機能の確率を指定する複数のスループットコントローラーで構成される動作モジュールで作業します。各スループットコントローラーには、機能を実装する対応するモジュールを参照するモジュールコントローラーがあります。

オフトピック

スクリプトの開発中に、Groovyを最大限に活用しようとしましたが、Javaプログラマのおかげで、自分自身にいくつかのトリックを発見しました（誰かに役立つかもしれません）。

テスト計画の最初のどこかで関数を宣言し、それを他のプリプロセッサ、ポストプロセッサ、およびサンプラーで使用できます。 Groovyの良さ：メソッドをクロージャーに変える：

 //     - def sum(Integer x, Integer y) { return x + y } vars.putObject('sum', this.&sum) //      closure.   . //     sampler`       def sum= vars.getObject('sum'); println sum(2, 2);

groovy.json.JsonSlurperは優れた高速JSONパーサーです。 groovyとともに、データをエレガントに解析して処理することができます。

 import groovy.json.JsonSlurper def canBuild = vars.getObject(canBuild); // ""       def content = jsonSlurper.parseText(response).content def buildings = content[0].buildings //         //               def constructableBuildingDefs = buildings .collect { k,v -> v } .grep{ it.definitions .grep { it2 -> it2['@type'] == 'type.googleapis.com/ConstructionDefinitionDTO'} .grep { it2 -> canBuild(it2) } //   .size() > 0 } if (!constructableBuildingDefs) { return; } Collections.shuffle(constructableBuildingDefs) //

VU /スレッド

Jenkinsジョブを構成するときに、ユーザーがTHREAD_COUNT_TOTALパラメーターを使用して必要な数のVUを入力すると、何らかの方法で必要な数のJmeterサーバーを起動し、それらの間で最終的な数のVUを分配する必要があります。この部分は、 controller / provisionと呼ばれる部分のJLTCにあります。

基本的に、アルゴリズムは次のとおりです。

必要な数のVU threads_numを200-300スレッドに分割し、適切なサイズ-Xmsm -Xmxmに基づいて、1つのjmeter-server required_memory_for_jri （JRI-Jmeter-serverの代わりにJmeterリモートインスタンスを呼び出します）に必要なメモリ値を決定します。
threads_numとrequired_memory_for_jriから、jmeter-serverの合計数： target_amount_jriと必要なメモリの合計値：required_memory_totalを見つけます。
すべてのloadgeneratorNジェネレーターを1つずつソートし、使用可能なメモリに基づいて最大数のjmeterサーバーを開始します。実行中のcurrent_amount_jriインスタンスの数がtarget_amount_jri と等しくなるまで 。
（ジェネレーターと合計メモリーの数が十分でない場合は、新しいものをプールに追加します）

各ジェネレーターに接続し、 netstatを使用してすべてのビジーポートを記憶し、必要な数のjmeterサーバーをランダムポート（空いているポート）で実行します。

  netstat_cmd= 'netstat -tulpn | grep LISTEN' stdin, stdout, stderr = ssh.exec_command(cmd1) used_ports = [] netstat_output = str(stdout.readlines()) ports = re.findall('\d+\.\d+\.\d+\.\d+\:(\d+)', netstat_output) ports_ipv6 = re.findall('\:\:\:(\d+)', netstat_output) p.wait() for port in ports: used_ports.append(int(port)) for port in ports_ipv6: used_ports.append(int(port)) ssh.close() for i in range(1, possible_jris_on_host + 1): port = int(random.randint(10000, 20000)) while port in used_ports: port = int(random.randint(10000, 20000)) # ...  Jmeter-

実行中のすべてのjmeter-serverをフォーマットアドレスで一度に収集します：port、たとえばgenerator13：15576、generator9：14015、generator11：19152、generator14：12125、generator2：17602

結果のリストとthreads_per_hostは、テストの開始時にJMeterクライアントに送信されます。

 REMOTE_TESTING_FLAG=" -R $REMOTE_HOSTS_STRING" java -jar -Xms7g -Xmx7g -Xss228k $JMETER_DIR/bin/ApacheJMeter.jar -Jserver.rmi.ssl.disable=true -n -t $TEST_PLAN -j $WORKSPACE/loadtest.log -GTHREAD_COUNT=$THREADS_PER_HOST $OTHER_VARS $REMOTE_TESTING_FLAG -Jjmeter.save.saveservice.default_delimiter=,

私たちの場合、テストは300のJmeterサーバー、それぞれ500スレッドから同時に行われ、Javaパラメーターを使用した1つのJmeterサーバーの起動形式は次のようになりました。

 nohup java -server -Xms1200m -Xmx1200m -Xss228k -XX:+DisableExplicitGC -XX:+CMSClassUnloadingEnabled -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=70 -XX:+ScavengeBeforeFullGC -XX:+CMSScavengeBeforeRemark -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -Djava.net.preferIPv6Addresses=true -Djava.net.preferIPv4Stack=false -jar "/tmp/jmeter-JwKse5nY/bin/ApacheJMeter.jar" -Jserver.rmi.ssl.disable=true "-Djava.rmi.server.hostname=generator12.loadtest.ig.local" -Duser.dir=/tmp/jmeter-JwKse5nY/bin/ -Dserver_port=13114 -s -Jpoll=49 > /dev/null 2>&1

50ms

タスクは、データベースとシステム全体をクリティカルな状態に過負荷にするのではなく、データベースがどれだけ耐えられるかを判断することです。非常に多くのJmeterサーバーでは、何らかの方法で負荷を特定のレベルに維持し、システム全体を強制終了する必要はありません。テストの開始時に指定されたTARGET_RESPONSE_TIMEパラメーターがこれを担当します。システムが責任を負うべき最適な応答時間は50ミリ秒であることに同意しました。

JMeterには、デフォルトでスループットを制御できるさまざまなタイマーがありますが、このケースではどこで入手できるかはわかりません。しかし、 現在のシステム応答時間を使用して何かを思い付くことができるJSR223-Timerがあります。タイマー自体はメインのBehaviorブロックにあります：

 //      = 0 vars.put('samples', '20'); vars.putObject('respAvg', ${TARGET_RESPONSE_TIME}.0); vars.putObject('sleep', 0.0); //  JSR223-Timer           "" double sleep = vars.getObject('sleep'); double respAvg = vars.getObject('respAvg'); double previous = sleep; double target = ${TARGET_RESPONSE_TIME}; if (respAvg < target) { sleep /= 1.5; } if (respAvg > target) { sleep *= 1.1; } sleep = Math.max(10, sleep); //      sleep = Math.min(20000, sleep); vars.putObject('sleep', sleep); return (int)sleep;

結果の分析（デーモン）

Grafanaのグラフに加えて、テストを集約してJLTCでテストを比較できるようにする必要もあります。

そのようなテストの1つは1秒あたり16kから20kの要求を生成し、4時間で数百GBのサイズのCSVファイルを生成することは簡単に計算できるため、毎分データを解析し、データベースに送信してメインファイルを消去するジョブを考え出す必要がありました。

アルゴリズムは次のとおりです。

jmeter-clientによって生成されたCSVファイルresult.jtlからデータを読み取り、ファイルを覚えてクリーニングします（正しくクリーニングする必要があります。そうしないと、空のファイルは同じサイズの同じFDになります）。

 with open(jmeter_results_file, 'r+') as f: rows = f.readlines() f.seek(0) f.truncate(0) f.writelines(rows[-1])

読み取りデータを一時ファイルtemp_result.jtlに書き込みます。

 rows_num = len(rows) open(temp_result_filename, 'w').writelines(rows[0:rows_num]) # avoid last line

ファイルtemp_result.jtlを読み取ります。読み取りデータを「数分で」配布します。

 for r in f.readlines(): row = r.split(',') if len(row[0]) == 13: ts_c = int(row[0]) dt_c = datetime.datetime.fromtimestamp(ts_c/1000) minutes_data.setdefault(dt_c.strftime('%Y_%m_%d_%H_%M'), []).append(r)

minutes_dataからの各分のデータは、 to_parse /フォルダー内の対応するファイルに書き込まれます。（したがって、現時点では、テストの1分ごとに独自のデータファイルがあり、集約中に各ファイルにデータが入った順番は関係ありません）：

 for key, value in minutes_data.iteritems(): #      timestamp (key) temp_ts_file = os.path.join(temp_to_parse_path, key) open(temp_ts_file, 'a+').writelines(value)

途中で、to_parseフォルダー内のファイルを分析し、それらのいずれかが1分以内に変更されなかった場合、このファイルはデータ分析、集約、およびJLTCデータベースへの送信の候補になります。

 for filename in os.listdir(temp_to_parse_path): data_file = os.path.join(temp_to_parse_path, filename) file_mod_time = os.stat(data_file).st_mtime last_time = (time.time() - file_mod_time) if last_time > 60: logger.info('[DAEMON] File {} was not modified since 1min, adding to parse list.'.format(data_file)) files_to_parse.append(data_file)

そのようなファイル（1つまたは複数）がある場合は、解析されたファイルをparse_csv_data関数に送信します（各ファイルを並列に実行します）。

 for f in files_to_parse: logger.info('[DAEMON THREAD] Parse {}.'.format(f)) t = threading.Thread( target=parse_csv_data, args=( f, jmeter_results_file_fields, test, data_resolution)) t.start() threads.append(t) for t in threads: t.join()

cron.d内のデーモン自体は毎分開始されます。

デーモンは毎分cron.dで開始します。

 * * * * * root sleep 21 && /usr/bin/python /var/lib/jltc/manage.py daemon

したがって、結果を含むファイルは想像を超えるサイズに膨らむことはありませんが、その場で分析され、クリアされます。

結果

アプリ

150,000の仮想プレーヤー：

このテストでは、応答時間が50ミリ秒に「一致」しようとするため、負荷自体は16k〜18kリクエスト/ cの間の領域で絶えずジャンプします。

アプリケーションサーバー（15アプリ）を読み込みます。 2台のサーバーは、低速のM620に「不運」です。

データベースの応答時間（アプリサーバーの場合）：

データベース

db1（VM）のCPU使用率：

ハイパーバイザーのCPU使用率：

仮想マシンには48個の実際のコアがあると考えられているため、仮想マシンの負荷は低くなります。実際、ハイパーバイザーには24個のハイパースレッディングコアがあります。

最大で25万件のクエリ/秒がデータベースに送信され、次の項目で構成されます（83％の選択、3％-挿入、11.6％-更新（90％HOT）、1.6％の削除）：

autovacuum_vacuum_scale_factor = 0.2のデフォルト値では、 デッドタプルの数がテストで非常に急速に増加し（テーブルサイズが大きくなる）、テスト全体を数回台無しにする短いデータベースパフォーマンスの問題が数回発生しました。このパラメーターautovacuum_vacuum_scale_factorに個人的な値を割り当てることで、いくつかのテーブルでこの成長を「調整」する必要がありました。

ALTER TABLE ... SET（autovacuum_vacuum_scale_factor = ...）

ALTER TABLE構築SET（autovacuum_vacuum_scale_factor = 0.10）;

ALTER TABLE production SET（autovacuum_vacuum_scale_factor = 0.01）;

ALTER TABLE game_entity SET（autovacuum_vacuum_scale_factor = 0.01）;

ALTER TABLE game_entity SET（autovacuum_analyze_scale_factor = 0.01）;

ALTER TABLE building SET（autovacuum_vacuum_scale_factor = 0.01）;

ALTER TABLE building SET（autovacuum_analyze_scale_factor = 0.01）;

ALTER TABLE core_inventory_player_resource SET（autovacuum_vacuum_scale_factor = 0.10）;

ALTER TABLE survivor SET（autovacuum_vacuum_scale_factor = 0.01）;

ALTER TABLE survivor SET（autovacuum_analyze_scale_factor = 0.01）;

理想的には、rows_fetchedはrows_returnedに近いはずです。幸いなことに、次のことを確認します。

hot_standby_feedback

問題はhot_standby_feedbackパラメーターにあり、 スタンバイサーバーにWALファイルからの変更を適用する時間がない場合、 メインサーバーのパフォーマンスに大きく影響する可能性がありました。ドキュメント（https://postgrespro.ru/docs/postgrespro/11/runtime-config-replication）は、「ホットスタンバイサーバーが現在実行中の要求についてマスターまたは上位スレーブに通知するかどうかを決定する」と述べています。デフォルトではオフになっていますが、設定でオンになっています。 2つのスタンバイサーバーがあり、ロード中のレプリケーションラグがゼロと異なる場合（さまざまな理由により）、悲しい結果につながります。このような状況を観察でき、テスト全体のクラッシュにつながる可能性があります。

これは、hot_standby_feedbackが有効になっている場合、レプリケーションの競合を防ぐためにスタンバイサーバーがトランザクションIDで遅れている場合、VACUUMはデッドタプルを削除したくないためです。詳細な記事PostgreSQLのhot_standby_feedbackが実際に行うこと：

 xl1_game=# VACUUM VERBOSE core_inventory_player_resource; INFO: vacuuming "public.core_inventory_player_resource" INFO: scanned index "core_inventory_player_resource_pkey" to remove 62869 row versions DETAIL: CPU: user: 1.37 s, system: 0.58 s, elapsed: 4.20 s ………... INFO: "core_inventory_player_resource": found 13682 removable, 7257082 nonremovable row versions in 71842 out of 650753 pages <b>DETAIL: 3427824 dead row versions cannot be removed yet, oldest xmin: 3810193429</b> There were 1920498 unused item pointers. Skipped 8 pages due to buffer pins, 520953 frozen pages. 0 pages are entirely empty. CPU: user: 4.55 s, system: 1.46 s, elapsed: 11.74 s.

このような多数の無効なタプルは、上記の図につながります。 hot_standby_feedbackをオンおよびオフにした2つのテストを次に示します。

そして、これはテスト中のレプリケーションラグであり、将来的には何かを行う必要があります。

おわりに

幸いなことに（または記事の内容について）このテストは、ゲームのプロトタイプのこの段階で、ユーザーの一部に必要な負荷を圧倒する可能性が非常に高いことを示しました。これは、さらなるプロトタイプ作成と開発のための青信号を出すのに十分です。開発の後続の段階では、基本的なルール（実行されたクエリの単純さを維持し、インデックスやインデックスなしの読み取りなどを防止するため）に従う必要があります。最も重要なのは、開発の重要な各段階でプロジェクトをテストして問題を見つけ、修正することですより早くすることができます。おそらくすぐに、特定の問題をすでに解決したので、記事を書きます。

皆さんに幸運を！

念のため、GitHub ;）

数十万人の仮想ユーザーによるゲームの負荷テスト