SRE: പ്രകടന വിശകലനം. Go-യിലെ ഒരു ലളിതമായ വെബ് സെർവർ ഉപയോഗിക്കുന്ന കോൺഫിഗറേഷൻ രീതി

ക്ലയന്റുകളുടെ പെർഫോമൻസ് കംപ്ലയൻസ് പരിശോധിക്കുന്നതിനുള്ള ശക്തമായ ഉപകരണമാണ് പ്രകടന വിശകലനവും ട്യൂണിംഗും.

ട്യൂണിംഗ് പരീക്ഷണങ്ങൾ പരിശോധിക്കുന്നതിന് ശാസ്ത്രീയ സമീപനം പ്രയോഗിച്ച് പ്രോഗ്രാമിലെ തടസ്സങ്ങൾ പരിശോധിക്കാൻ പ്രകടന വിശകലനം ഉപയോഗിക്കാം. ഒരു Go വെബ്‌സെർവർ ഉദാഹരണമായി ഉപയോഗിച്ച് പ്രകടന വിശകലനത്തിനും ട്യൂണിംഗിനുമുള്ള ഒരു പൊതു സമീപനത്തെ ഈ ലേഖനം നിർവചിക്കുന്നു.

പ്രൊഫൈലിംഗ് ടൂളുകൾ ഉള്ളതിനാൽ Go എന്നത് ഇവിടെ വളരെ നല്ലതാണ് pprof സാധാരണ ലൈബ്രറിയിൽ.

തന്ത്രം

നമ്മുടെ ഘടനാപരമായ വിശകലനത്തിനായി ഒരു സംഗ്രഹ ലിസ്റ്റ് ഉണ്ടാക്കാം. അവബോധത്തെയോ ഊഹത്തെയോ അടിസ്ഥാനമാക്കി മാറ്റങ്ങൾ വരുത്തുന്നതിനുപകരം തീരുമാനങ്ങൾ എടുക്കാൻ ഞങ്ങൾ കുറച്ച് ഡാറ്റ ഉപയോഗിക്കാൻ ശ്രമിക്കും. ഇത് ചെയ്യുന്നതിന്, ഞങ്ങൾ ഇത് ചെയ്യും:

• ഒപ്റ്റിമൈസേഷൻ അതിരുകൾ ഞങ്ങൾ നിർണ്ണയിക്കുന്നു (ആവശ്യങ്ങൾ);
• സിസ്റ്റത്തിനായുള്ള ഇടപാട് ലോഡ് ഞങ്ങൾ കണക്കാക്കുന്നു;
• ഞങ്ങൾ പരിശോധന നടത്തുന്നു (ഡാറ്റ സൃഷ്ടിക്കുക);
• ഞങ്ങൾ നിരീക്ഷിക്കുന്നു;
• ഞങ്ങൾ വിശകലനം ചെയ്യുന്നു - എല്ലാ ആവശ്യങ്ങളും നിറവേറ്റുന്നുണ്ടോ?
• ഞങ്ങൾ അത് ശാസ്ത്രീയമായി സ്ഥാപിച്ചു, ഒരു സിദ്ധാന്തം ഉണ്ടാക്കുക;
• ഈ സിദ്ധാന്തം പരിശോധിക്കാൻ ഞങ്ങൾ ഒരു പരീക്ഷണം നടത്തുന്നു.

ലളിതമായ HTTP സെർവർ ആർക്കിടെക്ചർ

ഈ ലേഖനത്തിനായി ഞങ്ങൾ Golang-ലെ ഒരു ചെറിയ HTTP സെർവർ ഉപയോഗിക്കും. ഈ ലേഖനത്തിൽ നിന്നുള്ള എല്ലാ കോഡുകളും കണ്ടെത്താനാകും ഇവിടെ.

ഓരോ അഭ്യർത്ഥനയ്ക്കും Postgresql വോട്ടെടുപ്പ് നടത്തുന്ന ഒരു HTTP സെർവറാണ് വിശകലനം ചെയ്യുന്ന ആപ്ലിക്കേഷൻ. കൂടാതെ, ആപ്ലിക്കേഷനും സിസ്റ്റം മെട്രിക്കുകളും ശേഖരിക്കുന്നതിനും പ്രദർശിപ്പിക്കുന്നതിനും Prometheus, node_exporter, Grafana എന്നിവയുണ്ട്.

ലളിതമാക്കുന്നതിന്, തിരശ്ചീന സ്കെയിലിംഗിനായി (കണക്കുകൂട്ടലുകൾ ലളിതമാക്കുന്നതിനും) ഓരോ സേവനവും ഡാറ്റാബേസും ഒരുമിച്ച് വിന്യസിച്ചിരിക്കുന്നത് ഞങ്ങൾ പരിഗണിക്കുന്നു:

ലക്ഷ്യങ്ങൾ നിർവചിക്കുന്നു

ഈ ഘട്ടത്തിൽ, ഞങ്ങൾ ലക്ഷ്യം തീരുമാനിക്കുന്നു. എന്താണ് നമ്മൾ വിശകലനം ചെയ്യാൻ ശ്രമിക്കുന്നത്? അത് അവസാനിക്കാൻ സമയമായെന്ന് നമുക്ക് എങ്ങനെ അറിയാം? ഈ ലേഖനത്തിൽ, ഞങ്ങൾക്ക് ക്ലയന്റുകളുണ്ടെന്നും ഞങ്ങളുടെ സേവനം സെക്കൻഡിൽ 10 അഭ്യർത്ഥനകൾ പ്രോസസ്സ് ചെയ്യുമെന്നും ഞങ്ങൾ സങ്കൽപ്പിക്കും.

В Google SRE ബുക്ക് തിരഞ്ഞെടുക്കലിന്റെയും മോഡലിംഗിന്റെയും രീതികൾ വിശദമായി ചർച്ചചെയ്യുന്നു. നമുക്ക് ഇത് ചെയ്ത് മോഡലുകൾ നിർമ്മിക്കാം:

• കാലതാമസം: 99% അഭ്യർത്ഥനകളും 60 മില്ലിമീറ്ററിൽ താഴെയുള്ള സമയത്തിനുള്ളിൽ പൂർത്തിയാക്കണം;
• ചെലവ്: ന്യായമായും സാധ്യമാണെന്ന് ഞങ്ങൾ കരുതുന്ന ഏറ്റവും കുറഞ്ഞ തുക സേവനം ഉപയോഗിക്കണം. ഇത് ചെയ്യുന്നതിന്, ഞങ്ങൾ ത്രൂപുട്ട് പരമാവധിയാക്കുന്നു;
• കപ്പാസിറ്റി പ്ലാനിംഗ്: മൊത്തത്തിലുള്ള സ്കെയിലിംഗ് ഫംഗ്‌ഷണാലിറ്റി ഉൾപ്പെടെ, ആപ്ലിക്കേഷന്റെ എത്ര സന്ദർഭങ്ങൾ റൺ ചെയ്യേണ്ടതുണ്ട്, പ്രാരംഭ ലോഡും പ്രൊവിഷനിംഗ് ആവശ്യകതകളും നിറവേറ്റുന്നതിന് എത്ര സന്ദർഭങ്ങൾ ആവശ്യമാണെന്ന് മനസ്സിലാക്കുകയും രേഖപ്പെടുത്തുകയും ചെയ്യേണ്ടത് ആവശ്യമാണ്. ആവർത്തനം n+1.

ലേറ്റൻസിക്ക് വിശകലനത്തിന് പുറമേ ഒപ്റ്റിമൈസേഷൻ ആവശ്യമായി വന്നേക്കാം, എന്നാൽ ത്രൂപുട്ട് വ്യക്തമായി വിശകലനം ചെയ്യേണ്ടതുണ്ട്. SRE SLO പ്രോസസ്സ് ഉപയോഗിക്കുമ്പോൾ, കാലതാമസം അഭ്യർത്ഥന വരുന്നത് ഉൽപ്പന്ന ഉടമ പ്രതിനിധീകരിക്കുന്ന ഉപഭോക്താവിൽ നിന്നോ ബിസിനസ്സിൽ നിന്നോ ആണ്. ഞങ്ങളുടെ സേവനം ക്രമീകരണങ്ങളില്ലാതെ തുടക്കം മുതൽ ഈ ബാധ്യത നിറവേറ്റും!

ഒരു പരീക്ഷണ അന്തരീക്ഷം സജ്ജീകരിക്കുന്നു

ഒരു ടെസ്റ്റ് പരിതസ്ഥിതിയുടെ സഹായത്തോടെ, ഞങ്ങളുടെ സിസ്റ്റത്തിൽ അളന്ന ലോഡ് സ്ഥാപിക്കാൻ ഞങ്ങൾക്ക് കഴിയും. വിശകലനത്തിനായി, വെബ് സേവനത്തിന്റെ പ്രകടനത്തെക്കുറിച്ചുള്ള ഡാറ്റ സൃഷ്ടിക്കും.

ഇടപാട് ലോഡ്

ഈ പരിസ്ഥിതി ഉപയോഗിക്കുന്നു വെജിറ്റ നിർത്തുന്നത് വരെ ഒരു ഇഷ്‌ടാനുസൃത HTTP അഭ്യർത്ഥന നിരക്ക് സൃഷ്‌ടിക്കാൻ:

$ make load-test LOAD_TEST_RATE=50
echo "POST http://localhost:8080" | vegeta attack -body tests/fixtures/age_no_match.json -rate=50 -duration=0 | tee results.bin | vegeta report

നിരീക്ഷണം

റൺടൈമിൽ ഇടപാട് ലോഡ് ബാധകമാകും. ആപ്ലിക്കേഷൻ (അഭ്യർത്ഥനകളുടെ എണ്ണം, പ്രതികരണ ലേറ്റൻസി), ഓപ്പറേറ്റിംഗ് സിസ്റ്റം (മെമ്മറി, സിപിയു, ഐഒപിഎസ്) മെട്രിക്‌സ് എന്നിവയ്‌ക്ക് പുറമേ, ആപ്ലിക്കേഷൻ പ്രൊഫൈലിംഗ് അതിന് എവിടെയാണ് പ്രശ്‌നങ്ങളുള്ളതെന്നും സിപിയു സമയം എങ്ങനെ ചെലവഴിക്കുന്നുവെന്നും മനസ്സിലാക്കാൻ പ്രവർത്തിപ്പിക്കും.

പ്രൊഫൈലിംഗ്

ഒരു ആപ്ലിക്കേഷൻ പ്രവർത്തിക്കുമ്പോൾ സിപിയു സമയം എവിടേക്കാണ് പോകുന്നതെന്ന് കാണാൻ നിങ്ങളെ അനുവദിക്കുന്ന ഒരു തരം അളവെടുപ്പാണ് പ്രൊഫൈലിംഗ്. പ്രോസസ്സർ സമയം എവിടെ, എത്രമാത്രം ചെലവഴിച്ചുവെന്ന് കൃത്യമായി നിർണ്ണയിക്കാൻ ഇത് നിങ്ങളെ അനുവദിക്കുന്നു:

പാഴായ സിപിയു സമയത്തെക്കുറിച്ചും അനാവശ്യ ജോലികൾ ചെയ്യുന്നതിനെക്കുറിച്ചും ഉൾക്കാഴ്ച നേടുന്നതിന് വിശകലന സമയത്ത് ഈ ഡാറ്റ ഉപയോഗിക്കാം. Go (pprof) ന് പ്രൊഫൈലുകൾ ജനറേറ്റ് ചെയ്യാനും ഒരു സ്റ്റാൻഡേർഡ് ടൂളുകൾ ഉപയോഗിച്ച് അവയെ ഫ്ലേം ഗ്രാഫുകളായി ദൃശ്യവൽക്കരിക്കാനും കഴിയും. അവയുടെ ഉപയോഗത്തെയും സജ്ജീകരണ ഗൈഡിനെയും കുറിച്ച് ഞാൻ പിന്നീട് ലേഖനത്തിൽ സംസാരിക്കും.

നിർവ്വഹണം, നിരീക്ഷണം, വിശകലനം.

നമുക്ക് ഒരു പരീക്ഷണം നടത്താം. പ്രകടനത്തിൽ തൃപ്തരാകുന്നതുവരെ ഞങ്ങൾ പ്രകടനം നടത്തുകയും നിരീക്ഷിക്കുകയും വിശകലനം ചെയ്യുകയും ചെയ്യും. ആദ്യ നിരീക്ഷണങ്ങളുടെ ഫലങ്ങൾ ലഭിക്കുന്നതിന്, അത് പ്രയോഗിക്കുന്നതിന് നമുക്ക് ഏകപക്ഷീയമായി കുറഞ്ഞ ലോഡ് മൂല്യം തിരഞ്ഞെടുക്കാം. ഓരോ തുടർന്നുള്ള ഘട്ടത്തിലും ഞങ്ങൾ ഒരു നിശ്ചിത സ്കെയിലിംഗ് ഘടകം ഉപയോഗിച്ച് ലോഡ് വർദ്ധിപ്പിക്കും, ചില വ്യത്യാസങ്ങളോടെ തിരഞ്ഞെടുത്തു. ക്രമീകരിച്ച അഭ്യർത്ഥനകളുടെ എണ്ണം ഉപയോഗിച്ചാണ് ഓരോ ലോഡ് ടെസ്റ്റിംഗ് റണ്ണും നടത്തുന്നത്: make load-test LOAD_TEST_RATE=X.

സെക്കൻഡിൽ 50 അഭ്യർത്ഥനകൾ

മുകളിലെ രണ്ട് ഗ്രാഫുകൾ ശ്രദ്ധിക്കുക. ഞങ്ങളുടെ ആപ്ലിക്കേഷൻ സെക്കൻഡിൽ 50 അഭ്യർത്ഥനകൾ പ്രോസസ്സ് ചെയ്യുന്നതായി മുകളിൽ ഇടത് കാണിക്കുന്നു (അത് കരുതുന്നു) മുകളിൽ വലത് ഓരോ അഭ്യർത്ഥനയുടെയും ദൈർഘ്യം കാണിക്കുന്നു. രണ്ട് പാരാമീറ്ററുകളും ഞങ്ങൾ ഞങ്ങളുടെ പ്രകടന പരിധിക്കുള്ളിലാണോ അല്ലയോ എന്ന് നോക്കാനും വിശകലനം ചെയ്യാനും സഹായിക്കുന്നു. ഗ്രാഫിൽ ചുവന്ന വര HTTP അഭ്യർത്ഥന ലേറ്റൻസി 60ms-ൽ SLO കാണിക്കുന്നു. ഞങ്ങളുടെ പരമാവധി പ്രതികരണ സമയത്തിന് ഞങ്ങൾ വളരെ താഴെയാണെന്ന് ലൈൻ കാണിക്കുന്നു.

ചെലവ് വശം നോക്കാം:

സെക്കൻഡിൽ 10000 അഭ്യർത്ഥനകൾ / ഒരു സെർവറിന് 50 അഭ്യർത്ഥനകൾ = 200 സെർവറുകൾ + 1

ഈ കണക്ക് ഇനിയും നമുക്ക് മെച്ചപ്പെടുത്താം.

സെക്കൻഡിൽ 500 അഭ്യർത്ഥനകൾ

സെക്കൻഡിൽ 500 അഭ്യർത്ഥനകൾ ലോഡ് ചെയ്യുമ്പോൾ കൂടുതൽ രസകരമായ കാര്യങ്ങൾ സംഭവിക്കാൻ തുടങ്ങുന്നു:

വീണ്ടും, മുകളിൽ ഇടത് ഗ്രാഫിൽ ആപ്ലിക്കേഷൻ സാധാരണ ലോഡ് രേഖപ്പെടുത്തുന്നത് കാണാം. ഇത് അങ്ങനെയല്ലെങ്കിൽ, ആപ്ലിക്കേഷൻ പ്രവർത്തിക്കുന്ന സെർവറിൽ ഒരു പ്രശ്നമുണ്ട്. പ്രതികരണ ലേറ്റൻസി ഗ്രാഫ് മുകളിൽ വലതുവശത്ത് സ്ഥിതിചെയ്യുന്നു, സെക്കൻഡിൽ 500 അഭ്യർത്ഥനകൾ 25-40 മി.എസ് പ്രതികരണ കാലതാമസത്തിന് കാരണമാകുന്നുവെന്ന് കാണിക്കുന്നു. മുകളിൽ തിരഞ്ഞെടുത്ത 99ms SLO-യിലേക്ക് 60-ാമത്തെ പെർസന്റൈൽ ഇപ്പോഴും നന്നായി യോജിക്കുന്നു.

ചെലവിന്റെ കാര്യത്തിൽ:

സെക്കൻഡിൽ 10000 അഭ്യർത്ഥനകൾ / ഒരു സെർവറിന് 500 അഭ്യർത്ഥനകൾ = 20 സെർവറുകൾ + 1

എല്ലാം ഇനിയും മെച്ചപ്പെടുത്താം.

സെക്കൻഡിൽ 1000 അഭ്യർത്ഥനകൾ

മികച്ച ലോഞ്ച്! സെക്കൻഡിൽ 1000 അഭ്യർത്ഥനകൾ പ്രോസസ്സ് ചെയ്തതായി ആപ്ലിക്കേഷൻ കാണിക്കുന്നു, എന്നാൽ ലേറ്റൻസി പരിധി SLO ലംഘിച്ചു. മുകളിൽ വലതുവശത്തുള്ള ഗ്രാഫിലെ p99 വരിയിൽ ഇത് കാണാം. p100 ലൈൻ വളരെ ഉയർന്നതാണെങ്കിലും, യഥാർത്ഥ കാലതാമസം പരമാവധി 60ms എന്നതിനേക്കാൾ കൂടുതലാണ്. ആപ്ലിക്കേഷൻ യഥാർത്ഥത്തിൽ എന്താണ് ചെയ്യുന്നതെന്ന് കണ്ടെത്താൻ നമുക്ക് പ്രൊഫൈലിങ്ങിലേക്ക് കടക്കാം.

പ്രൊഫൈലിംഗ്

പ്രൊഫൈലിങ്ങിനായി, ഞങ്ങൾ ലോഡ് ഒരു സെക്കൻഡിൽ 1000 അഭ്യർത്ഥനകളായി സജ്ജമാക്കി, തുടർന്ന് ഉപയോഗിക്കുക pprof ആപ്ലിക്കേഷൻ എവിടെയാണ് CPU സമയം ചെലവഴിക്കുന്നതെന്ന് കണ്ടെത്താൻ ഡാറ്റ ക്യാപ്‌ചർ ചെയ്യാൻ. HTTP എൻഡ്‌പോയിന്റ് സജീവമാക്കുന്നതിലൂടെ ഇത് ചെയ്യാൻ കഴിയും pprof, തുടർന്ന്, ലോഡിന് കീഴിൽ, ചുരുളൻ ഉപയോഗിച്ച് ഫലങ്ങൾ സംരക്ഷിക്കുക:

$ curl http://localhost:8080/debug/pprof/profile?seconds=29 > cpu.1000_reqs_sec_no_optimizations.prof

ഫലങ്ങൾ ഇതുപോലെ പ്രദർശിപ്പിക്കാൻ കഴിയും:

$ go tool pprof -http=:12345 cpu.1000_reqs_sec_no_optimizations.prof

ആപ്ലിക്കേഷൻ എവിടെ, എത്രമാത്രം CPU സമയം ചെലവഴിക്കുന്നുവെന്ന് ഗ്രാഫ് കാണിക്കുന്നു. വിവരണത്തിൽ നിന്ന് ബ്രണ്ടൻ ഗ്രെഗ്:

X അക്ഷം എന്നത് സ്റ്റാക്ക് പ്രൊഫൈൽ പോപ്പുലേഷൻ ആണ്, അക്ഷരമാലാക്രമത്തിൽ അടുക്കിയിരിക്കുന്നു (ഇത് സമയമല്ല), Y അക്ഷം സ്റ്റാക്കിന്റെ ആഴം കാണിക്കുന്നു, [മുകളിൽ] പൂജ്യത്തിൽ നിന്ന് എണ്ണുന്നു. ഓരോ ദീർഘചതുരവും ഒരു സ്റ്റാക്ക് ഫ്രെയിമാണ്. വിശാലമായ ഫ്രെയിം, പലപ്പോഴും അത് സ്റ്റാക്കുകളിൽ കാണപ്പെടുന്നു. മുകളിലുള്ളത് സിപിയുവിൽ പ്രവർത്തിക്കുന്നു, താഴെയുള്ളവ ചൈൽഡ് ഘടകങ്ങളാണ്. നിറങ്ങൾ സാധാരണയായി ഒന്നും അർത്ഥമാക്കുന്നില്ല, എന്നാൽ ഫ്രെയിമുകൾ വേർതിരിച്ചറിയാൻ ക്രമരഹിതമായി തിരഞ്ഞെടുക്കപ്പെടുന്നു.

വിശകലനം - അനുമാനം

ട്യൂണിംഗിനായി, പാഴായ സിപിയു സമയം കണ്ടെത്താനുള്ള ശ്രമത്തിൽ ഞങ്ങൾ ശ്രദ്ധ കേന്ദ്രീകരിക്കും. ഉപയോഗശൂന്യമായ ചെലവുകളുടെ ഏറ്റവും വലിയ ഉറവിടങ്ങൾ ഞങ്ങൾ അന്വേഷിക്കുകയും അവ നീക്കം ചെയ്യുകയും ചെയ്യും. ശരി, ആപ്ലിക്കേഷൻ അതിന്റെ പ്രോസസ്സർ സമയം എവിടെയാണ് ചെലവഴിക്കുന്നതെന്ന് പ്രൊഫൈലിംഗ് വളരെ കൃത്യമായി വെളിപ്പെടുത്തുന്നു, നിങ്ങൾ ഇത് പലതവണ ചെയ്യേണ്ടി വന്നേക്കാം, കൂടാതെ നിങ്ങൾ ആപ്ലിക്കേഷൻ സോഴ്സ് കോഡ് മാറ്റുകയും ടെസ്റ്റുകൾ വീണ്ടും പ്രവർത്തിപ്പിക്കുകയും പ്രകടനം ലക്ഷ്യത്തിലേക്ക് അടുക്കുന്നത് കാണുകയും ചെയ്യേണ്ടതുണ്ട്.

ബ്രണ്ടൻ ഗ്രെഗിന്റെ ശുപാർശകൾ പിന്തുടർന്ന്, ഞങ്ങൾ ചാർട്ട് മുകളിൽ നിന്ന് താഴേക്ക് വായിക്കും. ഓരോ വരിയും ഒരു സ്റ്റാക്ക് ഫ്രെയിം (ഫംഗ്ഷൻ കോൾ) പ്രദർശിപ്പിക്കുന്നു. ആദ്യ വരി പ്രോഗ്രാമിലേക്കുള്ള പ്രവേശന പോയിന്റാണ്, മറ്റെല്ലാ കോളുകളുടെയും രക്ഷകർത്താവ് (മറ്റൊരു രീതിയിൽ പറഞ്ഞാൽ, മറ്റെല്ലാ കോളുകൾക്കും അത് അവരുടെ സ്റ്റാക്കിൽ ഉണ്ടായിരിക്കും). അടുത്ത വരി ഇതിനകം വ്യത്യസ്തമാണ്:

ഗ്രാഫിലെ ഒരു ഫംഗ്‌ഷന്റെ പേരിൽ നിങ്ങൾ കഴ്‌സർ ഹോവർ ചെയ്‌താൽ, ഡീബഗ്ഗിംഗ് സമയത്ത് അത് സ്റ്റാക്കിലുണ്ടായിരുന്ന ആകെ സമയം പ്രദർശിപ്പിക്കും. HTTPServe ഫംഗ്‌ഷൻ 65% സമയവും ഉണ്ടായിരുന്നു, മറ്റ് റൺടൈം ഫംഗ്‌ഷനുകൾ runtime.mcall, mstart и gc, ബാക്കി സമയം എടുത്തു. രസകരമായ വസ്തുത: മൊത്തം സമയത്തിന്റെ 5% DNS അന്വേഷണങ്ങൾക്കായി ചെലവഴിക്കുന്നു:

പ്രോഗ്രാം തിരയുന്ന വിലാസങ്ങൾ Postgresql-ന്റേതാണ്. ക്ലിക്ക് ചെയ്യുക FindByAge:

രസകരമെന്നു പറയട്ടെ, തത്ത്വത്തിൽ, കാലതാമസം ചേർക്കുന്ന മൂന്ന് പ്രധാന ഉറവിടങ്ങളുണ്ടെന്ന് പ്രോഗ്രാം കാണിക്കുന്നു: കണക്ഷനുകൾ തുറക്കുകയും അടയ്ക്കുകയും ചെയ്യുക, ഡാറ്റ അഭ്യർത്ഥിക്കുക, ഡാറ്റാബേസിലേക്ക് ബന്ധിപ്പിക്കുക. DNS അഭ്യർത്ഥനകൾ, കണക്ഷനുകൾ തുറക്കുന്നതും അടയ്ക്കുന്നതും മൊത്തം എക്സിക്യൂഷൻ സമയത്തിന്റെ 13% എടുക്കുമെന്ന് ഗ്രാഫ് കാണിക്കുന്നു.

അനുമാനം: പൂളിംഗ് ഉപയോഗിച്ച് കണക്ഷനുകൾ വീണ്ടും ഉപയോഗിക്കുന്നത് ഒരൊറ്റ HTTP അഭ്യർത്ഥനയുടെ സമയം കുറയ്ക്കുകയും ഉയർന്ന ത്രൂപുട്ടും കുറഞ്ഞ ലേറ്റൻസിയും അനുവദിക്കുകയും ചെയ്യും.

ആപ്ലിക്കേഷൻ സജ്ജീകരിക്കുന്നു - പരീക്ഷണം

ഞങ്ങൾ സോഴ്സ് കോഡ് അപ്ഡേറ്റ് ചെയ്യുന്നു, ഓരോ അഭ്യർത്ഥനയ്ക്കും Postgresql-ലേക്കുള്ള കണക്ഷൻ നീക്കം ചെയ്യാൻ ശ്രമിക്കുക. ആദ്യ ഓപ്ഷൻ ഉപയോഗിക്കുക എന്നതാണ് കണക്ഷൻ കുളം ആപ്ലിക്കേഷൻ തലത്തിൽ. ഈ പരീക്ഷണത്തിൽ ഞങ്ങൾ നമുക്ക് അത് സജ്ജമാക്കാം പോകാൻ വേണ്ടി sql ഡ്രൈവർ ഉപയോഗിച്ച് കണക്ഷൻ പൂളിംഗ്:

db, err := sql.Open("postgres", dbConnectionString)
db.SetMaxOpenConns(8)

if err != nil {
   return nil, err
}

നിർവ്വഹണം, നിരീക്ഷണം, വിശകലനം

ഒരു സെക്കൻഡിൽ 1000 അഭ്യർത്ഥനകളോടെ ടെസ്റ്റ് പുനരാരംഭിച്ചതിന് ശേഷം, 99ms-ന്റെ SLO ഉപയോഗിച്ച് p60-ന്റെ ലേറ്റൻസി ലെവലുകൾ സാധാരണ നിലയിലായതായി വ്യക്തമാണ്!

എന്താണ് ചെലവ്?

സെക്കൻഡിൽ 10000 അഭ്യർത്ഥനകൾ / ഒരു സെർവറിന് 1000 അഭ്യർത്ഥനകൾ = 10 സെർവറുകൾ + 1

നമുക്ക് ഇത് കൂടുതൽ നന്നായി ചെയ്യാം!

സെക്കൻഡിൽ 2000 അഭ്യർത്ഥനകൾ

ലോഡ് ഇരട്ടിയാക്കുന്നത് ഒരേ കാര്യം കാണിക്കുന്നു, ആപ്ലിക്കേഷൻ സെക്കൻഡിൽ 2000 അഭ്യർത്ഥനകൾ പ്രോസസ്സ് ചെയ്യുന്നതായി കാണിക്കുന്നു, p100 60ms-ൽ താഴെയാണ്, p99 SLO-യെ തൃപ്തിപ്പെടുത്തുന്നു.

ചെലവിന്റെ കാര്യത്തിൽ:

സെക്കൻഡിൽ 10000 അഭ്യർത്ഥനകൾ / ഒരു സെർവറിന് 2000 അഭ്യർത്ഥനകൾ = 5 സെർവറുകൾ + 1

സെക്കൻഡിൽ 3000 അഭ്യർത്ഥനകൾ

ഇവിടെ അപ്ലിക്കേഷന് 3000ms-ൽ താഴെയുള്ള p99 ലേറ്റൻസി ഉപയോഗിച്ച് 60 അഭ്യർത്ഥനകൾ പ്രോസസ്സ് ചെയ്യാൻ കഴിയും. SLO ലംഘിച്ചിട്ടില്ല, ചെലവ് ഇനിപ്പറയുന്ന രീതിയിൽ സ്വീകരിക്കുന്നു:

സെക്കൻഡിൽ 10000 അഭ്യർത്ഥനകൾ / ഓരോ സെർവറിനും 3000 അഭ്യർത്ഥനകൾ = 4 സെർവറുകൾ + 1 (രചയിതാവ് റൗണ്ട് അപ്പ് ചെയ്തു, ഏകദേശം. വിവർത്തകൻ)

നമുക്ക് മറ്റൊരു വിശകലനം പരീക്ഷിക്കാം.

വിശകലനം - അനുമാനം

ഒരു സെക്കൻഡിൽ 3000 അഭ്യർത്ഥനകളിൽ ഞങ്ങൾ ആപ്ലിക്കേഷൻ ഡീബഗ്ഗിംഗ് ഫലങ്ങൾ ശേഖരിക്കുകയും പ്രദർശിപ്പിക്കുകയും ചെയ്യുന്നു:

ഇപ്പോഴും 6% സമയവും കണക്ഷനുകൾ സ്ഥാപിക്കാൻ ചെലവഴിക്കുന്നു. പൂൾ സജ്ജീകരിക്കുന്നത് പ്രകടനം മെച്ചപ്പെടുത്തിയിട്ടുണ്ട്, പക്ഷേ ഡാറ്റാബേസിലേക്ക് പുതിയ കണക്ഷനുകൾ സൃഷ്ടിക്കുന്നതിൽ ആപ്ലിക്കേഷൻ തുടർന്നും പ്രവർത്തിക്കുന്നത് നിങ്ങൾക്ക് കാണാൻ കഴിയും.

അനുമാനം: കണക്ഷനുകൾ, ഒരു പൂളിന്റെ സാന്നിധ്യം ഉണ്ടായിരുന്നിട്ടും, ഇപ്പോഴും ഉപേക്ഷിക്കപ്പെടുകയും വൃത്തിയാക്കുകയും ചെയ്യുന്നു, അതിനാൽ ആപ്ലിക്കേഷന് അവ പുനഃസജ്ജമാക്കേണ്ടതുണ്ട്. പൂൾ വലുപ്പത്തിൽ തീർപ്പാക്കാത്ത കണക്ഷനുകളുടെ എണ്ണം സജ്ജീകരിക്കുന്നത്, ഒരു കണക്ഷൻ സൃഷ്ടിക്കാൻ ആപ്ലിക്കേഷൻ ചെലവഴിക്കുന്ന സമയം കുറയ്ക്കുന്നതിലൂടെ ലേറ്റൻസിയെ സഹായിക്കും.

ആപ്ലിക്കേഷൻ സജ്ജീകരിക്കുന്നു - പരീക്ഷണം

ഇൻസ്റ്റാൾ ചെയ്യാൻ ശ്രമിക്കുന്നു MaxIdleConns കുളത്തിന്റെ വലുപ്പത്തിന് തുല്യമാണ് (ഇതും വിവരിച്ചിരിക്കുന്നു ഇവിടെ):

db, err := sql.Open("postgres", dbConnectionString)
db.SetMaxOpenConns(8)
db.SetMaxIdleConns(8)
if err != nil {
   return nil, err
}

നിർവ്വഹണം, നിരീക്ഷണം, വിശകലനം

സെക്കൻഡിൽ 3000 അഭ്യർത്ഥനകൾ

p99 60ms-ൽ കുറവാണ്, p100-ൽ കാര്യമായി കുറവ്!

ഫ്ലേം ഗ്രാഫ് പരിശോധിക്കുന്നത്, കണക്ഷൻ ഇനി ശ്രദ്ധയിൽപ്പെടില്ലെന്ന് കാണിക്കുന്നു! കൂടുതൽ വിശദമായി പരിശോധിക്കാം pg(*conn).query - ഇവിടെ കണക്ഷൻ സ്ഥാപിക്കുന്നത് ഞങ്ങൾ ശ്രദ്ധിക്കുന്നില്ല.

തീരുമാനം

ഉപഭോക്തൃ പ്രതീക്ഷകളും പ്രവർത്തനപരമല്ലാത്ത ആവശ്യകതകളും നിറവേറ്റപ്പെടുന്നുണ്ടെന്ന് മനസ്സിലാക്കാൻ പ്രകടന വിശകലനം നിർണായകമാണ്. നിരീക്ഷണങ്ങളെ ഉപഭോക്തൃ പ്രതീക്ഷകളുമായി താരതമ്യപ്പെടുത്തി വിശകലനം ചെയ്യുന്നത് സ്വീകാര്യവും അല്ലാത്തതും നിർണ്ണയിക്കാൻ സഹായിക്കും. വിശകലനം ലളിതവും ആക്സസ് ചെയ്യാവുന്നതുമാക്കുന്ന സ്റ്റാൻഡേർഡ് ലൈബ്രറിയിൽ നിർമ്മിച്ച ശക്തമായ ടൂളുകൾ Go നൽകുന്നു.

അവലംബം: www.habr.com