🥇விநியோகிக்கப்பட்ட விண்ணப்பங்களின் கட்டுமானத் தொகுதிகள். இரண்டாவது தோராயம்

அறிவிப்பு

சகாக்களே, கோடையின் நடுப்பகுதியில் வரிசை அமைப்புகளின் வடிவமைப்பு குறித்த மற்றொரு தொடர் கட்டுரைகளை வெளியிட திட்டமிட்டுள்ளேன்: “VTrade சோதனை” - வர்த்தக அமைப்புகளுக்கான கட்டமைப்பை எழுதும் முயற்சி. இந்தத் தொடர் ஒரு பரிமாற்றம், ஏலம் மற்றும் கடையை உருவாக்குவதற்கான கோட்பாடு மற்றும் நடைமுறையை ஆராயும். கட்டுரையின் முடிவில், உங்களுக்கு மிகவும் விருப்பமான தலைப்புகளுக்கு வாக்களிக்க உங்களை அழைக்கிறேன்.

Erlang/Elixir இல் விநியோகிக்கப்பட்ட எதிர்வினை பயன்பாடுகள் குறித்த தொடரின் இறுதிக் கட்டுரை இதுவாகும். IN முதல் கட்டுரை எதிர்வினை கட்டமைப்பின் தத்துவார்த்த அடித்தளங்களை நீங்கள் காணலாம். இரண்டாவது கட்டுரை அத்தகைய அமைப்புகளை உருவாக்குவதற்கான அடிப்படை வடிவங்கள் மற்றும் வழிமுறைகளை விளக்குகிறது.

இன்று நாம் குறியீடு அடிப்படை மற்றும் திட்டங்களின் வளர்ச்சியின் சிக்கல்களை பொதுவாக எழுப்புவோம்.

சேவைகளின் அமைப்பு

நிஜ வாழ்க்கையில், ஒரு சேவையை உருவாக்கும் போது, நீங்கள் அடிக்கடி ஒரு கட்டுப்படுத்தியில் பல தொடர்பு முறைகளை இணைக்க வேண்டும். எடுத்துக்காட்டாக, திட்டப் பயனர் சுயவிவரங்களை நிர்வகிப்பதில் உள்ள சிக்கலைத் தீர்க்கும் பயனர்கள் சேவை, req-resp கோரிக்கைகளுக்கு பதிலளிக்க வேண்டும் மற்றும் பப்-சப் வழியாக சுயவிவர புதுப்பிப்புகளைப் புகாரளிக்க வேண்டும். இந்த வழக்கு மிகவும் எளிமையானது: செய்தியிடலுக்குப் பின்னால் சேவை தர்க்கத்தை செயல்படுத்தி புதுப்பிப்புகளை வெளியிடும் ஒரு கட்டுப்படுத்தி உள்ளது.

பிழை-சகிப்புத்தன்மை கொண்ட விநியோகிக்கப்பட்ட சேவையை நாம் செயல்படுத்த வேண்டியிருக்கும் போது நிலைமை மிகவும் சிக்கலானதாகிறது. பயனர்களுக்கான தேவைகள் மாறிவிட்டன என்று கற்பனை செய்யலாம்:

இப்போது சேவையானது 5 கிளஸ்டர் முனைகளில் கோரிக்கைகளைச் செயல்படுத்த வேண்டும்,
பின்னணி செயலாக்க பணிகளைச் செய்ய முடியும்,
மேலும் சுயவிவர புதுப்பிப்புகளுக்கான சந்தா பட்டியல்களை மாறும் வகையில் நிர்வகிக்க முடியும்.

கருத்து: நிலையான சேமிப்பு மற்றும் தரவு நகலெடுப்பின் சிக்கலை நாங்கள் கருத்தில் கொள்ளவில்லை. இந்தச் சிக்கல்கள் முன்பே தீர்க்கப்பட்டுவிட்டன என்றும், கணினி ஏற்கனவே நம்பகமான மற்றும் அளவிடக்கூடிய சேமிப்பக அடுக்கைக் கொண்டுள்ளது என்றும், கையாளுபவர்கள் அதனுடன் தொடர்புகொள்வதற்கான வழிமுறைகளைக் கொண்டுள்ளனர் என்றும் வைத்துக்கொள்வோம்.

பயனர் சேவையின் முறையான விளக்கம் மிகவும் சிக்கலானதாகிவிட்டது. ஒரு புரோகிராமரின் பார்வையில், செய்தி அனுப்புதலின் பயன்பாடு காரணமாக மாற்றங்கள் குறைவாக இருக்கும். முதல் தேவையை பூர்த்தி செய்ய, req-resp பரிமாற்ற புள்ளியில் சமநிலையை உள்ளமைக்க வேண்டும்.

பின்னணி பணிகளைச் செயல்படுத்துவதற்கான தேவை அடிக்கடி நிகழ்கிறது. பயனர்களில், இது பயனர் ஆவணங்களைச் சரிபார்ப்பது, பதிவிறக்கம் செய்யப்பட்ட மல்டிமீடியாவைச் செயலாக்குவது அல்லது சமூக ஊடகத்துடன் தரவை ஒத்திசைப்பது. நெட்வொர்க்குகள். இந்த பணிகள் எப்படியாவது கிளஸ்டருக்குள் விநியோகிக்கப்பட வேண்டும் மற்றும் செயல்பாட்டின் முன்னேற்றம் கண்காணிக்கப்பட வேண்டும். எனவே, எங்களிடம் இரண்டு தீர்வு விருப்பங்கள் உள்ளன: முந்தைய கட்டுரையிலிருந்து பணி விநியோக டெம்ப்ளேட்டைப் பயன்படுத்தவும் அல்லது அது பொருந்தவில்லை என்றால், தனிப்பயன் பணி அட்டவணையை எழுதவும், இது செயலிகளின் தொகுப்பை நமக்குத் தேவையான வழியில் நிர்வகிக்கும்.

புள்ளி 3க்கு பப்-சப் டெம்ப்ளேட் நீட்டிப்பு தேவை. செயல்படுத்துவதற்கு, ஒரு பப்-சப் எக்ஸ்சேஞ்ச் புள்ளியை உருவாக்கிய பிறகு, இந்த புள்ளியின் கட்டுப்படுத்தியை எங்கள் சேவையில் கூடுதலாகத் தொடங்க வேண்டும். எனவே, சந்தாக்களை செயலாக்குவதற்கும், மெசேஜிங் லேயரில் இருந்து குழுவிலகுவதற்கும் தர்க்கத்தை நாம் பயனர்களின் செயலாக்கத்திற்கு நகர்த்துவது போலாகும்.

இதன் விளைவாக, சிக்கலின் சிதைவு, தேவைகளைப் பூர்த்தி செய்ய, வெவ்வேறு முனைகளில் சேவையின் 5 நிகழ்வுகளைத் தொடங்க வேண்டும் மற்றும் கூடுதல் நிறுவனத்தை உருவாக்க வேண்டும் - ஒரு பப்-சப் கன்ட்ரோலர், சந்தாவுக்குப் பொறுப்பாகும்.
5 ஹேண்ட்லர்களை இயக்க, நீங்கள் சேவைக் குறியீட்டை மாற்ற வேண்டியதில்லை. பரிமாற்ற புள்ளியில் சமநிலை விதிகளை அமைப்பது மட்டுமே கூடுதல் செயல், இதைப் பற்றி சிறிது நேரம் கழித்து பேசுவோம்.
கூடுதல் சிக்கலானது உள்ளது: பப்-சப் கன்ட்ரோலர் மற்றும் தனிப்பயன் பணி திட்டமிடல் ஆகியவை ஒரே நகலில் வேலை செய்ய வேண்டும். மீண்டும், செய்தியிடல் சேவை, ஒரு அடிப்படையான ஒன்றாக, ஒரு தலைவரைத் தேர்ந்தெடுப்பதற்கான வழிமுறையை வழங்க வேண்டும்.

தலைவர் தேர்வு

விநியோகிக்கப்பட்ட அமைப்புகளில், தலைவர் தேர்தல் என்பது சில சுமைகளின் விநியோகிக்கப்பட்ட செயலாக்கத்தை திட்டமிடுவதற்கு பொறுப்பான ஒரு செயல்முறையை நியமிப்பதற்கான செயல்முறையாகும்.

மையப்படுத்தலுக்கு வாய்ப்பில்லாத அமைப்புகளில், பாக்ஸோஸ் அல்லது ராஃப்ட் போன்ற உலகளாவிய மற்றும் ஒருமித்த அடிப்படையிலான வழிமுறைகள் பயன்படுத்தப்படுகின்றன.
செய்தி அனுப்புதல் ஒரு தரகர் மற்றும் ஒரு மைய உறுப்பு என்பதால், அது அனைத்து சேவைக் கட்டுப்பாட்டாளர்களையும் - வேட்பாளர் தலைவர்களையும் பற்றி அறிந்திருக்கிறது. வாக்களிக்காமலேயே மெசேஜிங் ஒரு தலைவரை நியமிக்கலாம்.

பரிமாற்ற புள்ளியைத் தொடங்கி இணைத்த பிறகு, அனைத்து சேவைகளும் கணினி செய்தியைப் பெறுகின்றன #'$leader'{exchange = ?EXCHANGE, pid = LeaderPid, servers = Servers}. என்றால் LeaderPid உடன் ஒத்துப்போகிறது pid தற்போதைய செயல்முறை, அது தலைவராக நியமிக்கப்பட்டார், மற்றும் பட்டியல் Servers அனைத்து முனைகளும் அவற்றின் அளவுருக்களும் அடங்கும்.
புதியது தோன்றும் மற்றும் வேலை செய்யும் கிளஸ்டர் முனை துண்டிக்கப்பட்ட தருணத்தில், அனைத்து சேவைக் கட்டுப்படுத்திகளும் பெறும் #'$slave_up'{exchange = ?EXCHANGE, pid = SlavePid, options = SlaveOpts} и #'$slave_down'{exchange = ?EXCHANGE, pid = SlavePid, options = SlaveOpts} முறையே.

இந்த வழியில், அனைத்து கூறுகளும் அனைத்து மாற்றங்களையும் அறிந்திருக்கின்றன, மேலும் கிளஸ்டருக்கு எந்த நேரத்திலும் ஒரு தலைவர் இருப்பது உறுதி.

இடைத்தரகர்கள்

சிக்கலான விநியோகிக்கப்பட்ட செயலாக்க செயல்முறைகளை செயல்படுத்துவதற்கும், ஏற்கனவே உள்ள கட்டமைப்பை மேம்படுத்துவதில் உள்ள சிக்கல்களிலும், இடைத்தரகர்களைப் பயன்படுத்துவது வசதியானது.
சேவைக் குறியீட்டை மாற்றாமல், எடுத்துக்காட்டாக, கூடுதல் செயலாக்கம், ரூட்டிங் அல்லது பதிவுசெய்தல் போன்ற சிக்கல்களைத் தீர்க்க, சேவைக்கு முன் ப்ராக்ஸி ஹேண்ட்லரை இயக்கலாம், இது அனைத்து கூடுதல் வேலைகளையும் செய்யும்.

பப்-சப் ஆப்டிமைசேஷனுக்கு ஒரு சிறந்த உதாரணம், சந்தையில் விலை மாற்றங்கள் போன்ற புதுப்பிப்பு நிகழ்வுகளை உருவாக்கும் வணிக மையத்துடன் கூடிய விநியோகிக்கப்பட்ட பயன்பாடாகும்.
நீங்கள் தலையிட முடிவு செய்தால், வாடிக்கையாளர் சேவை இப்படி இருக்கும்:

வாடிக்கையாளர் தளத்துடன் இணைப்புகளை நிறுவுகிறார். போக்குவரத்தை நிறுத்தும் சேவையகத்தின் பக்கத்தில், இந்த இணைப்பைச் சேவை செய்வதற்கான செயல்முறை தொடங்கப்பட்டது.
சேவை செயல்முறையின் சூழலில், புதுப்பிப்புகளுக்கான அங்கீகாரம் மற்றும் சந்தா ஆகியவை நிகழ்கின்றன. செயல்முறை தலைப்புகளுக்கான சந்தா முறையை அழைக்கிறது.
கர்னலில் ஒரு நிகழ்வு உருவாக்கப்பட்டவுடன், அது இணைப்புகளுக்குச் சேவை செய்யும் செயல்முறைகளுக்கு வழங்கப்படும்.

"செய்தி" தலைப்புக்கு எங்களிடம் 50000 சந்தாதாரர்கள் இருப்பதாக கற்பனை செய்யலாம். சந்தாதாரர்கள் 5 சேவையகங்களில் சமமாக விநியோகிக்கப்படுகிறார்கள். இதன் விளைவாக, பரிமாற்ற புள்ளியில் வரும் ஒவ்வொரு புதுப்பிப்பும் 50000 முறை பிரதிபலிக்கப்படும்: ஒவ்வொரு சேவையகத்திலும் 10000 முறை, அதில் உள்ள சந்தாதாரர்களின் எண்ணிக்கைக்கு ஏற்ப. மிகவும் பயனுள்ள திட்டம் அல்ல, இல்லையா?
நிலைமையை மேம்படுத்த, பரிமாற்ற புள்ளியின் அதே பெயரைக் கொண்ட ப்ராக்ஸியை அறிமுகப்படுத்துவோம். உலகளாவிய பெயர் பதிவாளர் பெயரால் மிக நெருக்கமான செயல்முறையைத் திரும்பப் பெற வேண்டும், இது முக்கியமானது.

இந்த ப்ராக்ஸியை அணுகல் லேயர் சேவையகங்களில் தொடங்குவோம், மேலும் Websocket api ஐ வழங்கும் எங்கள் அனைத்து செயல்முறைகளும் அதற்கு குழுசேரும், கர்னலில் உள்ள அசல் பப்-சப் பரிமாற்ற புள்ளிக்கு அல்ல. ப்ராக்ஸி ஒரு தனித்துவமான சந்தாவின் விஷயத்தில் மட்டுமே மையத்திற்கு சந்தா செலுத்துகிறது மற்றும் உள்வரும் செய்தியை அதன் அனைத்து சந்தாதாரர்களுக்கும் பிரதிபலிக்கிறது.
இதன் விளைவாக, கர்னல் மற்றும் அணுகல் சேவையகங்களுக்கு இடையே 5 க்கு பதிலாக 50000 செய்திகள் அனுப்பப்படும்.

ரூட்டிங் மற்றும் பேலன்சிங்

Req-Resp

தற்போதைய செய்தியிடல் செயலாக்கத்தில், 7 கோரிக்கை விநியோக உத்திகள் உள்ளன:

default. கோரிக்கை அனைத்து கட்டுப்பாட்டாளர்களுக்கும் அனுப்பப்படுகிறது.
round-robin. கோரிக்கைகள் கணக்கிடப்பட்டு கட்டுப்படுத்திகளுக்கு இடையே சுழற்சி முறையில் விநியோகிக்கப்படுகின்றன.
consensus. சேவைக்கு சேவை செய்யும் கட்டுப்பாட்டாளர்கள் தலைவர்கள் மற்றும் அடிமைகளாக பிரிக்கப்பட்டுள்ளனர். கோரிக்கைகள் தலைவருக்கு மட்டுமே அனுப்பப்படுகின்றன.
consensus & round-robin. குழுவிற்கு ஒரு தலைவர் இருக்கிறார், ஆனால் கோரிக்கைகள் அனைத்து உறுப்பினர்களுக்கும் விநியோகிக்கப்படுகின்றன.
sticky. ஹாஷ் செயல்பாடு கணக்கிடப்பட்டு ஒரு குறிப்பிட்ட ஹேண்ட்லருக்கு ஒதுக்கப்படுகிறது. இந்தக் கையொப்பத்துடன் கூடிய அடுத்தடுத்த கோரிக்கைகள் அதே கையாளுபவருக்குச் செல்லும்.
sticky-fun. பரிமாற்ற புள்ளியை துவக்கும் போது, ஹாஷ் கணக்கீடு செயல்பாடு sticky சமநிலைப்படுத்துதல்.
fun. ஸ்டிக்கி-ஃபனைப் போலவே, நீங்கள் மட்டுமே அதைத் திருப்பிவிடலாம், நிராகரிக்கலாம் அல்லது முன்கூட்டியே செயலாக்கலாம்.

பரிமாற்றப் புள்ளி துவக்கப்படும் போது விநியோக உத்தி அமைக்கப்படுகிறது.

சமநிலையுடன் கூடுதலாக, செய்தியிடல் நீங்கள் நிறுவனங்களைக் குறியிட அனுமதிக்கிறது. கணினியில் உள்ள குறிச்சொற்களின் வகைகளைப் பார்ப்போம்:

இணைப்பு குறிச்சொல். நிகழ்வுகள் எந்த இணைப்பின் மூலம் வந்தன என்பதைப் புரிந்துகொள்ள உங்களை அனுமதிக்கிறது. ஒரு கட்டுப்படுத்தி செயல்முறை ஒரே பரிமாற்ற புள்ளியுடன் இணைக்கப்படும்போது பயன்படுத்தப்படுகிறது, ஆனால் வெவ்வேறு ரூட்டிங் விசைகளுடன்.
சேவை குறிச்சொல். ஒரு சேவைக்காக ஹேண்ட்லர்களை குழுக்களாக இணைக்கவும், ரூட்டிங் மற்றும் பேலன்சிங் திறன்களை விரிவுபடுத்தவும் உங்களை அனுமதிக்கிறது. ரெக்-ரெஸ்ப் பேட்டர்னுக்கு, ரூட்டிங் நேரியல். பரிமாற்ற புள்ளிக்கு ஒரு கோரிக்கையை அனுப்புகிறோம், பின்னர் அது சேவைக்கு அனுப்பப்படும். ஆனால் நாம் கையாளுபவர்களை தர்க்கரீதியான குழுக்களாகப் பிரிக்க வேண்டும் என்றால், குறிச்சொற்களைப் பயன்படுத்தி பிரித்தல் செய்யப்படுகிறது. குறிச்சொல்லைக் குறிப்பிடும்போது, கோரிக்கையானது ஒரு குறிப்பிட்ட கட்டுப்பாட்டுக் குழுவிற்கு அனுப்பப்படும்.
கோரிக்கை குறிச்சொல். பதில்களை வேறுபடுத்தி அறிய உங்களை அனுமதிக்கிறது. எங்கள் சிஸ்டம் ஒத்திசைவற்றதாக இருப்பதால், சேவை பதில்களைச் செயல்படுத்த, கோரிக்கையை அனுப்பும்போது ஒரு கோரிக்கை குறிச்சொல்லைக் குறிப்பிட வேண்டும். அதிலிருந்து எந்தக் கோரிக்கை எங்களிடம் வந்தது என்பதைப் புரிந்து கொள்ள முடியும்.

பப்-சப்

பப்-சப் எல்லாம் கொஞ்சம் எளிமையானது. செய்திகள் வெளியிடப்படும் பரிமாற்ற புள்ளி எங்களிடம் உள்ளது. பரிமாற்ற புள்ளி, தங்களுக்குத் தேவையான ரூட்டிங் விசைகளுக்கு சந்தா செலுத்திய சந்தாதாரர்களிடையே செய்திகளை விநியோகிக்கிறது (இது தலைப்புகளுக்கு ஒப்பானது என்று நாம் கூறலாம்).

அளவிடுதல் மற்றும் தவறு சகிப்புத்தன்மை

ஒட்டுமொத்த அமைப்பின் அளவிடுதல் அமைப்பின் அடுக்குகள் மற்றும் கூறுகளின் அளவிடுதல் அளவைப் பொறுத்தது:

இந்தச் சேவைக்கான ஹேண்ட்லர்களைக் கொண்ட கிளஸ்டரில் கூடுதல் முனைகளைச் சேர்ப்பதன் மூலம் சேவைகள் அளவிடப்படுகின்றன. சோதனைச் செயல்பாட்டின் போது, உகந்த சமநிலைக் கொள்கையை நீங்கள் தேர்வு செய்யலாம்.
தனித்தனி கிளஸ்டரில் உள்ள செய்தியிடல் சேவையானது, குறிப்பாக ஏற்றப்பட்ட பரிமாற்ற புள்ளிகளை தனித்தனி கிளஸ்டர் முனைகளுக்கு நகர்த்துவதன் மூலமாகவோ அல்லது கிளஸ்டரின் குறிப்பாக ஏற்றப்பட்ட பகுதிகளுக்கு ப்ராக்ஸி செயல்முறைகளைச் சேர்ப்பதன் மூலமாகவோ பொதுவாக அளவிடப்படுகிறது.
ஒரு சிறப்பியல்பு என முழு அமைப்பின் அளவிடுதல், கட்டிடக்கலையின் நெகிழ்வுத்தன்மை மற்றும் தனிப்பட்ட கிளஸ்டர்களை ஒரு பொதுவான தருக்க நிறுவனமாக இணைக்கும் திறனைப் பொறுத்தது.

ஒரு திட்டத்தின் வெற்றி பெரும்பாலும் எளிமை மற்றும் அளவிடுதலின் வேகத்தைப் பொறுத்தது. அதன் தற்போதைய பதிப்பில் செய்தியிடல் பயன்பாடுடன் சேர்ந்து வளரும். எங்களிடம் 50-60 இயந்திரங்கள் இல்லாவிட்டாலும், நாம் கூட்டமைப்பை நாடலாம். துரதிர்ஷ்டவசமாக, கூட்டமைப்பு என்ற தலைப்பு இந்தக் கட்டுரையின் எல்லைக்கு அப்பாற்பட்டது.

இட ஒதுக்கீடு

சுமை சமநிலையை பகுப்பாய்வு செய்யும் போது, சேவைக் கட்டுப்பாட்டாளர்களின் பணிநீக்கத்தைப் பற்றி ஏற்கனவே விவாதித்தோம். இருப்பினும், செய்தி அனுப்புதலும் முன்பதிவு செய்யப்பட வேண்டும். கணு அல்லது இயந்திரம் செயலிழந்தால், செய்தி அனுப்புதல் தானாகவே மீட்கப்பட வேண்டும், மேலும் குறுகிய காலத்தில்.

எனது திட்டங்களில், வீழ்ச்சி ஏற்பட்டால் சுமைகளை எடுக்கும் கூடுதல் முனைகளைப் பயன்படுத்துகிறேன். OTP பயன்பாடுகளுக்கு Erlang ஒரு நிலையான விநியோக முறை செயல்படுத்தலைக் கொண்டுள்ளது. விநியோகிக்கப்பட்ட பயன்முறையானது தோல்வியுற்றால், ஏற்கனவே தொடங்கப்பட்ட மற்றொரு முனையில் தோல்வியுற்ற பயன்பாட்டைத் தொடங்குவதன் மூலம் மீட்டெடுக்கிறது. செயல்முறை வெளிப்படையானது; தோல்விக்குப் பிறகு, பயன்பாடு தானாகவே தோல்வி முனைக்கு நகரும். இந்த செயல்பாட்டைப் பற்றி மேலும் படிக்கலாம் இங்கே.

உற்பத்தித்

குறைந்தபட்சம் rabbitmq இன் செயல்திறன் மற்றும் எங்கள் தனிப்பயன் செய்திகளை ஒப்பிட்டுப் பார்க்க முயற்சிப்போம்.
நான் கண்டேன் அதிகாரப்பூர்வ முடிவுகள் ஓபன்ஸ்டாக் குழுவிலிருந்து rabbitmq சோதனை.

பத்தி 6.14.1.2.1.2.2 இல். அசல் ஆவணம் RPC CAST இன் முடிவைக் காட்டுகிறது:

OS கர்னல் அல்லது erlang VM க்கு முன்கூட்டியே எந்த கூடுதல் அமைப்புகளையும் நாங்கள் செய்ய மாட்டோம். சோதனைக்கான நிபந்தனைகள்:

erl விருப்பங்கள்: +A1 +sbtu.
ஒற்றை எர்லாங் முனையில் உள்ள சோதனையானது, மொபைல் பதிப்பில் பழைய i7 உடன் மடிக்கணினியில் இயக்கப்படுகிறது.
10G நெட்வொர்க் கொண்ட சர்வர்களில் கிளஸ்டர் சோதனைகள் மேற்கொள்ளப்படுகின்றன.
குறியீடு டோக்கர் கொள்கலன்களில் இயங்குகிறது. NAT பயன்முறையில் நெட்வொர்க்.

சோதனைக் குறியீடு:

req_resp_bench(_) ->
  W = perftest:comprehensive(10000,
    fun() ->
      messaging:request(?EXCHANGE, default, ping, self()),
      receive
        #'$msg'{message = pong} -> ok
      after 5000 ->
        throw(timeout)
      end
    end
  ),
  true = lists:any(fun(E) -> E >= 30000 end, W),
  ok.

காட்சி 1: சோதனையானது பழைய i7 மொபைல் பதிப்பைக் கொண்ட மடிக்கணினியில் இயங்குகிறது. சோதனை, செய்தி அனுப்புதல் மற்றும் சேவை ஆகியவை ஒரு டோக்கர் கொள்கலனில் ஒரு முனையில் செயல்படுத்தப்படுகின்றன:

Sequential 10000 cycles in ~0 seconds (26987 cycles/s)
Sequential 20000 cycles in ~1 seconds (26915 cycles/s)
Sequential 100000 cycles in ~4 seconds (26957 cycles/s)
Parallel 2 100000 cycles in ~2 seconds (44240 cycles/s)
Parallel 4 100000 cycles in ~2 seconds (53459 cycles/s)
Parallel 10 100000 cycles in ~2 seconds (52283 cycles/s)
Parallel 100 100000 cycles in ~3 seconds (49317 cycles/s)

காட்சி 2: டாக்கரின் (NAT) கீழ் வெவ்வேறு இயந்திரங்களில் இயங்கும் 3 முனைகள்.

Sequential 10000 cycles in ~1 seconds (8684 cycles/s)
Sequential 20000 cycles in ~2 seconds (8424 cycles/s)
Sequential 100000 cycles in ~12 seconds (8655 cycles/s)
Parallel 2 100000 cycles in ~7 seconds (15160 cycles/s)
Parallel 4 100000 cycles in ~5 seconds (19133 cycles/s)
Parallel 10 100000 cycles in ~4 seconds (24399 cycles/s)
Parallel 100 100000 cycles in ~3 seconds (34517 cycles/s)

எல்லா சந்தர்ப்பங்களிலும், CPU பயன்பாடு 250% ஐ விட அதிகமாக இல்லை

முடிவுகளை

இந்தச் சுழற்சி ஒரு மனக்கசப்பைப் போலத் தோன்றாது என்றும், விநியோகிக்கப்பட்ட அமைப்புகளின் ஆராய்ச்சியாளர்கள் மற்றும் பயிற்சியாளர்கள் இருவருக்கும் உண்மையான பயனாக இருக்கும் என்று நம்புகிறேன் , ஆனால் அது மதிப்புக்குரியதா என்பதில் சந்தேகம் உள்ளது ...

புகைப்படம் @சட்டர்ஸ்னாப்

பதிவு செய்த பயனர்கள் மட்டுமே கணக்கெடுப்பில் பங்கேற்க முடியும். உள்நுழையவும், தயவு செய்து.

VTrade சோதனைத் தொடரின் ஒரு பகுதியாக நான் என்ன தலைப்புகளை இன்னும் விரிவாகப் பேச வேண்டும்?

கோட்பாடு: சந்தைகள், ஆர்டர்கள் மற்றும் அவற்றின் நேரம்: DAY, GTD, GTC, IOC, FOK, MOO, MOC, LOO, LOC
உத்தரவு புத்தகம். ஒரு புத்தகத்தை குழுக்களுடன் செயல்படுத்துவதற்கான கோட்பாடு மற்றும் நடைமுறை
வர்த்தகத்தின் காட்சிப்படுத்தல்: உண்ணிகள், பார்கள், தீர்மானங்கள். எப்படி சேமிப்பது மற்றும் எப்படி ஒட்டுவது
மீண்டும் அலுவலகம். திட்டமிடல் மற்றும் மேம்பாடு. பணியாளர் கண்காணிப்பு மற்றும் சம்பவ விசாரணை
API. என்ன இடைமுகங்கள் தேவை மற்றும் அவற்றை எவ்வாறு செயல்படுத்துவது என்பதைக் கண்டுபிடிப்போம்
தகவல் சேமிப்பு: வர்த்தக அமைப்புகளில் PostgreSQL, Timescale, Tarantool
வர்த்தக அமைப்புகளில் வினைத்திறன்
மற்றவை. கருத்துகளில் எழுதுகிறேன்

6 பயனர்கள் வாக்களித்தனர். 4 பயனர்கள் வாக்களிக்கவில்லை.

ஆதாரம்: www.habr.com

விநியோகிக்கப்பட்ட பயன்பாடுகளின் கட்டுமானத் தொகுதிகள். இரண்டாவது தோராயம்