વિતરિત એપ્લિકેશનોના બિલ્ડીંગ બ્લોક્સ. બીજા અંદાજ

ઘોષણા

સાથીઓ, ઉનાળાના મધ્યમાં હું કતારબદ્ધ સિસ્ટમની રચના પર લેખોની બીજી શ્રેણી બહાર પાડવાની યોજના ઘડી રહ્યો છું: “ધી વીટ્રેડ પ્રયોગ” - ટ્રેડિંગ સિસ્ટમ્સ માટે માળખું લખવાનો પ્રયાસ. આ શ્રેણીમાં વિનિમય, હરાજી અને સ્ટોર બનાવવાના સિદ્ધાંત અને પ્રેક્ટિસની તપાસ કરવામાં આવશે. લેખના અંતે, હું તમને સૌથી વધુ રુચિ ધરાવતા વિષયો માટે મત આપવા માટે આમંત્રિત કરું છું.

Erlang/Elixir માં વિતરિત પ્રતિક્રિયાત્મક એપ્લિકેશનો પરની શ્રેણીનો આ અંતિમ લેખ છે. IN પ્રથમ લેખ તમે પ્રતિક્રિયાશીલ આર્કિટેક્ચરના સૈદ્ધાંતિક પાયા શોધી શકો છો. બીજો લેખ આવી સિસ્ટમો બનાવવા માટેની મૂળભૂત પેટર્ન અને પદ્ધતિઓ સમજાવે છે.

આજે આપણે સામાન્ય રીતે કોડ બેઝ અને પ્રોજેક્ટ્સના વિકાસના મુદ્દાઓ ઉઠાવીશું.

સેવાઓનું સંગઠન

વાસ્તવિક જીવનમાં, સેવા વિકસાવતી વખતે, તમારે ઘણીવાર એક નિયંત્રકમાં ઘણી ક્રિયાપ્રતિક્રિયા પેટર્નને જોડવી પડે છે. ઉદાહરણ તરીકે, યુઝર સર્વિસ, જે પ્રોજેક્ટ યુઝર પ્રોફાઇલ્સને મેનેજ કરવાની સમસ્યાનું નિરાકરણ લાવે છે, તેણે req-resp વિનંતીઓનો જવાબ આપવો જોઈએ અને પબ-સબ દ્વારા પ્રોફાઇલ અપડેટ્સની જાણ કરવી જોઈએ. આ કેસ એકદમ સરળ છે: મેસેજિંગ પાછળ એક નિયંત્રક છે જે સેવાના તર્કને લાગુ કરે છે અને અપડેટ્સ પ્રકાશિત કરે છે.

જ્યારે આપણે ખામી-સહિષ્ણુ વિતરણ સેવાનો અમલ કરવાની જરૂર હોય ત્યારે પરિસ્થિતિ વધુ જટિલ બને છે. ચાલો કલ્પના કરીએ કે વપરાશકર્તાઓ માટેની આવશ્યકતાઓ બદલાઈ ગઈ છે:

1. હવે સેવાએ 5 ક્લસ્ટર નોડ્સ પર વિનંતીઓ પર પ્રક્રિયા કરવી જોઈએ,
2. પૃષ્ઠભૂમિ પ્રક્રિયા કાર્યો કરવા માટે સમર્થ થાઓ,
3. અને પ્રોફાઇલ અપડેટ્સ માટે સબ્સ્ક્રિપ્શન લિસ્ટને ગતિશીલ રીતે સંચાલિત કરવામાં પણ સક્ષમ બનો.

ટિપ્પણી: અમે સુસંગત સ્ટોરેજ અને ડેટા પ્રતિકૃતિના મુદ્દાને ધ્યાનમાં લેતા નથી. ચાલો ધારીએ કે આ મુદ્દાઓ અગાઉ ઉકેલાઈ ગયા છે અને સિસ્ટમમાં પહેલેથી જ વિશ્વસનીય અને માપી શકાય તેવું સ્ટોરેજ સ્તર છે, અને હેન્ડલર્સ પાસે તેની સાથે ક્રિયાપ્રતિક્રિયા કરવા માટેની પદ્ધતિઓ છે.

વપરાશકર્તાઓની સેવાનું ઔપચારિક વર્ણન વધુ જટિલ બન્યું છે. પ્રોગ્રામરના દૃષ્ટિકોણથી, મેસેજિંગના ઉપયોગને કારણે ફેરફારો ઓછા છે. પ્રથમ જરૂરિયાતને સંતોષવા માટે, અમારે 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} અનુક્રમે.

આ રીતે, તમામ ઘટકો તમામ ફેરફારોથી વાકેફ છે, અને ક્લસ્ટરમાં કોઈપણ સમયે એક લીડર હોવાની ખાતરી આપવામાં આવે છે.

મધ્યસ્થીઓ

જટિલ વિતરિત પ્રક્રિયા પ્રક્રિયાઓને અમલમાં મૂકવા માટે, તેમજ હાલના આર્કિટેક્ચરને ઑપ્ટિમાઇઝ કરવાની સમસ્યાઓમાં, મધ્યસ્થીઓનો ઉપયોગ કરવો અનુકૂળ છે.
સેવા કોડમાં ફેરફાર ન કરવા અને ઉકેલવા માટે, ઉદાહરણ તરીકે, વધારાની પ્રક્રિયા, રૂટીંગ અથવા લોગિંગ સંદેશાઓની સમસ્યાઓ, તમે સેવા પહેલાં પ્રોક્સી હેન્ડલરને સક્ષમ કરી શકો છો, જે તમામ વધારાના કાર્ય કરશે.

પબ-સબ ઓપ્ટિમાઇઝેશનનું ઉત્તમ ઉદાહરણ એ બિઝનેસ કોર સાથે વિતરિત એપ્લિકેશન છે જે અપડેટ ઇવેન્ટ્સ જનરેટ કરે છે, જેમ કે માર્કેટમાં કિંમતમાં ફેરફાર, અને એક્સેસ લેયર - N સર્વર્સ જે વેબ ક્લાયન્ટ્સ માટે વેબસોકેટ API પ્રદાન કરે છે.
જો તમે હેડ-ઓન નક્કી કરો છો, તો ગ્રાહક સેવા આના જેવી લાગે છે:

• ક્લાયંટ પ્લેટફોર્મ સાથે જોડાણો સ્થાપિત કરે છે. સર્વરની બાજુએ જે ટ્રાફિકને સમાપ્ત કરે છે, આ કનેક્શનને સેવા આપવા માટે એક પ્રક્રિયા શરૂ કરવામાં આવે છે.
• સેવા પ્રક્રિયાના સંદર્ભમાં, અપડેટ્સ માટે અધિકૃતતા અને સબ્સ્ક્રિપ્શન થાય છે. પ્રક્રિયા વિષયો માટે સબ્સ્ક્રાઇબ પદ્ધતિને કૉલ કરે છે.
• એકવાર કર્નલમાં ઇવેન્ટ જનરેટ થઈ જાય, તે કનેક્શન્સને સર્વિસ કરતી પ્રક્રિયાઓને વિતરિત કરવામાં આવે છે.

ચાલો કલ્પના કરીએ કે અમારી પાસે "સમાચાર" વિષયના 50000 સબ્સ્ક્રાઇબર્સ છે. સબ્સ્ક્રાઇબર્સને 5 સર્વર પર સમાનરૂપે વિતરિત કરવામાં આવે છે. પરિણામે, દરેક અપડેટ, એક્સચેન્જ પોઈન્ટ પર પહોંચતા, તેના પરના સબસ્ક્રાઈબર્સની સંખ્યા અનુસાર, દરેક સર્વર પર 50000 વખત: 10000 વખત નકલ કરવામાં આવશે. બહુ અસરકારક યોજના નથી, ખરું ને?
પરિસ્થિતિને સુધારવા માટે, ચાલો એક પ્રોક્સી રજૂ કરીએ જેનું નામ વિનિમય બિંદુ જેવું જ છે. વૈશ્વિક નામ રજિસ્ટ્રાર નામ દ્વારા નજીકની પ્રક્રિયા પરત કરવામાં સક્ષમ હોવા જોઈએ, આ મહત્વપૂર્ણ છે.

ચાલો આ પ્રોક્સીને એક્સેસ લેયર સર્વર્સ પર લોંચ કરીએ, અને વેબસોકેટ એપીઆઈને સેવા આપતી અમારી બધી પ્રક્રિયાઓ તેને સબ્સ્ક્રાઇબ કરશે, કર્નલમાં મૂળ પબ-સબ એક્સચેન્જ પોઈન્ટ પર નહીં. પ્રોક્સી ફક્ત અનન્ય સબ્સ્ક્રિપ્શનના કિસ્સામાં કોર પર સબ્સ્ક્રાઇબ કરે છે અને તેના તમામ સબ્સ્ક્રાઇબર્સને આવનારા સંદેશની નકલ કરે છે.
પરિણામે, કર્નલ અને એક્સેસ સર્વર્સ વચ્ચે 5 ને બદલે 50000 સંદેશા મોકલવામાં આવશે.

રૂટીંગ અને સંતુલન

Req-Resp

વર્તમાન મેસેજિંગ અમલીકરણમાં, 7 વિનંતી વિતરણ વ્યૂહરચના છે:

• default. વિનંતી બધા નિયંત્રકોને મોકલવામાં આવે છે.
• round-robin. વિનંતીઓની ગણતરી કરવામાં આવે છે અને નિયંત્રકો વચ્ચે ચક્રીય રીતે વિતરિત કરવામાં આવે છે.
• consensus. સેવાની સેવા આપતા નિયંત્રકો નેતાઓ અને ગુલામોમાં વહેંચાયેલા છે. વિનંતીઓ ફક્ત નેતાને મોકલવામાં આવે છે.
• consensus & round-robin. જૂથમાં એક નેતા છે, પરંતુ વિનંતીઓ બધા સભ્યોમાં વહેંચવામાં આવે છે.
• sticky. હેશ ફંક્શનની ગણતરી કરવામાં આવે છે અને ચોક્કસ હેન્ડલરને સોંપવામાં આવે છે. આ હસ્તાક્ષર સાથે અનુગામી વિનંતીઓ સમાન હેન્ડલરને જાય છે.
• sticky-fun. જ્યારે વિનિમય બિંદુ શરૂ થાય છે, ત્યારે માટે હેશ ગણતરી કાર્ય sticky સંતુલન
• fun. સ્ટીકી-ફન જેવું જ, ફક્ત તમે જ તેને રીડાયરેક્ટ, રિજેક્ટ અથવા પ્રી-પ્રોસેસ કરી શકો છો.

વિતરણ વ્યૂહરચના સેટ કરવામાં આવે છે જ્યારે વિનિમય બિંદુ પ્રારંભ થાય છે.

સંતુલન ઉપરાંત, મેસેજિંગ તમને એન્ટિટીને ટેગ કરવાની મંજૂરી આપે છે. ચાલો સિસ્ટમમાં ટૅગ્સના પ્રકારો જોઈએ:

• કનેક્શન ટેગ. ઘટનાઓ કયા કનેક્શન દ્વારા આવી છે તે તમને સમજવાની મંજૂરી આપે છે. જ્યારે નિયંત્રક પ્રક્રિયા સમાન વિનિમય બિંદુ સાથે જોડાય છે, પરંતુ વિવિધ રૂટીંગ કી સાથે વપરાય છે.
• સેવા ટેગ. તમને એક સેવા માટે હેન્ડલર્સને જૂથોમાં જોડવાની અને રૂટીંગ અને સંતુલન ક્ષમતાઓને વિસ્તૃત કરવાની મંજૂરી આપે છે. req-resp પેટર્ન માટે, રૂટીંગ રેખીય છે. અમે વિનિમય બિંદુ પર વિનંતી મોકલીએ છીએ, પછી તે તેને સેવામાં પસાર કરે છે. પરંતુ જો આપણે હેન્ડલર્સને લોજિકલ જૂથોમાં વિભાજિત કરવાની જરૂર હોય, તો પછી વિભાજન ટૅગ્સનો ઉપયોગ કરીને કરવામાં આવે છે. ટેગનો ઉલ્લેખ કરતી વખતે, વિનંતી નિયંત્રકોના ચોક્કસ જૂથને મોકલવામાં આવશે.
• વિનંતી ટેગ. તમને જવાબો વચ્ચે તફાવત કરવાની મંજૂરી આપે છે. અમારી સિસ્ટમ અસુમેળ હોવાથી, સેવા પ્રતિસાદો પર પ્રક્રિયા કરવા માટે, વિનંતી મોકલતી વખતે અમારે RequestTag નો ઉલ્લેખ કરવામાં સમર્થ હોવા જરૂરી છે. તેમાંથી અમે સમજી શકીશું કે અમને કઈ વિનંતીનો જવાબ આવ્યો.

પબ-સબ

પબ-સબ માટે બધું થોડું સરળ છે. અમારી પાસે એક વિનિમય બિંદુ છે જેના પર સંદેશા પ્રકાશિત થાય છે. વિનિમય બિંદુ સબ્સ્ક્રાઇબર્સ વચ્ચે સંદેશાઓનું વિતરણ કરે છે જેમણે તેમને જરૂરી રૂટીંગ કી પર સબ્સ્ક્રાઇબ કર્યું છે (અમે કહી શકીએ કે આ વિષયો સાથે સમાન છે).

માપનીયતા અને દોષ સહિષ્ણુતા

સમગ્ર સિસ્ટમની માપનીયતા સિસ્ટમના સ્તરો અને ઘટકોની માપનીયતાની ડિગ્રી પર આધારિત છે:

• આ સેવા માટે હેન્ડલર્સ સાથે ક્લસ્ટરમાં વધારાના નોડ્સ ઉમેરીને સેવાઓને માપવામાં આવે છે. ટ્રાયલ ઓપરેશન દરમિયાન, તમે શ્રેષ્ઠ સંતુલન નીતિ પસંદ કરી શકો છો.
• એક અલગ ક્લસ્ટરની અંદરની મેસેજિંગ સર્વિસ સામાન્ય રીતે અલગ ક્લસ્ટર નોડ્સ પર ખાસ લોડ કરેલા એક્સચેન્જ પોઈન્ટને ખસેડીને અથવા ક્લસ્ટરના ખાસ કરીને લોડ થયેલ વિસ્તારોમાં પ્રોક્સી પ્રક્રિયાઓ ઉમેરીને માપવામાં આવે છે.
• લાક્ષણિકતા તરીકે સમગ્ર સિસ્ટમની માપનીયતા આર્કિટેક્ચરની લવચીકતા અને વ્યક્તિગત ક્લસ્ટરોને સામાન્ય લોજિકલ એન્ટિટીમાં જોડવાની ક્ષમતા પર આધારિત છે.

પ્રોજેક્ટની સફળતા ઘણીવાર સ્કેલિંગની સરળતા અને ઝડપ પર આધારિત છે. તેના વર્તમાન સંસ્કરણમાં મેસેજિંગ એપ્લિકેશન સાથે વધે છે. જો અમારી પાસે 50-60 મશીનોના ક્લસ્ટરનો અભાવ હોય તો પણ અમે ફેડરેશનનો આશરો લઈ શકીએ છીએ. કમનસીબે, ફેડરેશનનો વિષય આ લેખના અવકાશની બહાર છે.

આરક્ષણ

લોડ સંતુલનનું વિશ્લેષણ કરતી વખતે, અમે સેવા નિયંત્રકોની નિરર્થકતા વિશે પહેલેથી જ ચર્ચા કરી છે. જો કે, મેસેજિંગ પણ આરક્ષિત હોવું જોઈએ. નોડ અથવા મશીન ક્રેશની ઘટનામાં, મેસેજિંગ આપોઆપ પુનઃપ્રાપ્ત થવું જોઈએ, અને ટૂંકી શક્ય સમયમાં.

મારા પ્રોજેક્ટ્સમાં હું વધારાના નોડ્સનો ઉપયોગ કરું છું જે પડવાના કિસ્સામાં લોડ ઉપાડે છે. એર્લાંગ પાસે OTP એપ્લિકેશન્સ માટે પ્રમાણભૂત વિતરિત મોડ અમલીકરણ છે. ડિસ્ટ્રિબ્યુટેડ મોડ નિષ્ફળતાના કિસ્સામાં અન્ય અગાઉ લોંચ થયેલ નોડ પર નિષ્ફળ એપ્લિકેશનને લોન્ચ કરીને પુનઃપ્રાપ્તિ કરે છે. પ્રક્રિયા પારદર્શક છે; નિષ્ફળતા પછી, એપ્લિકેશન આપમેળે ફેલઓવર નોડ પર જાય છે. તમે આ કાર્યક્ષમતા વિશે વધુ વાંચી શકો છો અહીં.

ઉત્પાદકતા

ચાલો rabbitmq અને અમારા કસ્ટમ મેસેજિંગની કામગીરીની ઓછામાં ઓછી અંદાજે સરખામણી કરવાનો પ્રયાસ કરીએ.
મે શોધિયું સત્તાવાર પરિણામો ઓપનસ્ટેક ટીમ તરફથી rabbitmq પરીક્ષણ.

ફકરા 6.14.1.2.1.2.2 માં. મૂળ દસ્તાવેજ RPC CAST નું પરિણામ દર્શાવે છે:

અમે OS કર્નલ અથવા erlang VM પર અગાઉથી કોઈ વધારાની સેટિંગ્સ કરીશું નહીં. પરીક્ષણ માટેની શરતો:

• erl opts: +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% થી વધુ ન હતો

પરિણામો

હું આશા રાખું છું કે આ ચક્ર માઇન્ડ ડમ્પ જેવું લાગતું નથી અને મારો અનુભવ ડિસ્ટ્રિબ્યુટેડ સિસ્ટમના સંશોધકો અને પ્રેક્ટિશનરો બંને માટે વાસ્તવિક લાભદાયી રહેશે જેઓ તેમની બિઝનેસ સિસ્ટમ્સ માટે ડિસ્ટ્રિબ્યુટેડ આર્કિટેક્ચર બનાવવાની શરૂઆતમાં છે અને રસ સાથે Erlang/Elixir જોઈ રહ્યા છે. , પરંતુ શંકા છે કે તે મૂલ્યવાન છે ...

ફોટો @chuttersnap

ફક્ત નોંધાયેલા વપરાશકર્તાઓ જ સર્વેમાં ભાગ લઈ શકે છે. સાઇન ઇન કરો, મહેરબાની કરીને.

VTrade પ્રયોગ શ્રેણીના ભાગરૂપે મારે કયા વિષયોને વધુ વિગતવાર આવરી લેવા જોઈએ?

• થિયરી: બજારો, ઓર્ડર્સ અને તેમનો સમય: DAY, GTD, GTC, IOC, FOK, MOO, MOC, LOO, LOC

• ઓર્ડર બુક. જૂથો સાથે પુસ્તકનો અમલ કરવાનો સિદ્ધાંત અને પ્રેક્ટિસ

• વેપારનું વિઝ્યુલાઇઝેશન: ટીક્સ, બાર, રિઝોલ્યુશન. કેવી રીતે સંગ્રહિત કરવું અને કેવી રીતે ગુંદર કરવું

• પાછા કામે. આયોજન અને વિકાસ. કર્મચારીની દેખરેખ અને ઘટનાની તપાસ

• API. ચાલો જાણીએ કે કયા ઇન્ટરફેસની જરૂર છે અને તેમને કેવી રીતે અમલમાં મૂકવું

• માહિતી સંગ્રહ: પોસ્ટગ્રેએસક્યુએલ, ટાઇમસ્કેલ, ટ્રેડિંગ સિસ્ટમ્સમાં ટેરેન્ટૂલ

• ટ્રેડિંગ સિસ્ટમ્સમાં પ્રતિક્રિયાશીલતા

• અન્ય. હું ટિપ્પણીઓમાં લખીશ

6 વપરાશકર્તાઓએ મત ​​આપ્યો. 4 વપરાશકર્તાઓ દૂર રહ્યા.

સોર્સ: www.habr.com