මෙම ලිපියෙන් අපි වර්ධනය වන්නේ කෙසේද සහ ඇයි යන්න ගැන කතා කරමු - සේවාදායක යෙදුම් සහ 1C: ව්‍යවසාය සේවාදායකයන් අතර තොරතුරු මාරු කරන යාන්ත්රණයක් - කාර්යයක් සැකසීමේ සිට ගෘහ නිර්මාණ ශිල්පය සහ ක්රියාත්මක කිරීමේ විස්තර හරහා සිතීම දක්වා.
අන්තර්ක්‍රියා පද්ධතිය (මෙතැන් සිට SV ලෙස හැඳින්වේ) යනු සහතික කළ බෙදාහැරීමක් සහිත බෙදා හරින ලද, දෝෂ-ඉවසන පණිවිඩ පද්ධතියකි. SV සැලසුම් කර ඇත්තේ ඉහළ පරිමාණයක් සහිත ඉහළ බරක් සහිත සේවාවක් ලෙස වන අතර එය මාර්ගගත සේවාවක් ලෙස (1C මගින් සපයනු ලැබේ) සහ ඔබේම සේවාදායක පහසුකම් මත යෙදවිය හැකි මහා පරිමාණ නිෂ්පාදනයක් ලෙස ලබා ගත හැකිය.
SV බෙදා හරින ලද ගබඩාව භාවිතා කරයි සහ සෙවුම් යන්ත්‍රය . අපි Java ගැනත් PostgreSQL තිරස්ව පරිමාණය කරන ආකාරය ගැනත් කතා කරමු.
ගැටලුව ප්රකාශ කිරීම
අපි අන්තර්ක්‍රියා පද්ධතිය නිර්මාණය කළේ ඇයිද යන්න පැහැදිලි කිරීම සඳහා, 1C හි ව්‍යාපාරික යෙදුම් සංවර්ධනය කරන ආකාරය ගැන මම ඔබට ටිකක් කියන්නම්.
ආරම්භ කිරීමට, අපි කරන්නේ කුමක්දැයි තවමත් නොදන්නා අය සඳහා අප ගැන ටිකක් :) අපි 1C: ව්‍යවසාය තාක්‍ෂණ වේදිකාව හදනවා. වේදිකාවට ව්‍යාපාරික යෙදුම් සංවර්ධන මෙවලමක් මෙන්ම ව්‍යාපාරික යෙදුම් හරස් වේදිකා පරිසරයක් තුළ ක්රියාත්මක වීමට ඉඩ සලසන ධාවන කාලයක් ඇතුළත් වේ.
සේවාදායක-සේවාදායක සංවර්ධන ආදර්ශය
1C: Enterprise මත නිර්මාණය කරන ලද ව්‍යාපාරික යෙදුම් තුන්-මට්ටමකින් ක්රියාත්මක වේ ගෘහ නිර්මාණ ශිල්පය "DBMS - යෙදුම් සේවාදායකය - සේවාදායකයා". යෙදුම් කේතය ලියා ඇත , යෙදුම් සේවාදායකයේ හෝ සේවාදායකයා මත ක්රියාත්මක කළ හැක. යෙදුම් වස්තු (නාමාවලි, ලේඛන, ආදිය) සමඟ සියලුම වැඩ කටයුතු මෙන්ම දත්ත සමුදාය කියවීම සහ ලිවීම සිදු කරනු ලබන්නේ සේවාදායකයේ පමණි. පෝරම සහ විධාන අතුරුමුහුණතෙහි ක්රියාකාරිත්වය සේවාදායකයේ ද ක්රියාත්මක වේ. සේවාදායකයා පෝරම ලබා ගැනීම, විවෘත කිරීම සහ ප්‍රදර්ශනය කිරීම, පරිශීලකයා සමඟ “සන්නිවේදනය” (අනතුරු ඇඟවීම්, ප්‍රශ්න...), ඉක්මන් ප්‍රතිචාරයක් අවශ්‍ය ආකෘතිවල කුඩා ගණනය කිරීම් (උදාහරණයක් ලෙස, ප්‍රමාණයෙන් මිල ගුණ කිරීම), දේශීය ලිපිගොනු සමඟ වැඩ කිරීම, උපකරණ සමඟ වැඩ කිරීම.
යෙදුම් කේතයේ, ක්‍රියා පටිපාටි සහ ශ්‍රිතවල ශීර්ෂයන් කේතය ක්රියාත්මක කරන්නේ කොතැනද යන්න පැහැදිලිව සඳහන් කළ යුතුය - &AtClient / &AtServer විධාන (&AtClient / &AtServer භාෂාවේ ඉංග්‍රීසි අනුවාදයේ). 1C සංවර්ධකයින් දැන් නියමයන් බව පවසමින් මාව නිවැරදි කරනු ඇත , නමුත් අපට මෙය දැන් වැදගත් නොවේ.
ඔබට සේවාදායක කේතයෙන් සේවාදායක කේතය ඇමතීමට හැකිය, නමුත් ඔබට සේවාදායක කේතයෙන් සේවාදායක කේතය ඇමතීමට නොහැක. මෙය හේතු ගණනාවක් නිසා අප කළ මූලික සීමාවකි. විශේෂයෙන්, සේවාදායකයාගෙන් හෝ සේවාදායකයෙන් - සේවාදායක කේතය කොතැනක හැඳින්වුවද එය එකම ආකාරයෙන් ක්රියාත්මක වන ආකාරයට ලිවිය යුතු බැවිනි. වෙනත් සේවාදායක කේතයකින් සේවාදායක කේතය ඇමතීමේදී, එවැනි සේවාදායකයෙක් නොමැත. තවද සේවාදායක කේතය ක්රියාත්මක කිරීමේදී, එය ඇමතූ සේවාදායකයාට වසා දැමීමට, යෙදුමෙන් පිටවීමට හැකි වන අතර, සේවාදායකයට තවදුරටත් ඇමතීමට කිසිවෙකු නොමැති බැවිනි.
බොත්තම ක්ලික් කිරීමක් හසුරුවන කේතය: සේවාදායකයාගෙන් සේවාදායක ක්‍රියා පටිපාටියක් ඇමතීම ක්‍රියා කරයි, සේවාදායකයෙන් සේවාදායක ක්‍රියා පටිපාටියක් ඇමතීම සිදු නොවේ
මෙයින් අදහස් කරන්නේ අපට සේවාදායකයෙන් සේවාදායක යෙදුමට යම් පණිවිඩයක් යැවීමට අවශ්‍ය නම්, උදාහරණයක් ලෙස, “දිගුකාලීන” වාර්තාවක් උත්පාදනය අවසන් වී ඇති බවත් වාර්තාව නැරඹිය හැකි බවත්, අපට එවැනි ක්‍රමයක් නොමැත. ඔබට උපක්‍රම භාවිතා කළ යුතුය, උදාහරණයක් ලෙස, සේවාදායකයාට සේවාදායක කේතයෙන් වරින් වර ඡන්ද විමසන්න. නමුත් මෙම ප්රවේශය අනවශ්ය ඇමතුම් සමඟ පද්ධතිය පටවන අතර, සාමාන්යයෙන් ඉතා අලංකාර ලෙස පෙනෙන්නේ නැත.
උදාහරණයක් ලෙස දුරකථන ඇමතුමක් පැමිණි විට අවශ්‍යතාවයක් ද ඇත - ඇමතුමක් ගන්නා විට, මේ පිළිබඳව සේවාලාභී යෙදුමට දැනුම් දෙන්න, එවිට එය ඇමතුම්කරුගේ අංකය භාවිතා කර එය ප්‍රතිවිරුද්ධ දත්ත ගබඩාවේ සොයා ගැනීමට සහ ඇමතුම් ප්‍රති පාර්ශවය පිළිබඳ පරිශීලක තොරතුරු පෙන්විය හැකිය. නැතහොත්, උදාහරණයක් ලෙස, ගබඩාවට ඇණවුමක් පැමිණි විට, මේ පිළිබඳව පාරිභෝගිකයාගේ සේවාදායක අයදුම්පතට දැනුම් දෙන්න. සාමාන්යයෙන්, එවැනි යාන්ත්රණයක් ප්රයෝජනවත් වන අවස්ථා බොහොමයක් තිබේ.
නිෂ්පාදනය ම ය
පණිවිඩ යැවීමේ යාන්ත්රණයක් සාදන්න. වේගවත්, විශ්වාසදායක, සහතික භාරදීමක් සමඟ, නම්‍යශීලීව පණිවිඩ සෙවීමේ හැකියාව ඇත. යාන්ත්රණය මත පදනම්ව, 1C යෙදුම් තුළ ක්රියාත්මක වන පණිවිඩකරුවෙකු (පණිවිඩ, වීඩියෝ ඇමතුම්) ක්රියාත්මක කරන්න.
පද්ධතිය තිරස් ලෙස පරිමාණය කිරීමට සැලසුම් කරන්න. වැඩිවන බර නෝඩ් ගණන වැඩි කිරීමෙන් ආවරණය කළ යුතුය.
Реализация
SV හි සේවාදායක කොටස සෘජුවම 1C: Enterprise වේදිකාවට ඒකාබද්ධ නොකිරීමට අපි තීරණය කළෙමු, නමුත් එය වෙනම නිෂ්පාදනයක් ලෙස ක්රියාත්මක කිරීමට, API 1C යෙදුම් විසඳුම් කේතයෙන් ඇමතිය හැකිය. මෙය හේතු ගණනාවක් නිසා සිදු කරන ලද අතර, ඉන් ප්‍රධානතම කරුණ නම්, විවිධ 1C යෙදුම් අතර (උදාහරණයක් ලෙස, වෙළඳ කළමනාකරණය සහ ගිණුම්කරණය අතර) පණිවිඩ හුවමාරු කර ගැනීමට මට අවශ්‍ය විය. විවිධ 1C යෙදුම් 1C හි විවිධ අනුවාද මත ධාවනය කළ හැකිය: ව්‍යවසාය වේදිකාව, විවිධ සේවාදායක මත පිහිටා ඇත, ආදිය. එවැනි තත්වයන් තුළ, 1C ස්ථාපනයන්හි "පැත්තේ" පිහිටා ඇති වෙනම නිෂ්පාදනයක් ලෙස SV ක්රියාත්මක කිරීම ප්රශස්ත විසඳුම වේ.
ඉතින් අපි තීරණය කළා SV එක වෙනම නිෂ්පාදනයක් විදියට කරන්න. අපගේ වලාකුළෙහි (wss://1cdialog.com) ස්ථාපනය කර ඇති CB සේවාදායකය කුඩා සමාගම් විසින් දේශීය ස්ථාපනය සහ සේවාදායකයේ වින්‍යාස කිරීම හා සම්බන්ධ පොදු කාර්ය පිරිවැය මඟහරවා ගැනීමට අපි නිර්දේශ කරමු. විශාල ගනුදෙනුකරුවන්ට ඔවුන්ගේ පහසුකම්වල තමන්ගේම CB සේවාදායකයක් ස්ථාපනය කිරීම සුදුසු යැයි සිතිය හැකිය. අපි අපගේ Cloud SaaS නිෂ්පාදනයේ සමාන ප්‍රවේශයක් භාවිතා කළෙමු - එය සේවාලාභීන්ගේ වෙබ් අඩවිවල ස්ථාපනය කිරීම සඳහා විශාල වශයෙන් නිෂ්පාදනය කරන ලද නිෂ්පාදනයක් ලෙස නිපදවන අතර අපගේ වලාකුළෙහි ද යොදවනු ලැබේ .
අයදුම්පත
බර පැටවීම සහ දෝෂ ඉවසීම බෙදා හැරීම සඳහා, අපි එක් ජාවා යෙදුමක් නොව කිහිපයක් යොදවන්නෙමු, ඒවා ඉදිරිපිට පැටවුම් සමතුලිතතාවයක් ඇත. ඔබට නෝඩයේ සිට නෝඩයට පණිවිඩයක් මාරු කිරීමට අවශ්‍ය නම්, Hazelcast හි ප්‍රකාශනය/දායක වීම භාවිත කරන්න.
සේවාදායකයා සහ සේවාදායකයා අතර සන්නිවේදනය websocket හරහා වේ. එය තත්‍ය කාලීන පද්ධති සඳහා හොඳින් ගැලපේ.
බෙදා හරින ලද හැඹිලිය
අපි Redis, Hazelcast සහ Ehcache අතර තෝරා ගත්තා. එය 2015 ය. රෙඩිස් දැන් අලුත් පොකුරක් නිකුත් කළා (අලුත්, භයානකයි), ගොඩක් සීමා සහිත සෙන්ටිනල් තියෙනවා. Ehcache පොකුරකට එකලස් කරන්නේ කෙසේදැයි නොදනී (මෙම ක්රියාකාරිත්වය පසුව දර්ශනය විය). අපි එය Hazelcast 3.4 සමඟ උත්සාහ කිරීමට තීරණය කළෙමු.
Hazelcast පෙට්ටියෙන් පිටත පොකුරකට එකලස් කර ඇත. තනි නෝඩ් මාදිලියේදී, එය ඉතා ප්රයෝජනවත් නොවන අතර එය හැඹිලියක් ලෙස පමණක් භාවිතා කළ හැකිය - එය තැටියට දත්ත ඩම්ප් කරන්නේ කෙසේදැයි නොදනී, ඔබට එකම නෝඩය නැති වුවහොත් ඔබට දත්ත අහිමි වේ. අපි Hazelcasts කිහිපයක් යොදවන්නෙමු, ඒවා අතර අපි විවේචනාත්මක දත්ත උපස්ථ කරමු. අපි හැඹිලිය උපස්ථ කරන්නේ නැහැ - අපි එය ගණන් ගන්නේ නැහැ.
අපට, Hazelcast යනු:
- පරිශීලක සැසි ගබඩා කිරීම. හැම වෙලාවෙම සැසියකට ඩේටාබේස් එකට යන්න සෑහෙන වෙලාවක් යන නිසා අපි සේරම සෙෂන් එක හේසල්කාස්ට් එකට දානවා.
- හැඹිලිය. ඔබ පරිශීලක පැතිකඩක් සොයන්නේ නම්, හැඹිලිය පරීක්ෂා කරන්න. නව පණිවිඩයක් ලිවීය - එය හැඹිලියට දමන්න.
- යෙදුම් අවස්ථා අතර සන්නිවේදනය සඳහා මාතෘකා. නෝඩය සිදුවීමක් ජනනය කර එය Hazelcast මාතෘකාව තුළ තබයි. මෙම මාතෘකාවට දායක වූ අනෙකුත් යෙදුම් නෝඩ් සිදුවීම ලබා ගැනීම සහ සැකසීම.
- පොකුරු අගුල්. උදාහරණයක් ලෙස, අපි අද්විතීය යතුරක් භාවිතයෙන් සාකච්ඡාවක් සාදන්නෙමු (1C දත්ත සමුදාය තුළ තනි සාකච්ඡාව):
conversationKeyChecker.check("БЕНЗОКОЛОНКА");
doInClusterLock("БЕНЗОКОЛОНКА", () -> {
conversationKeyChecker.check("БЕНЗОКОЛОНКА");
createChannel("БЕНЗОКОЛОНКА");
});නාලිකාවක් නොමැති බව අපි පරීක්ෂා කළා. අපි අගුල ගෙන එය නැවත පරීක්ෂා කර එය නිර්මාණය කළෙමු. ඔබ අගුල ගත් පසු අගුල පරීක්ෂා නොකළේ නම්, එම මොහොතේ වෙනත් නූලක් පරීක්ෂා කර දැන් එම සාකච්ඡාවම නිර්මාණය කිරීමට උත්සාහ කිරීමට අවස්ථාවක් තිබේ - නමුත් එය දැනටමත් පවතී. ඔබට සමමුහුර්ත හෝ සාමාන්‍ය java Lock භාවිතයෙන් අගුලු දැමිය නොහැක. දත්ත සමුදාය හරහා - එය මන්දගාමී වන අතර එය දත්ත සමුදායට අනුකම්පාවකි; Hazelcast හරහා - ඔබට අවශ්‍ය වන්නේ එයයි.
DBMS තෝරා ගැනීම
PostgreSQL සමඟ වැඩ කිරීම සහ මෙම DBMS හි සංවර්ධකයින් සමඟ සහයෝගයෙන් වැඩ කිරීමේ පුළුල් සහ සාර්ථක අත්දැකීම් අපට ඇත.
PostgreSQL පොකුරක් සමඟ එය පහසු නැත - තිබේ , , , නමුත් සාමාන්යයෙන් මේවා පෙට්ටියෙන් බැහැර වන NoSQL නොවේ. අපි NoSQL ප්රධාන ගබඩාව ලෙස සැලකුවේ නැත; අප මීට පෙර වැඩ නොකළ Hazelcast ගැනීම ප්රමාණවත් විය.
ඔබට සම්බන්ධතා දත්ත සමුදායක් පරිමාණය කිරීමට අවශ්‍ය නම්, එයින් අදහස් වේ . ඔබ දන්නා පරිදි, බෙදා හැරීම සමඟ අපි දත්ත සමුදාය වෙනම කොටස් වලට බෙදන්නෙමු, එවිට ඒ සෑම එකක්ම වෙනම සේවාදායකයක තැබිය හැකිය.
අපගේ බෙදා හැරීමේ පළමු අනුවාදය අපගේ යෙදුමේ එක් එක් වගු විවිධ සර්වර් හරහා විවිධ අනුපාතවලින් බෙදා හැරීමේ හැකියාව උපකල්පනය කළේය. A සේවාදායකයේ පණිවිඩ රාශියක් ඇත - කරුණාකර, අපි මෙම වගුවේ කොටසක් B සේවාදායකය වෙත ගෙන යමු. මෙම තීරණය හුදෙක් අකාල ප්‍රශස්තකරණය ගැන කෑගැසුවේය, එබැවින් අපි බහු-කුලී ප්‍රවේශයකට සීමා වීමට තීරණය කළෙමු.
ඔබට බහු කුලී නිවැසියන් ගැන කියවිය හැකිය, උදාහරණයක් ලෙස, වෙබ් අඩවියේ .
SV සතුව යෙදුම සහ ග්‍රාහකත්වය පිළිබඳ සංකල්ප ඇත. යෙදුමක් යනු එහි පරිශීලකයින් සහ ව්‍යාපාරික දත්ත සමඟ ERP හෝ ගිණුම්කරණය වැනි ව්‍යාපාරික යෙදුමක නිශ්චිත ස්ථාපනයකි. ග්‍රාහකයෙකු යනු SV සේවාදායකයේ අයදුම්පත ලියාපදිංචි කර ඇති සංවිධානයක් හෝ පුද්ගලයෙකි. ග්‍රාහකයෙකුට අයදුම්පත් කිහිපයක් ලියාපදිංචි කර තිබිය හැකි අතර, මෙම යෙදුම් එකිනෙකා සමඟ පණිවිඩ හුවමාරු කර ගත හැක. ග්‍රාහකයා අපගේ පද්ධතියේ කුලී නිවැසියෙකු බවට පත් විය. ග්‍රාහකයින් කිහිප දෙනෙකුගෙන් ලැබෙන පණිවිඩ එක් භෞතික දත්ත ගබඩාවක ස්ථානගත කළ හැක; ග්‍රාහකයෙකු විශාල තදබදයක් ජනනය කිරීමට පටන් ගෙන ඇති බව අප දුටුවහොත්, අපි එය වෙනම භෞතික දත්ත ගබඩාවකට (හෝ වෙනම දත්ත සමුදා සේවාදායකයකට) ගෙන යන්නෙමු.
සියලුම ග්රාහක දත්ත සමුදායේ පිහිටීම පිළිබඳ තොරතුරු සහිත මාර්ගගත වගුවක් ගබඩා කර ඇති ප්රධාන දත්ත සමුදායක් අප සතුව ඇත.
ප්රධාන දත්ත සමුදාය බාධාවක් වීම වැළැක්වීම සඳහා, අපි මාර්ගගත කිරීමේ වගුව (සහ නිතර අවශ්‍ය වන අනෙකුත් දත්ත) හැඹිලියක තබා ගනිමු.
ග්‍රාහකයාගේ දත්ත සමුදාය මන්දගාමී වීමට පටන් ගන්නේ නම්, අපි එය ඇතුළත කොටස් වලට කපා දමමු. අපි භාවිතා කරන වෙනත් ව්යාපෘති මත .
පරිශීලක පණිවිඩ නැතිවීම නරක බැවින්, අපි අපගේ දත්ත සමුදායන් අනුපිටපත් සමඟ නඩත්තු කරමු. සමමුහුර්ත සහ අසමමුහුර්ත අනුරූ වල සංයෝජනය මඟින් ප්රධාන දත්ත සමුදාය නැතිවීමකදී ඔබම රක්ෂණය කිරීමට ඔබට ඉඩ සලසයි. ප්‍රාථමික දත්ත සමුදාය සහ එහි සමමුහුර්ත අනුරුව එකවර අසමත් වුවහොත් පමණක් පණිවිඩ නැතිවීම සිදුවේ.
සමමුහුර්ත අනුරුවක් නැති වුවහොත්, අසමමුහුර්ත අනුරුව සමමුහුර්ත වේ.
ප්රධාන දත්ත සමුදාය නැති වුවහොත්, සමමුහුර්ත අනුරුව ප්රධාන දත්ත ගබඩාව බවට පත් වන අතර අසමමුහුර්ත අනුරුව සමමුහුර්ත අනුරුවක් බවට පත්වේ.
සෙවීම සඳහා ඉලාස්ටික් සෙවුම
වෙනත් දේ අතර, SV ද පණිවිඩකරුවෙකු වන බැවින්, එයට වේගවත්, පහසු සහ නම්‍යශීලී සෙවීමක් අවශ්‍ය වේ, රූප විද්‍යාව සැලකිල්ලට ගනිමින්, නිරවද්‍ය නොවන ගැලපීම් භාවිතා කරයි. රෝදය ප්‍රතිනිර්මාණය නොකිරීමට සහ පුස්තකාලය මත පදනම්ව නිර්මාණය කරන ලද නිදහස් සෙවුම් යන්ත්‍රය Elasticsearch භාවිතා නොකිරීමට අපි තීරණය කළෙමු . යෙදුම් නෝඩ් අසාර්ථක වූ විට ගැටළු තුරන් කිරීම සඳහා අපි පොකුරක් (ප්රධාන - දත්ත - දත්ත) තුළ ප්‍රත්‍යාස්ථ සෙවීම් යොදන්නෙමු.
github එකෙන් අපිට හම්බුනා Elasticsearch සඳහා සහ එය භාවිතා කරන්න. Elasticsearch දර්ශකයේ අපි වචන මූලයන් (ප්ලගිනය තීරණය කරන) සහ N-ග්‍රෑම් ගබඩා කරමු. පරිශීලකයා සෙවීමට පෙළ ඇතුළු කරන විට, අපි N-gram අතර ටයිප් කළ පෙළ සොයන්නෙමු. දර්ශකයට සුරකින විට, "පෙළ" යන වචනය පහත N-gram වලට බෙදනු ඇත:
[ඒ, ටෙක්, ටෙක්ස්, පෙළ, පෙළ, ek, ex, ext, texts, ks, kst, ksty, st, sty, you],තවද "පෙළ" යන වචනයේ මූලය ද ආරක්ෂා වනු ඇත. මෙම ප්රවේශය ඔබට වචනයේ ආරම්භයේ, මැද සහ අවසානයේ සෙවීමට ඉඩ සලසයි.
විශාල පින්තූරය
ලිපියේ ආරම්භයේ සිට පින්තූරය නැවත නැවත කරන්න, නමුත් පැහැදිලි කිරීම් සමඟ:
- බැලන්සර් අන්තර්ජාලයේ හෙළිදරව් විය; අපට nginx ඇත, එය ඕනෑම දෙයක් විය හැකිය.
- ජාවා යෙදුම් අවස්ථා Hazelcast හරහා එකිනෙකා සමඟ සන්නිවේදනය කරයි.
- අපි භාවිතා කරන වෙබ් සොකට් එකක් සමඟ වැඩ කිරීමට .
- ජාවා යෙදුම Java 8 හි ලියා ඇති අතර එය මිටි වලින් සමන්විත වේ . සැලසුම් වලට Java 10 වෙත සංක්‍රමණය සහ මොඩියුල වෙත සංක්‍රමණය ඇතුළත් වේ.
සංවර්ධනය සහ පරීක්ෂණ
SV සංවර්ධනය කිරීමේ සහ පරීක්ෂා කිරීමේ ක්‍රියාවලියේදී, අප භාවිතා කරන නිෂ්පාදනවල රසවත් විශේෂාංග ගණනාවක් අපට හමු විය.
බර පරීක්ෂා කිරීම සහ මතක කාන්දුවීම්
සෑම SV නිකුතුවක්ම මුදා හැරීමට බර පරීක්ෂා කිරීම ඇතුළත් වේ. එය සාර්ථක වන්නේ:
- පරීක්ෂණය දින කිහිපයක් ක්රියාත්මක වූ අතර සේවා අසාර්ථක වීමක් සිදු නොවීය
- ප්රධාන මෙහෙයුම් සඳහා ප්‍රතිචාර කාලය සුව පහසු සීමාවක් ඉක්මවා නැත
- පෙර අනුවාදයට සාපේක්ෂව කාර්ය සාධනය පිරිහීම 10% ට වඩා වැඩි නොවේ
අපි පරීක්ෂණ දත්ත සමුදාය දත්ත සමඟ පුරවන්නෙමු - මෙය සිදු කිරීම සඳහා, නිෂ්පාදන සේවාදායකයෙන් වඩාත් ක්රියාකාරී ග්‍රාහකයා පිළිබඳ තොරතුරු අපට ලැබේ, එහි අංක 5 කින් ගුණ කරන්න (පණිවිඩ, සාකච්ඡා, පරිශීලකයින්) සහ එය එසේ පරීක්ෂා කරන්න.
අපි වින්‍යාස තුනකින් අන්තර්ක්‍රියා පද්ධතියේ බර පරීක්ෂාව සිදු කරන්නෙමු:
- මානසික ආතතිය ටෙස්ට්
- සම්බන්ධතා පමණි
- ග්රාහක ලියාපදිංචිය
ආතති පරීක්ෂණය අතරතුර, අපි නූල් සිය ගණනක් දියත් කරන අතර, ඒවා නතර නොකර පද්ධතිය පූරණය කරයි: පණිවිඩ ලිවීම, සාකච්ඡා නිර්මාණය කිරීම, පණිවිඩ ලැයිස්තුවක් ලබා ගැනීම. අපි සාමාන්‍ය පරිශීලකයින්ගේ ක්‍රියා අනුකරණය කරමු (මගේ නොකියවූ පණිවිඩ ලැයිස්තුවක් ලබා ගන්න, යමෙකුට ලියන්න) සහ මෘදුකාංග විසඳුම් (වෙනස් වින්‍යාසයක පැකේජයක් සම්ප්‍රේෂණය කරන්න, අනතුරු ඇඟවීමක් කරන්න).
උදාහරණයක් ලෙස, ආතති පරීක්ෂණයේ කොටස පෙනෙන්නේ මෙයයි:
- පරිශීලක පුරනය වේ
- ඔබගේ නොකියවූ සාකච්ඡා ඉල්ලයි
- 50% පණිවිඩ කියවීමට ඉඩ ඇත
- 50% කෙටි පණිවිඩ යැවීමට ඉඩ ඇත
- ඊළඟ පරිශීලක:
- නව සාකච්ඡාවක් නිර්මාණය කිරීමට 20% ක අවස්ථාවක් ඇත
- එහි ඕනෑම සාකච්ඡාවක් අහඹු ලෙස තෝරා ගනී
- ඇතුලට යනවා
- පණිවිඩ, පරිශීලක පැතිකඩ ඉල්ලයි
- මෙම සාකච්ඡාවෙන් අහඹු පරිශීලකයන් වෙත පණිවිඩ පහක් නිර්මාණය කරයි
- සාකච්ඡාවට පිටත් වේ
- 20 වතාවක් පුනරාවර්තනය වේ
- ලොග් අවුට් වෙනවා, ස්ක්‍රිප්ට් එකේ මුලට ආපහු යනවා
- චැට්බෝට් පද්ධතියට ඇතුළු වේ (යෙදුම් කේතයෙන් පණිවිඩ යැවීම අනුකරණය කරයි)
- දත්ත හුවමාරුව සඳහා නව නාලිකාවක් නිර්මාණය කිරීමට 50% ක අවස්ථාවක් ඇත (විශේෂ සාකච්ඡාව)
- 50%ක් පවතින ඕනෑම නාලිකාවකට පණිවිඩයක් ලිවීමට ඉඩ ඇත
"සම්බන්ධතා පමණි" දර්ශනය හේතුවක් සඳහා දර්ශනය විය. තත්වයක් තිබේ: පරිශීලකයින් පද්ධතිය සම්බන්ධ කර ඇත, නමුත් තවමත් සම්බන්ධ වී නොමැත. සෑම පරිශීලකයෙක්ම උදේ 09 ට පරිගණකය ක්රියාත්මක කර සේවාදායකයට සම්බන්ධයක් ඇති කර ගෙන නිහඬව සිටියි. මේ අය භයානකයි, ඔවුන්ගෙන් බොහෝ දෙනෙක් සිටිති - ඔවුන් සතුව ඇති එකම පැකේජය PING/PONG වේ, නමුත් ඔවුන් සේවාදායකයට සම්බන්ධතාවය තබා ගනී (ඔවුන්ට එය තබා ගත නොහැක - නව පණිවිඩයක් තිබේ නම් කුමක් කළ යුතුද). එවැනි පරිශීලකයින් විශාල සංඛ්‍යාවක් පැය භාගයක් තුළ පද්ධතියට ඇතුළු වීමට උත්සාහ කරන තත්වයක් පරීක්ෂණය ප්‍රතිනිෂ්පාදනය කරයි. එය ආතති පරීක්ෂණයකට සමාන ය, නමුත් එහි අවධානය හරියටම මෙම පළමු ආදානය මත ය - එමඟින් කිසිදු අසාර්ථකත්වයක් නොමැත (පුද්ගලයෙකු පද්ධතිය භාවිතා නොකරන අතර එය දැනටමත් වැටේ - නරක දෙයක් ගැන සිතීම දුෂ්කර ය).
ග්‍රාහකයින් ලියාපදිංචි කිරීමේ ස්ක්‍රිප්ට් පළමු දියත් කිරීමේ සිට ආරම්භ වේ. අපි ආතති පරීක්ෂණයක් පැවැත්වූ අතර ලිපි හුවමාරු කිරීමේදී පද්ධතිය මන්දගාමී නොවන බවට සහතික විය. නමුත් පරිශීලකයින් පැමිණි අතර කල් ඉකුත්වීම හේතුවෙන් ලියාපදිංචිය අසාර්ථක වීමට පටන් ගත්තේය. ලියාපදිංචි කිරීමේදී අපි භාවිතා කළෙමු , පද්ධතියේ එන්ට්‍රොපිය හා සම්බන්ධ වේ. සේවාදායකයට ප්රමාණවත් එන්ට්‍රොපි සමුච්චය කිරීමට වෙලාවක් නොතිබූ අතර නව SecureRandom එකක් ඉල්ලූ විට, එය තත්පර දස ගණනක් නිශ්චල විය. මෙම තත්වයෙන් බොහෝ ක්‍රම තිබේ, උදාහරණයක් ලෙස: අඩු ආරක්ෂිත /dev/urandom වෙත මාරු වන්න, එන්ට්‍රොපි ජනනය කරන විශේෂ පුවරුවක් ස්ථාපනය කරන්න, අහඹු සංඛ්‍යා කල්තියා ජනනය කර ඒවා තටාකයක ගබඩා කරන්න. අපි තටාකය සමඟ ගැටළුව තාවකාලිකව වසා දැමුවෙමු, නමුත් එතැන් සිට අපි නව ග්‍රාහකයින් ලියාපදිංචි කිරීම සඳහා වෙනම පරීක්ෂණයක් පවත්වමු.
අපි බඩු උත්පාදක යන්ත්රයක් ලෙස භාවිතා කරමු . එය websocket සමඟ වැඩ කරන්නේ කෙසේදැයි නොදනී; එයට ප්ලගිනයක් අවශ්‍ය වේ. "jmeter websocket" විමසුම සඳහා සෙවුම් ප්‍රතිඵලවල පළමු ඒවා වන්නේ: , නිර්දේශ කරන .
එතනින් තමයි අපි පටන් ගන්න තීරණය කළේ.
බරපතල පරීක්ෂණ ආරම්භ කිරීමෙන් පසු, JMeter මතකය කාන්දු වීමට පටන් ගත් බව අපි සොයා ගත්තෙමු.
ප්ලගිනය වෙනම විශාල කතාවකි; තරු 176 කින්, එය github මත ගෑරුප්පු 132 ක් ඇත. කතුවරයාම 2015 සිට එයට කැපවී නැත (අපි එය 2015 දී ගත්තෙමු, පසුව එය සැක මතු කළේ නැත), මතක කාන්දුවීම් සම්බන්ධ github ගැටළු කිහිපයක්, 7 unclosed pull requests.
ඔබ මෙම ප්ලගිනය භාවිතයෙන් බර පරීක්ෂාව සිදු කිරීමට තීරණය කරන්නේ නම්, කරුණාකර පහත සාකච්ඡා වෙත අවධානය යොමු කරන්න:
- බහු-නූල් පරිසරයක් තුළ, නිතිපතා LinkedList භාවිතා කරන ලද අතර, ප්රතිඵලය විය ධාවන කාලය තුළ. ConcurrentLinkedDeque වෙත මාරු වීමෙන් හෝ සමමුහුර්ත කළ බ්ලොක් මගින් මෙය විසඳිය හැක. අපි අප වෙනුවෙන් පළමු විකල්පය තෝරා ගත්තෙමු ().
- මතක කාන්දු වීම; විසන්ධි කරන විට, සම්බන්ධතා තොරතුරු මකා නොදමනු ලැබේ ().
- ප්‍රවාහ ප්‍රකාරයේදී (සාම්පලයේ අවසානයේ වෙබ් සොකට් එක වසා නොමැති නමුත් සැලසුමේ පසුව භාවිතා කරන විට), ප්‍රතිචාර රටා ක්‍රියා නොකරයි ().
මේක github එකේ තියෙන එකක්. අපි කළ දේ:
- ගෙන ඇත (@elyrank) - එය ගැටළු 1 සහ 3 විසඳයි
- විසඳන ලද ගැටළුව 2
- ජැටිය 9.2.14 සිට 9.3.12 දක්වා යාවත්කාලීන කරන ලදී
- ThreadLocal හි ඔතා ඇති SimpleDateFormat; SimpleDateFormat නූල්-ආරක්ෂිත නොවේ, එය ධාවන වේලාවේදී NPE වලට හේතු විය
- තවත් මතක කාන්දුවක් නිරාකරණය කර ඇත (සම්බන්ධතාවය විසන්ධි වූ විට වැරදි ලෙස වසා ඇත)
සහ තවමත් එය ගලා යයි!
මතකය ඉවර වෙන්න පටන් ගත්තේ දවසකින් නෙවෙයි, දෙකකින්. කාලය ඉතිරිව නොතිබුණි, එබැවින් අපි අඩු නූල් දියත් කිරීමට තීරණය කළෙමු, නමුත් නියෝජිතයන් හතරක් මත. මෙය අවම වශයෙන් සතියකට ප්රමාණවත් විය යුතුය.
දවස් දෙකක් ගෙවිලා ගියා...
දැන් Hazelcast මතකය ඉවරයි. දින කිහිපයක පරීක්‍ෂණයකින් පසු, හේසල්කාස්ට් මතකය නොමැතිකම ගැන පැමිණිලි කිරීමට පටන් ගත් බවත්, ටික වේලාවකට පසු පොකුර කඩා වැටුණු බවත්, නෝඩ් එකින් එක මිය යන බවත් ලඝු-සටහන් පෙන්වා දුන්නේය. අපි JVisualVM hazelcast වෙත සම්බන්ධ කළ අතර “නැගී එන කියත්” දුටුවෙමු - එය නිතිපතා GC ලෙස හැඳින්වූ නමුත් මතකය ඉවත් කිරීමට නොහැකි විය.
hazelcast 3.4 හි, සිතියමක් / multiMap (map.destroy()) මකා දැමීමේදී, මතකය සම්පූර්ණයෙන්ම නිදහස් නොවන බව පෙනී ගියේය:
දෝෂය දැන් 3.5 හි නිවැරදි කර ඇත, නමුත් එය එවකට ගැටලුවක් විය. අපි ගතික නම් සහිත නව බහු සිතියම් නිර්මාණය කර අපගේ තර්කනය අනුව ඒවා මකා දැමුවෙමු. කේතය මේ වගේ දෙයක් පෙනුණා:
public void join(Authentication auth, String sub) {
MultiMap<UUID, Authentication> sessions = instance.getMultiMap(sub);
sessions.put(auth.getUserId(), auth);
}
public void leave(Authentication auth, String sub) {
MultiMap<UUID, Authentication> sessions = instance.getMultiMap(sub);
sessions.remove(auth.getUserId(), auth);
if (sessions.size() == 0) {
sessions.destroy();
}
}වයිසොව්:
service.join(auth1, "НОВЫЕ_СООБЩЕНИЯ_В_ОБСУЖДЕНИИ_UUID1");
service.join(auth2, "НОВЫЕ_СООБЩЕНИЯ_В_ОБСУЖДЕНИИ_UUID1");එක් එක් ග්‍රාහකත්වය සඳහා multiMap සාදන ලද අතර එය අවශ්‍ය නොවන විට මකා දමන ලදී. අපි සිතියම ආරම්භ කිරීමට තීරණය කළෙමු , යතුර දායකත්වයේ නම වනු ඇත, සහ අගයන් සැසි හඳුනාගැනීම් වනු ඇත (අවශ්‍ය නම් ඔබට පරිශීලක හඳුනාගැනීම් ලබා ගත හැක).
public void join(Authentication auth, String sub) {
addValueToMap(sub, auth.getSessionId());
}
public void leave(Authentication auth, String sub) {
removeValueFromMap(sub, auth.getSessionId());
}ප්‍රස්ථාර වැඩි දියුණු වී ඇත.
බර පරීක්ෂාව ගැන අප ඉගෙන ගෙන ඇති තවත් මොනවාද?
- JSR223 අනර්ඝ ලෙස ලිවිය යුතු අතර සම්පාදන හැඹිලි ඇතුළත් කළ යුතුය - එය වඩා වේගවත් වේ. .
- Jmeter-Plugins ප්‍රස්ථාර සම්මත ඒවාට වඩා තේරුම් ගැනීමට පහසුය. .
Hazelcast සමඟ අපගේ අත්දැකීම් ගැන
Hazelcast අපට නව නිෂ්පාදනයක් විය, අපි එය සමඟ වැඩ කිරීමට පටන් ගත්තේ 3.4.1 අනුවාදයෙන්, දැන් අපගේ නිෂ්පාදන සේවාදායකය 3.9.2 අනුවාදය ක්රියාත්මක වේ (ලියන අවස්ථාව වන විට, Hazelcast හි නවතම අනුවාදය 3.10 වේ).
හැඳුනුම්පත උත්පාදනය
අපි ආරම්භ කළේ පූර්ණ සංඛ්‍යා හඳුනාගැනීම් වලින්. අපි හිතමු අපිට අලුත් ආයතනයක් සඳහා තවත් දිගුවක් අවශ්‍යයි කියලා. දත්ත සමුදායේ අනුපිළිවෙල සුදුසු නොවේ, වගු බෙදා හැරීමට සම්බන්ධ වේ - DB1 හි ID = 1 පණිවිඩයක් සහ DB1 හි ID = 2 පණිවිඩයක් ඇති බව පෙනේ, ඔබට මෙම හැඳුනුම්පත Elasticsearch හි හෝ Hazelcast හි තැබිය නොහැක. , නමුත් නරකම දෙය නම් ඔබට දත්ත සමුදා දෙකක දත්ත එකකට ඒකාබද්ධ කිරීමට අවශ්‍ය නම් (උදාහරණයක් ලෙස, මෙම ග්‍රාහකයින් සඳහා එක් දත්ත සමුදායක් ප්රමාණවත් බව තීරණය කිරීම). ඔබට Hazelcast වෙත AtomicLongs කිහිපයක් එකතු කර කවුන්ටරය එහි තබා ගත හැක, එවිට නව හැඳුනුම්පතක් ලබා ගැනීමේ කාර්ය සාධනය incrementAndGet සහ Hazelcast වෙත ඉල්ලීමක් සඳහා කාලය වේ. නමුත් Hazelcast වඩා ප්රශස්ත දෙයක් ඇත - FlakeIdGenerator. එක් එක් සේවාදායකයා සම්බන්ධ කර ගන්නා විට, ඔවුන්ට හැඳුනුම් පරාසයක් ලබා දී ඇත, උදාහරණයක් ලෙස, පළමු එක - 1 සිට 10 දක්වා, දෙවන - 000 සිට 10 දක්වා, සහ යනාදිය. දැන් සේවාලාභියාට නිකුත් කරන ලද පරාසය අවසන් වන තුරුම නව හඳුනාගැනීම් නිකුත් කළ හැකිය. එය ඉක්මනින් ක්‍රියා කරයි, නමුත් ඔබ යෙදුම (සහ Hazelcast සේවාදායකයා) නැවත ආරම්භ කරන විට, නව අනුපිළිවෙලක් ආරම්භ වේ - එබැවින් මඟ හැරීම් ආදිය. ඊට අමතරව, සංවර්ධකයන්ට හැඳුනුම්පත් පූර්ණ සංඛ්‍යා වන්නේ මන්දැයි ඇත්ත වශයෙන්ම නොතේරෙන නමුත් එතරම් නොගැලපේ. අපි හැම දෙයක්ම කිරා මැන බලා UUID වලට මාරු වුණා.
මාර්ගය වන විට, ට්විටර් වැනි වීමට කැමති අය සඳහා, එවැනි Snowcast පුස්තකාලයක් ඇත - මෙය Hazelcast මුදුනේ Snowflake ක්රියාත්මක කිරීමකි. ඔබට එය මෙතැනින් නැරඹිය හැක:
නමුත් අපි තව දුරටත් ඒ සඳහා යොමු වී නැත.
TransactionalMap.replace
තවත් පුදුමයක්: TransactionalMap.replace ක්‍රියා නොකරයි. මෙන්න පරීක්ෂණයක්:
@Test
public void replaceInMap_putsAndGetsInsideTransaction() {
hazelcastInstance.executeTransaction(context -> {
HazelcastTransactionContextHolder.setContext(context);
try {
context.getMap("map").put("key", "oldValue");
context.getMap("map").replace("key", "oldValue", "newValue");
String value = (String) context.getMap("map").get("key");
assertEquals("newValue", value);
return null;
} finally {
HazelcastTransactionContextHolder.clearContext();
}
});
}
Expected : newValue
Actual : oldValueමට getForUpdate භාවිතයෙන් මගේම ආදේශකයක් ලිවීමට සිදු විය:
protected <K,V> boolean replaceInMap(String mapName, K key, V oldValue, V newValue) {
TransactionalTaskContext context = HazelcastTransactionContextHolder.getContext();
if (context != null) {
log.trace("[CACHE] Replacing value in a transactional map");
TransactionalMap<K, V> map = context.getMap(mapName);
V value = map.getForUpdate(key);
if (oldValue.equals(value)) {
map.put(key, newValue);
return true;
}
return false;
}
log.trace("[CACHE] Replacing value in a not transactional map");
IMap<K, V> map = hazelcastInstance.getMap(mapName);
return map.replace(key, oldValue, newValue);
}සාමාන්‍ය දත්ත ව්‍යුහයන් පමණක් නොව, ඒවායේ ගනුදෙනු අනුවාද ද පරීක්ෂා කරන්න. IMap ක්‍රියා කරන නමුත් TransactionalMap තවදුරටත් නොපවතී.
අක්‍රිය කාලයකින් තොරව නව JAR එකක් ඇතුළු කරන්න
පළමුව, අපි Hazelcast හි අපගේ පන්තිවල වස්තූන් වාර්තා කිරීමට තීරණය කළෙමු. උදාහරණයක් ලෙස, අපට යෙදුම් පන්තියක් ඇත, අපට එය සුරැකීමට සහ කියවීමට අවශ්‍යය. සුරකින්න:
IMap<UUID, Application> map = hazelcastInstance.getMap("application");
map.set(id, application);අපි කියවන්නේ:
IMap<UUID, Application> map = hazelcastInstance.getMap("application");
return map.get(id);හැම දෙයක්ම වැඩ කරනවා. පසුව අපි සෙවීමට Hazelcast හි දර්ශකයක් තැනීමට තීරණය කළෙමු:
map.addIndex("subscriberId", false);තවද නව ආයතනයක් ලියන විට, ඔවුන් ClassNotFoundException ලැබීමට පටන් ගත්හ. Hazelcast දර්ශකයට එක් කිරීමට උත්සාහ කළ නමුත් අපගේ පන්තිය ගැන කිසිවක් දැන නොසිටි අතර මෙම පන්තිය සහිත JAR එකක් එයට සැපයීමට අවශ්‍ය විය. අපි එය කළෙමු, සියල්ල ක්රියාත්මක විය, නමුත් නව ගැටළුවක් මතු විය: පොකුර සම්පූර්ණයෙන්ම නතර නොකර JAR යාවත්කාලීන කරන්නේ කෙසේද? Node-by-node යාවත්කාලීන කිරීමේදී Hazelcast නව JAR ලබා නොගනී. මෙම අවස්ථාවේදී අපි දර්ශක සෙවීමකින් තොරව ජීවත් විය හැකි බව තීරණය කළෙමු. ඇත්ත වශයෙන්ම, ඔබ ප්රධාන වටිනාකම් ගබඩාවක් ලෙස Hazelcast භාවිතා කරන්නේ නම්, එවිට සියල්ල ක්රියාත්මක වනු ඇත? ඇත්තෙන්ම නැහැ. මෙහිදී නැවතත් IMap සහ TransactionalMap වල හැසිරීම වෙනස් වේ. IMap ගණන් නොගන්නා තැන, TransactionalMap දෝෂයක් ඇති කරයි.
IMap. අපි වස්තු 5000 ක් ලියන්නෙමු, ඒවා කියවන්න. සෑම දෙයක්ම අපේක්ෂා කෙරේ.
@Test
void get5000() {
IMap<UUID, Application> map = hazelcastInstance.getMap("application");
UUID subscriberId = UUID.randomUUID();
for (int i = 0; i < 5000; i++) {
UUID id = UUID.randomUUID();
String title = RandomStringUtils.random(5);
Application application = new Application(id, title, subscriberId);
map.set(id, application);
Application retrieved = map.get(id);
assertEquals(id, retrieved.getId());
}
}නමුත් එය ගනුදෙනුවකදී ක්‍රියා නොකරයි, අපට ClassNotFoundException එකක් ලැබේ:
@Test
void get_transaction() {
IMap<UUID, Application> map = hazelcastInstance.getMap("application_t");
UUID subscriberId = UUID.randomUUID();
UUID id = UUID.randomUUID();
Application application = new Application(id, "qwer", subscriberId);
map.set(id, application);
Application retrievedOutside = map.get(id);
assertEquals(id, retrievedOutside.getId());
hazelcastInstance.executeTransaction(context -> {
HazelcastTransactionContextHolder.setContext(context);
try {
TransactionalMap<UUID, Application> transactionalMap = context.getMap("application_t");
Application retrievedInside = transactionalMap.get(id);
assertEquals(id, retrievedInside.getId());
return null;
} finally {
HazelcastTransactionContextHolder.clearContext();
}
});
}3.8 හි, පරිශීලක පන්තියේ යෙදවීමේ යාන්ත්රණය දර්ශනය විය. ඔබට එක් ප්රධාන නෝඩයක් නම් කර එය මත JAR ගොනුව යාවත්කාලීන කළ හැකිය.
දැන් අපි අපගේ ප්රවේශය සම්පූර්ණයෙන්ම වෙනස් කර ඇත: අපි එය අප විසින්ම JSON වෙත අනුක්‍රමික කර Hazelcast හි සුරකිමු. Hazelcast හට අපගේ පන්තිවල ව්‍යුහය දැන ගැනීමට අවශ්‍ය නොවන අතර, අපට අක්‍රිය කාලයකින් තොරව යාවත්කාලීන කළ හැක. වසම් වස්තු අනුවාද කිරීම යෙදුම මගින් පාලනය වේ. යෙදුමේ විවිධ අනුවාද එකවර ක්රියාත්මක විය හැකි අතර, නව යෙදුම නව ක්ෂේත්‍ර සමඟ වස්තූන් ලියන විට තත්වයක් ඇතිවිය හැකි නමුත් පැරණි එක තවමත් මෙම ක්ෂේත්‍ර ගැන නොදනී. ඒ අතරම, නව යෙදුම නව ක්ෂේත්‍ර නොමැති පැරණි යෙදුමෙන් ලියා ඇති වස්තූන් කියවයි. අපි යෙදුම තුළ එවැනි තත්ත්වයන් හසුරුවන්නෙමු, නමුත් සරල බව සඳහා අපි ක්ෂේත්‍ර වෙනස් කිරීම හෝ මකා නොදමමු, අපි නව ක්ෂේත්‍ර එකතු කිරීමෙන් පමණක් පන්ති පුළුල් කරමු.
අපි ඉහළ කාර්ය සාධනය සහතික කරන ආකාරය
Hazelcast වෙත සංචාර හතරක් - හොඳයි, දත්ත ගබඩාවට දෙකක් - නරකයි
දත්ත සඳහා හැඹිලිය වෙත යාම සැමවිටම දත්ත සමුදායට යාමට වඩා හොඳය, නමුත් භාවිතයට නොගත් වාර්තා ගබඩා කිරීමටද ඔබට අවශ්‍ය නැත. සංවර්ධනයේ අවසාන අදියර දක්වා හැඹිලිගත කළ යුතු දේ පිළිබඳ තීරණය අපි තබමු. නව ක්‍රියාකාරීත්වය කේතනය කළ විට, අපි PostgreSQL (log_min_duration_statement to 0) හි සියලුම විමසුම් ලොග් කිරීම ක්රියාත්මක කර මිනිත්තු 20ක් සඳහා load testing ක්රියාත්මක කරන්නෙමු. එකතු කරන ලද ලොග භාවිතා කරමින්, pgFouine සහ pgBadger වැනි උපයෝගිතා වලට විශ්ලේෂණාත්මක වාර්තා ගොඩනගා ගත හැක. වාර්තා වලදී, අපි මූලික වශයෙන් සොයන්නේ මන්දගාමී සහ නිරන්තර විමසුම් සඳහා ය. මන්දගාමී විමසුම් සඳහා, අපි ක්රියාත්මක කිරීමේ සැලැස්මක් (පැහැදිලි කරන්න) ගොඩනඟා එවැනි විමසුමක් වේගවත් කළ හැකිද යන්න ඇගයීමට ලක් කරන්නෙමු. එකම ආදාන දත්ත සඳහා නිරන්තර ඉල්ලීම් හැඹිලියට හොඳින් ගැලපේ. අපි විමසුම් "පැතලි" තබා ගැනීමට උත්සාහ කරමු, එක් විමසුමකට එක් වගුවක්.
මෙහෙයුම
SV ඔන්ලයින් සේවාවක් ලෙස 2017 වසන්තයේ දී ක්රියාත්මක කරන ලද අතර, වෙනම නිෂ්පාදනයක් ලෙස, SV 2017 නොවැම්බර් මාසයේදී නිකුත් කරන ලදී (ඒ වන විට බීටා අනුවාද තත්වයේ).
වසරකට වැඩි කාලයක් ක්රියාත්මක වන විට, CB ඔන්ලයින් සේවාව ක්රියාත්මක කිරීමේදී බරපතල ගැටළු නොමැත. අපි හරහා මාර්ගගත සේවාව නිරීක්ෂණය කරමු , සිට එකතු කිරීම සහ යෙදවීම .
SV සේවාදායක බෙදාහැරීම දේශීය පැකේජ ආකාරයෙන් සපයනු ලැබේ: RPM, DEB, MSI. Plus Windows සඳහා අපි එක් යන්ත්‍රයක සේවාදායකය, Hazelcast සහ Elasticsearch ස්ථාපනය කරන තනි EXE ආකාරයෙන් තනි ස්ථාපකයක් සපයන්නෙමු. අපි මුලින්ම ස්ථාපනයේ මෙම අනුවාදය "demo" අනුවාදය ලෙස හැඳින්වූ නමුත්, මෙය වඩාත් ජනප්රිය යෙදවුම් විකල්පය බව දැන් පැහැදිලි වී ඇත.
මූලාශ්රය: www.habr.com