👐🏻 🐃 🏓 अपने कार्यों के आधार पर एक दूसरे के संबंध में उपयोगकर्ताओं के महत्व का वजन निर्धारित करना (टारनटूल + लुआ) 😙 🌱 👩🏿‍🎨

कई उपयोगकर्ताओं के साथ एक प्रणाली है। सिस्टम का प्रत्येक उपयोगकर्ता एक दूसरे के संबंध में कार्रवाई कर सकता है। इन क्रियाओं के आधार पर, वजन की गणना की जाती है। प्रत्येक उपयोगकर्ता को सिस्टम के अन्य उपयोगकर्ताओं की सूची प्राप्त करने में सक्षम होना आवश्यक है, जो वजन के घटते क्रम में क्रमबद्ध हैं। निष्क्रिय उपयोगकर्ता का वजन नहीं बदलना चाहिए।

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

सरल बनाने के लिए, कल्पना करें कि सिस्टम एक गेम है, और उपयोगकर्ता एक खिलाड़ी है।

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

हमारे कठिन प्रोग्रामिंग दिनों में एक काफी मानक सांख्यिकीय कार्य। इस लेख में मैं दिखाऊंगा कि टारेंटूल + लुआ का उपयोग करके इसे कैसे लागू किया जा सकता है। अपने आखिरी लेख में, मैंने इस बारे में बात की कि कैसे एक टारेंटयुला को इकट्ठा और कॉन्फ़िगर किया जाता है; इसमें मैं केवल आरेख पर ही नहीं, बल्कि लुला के बारे में और पेरला से प्राप्त अच्छे के साथ काम करने के तरीके के बारे में अधिक विस्तार से बताऊंगा।

हमें इस समस्या को हल करने की आवश्यकता है:

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

ग्राफ के सांकेतिक स्थानों में से एक 05.02 का निशान है। इस बिंदु पर, यह स्पष्ट है कि कार्रवाई केवल उस खिलाड़ी के संबंध में की जानी चाहिए, जिसका वजन ग्राफ नारंगी में इंगित किया गया है। और 17.02 पर, किसी भी उपयोगकर्ता के संबंध में कोई कार्रवाई नहीं की जाती है, इसलिए वजन एक ही स्तर पर रहता है।

कुल, हमें 2 स्थान मिलते हैं। 5 क्षेत्रों में से पहला:
Player1
player2
भार
अंतिम अद्यतन तिथि
वजन घटाने प्रति दिन
2 क्षेत्रों में से दूसरा:
Player1
खिलाड़ी अंतिम गतिविधि Date1

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

slab_alloc_arena = 1 pid_file = "box.pid" logger="cat - >> Tarantool.log" primary_port = 33013 secondary_port = 33014 admin_port = 33015 rows_per_wal = 5000000 #    space[0].enabled = 1 space[0].index[0].type = "HASH" space[0].index[0].unique = 1 space[0].index[0].key_field[0].fieldno = 0 space[0].index[0].key_field[0].type = "NUM" space[0].index[0].key_field[1].fieldno = 1 space[0].index[0].key_field[1].type = "NUM" space[0].index[1].type = "TREE" space[0].index[1].unique = 0 space[0].index[1].key_field[0].fieldno = 0 space[0].index[1].key_field[0].type = "NUM" space[0].index[2].type = "TREE" space[0].index[2].unique = 0 space[0].index[2].key_field[0].fieldno = 0 space[0].index[2].key_field[0].type = "NUM" space[0].index[2].key_field[1].fieldno = 2 space[0].index[2].key_field[1].type = "NUM" space[1].enabled = 1 space[1].index[0].type = "HASH" space[1].index[0].unique = 1 space[1].index[0].key_field[0].fieldno = 0 space[1].index[0].key_field[0].type = "NUM"

टारेंटयुला तैयार है, आप भंडार को प्रारंभिक कर सकते हैं:

 $ tarantool_box --init-storage tarantool/src/box/tarantool_box: space 0 successfully configured tarantool/src/box/tarantool_box: space 1 successfully configured tarantool/src/box/tarantool_box: creating `./00000000000000000001.snap.inprogress' tarantool/src/box/tarantool_box: saving snapshot `./00000000000000000001.snap' tarantool/src/box/tarantool_box: done

रिपॉजिटरी तैयार की जाती है, आप लुआ प्रक्रियाओं को लिख सकते हैं।
हमें दो प्रक्रियाओं की आवश्यकता होगी:

उपयोगकर्ता क्रियाओं का पंजीकरण (वृद्धि_स्कोर)
उपयोगकर्ताओं की क्रमबद्ध सूची प्राप्त करना (get_top)

हम उन्हें box_popular_user.lua फ़ाइल में कार्यान्वित करते हैं, हम कॉन्फ़िगरेशन चर बॉक्स_config_popular_user.lua में स्थानांतरित करते हैं
फिर इस प्लगइन को init.lua से कनेक्ट करने के लिए आपको 1 लाइन: dofile ("box_popular_user.lua") लिखना होगा

तो, अब more_score () के बारे में।

 function increase_score(user_id, friend_id, action_type) --    local id = tonumber(user_id) local fid = tonumber(friend_id) if not id or not fid or not map_type_score[action_type] then return false end --     local dt = os.date('*t') local cd = box.time{year = dt.year; month=dt.month; day=dt.day} --     ,          local last_update = box.select('1', '0', id) if not last_update then last_update = box.insert('1',id,cd) end --        local difft = math.floor(( cd-box.unpack('i',last_update[1]) )/24/60/60) --    ,       if difft ~= 0 then if difft > 1 then --      ,        ,        -- ,           ,     table.insert(updates_in_fibers,id,box.fiber.wrap(function() _move_last_update(id, cd, difft) end)) difft = difft-1 else difft = 0 end box.update('1',id,'=p',1,cd) end --       local tup = box.select('0','0', id, fid) --          _get_score_koef if not tup then --      ,   local s_k = _get_score_koef(nil, nil, map_type_score[action_type], nil, cd) tup = box.insert('0', id, fid, s_k[1], cd, s_k[2]) else --      local s_k = _get_score_koef(box.unpack('i', tup[3])+difft, box.unpack('i', tup[2]), map_type_score[action_type], box.unpack('i',tup[4]), cd) --       ,       ,       tup = box.update('0',{id;fid},'=p=p=p',2, s_k[1],3,cd,4,s_k[2]) end return tup end

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

 function _move_last_update(id, cd, diff) weights = box.space[0] for tup in weights.index[1]:iterator(box.index.EQ, id) do --        if box.unpack('i',tup[3]) < cd then weights:update({box.unpack('i',tup[1]); box.unpack('i',tup[2])},'=p', 3, box.unpack('i',tup[3])+diff) end end --     id    table.remove(updates_in_fibers, id) end

यहां हम अपडेट का उपयोग करते हैं जो दूसरे धागे को नियंत्रण देता है, जो हमें इस तथ्य से बचाएगा कि जब तक तारीखें अपडेट नहीं हो जाती हैं, तब तक एक से अधिक क्लाइंट को प्रतिक्रिया नहीं मिलेगी।

अब वज़न को परिवर्तित करने के कार्य और इसकी कमी के गुणांक पर विचार करें।

 function _get_score_koef(last_update, last_score, add_score, koef, current_date) local score = 0; if not last_score then --        ,     ,            score = add_score else if current_date == last_update then --       ,          score = last_score + add_score else --      ,           local diff = (current_date-last_update)/24/60/60*koef if diff > last_score then -- ,    ,  ,    -       diff = last_score end --      ,   score = last_score + add_score - diff end end if add_score then --   ,   ,        ,     koef = score/box_pu_default['score_day'] end return {score,koef}; end

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

उपयोगकर्ता पुनर्प्राप्ति फ़ंक्शन पर विचार करें

 function get_top(user_id, count_users, ids) --   ,          (   "box_config_popular_user.lua") local id = tonumber(user_id) if not id then return false end local cu if not count_users then cu = box_pu_default['count_users'] else cu = tonumber(count_users) end local id_users = {} local count = 0 --    id   ,   ,    -   -  ,    if ids then for id in string.gmatch(ids, "%d+") do id_users[tonumber(id)] = 1 count=count+1 end if(count < cu) then cu = count end end --      local ret local last_update = box.select('1', '0', id) --  2                     for iter = 1, 2 do local need_update = {} ret = {} for v in box.space[0].index[2]:iterator(box.index.LE, id) do --         -  if not v or #ret == cu or box.unpack('i',v[0]) ~= id then break end --    ,    ,   if not ids or id_users[box.unpack('i',v[1])] == 1 then --                   --  ,         if not updates_in_fibers[id] and box.unpack('i', v[3]) ~= box.unpack('i', last_update[1]) then table.insert(need_update, v) else --        table.insert(ret, v) end end end local need_another_req = 0 for i = 1, #need_update do local v = need_update[i] local s_k = _get_score_koef(box.unpack('i', v[3]), box.unpack('i', v[2]), 0, box.unpack('i',v[4]), box.unpack('i', last_update[1])) --   ,      if s_k[1] == 0 then box.delete('0',{v[0],v[1]}) else --       ,    , ..     box.update('0',{v[0];v[1]},'=p=p=p',2, s_k[1],3,box.unpack('i', last_update[1]),4,s_k[2]) need_another_req = 1 end end if need_another_req == 0 then break end end return unpack(ret) end

कॉन्फ़िगरेशन फ़ाइल box_config_popular_user.lua में, निम्न मान रखें:

 map_type_score={user_page=100} --      increase_score,  ,  ,         increase_score box_pu_default={count_users=10;score_day=30} -- -    get_top  -        , .

Box_popular_user.lua फ़ाइल में पहली पंक्ति का विन्यास है:

 dofile("box_config_popular_user.lua")

दरअसल, इस प्लगइन को स्थापित करने के लिए, आपको इन दो फ़ाइलों को कार्यशील निर्देशिका में रखना होगा। आवश्यक कॉन्फ़िगरेशन मानों को लिखें। Init.lua प्लगइन को जोड़ने के लिए एक स्ट्रिंग लिखें। टारेंटयुला को पुनरारंभ करें और उपयोग करें। और, ज़ाहिर है, रिक्त स्थान के विन्यास के बारे में मत भूलना।

अब आइए इस प्रणाली को उपयोग के संदर्भ में देखें।

हम सबसे सरल पर्ल टेस्ट लिखेंगे, जो एक धागे में कुछ लॉग के आधार पर टारेंटयुला डेटा को सिंक्रोनाइज़ करता है।

लॉग में फ़ंक्शन का नाम युक्त लाइनें शामिल होंगी जिन्हें टारेंटयुला में खींचा जाना चाहिए और मापदंडों का एक सेट जिसे वहां स्थानांतरित किया जाना चाहिए। यह एक सिंथेटिक लॉग फाइल है, लेकिन इस तरह की फाइल की जरूरत है ताकि हमारी स्क्रिप्ट को अतिरिक्त काम के साथ बोझ न लगे, लेकिन हम स्थिरता के लिए टारेंटयुला की जांच करते हैं।

टारेंटयुला के साथ काम करने के लिए हमें DR :: Tarantool मॉड्यूल की आवश्यकता है, इसे स्कैन के साथ स्थापित किया जा सकता है, इसे आपके पसंदीदा पैकेज मैनेजर yum, apt, ... के माध्यम से स्थापित किया जा सकता है।

 use strict; use DR::Tarantool ':constant', 'tarantool'; my $client = tarantool host => 'localhost', port => 33013, spaces => { 0 => { name => 'user_score', default_type => 'NUM', fields => [ qw(id fid score last_update koef), ], indexes => { 0 => { name => 'idx_id_fid', fields => [ 'id', 'fid' ] }, 1 => { name => 'idx_id', fields => [ 'id' ] }, 2 => { name => 'idx_id_score', fields => [ 'id', 'score' ] }, } }, 1 => { name => 'user_last_update', default_type => 'NUM', fields => [ qw(id last_update), ], indexes => { 0 => { name => 'idx_id', fields => [ 'id' ] }, } }, }; while(<>){ my $line = $_; my @params = split( " ", $line); $client->call_lua($params[0], @params[1..$#params],($params[0] eq 'increase_score' ? ('user_page') : ()); };

यहाँ एक ऐसी छोटी सी लिपि है, जिसमें अंतरिक्ष के वर्णन से अधिकांश जगह घिरी हुई है, यह एक टारेंटयुला के साथ काम कर सकती है। वास्तव में, डेटा को ग्रेफाइट में भेजने वाले हिस्से को इस स्क्रिप्ट से बाहर निकाल दिया गया था, क्योंकि हम टारेंटयुला के साथ काम करने में अधिक रुचि रखते हैं। वास्तव में एक सूत्र में मुझे प्रति सेकंड लगभग 3,500 अनुरोध प्राप्त हुए।
हालाँकि, टारेंटयुला ने लगभग 17% CPU ही खाया। आइए 4 थ्रेड में स्क्रिप्ट को चलाने का प्रयास करें।

स्क्रिप्ट में से प्रत्येक टारेंटयुला को प्रति सेकंड 1050 लॉग प्रविष्टियों को खिलाने में कामयाब रहा, और चारों एक साथ लगभग 4200 रिकॉर्ड प्रति सेकंड। टारेंटयुला ने लगभग 38% प्रोसेसर खा लिया। ज्यादा विकास नहीं हुआ। यद्यपि हमारी स्क्रिप्ट जो टारेंटयुला में डेटा भेजती है, वह भी प्रोसेसर में नहीं चली।

कार्यवाही के दौरान, क्या समस्या है और हमारा सिस्टम कहां-कहां धुंधला हो रहा है, मैंने पाया कि सिंक्रोनस मोड में DR :: टारेंटूल भी AnyEvent और, का उपयोग करता है, यह प्रत्येक आने वाले अनुरोध के लिए एक नया AE :: io उत्पन्न करता है, जो बदले में एक सिस्टम का चयन करता है , जो, मेरी राय में, कुछ देरी का कारण बनता है। अधिक गहराई से, मैंने खुदाई न करने का फैसला किया, लेकिन बस एक और परीक्षण कार्यक्रम लिखा, लेकिन पहले से ही क्लाइंट :: टारेंटूल का उपयोग कर रहा था। मुझे बस इतना करना था कि ग्राहक के उपयोग और आरंभ को बदल दिया जाए।

 use Client::Tarantool; my $client = Client::Tarantool->new...

और इसलिए हम शुरू करते हैं और ग्राफ को देखते हैं:

सबसे पहले, एक नई स्क्रिप्ट ने 1 धागे में काम किया, 100% सीपीयू पर आराम किया, फिर इसे 3 थ्रेड्स में लॉन्च किया गया, जिनमें से प्रत्येक को 100% सीपीयू में भी आराम किया गया और, जो बहुत ही मनभावन था, यह था कि टारेंटयुला के लिए अनुरोधों की संख्या बढ़ रही थी! फिर उन्होंने इसे 4 धागे में लॉन्च किया और फिर टारेंटयुला 100% सीपीयू में चला गया। कुल यह प्रति सेकंड 18-20K अनुरोधों के बारे में निकला। इसके अलावा, सत्यापन के लिए पांचवीं प्रक्रिया शुरू की गई थी, और, उम्मीद के मुताबिक, प्रत्येक थ्रेड के लिए अनुरोधों की संख्या गिर गई और समान रूप से वितरित की गई, शेष 18-20K के स्तर पर।

यह सिंक्रोनस प्रोटोकॉल AnyEvent का उपयोग नहीं करता है, यह शुद्ध syswrite और sysread का उपयोग करता है, जो कुछ हद तक "अतिरिक्त" AE :: io का उपयोग करते समय सिद्धांत की पुष्टि करता है।

खैर, अंत में, किसी भी चीज की आलोचना नहीं करने के लिए, हम DR :: Tarantool :: AsyncClient के आधार पर एक अतुल्यकालिक परीक्षण लिखेंगे।

 #!/usr/bin/perl use strict; use DR::Tarantool::AsyncClient 'tarantool'; use AnyEvent; use AnyEvent::Handle; my $cv = condvar AnyEvent; my $counts = {}; my $hdl; my $w; my $client; #        my $done_sub = sub { $counts->{ae}--; $cv->send unless $counts->{ae}; }; #      my $read_line_sub = sub { my $line = shift; my @params = split( " ", $line); $counts->{ae}++; $counts->{$params[0]}++; $client->call_lua($params[0], [@params[1..$#params],($params[0] eq 'increase_score' ? ('user_page') : ())], $done_sub); }; my $limit_concur_req = 12000; #  -   DR::Tarantool::AsyncClient->connect( host => '127.0.0.1', port => 33013, spaces => { 0 => { name => 'user_score', default_type => 'NUM', fields => [ qw(id fid score last_update koef), ], indexes => { 0 => { name => 'idx_id_fid', fields => [ 'id', 'fid' ] }, 1 => { name => 'idx_id', fields => [ 'id' ] }, 2 => { name => 'idx_id_score', fields => [ 'id', 'score' ] }, } }, 1 => { name => 'user_last_update', default_type => 'NUM', fields => [ qw(id last_update), ], indexes => { 0 => { name => 'idx_id', fields => [ 'id' ] }, } }, }, sub { ($client) = @_; $counts->{ae}++; $hdl = new AnyEvent::Handle fh => \*STDIN, on_error => sub { #     my ($hdl, $fatal, $msg) = @_; AE::log error => $msg; $hdl->destroy; $cv->send; }, on_eof => $done_sub; my @start_request; #        @start_request = (line => sub { my ($hdl, $line) = @_; $line =~ s/[\r\n]//g; $read_line_sub->($line) if $line; #       -      $hdl->push_read (@start_request) if $counts->{ae} < $limit_concur_req; }); $w = AnyEvent->timer (after => 0, interval => 1, cb => sub{ #             $limit_concur_req += 1000 if $counts->{ae} < 1000; $hdl->push_read (@start_request) if $counts->{ae} < $limit_concur_req; }); } ); $cv->recv;

स्क्रिप्ट अधिक फैली हुई थी और शायद बहुत पठनीय नहीं थी, लेकिन यह काफी हद तक इवेंट कोड को पढ़ने की आदत पर निर्भर करता है।
हम एक ही मशीन पर और परीक्षणों के बीच की संभावनाओं को समतल करने के लिए समान डेटा पर 4 ऐसी स्क्रिप्ट चलाते हैं।

और हमें पहले सिंक्रोनस टेस्ट के संबंध में 7 गुना वृद्धि हुई है! और दूसरे टेस्ट के संबंध में लगभग 2 बार। यह लगभग 30,000 प्रश्न प्रति सेकंड है। एक ही समय में, टारेंटयुला में डेटा भेजने वाली मोती स्क्रिप्ट लगभग 100% सीपीयू की सीमा पर काम करती है

अब हम अपने एल्गोरिथ्म के लिए सबसे खराब स्थिति बना लेंगे, जब सभी खिलाड़ियों ने कई दिनों तक लॉग इन नहीं किया था, और फिर वे सभी एक साथ लौट आए, वास्तव में यह सामान्य जीवन में नहीं होना चाहिए, इसलिए यह परीक्षण सिंथेटिक है, लेकिन यह प्रदर्शन के निचले स्तर को दिखाएगा। संख्याओं के क्रम को समझने के लिए, परीक्षण लॉन्च के समय हमारे पास पहले स्थान पर 14169698 प्रविष्टियां हैं। खिलाड़ी संबंधों की सबसे बड़ी संख्या 5000 है।

कुल मिलाकर, औसतन, हमें प्रति सेकंड लगभग 20,000 अनुरोध मिलते हैं, हालांकि श्रमिकों में प्रसार बड़ा हो गया है, उनमें से कुछ बड़ी संख्या में कनेक्शन वाले खिलाड़ियों पर आते हैं, किसी में कम संख्या में कनेक्शन वाले खिलाड़ी।

कुल मिलाकर, हमें एक बॉक्स मिला है जो 30,000 अनुरोध प्रति सेकंड (20,000 निराशावादी संस्करण में) की क्षमता के साथ समस्या को हल कर सकता है, जो सामान्य रूप से, कई परियोजनाओं की जरूरतों को पूरा करेगा।

अपने कार्यों के आधार पर एक दूसरे के संबंध में उपयोगकर्ताओं के महत्व का वजन निर्धारित करना (टारनटूल + लुआ)

More articles: