🥇 🛷 👨‍👦 हजारों आभासी उपयोगकर्ताओं के एक जोड़े के साथ एक खेल का परीक्षण लोड करें 👎🏻 👩🏽‍🍳 🖐🏽

नमस्कार, हेब्र!

मैं एक गेमिंग कंपनी के लिए काम करता हूं जो ऑनलाइन गेम विकसित करती है। वर्तमान में, हमारे सभी खेलों को कई "बाजारों" (एक "बाजार" प्रति देश) में विभाजित किया गया है और प्रत्येक "बाजार" में एक दर्जन दुनिया हैं जिनके बीच खिलाड़ियों को पंजीकरण के दौरान वितरित किया जाता है (अच्छी तरह से, या कभी-कभी वे इसे स्वयं चुन सकते हैं)। प्रत्येक दुनिया में एक डेटाबेस और एक या अधिक वेब / ऐप सर्वर होते हैं। इस प्रकार, लोड को दुनिया भर में / सर्वरों में लगभग समान रूप से विभाजित और वितरित किया जाता है, और परिणामस्वरूप, हमें अधिकतम 6K-8K खिलाड़ियों (यह अधिकतम है, अधिकतर कई बार कम) और 200-300 अनुरोध प्रति दुनिया प्रति प्राइम टाइम मिलता है।

बाजारों और दुनिया में खिलाड़ियों के विभाजन के साथ ऐसी संरचना अप्रचलित हो रही है, खिलाड़ी कुछ वैश्विक चाहते हैं। पिछले खेलों में, हम लोगों को देश में विभाजित करना बंद कर देते हैं और केवल एक / दो बाजारों (अमेरिका और यूरोप) को छोड़ देते हैं, लेकिन फिर भी प्रत्येक में कई दुनिया के साथ। अगला कदम नई वास्तुकला के साथ खेलों का विकास और एक डेटाबेस में एक ही दुनिया में सभी खिलाड़ियों के एकीकरण का होगा।

आज मैं इस बारे में थोड़ी सी बात करना चाहता था कि मुझे कैसे चेक करने का काम सौंपा गया था अगर हमारे ऑनलाइन गेमों में से एक में (अगर यह 50-200 हजार यूजर्स हैं तो) नए आर्किटेक्चर पर बनाया गया अगला गेम खेलने के लिए "भेजें"। पूरी प्रणाली, विशेष रूप से डेटाबेस ( PostgreSQL 11 ) व्यावहारिक रूप से इस तरह के भार का सामना कर सकता है और, अगर यह नहीं पता कर सकता है कि हमारा अधिकतम कहां है। मैं आपको उन समस्याओं के बारे में थोड़ा बताऊंगा जो इतने उपयोगकर्ताओं के परीक्षण के लिए तैयार करने और निर्णय लेने की प्रक्रिया के बारे में है, इस प्रक्रिया के बारे में और परिणामों के बारे में थोड़ा सा।

पहचान

अतीत में, InnoGames GmbH में, प्रत्येक गेम टीम ने विभिन्न स्वादों, प्रोग्रामिंग भाषाओं और डेटाबेस का उपयोग करते हुए अक्सर अपने स्वाद और रंग के लिए एक गेम प्रोजेक्ट बनाया। इसके अलावा, हमारे पास भुगतान के लिए कई बाहरी सिस्टम जिम्मेदार हैं, जो पुश नोटिफिकेशन, मार्केटिंग और बहुत कुछ भेजते हैं। इन प्रणालियों के साथ काम करने के लिए, डेवलपर्स ने अपने अनूठे इंटरफेस भी बनाए जो सबसे अच्छा हो।

वर्तमान में मोबाइल गेमिंग व्यवसाय में बहुत पैसा है और, तदनुसार, बहुत सारी प्रतियोगिता। यहां मार्केटिंग पर खर्च किए गए प्रत्येक डॉलर और ऊपर से थोड़ा अधिक इसे वापस प्राप्त करना बहुत महत्वपूर्ण है, इसलिए सभी खेल कंपनियां बहुत बार "बंद" खेल बंद परीक्षण के चरण में भी करती हैं, अगर वे विश्लेषणात्मक अपेक्षाओं को पूरा नहीं करते हैं। तदनुसार, अगले पहिये के आविष्कार पर समय खोना लाभहीन है, इसलिए यह एक एकीकृत मंच बनाने का निर्णय लिया गया था जो डेवलपर्स को सभी बाहरी प्रणालियों के साथ एकीकरण के लिए तैयार समाधान, प्रतिकृति के साथ एक डेटाबेस और सभी सर्वोत्तम प्रथाओं के साथ प्रदान करेगा। इसके लिए डेवलपर्स की जरूरत है और इसके ऊपर एक अच्छा खेल विकसित करना है और खेल से संबंधित नहीं होने पर विकास पर समय बर्बाद करना है।

इस मंच को GameStarter कहा जाता है:

तो, बात करने के लिए। सभी भविष्य के इनओगेम्स गेम इस प्लेटफॉर्म पर बनाए जाएंगे, जिसमें दो डेटाबेस हैं - मास्टर और गेम (पोस्टग्रेक्यूएल 11)। मास्टर खिलाड़ियों (लॉगिन, पासवर्ड आदि) के बारे में बुनियादी जानकारी संग्रहीत करता है और मुख्य रूप से, केवल खेल में लॉगिन / पंजीकरण की प्रक्रिया में भाग लेता है। खेल - खेल का डेटाबेस, जहां, तदनुसार, सभी गेम डेटा और इकाइयां संग्रहीत की जाती हैं, जो कि खेल का मूल है, जहां पूरा भार जाएगा।
इस प्रकार, यह सवाल उठता है कि क्या यह पूरी संरचना हमारे सबसे लोकप्रिय खेलों में से अधिकतम ऑनलाइन के बराबर उपयोगकर्ताओं की ऐसी संभावित संख्या का सामना कर सकती है।

कार्य

कार्य स्वयं यह था: यह जांचने के लिए कि क्या डेटाबेस (PostgreSQL 11), प्रतिकृति सक्षम होने के साथ, सभी लोड का सामना कर सकता है जो हमारे पास वर्तमान में सबसे अधिक लोड किए गए गेम में है, जिसके निपटान में पूरे PowerEdge M630 हाइपरवाइजर (HV) हैं।
मैं स्पष्ट करूंगा कि इस समय कार्य केवल सत्यापित करने के लिए था , मौजूदा डेटाबेस कॉन्फ़िगर्स का उपयोग करके, जिसे हमने सबसे अच्छे तरीकों और अपने स्वयं के अनुभव को ध्यान में रखते हुए बनाया था।

मैं डेटाबेस से तुरंत कहूंगा, और पूरे सिस्टम ने खुद को अच्छी तरह से दिखाया, एक दो बिंदुओं को छोड़कर। लेकिन यह विशेष गेम परियोजना प्रोटोटाइप चरण में थी और भविष्य में, खेल यांत्रिकी की जटिलता के साथ, डेटाबेस के अनुरोध अधिक जटिल हो जाएंगे और लोड स्वयं ही काफी बढ़ सकता है और इसकी प्रकृति बदल सकती है। इसे रोकने के लिए, यह आवश्यक है कि परियोजना का परीक्षण प्रत्येक अधिक या कम महत्वपूर्ण मील के पत्थर के साथ किया जाए। हजारों की संख्या में उपयोगकर्ताओं के एक जोड़े के साथ इस प्रकार के परीक्षण चलाने की क्षमता को स्वचालित करना इस चरण में मुख्य कार्य बन गया है।

प्रोफ़ाइल

किसी भी लोड परीक्षण की तरह, यह सभी एक लोड प्रोफ़ाइल के साथ शुरू होता है।
हमारे संभावित मूल्य CCU60 (CCU एक निश्चित अवधि के लिए उपयोगकर्ताओं की अधिकतम संख्या है, इस मामले में 60 मिनट) को 250,000 उपयोगकर्ता माना जाता है। प्रतिस्पर्धी आभासी उपयोगकर्ताओं (VU) की संख्या CCU60 से कम है और विश्लेषकों ने सुझाव दिया है कि इसे सुरक्षित रूप से दो में विभाजित किया जा सकता है। राउंड अप और 150,000 प्रतिस्पर्धी VU स्वीकार करते हैं।

प्रति सेकंड अनुरोधों की कुल संख्या एक लोड किए गए गेम से ली गई थी:

इस प्रकार, हमारा लक्ष्य लोड 150,000 VU पर ~ 20,000 अनुरोध / s है ।

संरचना

"स्टैंड" के लक्षण

पिछले लेख में, मैंने पहले ही लोड टेस्टिंग की पूरी प्रक्रिया को स्वचालित करने के बारे में बात की थी। आगे, मैं अपने आप को थोड़ा दोहरा सकता हूं, लेकिन मैं आपको कुछ बिंदुओं के बारे में अधिक विस्तार से बताऊंगा।

आरेख में, नीले वर्ग हमारे हाइपरविजर (एचवी) हैं, एक क्लाउड जिसमें कई सर्वर शामिल हैं (डेल एम 620 - एम 640)। प्रत्येक एचवी पर, एक दर्जन वर्चुअल मशीन (वीएम) केवीएम (वेब / ऐप और मिक्स में डीबी) के माध्यम से लॉन्च किए जाते हैं। किसी भी नए वीएम को बनाते समय, एक उपयुक्त एचवी के मापदंडों के सेट के माध्यम से संतुलन और खोज होती है और यह शुरू में ज्ञात नहीं होता है कि यह किस सर्वर पर होगा।

डेटाबेस (गेम DB):

लेकिन हमारे db1 उद्देश्य के लिए, हमने M630 के आधार पर एक अलग HV targer_hypervisor आरक्षित किया।

Targer_hypervisor की संक्षिप्त विशेषताएँ:

डेल M_630
मॉडल का नाम: Intel® Xeon® CPU E5-2680 v3 @ 2.50GHz
सीपीयू (s): 48
प्रति कोर धागा (ओं): 2
कोर (एस) प्रति सॉकेट: 12
सॉकेट (ओं): 2
रैम: 128 जीबी
डेबियन जीएनयू / लिनक्स 9 (खिंचाव)
4.9.0-8-amd64 # 1 एसएमपी डेबियन 4.9.130-2 (2018-10-27)

विस्तृत विनिर्देशों

डेबियन जीएनयू / लिनक्स 9 (खिंचाव)
4.9.0-8-amd64 # 1 एसएमपी डेबियन 4.9.130-2 (2018-10-27)
lscpu
आर्किटेक्चर: x86_64
CPU ऑप-मोड (s): 32-बिट, 64-बिट
बाइट ऑर्डर: लिटिल एंडियन
सीपीयू (s): 48
ऑन-लाइन सीपीयू (एस) सूची: 0-47
प्रति कोर धागा (ओं): 2
कोर (एस) प्रति सॉकेट: 12
सॉकेट (ओं): 2
NUMA नोड (ओं): 2
विक्रेता ID: जेनुइनइंटेल
सीपीयू परिवार: 6
मॉडल: 63
मॉडल का नाम: Intel® Xeon® CPU E5-2680 v3 @ 2.50GHz
कदम: २
सीपीयू मेगाहर्ट्ज: 1309.356
सीपीयू अधिकतम मेगाहर्ट्ज: 3300.0000
सीपीयू मिनट मेगाहर्ट्ज: 1200.0000
BogoMIPS: 4988.42
वर्चुअलाइजेशन: वीटी-एक्स
L1d कैश: 32K
L1i कैश: 32K
L2 कैश: 256K
L3 कैश: 30720K
NUMA नोड0 सीपीयू (ओं): 0,2,4,6,8,10,12,14,16,18,20,22,24,26,28,30,32,36,36,38,40,42 , 44.46
NUMA नोड 1 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 sse2 ss2s ht tm pbe syscall nx pdpe1gb rdtscpm लगातार qtmmopopopopopopopopopopop/live&hl=hi निरंतर qtmmop एसएमएक्स स्था TM2 SSSE3 sdbg FMA cx16 xtpr PDCM pcid डीसीए sse4_1 sse4_2 x2apic MOVBE popcnt tsc_deadline_timer एईएस xsave AVX f16c rdrand lahf_lm एबीएम ईपीबी 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 इड़ा arat pln pts flush_l1d

/ usr / bin / qemu-system-x86_64 --version
QEMU एमुलेटर संस्करण 2.8.1 (डेबियन 1: 2.8 + dfsg-6 + deb9u5)
कॉपीराइट © 2003-2016 फेब्रिस बेलार्ड और क्यूईएमयू प्रोजेक्ट डेवलपर्स

Db1 की संक्षिप्त विशेषताएँ:
आर्किटेक्चर: x86_64
सीपीयू (s): 48
रैम: 64 जीबी
4.9.0-8-amd64 # 1 एसएमपी डेबियन 4.9.144-3.1 (2019-02-19) x86_64_U / लिनक्स
डेबियन जीएनयू / लिनक्स 9 (खिंचाव)
psql (PostgreSQL) 11.2 (डेबियन 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_checkpoint = पर
log_lock_waits = पर
log_statement = ddl
log_min_duration_statement = 100
log_temp_files = 0
autovacuum_max_workers = 5
autovacuum_naptime = 10s
autovacuum_vacuum_cost_delay = 20ms
वैक्यूम_कोस्ट_लिमिट = 2000
मेन्टेनेंस_वर्क_मेम = 128 एमबी
synous_commit = बंद
checkpoint_timeout = 30 मिनट
सुन_दादरी = '*'
वर्क_म = 32 एमबी
effective_cache_size = 26214MB # 50% उपलब्ध मेमोरी
share_buffers = 16384MB # 25% उपलब्ध मेमोरी
max_wal_size = 15GB
min_wal_size = 80MB
wal_level = hot_standby
max_wal_senders = 10
wal_compression = पर
संग्रह_मोड = पर
आर्काइव_कमांड = '/ बिन / सच'
संग्रह_ समय = १_००
hot_standby = on
wal_log_hints = पर
hot_standby_feedback = पर

hot_standby_feedback बंद करने के लिए चूक, हमने इसे चालू कर दिया था, लेकिन बाद में एक सफल परीक्षण करने के लिए इसे बंद करना पड़ा। मैं बाद में समझाऊंगा क्यों।

डेटाबेस में मुख्य सक्रिय टेबल (निर्माण, उत्पादन, game_entity, बिल्डिंग, core_inventory_player_resource, उत्तरजीवी) एक बैश स्क्रिप्ट का उपयोग करके डेटा (लगभग 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_hypervisers) पर, 15 ऐप सर्वर लॉन्च किए गए: 8 कोर, 4 जीबी। मुख्य बात जो यह कही जा सकती है: ओपनजडक 11.0.1 2018-10-16, वसंत, डेटाबेस के माध्यम से हिकारी के माध्यम से बातचीत (hikari.maximum-pool-size: 50)

तनाव परीक्षण वातावरण

पूरे लोड टेस्टिंग वातावरण में एक मुख्य सर्वर admin.loadtest और कई जनरेटर N.loadtest सर्वर होते हैं (इस मामले में वहां 14 थे)।

जनरेटरN.loadtest - "नंगे" वीएम डेबियन लिनक्स 9, स्थापित जावा के साथ 8. 32 कर्नेल / 32 गीगाबाइट। वे गैर-उत्पादक एचवी पर स्थित हैं ताकि गलती से महत्वपूर्ण वीएम के प्रदर्शन को मार न सकें।

admin.loadtest - डेबियन लिनक्स 9 वर्चुअल मशीन , 16 कोर / 16 गिग्स, यह जेनकींस, जेएलटीसी और अन्य अतिरिक्त महत्वहीन सॉफ्टवेयर चलाता है।

जेएलटीसी - जेमीटर लोड परीक्षण केंद्र । Py / Django में एक प्रणाली जो परीक्षणों के प्रक्षेपण, साथ ही परिणामों के विश्लेषण को नियंत्रित और स्वचालित करती है।

टेस्ट लॉन्च योजना

परीक्षण चलाने की प्रक्रिया इस तरह दिखती है:

परीक्षण जेनकिंस से शुरू किया गया है। आवश्यक नौकरी का चयन करें, फिर आपको वांछित परीक्षण पैरामीटर दर्ज करने की आवश्यकता है:
- परीक्षा - परीक्षा की अवधि
- RAMPUP - "वार्म-अप" समय
- THREAD_COUNT_TOTAL - वर्चुअल उपयोगकर्ताओं (VU) या थ्रेड्स की वांछित संख्या
- TARGET_RESPONSE_TIME एक महत्वपूर्ण पैरामीटर है, इसलिए संपूर्ण सिस्टम को ओवरलोड करने के लिए नहीं, इसकी मदद से हम वांछित प्रतिक्रिया समय निर्धारित करते हैं, तदनुसार परीक्षण लोड को उस स्तर पर रखेगा जिस पर संपूर्ण सिस्टम का प्रतिक्रिया समय निर्दिष्ट से अधिक नहीं है।
लांच
जेनकिन्स Gitlab से परीक्षण योजना को क्लोन करता है, इसे JLTC को भेजता है।
जेएलटीसी एक परीक्षण योजना के साथ थोड़ा काम करता है (उदाहरण के लिए, एक सीएसवी सरल लेखक सम्मिलित करता है)।
JLTC वांछित संख्या (VREAD_COUNT_TOTAL) को चलाने के लिए Jmeter सर्वर की आवश्यक संख्या की गणना करता है।
JLTC प्रत्येक लोडरगेंनेटर एन जनरेटर से जुड़ता है और जेमीटर सर्वर शुरू करता है।

परीक्षण के दौरान, JMeter- क्लाइंट परिणामों के साथ एक CSV फ़ाइल बनाता है। इसलिए परीक्षण के दौरान, डेटा की मात्रा और इस फ़ाइल का आकार एक पागल गति से बढ़ता है, और इसका उपयोग परीक्षण के बाद विश्लेषण के लिए नहीं किया जा सकता है - डेमन का आविष्कार किया गया था (एक प्रयोग के रूप में), जो इसे "मक्खी पर" बनाता है।

टेस्ट प्लान

आप यहां परीक्षण योजना डाउनलोड कर सकते हैं ।

पंजीकरण / लॉगिन के बाद, उपयोगकर्ता व्यवहार मॉड्यूल में काम करते हैं, जिसमें कई थ्रूपुट नियंत्रक होते हैं जो किसी विशेष गेम फ़ंक्शन की संभावना को निर्दिष्ट करते हैं। प्रत्येक थ्रूपुट नियंत्रक में, एक मॉड्यूल नियंत्रक होता है , जो संबंधित मॉड्यूल को संदर्भित करता है जो फ़ंक्शन को लागू करता है।

विषय से संबंधित नहीं

स्क्रिप्ट के विकास के दौरान, हमने ग्रूवी को पूरी तरह से उपयोग करने की कोशिश की और हमारे जावा प्रोग्रामर के लिए धन्यवाद, मैंने अपने लिए कुछ ट्रिक्स खोजे (शायद यह किसी के लिए उपयोगी होगा):

आप परीक्षण योजना की शुरुआत में कहीं पर एक समारोह की घोषणा कर सकते हैं, और फिर अन्य प्री-, पोस्ट-प्रोसेसर और नमूने में इसका उपयोग कर सकते हैं। अधिक ग्रूवी अच्छाई: क्लोजर में तरीके मोड़ें :
```
 //     - 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 की अंतिम संख्या वितरित करें। यह भाग नियंत्रक / प्रावधान नामक भाग में JLTC के साथ स्थित है।

संक्षेप में, एल्गोरिथ्म इस प्रकार है:

हम VU थ्रेड्स_num की वांछित संख्या को 200-300 थ्रेड में विभाजित करते हैं और अधिक या कम पर्याप्त आकार -Xmsm -Xmxm के आधार पर हम एक जेमीटर-सर्वर के लिए आवश्यक मेमोरी वैल्यू का निर्धारण करते हैं आवश्यक-memory -for_jri (JRI - मैं Jmeter- सर्वर के बजाय Jmeter दूरस्थ उदाहरण को कॉल करता हूं)।
थ्रेड्स_नम और आवश्यक_मेमोरी_फोर्स्री से हम जेमीटर-सर्वर की कुल संख्या: लक्ष्य_माउंट_जड़ी और आवश्यक मेमोरी का कुल मूल्य पाते हैं : आवश्यक_मिमोरी_टोटल ।
हम सभी loadgeneratorN जनरेटर को एक-एक करके सॉर्ट करते हैं और इसके लिए उपलब्ध मेमोरी के आधार पर अधिकतम संख्या में जेमीटर-सर्वर शुरू करते हैं। जब तक चालू_माउंट_जारी इंस्टेंसेस की संख्या टारगेट_माउंट_जारी के बराबर नहीं है ।
(यदि जनरेटर की संख्या और कुल मेमोरी पर्याप्त नहीं है, तो पूल में एक नया जोड़ें)

हम प्रत्येक जनरेटर से कनेक्ट करते हैं, नेटस्टैट का उपयोग करते हुए हम सभी व्यस्त बंदरगाहों को याद करते हैं, और यादृच्छिक बंदरगाहों (जो अप्रकाशित हैं) पर जमीटर-सर्वर की आवश्यक संख्या चलाते हैं:

  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-

हम सभी चल रहे जेमीटर-सर्वरों को एक समय में पते के पते पर इकट्ठा करते हैं: पोर्ट, उदाहरण के लिए जनरेटर 13: 15576, जनरेटर 9: 14015, जनरेटर 11: 19152, जनरेटर 14: 12125, जनरेटर 2: 17602

परीक्षण शुरू होने पर परिणामी सूची और थ्रेड_पर_हॉस्ट 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 धागे प्रत्येक से एक साथ हुआ, जावा पैरामीटर के साथ एक 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 पैरामीटर इसके लिए जिम्मेदार है। हम इस बात से सहमत थे कि 50ms इष्टतम प्रतिक्रिया समय है जिसके लिए सिस्टम को जिम्मेदार होना चाहिए।

JMeter में, डिफ़ॉल्ट रूप से, कई अलग-अलग टाइमर हैं जो आपको थ्रूपुट को नियंत्रित करने की अनुमति देते हैं, लेकिन यह ज्ञात नहीं है कि हमारे मामले में इसे कहां प्राप्त करना है। लेकिन JSR223- टाइमर है जिसके साथ आप वर्तमान सिस्टम प्रतिक्रिया समय का उपयोग करके कुछ के साथ आ सकते हैं। टाइमर ही मुख्य व्यवहार ब्लॉक में है:

 //      = 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;

परिणामों का विश्लेषण (डेमॉन)

ग्राफाना में ग्राफ के अलावा, एकत्रित परीक्षा परिणामों का होना भी आवश्यक है ताकि बाद में JLTC में परीक्षणों की तुलना की जा सके।

ऐसा एक परीक्षण प्रति सेकंड 16k-20k अनुरोधों को उत्पन्न करता है, यह गणना करना आसान है कि 4 घंटे में यह सौ जीबी के एक जोड़े की CSV फ़ाइल बनाता है, इसलिए नौकरी के साथ आना जरूरी था जो हर मिनट डेटा पार्स करता है, इसे डेटाबेस में भेजता है और मुख्य फाइल को साफ करता है।

एल्गोरिथ्म इस प्रकार है:

हम डेटा को CSV फ़ाइल result.jtl से पढ़ते हैं, जिसे jmeter-client द्वारा जनरेट किया गया है, इसे सहेजें और फ़ाइल को साफ़ करें (आपको इसे सही ढंग से साफ़ करने की आवश्यकता है, अन्यथा खाली दिखने वाली फ़ाइल में समान आकार की समान 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)

मिनट_डाटा से प्रत्येक मिनट के डेटा को the_parse / फ़ोल्डर में संबंधित फ़ाइल में लिखा जाता है। (इस प्रकार, परीक्षण के प्रत्येक मिनट में अपनी डेटा फ़ाइल होती है, फिर एकत्रीकरण के दौरान यह मायने नहीं रखेगा कि डेटा प्रत्येक फ़ाइल में किस क्रम में आया है):
```
 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) 
```
जिस तरह से, हम in_parse फ़ोल्डर में फ़ाइलों का विश्लेषण करते हैं और यदि उनमें से कोई एक मिनट के भीतर नहीं बदलता है, तो यह फ़ाइल डेटा विश्लेषण, एकत्रीकरण और 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) 
```
यदि ऐसी फाइलें (एक या कई) हैं, तो हम उन्हें पार्स_एससीवी_डेटा फ़ंक्शन (समानांतर में प्रत्येक फ़ाइल) में पार्स भेजते हैं:
```
 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.d के साथ शुरू होता है:

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

इस प्रकार, परिणामों के साथ फ़ाइल को समझ में नहीं आता है, लेकिन यह मक्खी पर विश्लेषण किया और मंजूरी दे दी है।

परिणाम

ऐप

हमारे 150,000 आभासी खिलाड़ी:

परीक्षण 50ms के प्रतिक्रिया समय को "मैच" करने की कोशिश करता है, इसलिए लोड खुद 16k-18k अनुरोधों के बीच क्षेत्र में लगातार कूदता है:

एप्लिकेशन सर्वर लोड (15 ऐप)। दो सर्वर "अनलकी" हैं जो M620 के धीमे होने के लिए हैं:

डेटाबेस प्रतिक्रिया समय (ऐप सर्वर के लिए):

डाटाबेस

Db1 (VM) पर CPU उपयोग:

हाइपरविजर पर CPU उपयोग:

वर्चुअल मशीन पर लोड कम है, क्योंकि यह मानता है कि इसके निपटान में 48 असली कोर हैं, वास्तव में, हाइपरविजर पर 24 हाइपरथ्रेडिंग कोर हैं।

अधिकतम ~ 250K क्वेरीज़ / s डेटाबेस में जाती है, जिसमें (83% चयन, 3% - आवेषण, 11.6% - अपडेट (90% HOT), 1.6% डिलीट) शामिल हैं:

ऑटोवैक्युम_वैक्यूम_सेले_फैक्टर = 0.2 के एक डिफ़ॉल्ट मान के साथ, मृत ट्यूपल्स की संख्या परीक्षण के साथ बहुत तेज़ी से बढ़ी (तालिका आकार में वृद्धि के साथ), जिससे कई बार शॉर्ट डेटाबेस प्रदर्शन समस्याओं का सामना करना पड़ा जिसने पूरे परीक्षण को कई बार बर्बाद कर दिया। मुझे इस पैरामीटर autovacuum_vacuum_scale_factor पर व्यक्तिगत मान निर्दिष्ट करके कुछ तालिकाओं के लिए यह वृद्धि "वश में" करना पड़ा:

तालिका में शामिल करें ... सेट (ऑटोवैकोम_वैक्यूम_सेले_फैक्टर = ...)

ALTER TABLE निर्माण SET (autovacuum_vacuum_scale_factor = 0.10);
वैकल्पिक टेबल उत्पादन 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);
वैकल्पिक टेबल SET (autovacuum_vacuum_scale_factor = 0.01);
वैकल्पिक टेबल SET (autovacuum_analyze_scale_factor = 0.01);
ALTER TABLE core_inventory_player_resource SET (autovacuum_vacuum_scale_factor = 0.10);
अन्य तालिका उत्तरजीवी सेट (ऑटोवैक्यूम_वैकुम_सेले_फैक्टर = 0.01);
ALTER TABLE उत्तरजीवी SET (autovacuum_analyze_scale_factor = 0.01);

आदर्श रूप से, row_fetched पंक्तियों के करीब होना चाहिए +, जो हम, सौभाग्य से, हम निरीक्षण करते हैं:

hot_standby_feedback

समस्या hot_standby_feedback पैरामीटर के साथ थी, जो मुख्य सर्वर के प्रदर्शन को बहुत प्रभावित कर सकती है यदि इसके स्टैंडबाय सर्वरों के पास वाल फ़ाइलों से परिवर्तन लागू करने का समय नहीं है। प्रलेखन (https://postgrespro.ru/docs/postgrespro/11/runtime-config-replication) कहता है कि यह निर्धारित करता है कि "हॉट स्टैंडबाय सर्वर मास्टर या श्रेष्ठ दास को उन अनुरोधों के बारे में सूचित करेगा जो वर्तमान में निष्पादित हो रहे हैं।" डिफ़ॉल्ट रूप से यह बंद है, लेकिन यह हमारे कॉन्फ़िगरेशन में चालू था। जिसके कारण दुःखद परिणाम हुए, अगर 2 स्टैंडबाय सर्वर हैं और लोड के दौरान प्रतिकृति अंतराल शून्य (विभिन्न कारणों से) से भिन्न है, तो आप ऐसी तस्वीर का निरीक्षण कर सकते हैं, जिससे पूरे परीक्षण का पतन हो सकता है:

यह इस तथ्य के कारण है कि जब hot_standby_feedback सक्षम होता है, तो VACUUM "मृत" tuples को हटाना नहीं चाहता है अगर स्टैंडबाय सर्वर प्रतिकृति लेनदेन को रोकने के लिए अपने लेनदेन आईडी में पीछे हैं। विस्तृत लेख क्या 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 चालू और बंद है:

और यह परीक्षण के दौरान हमारी प्रतिकृति अंतराल है, जिसके साथ भविष्य में कुछ करना आवश्यक होगा:

निष्कर्ष

यह परीक्षण, सौभाग्य से (या लेख की सामग्री के लिए दुर्भाग्य से) ने दिखाया कि खेल के प्रोटोटाइप के इस चरण में उपयोगकर्ताओं के हिस्से पर वांछित भार को अवशोषित करना काफी संभव है, जो आगे के प्रोटोटाइप और विकास के लिए हरी बत्ती देने के लिए पर्याप्त है। विकास के बाद के चरणों में, बुनियादी नियमों का पालन करना आवश्यक है (निष्पादित प्रश्नों की सादगी रखने के लिए, अनुक्रमितों की अतिरेक को रोकने के लिए, साथ ही गैर-अनुक्रमित रीडिंग, आदि) और सबसे महत्वपूर्ण बात, समस्याओं को खोजने और ठीक करने के लिए विकास के प्रत्येक महत्वपूर्ण चरण में परियोजना का परीक्षण करें। पहले हो सकता है। शायद जल्द ही, मैं एक लेख लिखूंगा क्योंकि हम पहले से ही विशिष्ट समस्याओं को हल कर चुके हैं।

सभी को शुभकामनाएँ!

हमारे GitHub सिर्फ मामले में;)

हजारों आभासी उपयोगकर्ताओं के एक जोड़े के साथ एक खेल का परीक्षण लोड करें