SRE: પ્રદર્શન વિશ્લેષણ. ગોમાં સરળ વેબ સર્વરનો ઉપયોગ કરીને ગોઠવણી પદ્ધતિ

પર્ફોર્મન્સ એનાલિસિસ અને ટ્યુનિંગ એ ક્લાયન્ટ્સ માટે પર્ફોર્મન્સ અનુપાલન ચકાસવા માટેનું એક શક્તિશાળી સાધન છે.

પ્રદર્શન વિશ્લેષણનો ઉપયોગ ટ્યુનિંગ પ્રયોગોના પરીક્ષણ માટે વૈજ્ઞાનિક અભિગમ લાગુ કરીને પ્રોગ્રામમાં અવરોધો તપાસવા માટે થઈ શકે છે. આ લેખ ઉદાહરણ તરીકે ગો વેબસર્વરનો ઉપયોગ કરીને પ્રદર્શન વિશ્લેષણ અને ટ્યુનિંગ માટેના સામાન્ય અભિગમને વ્યાખ્યાયિત કરે છે.

ગો અહીં ખાસ કરીને સારું છે કારણ કે તેમાં પ્રોફાઇલિંગ ટૂલ્સ છે pprof પ્રમાણભૂત પુસ્તકાલયમાં.

સ્ટ્રેટેજી

ચાલો આપણા માળખાકીય વિશ્લેષણ માટે સારાંશ સૂચિ બનાવીએ. અમે અંતર્જ્ઞાન અથવા અનુમાનના આધારે ફેરફારો કરવાને બદલે નિર્ણયો લેવા માટે કેટલાક ડેટાનો ઉપયોગ કરવાનો પ્રયાસ કરીશું. આ કરવા માટે અમે આ કરીશું:

• અમે ઑપ્ટિમાઇઝેશન સીમાઓ (જરૂરિયાતો) નક્કી કરીએ છીએ;
• અમે સિસ્ટમ માટે ટ્રાન્ઝેક્શન લોડની ગણતરી કરીએ છીએ;
• અમે પરીક્ષણ કરીએ છીએ (ડેટા બનાવો);
• અમે અવલોકન કરીએ છીએ;
• અમે વિશ્લેષણ કરીએ છીએ - શું બધી આવશ્યકતાઓ પૂરી થાય છે?
• અમે તેને વૈજ્ઞાનિક રીતે સેટ કરીએ છીએ, એક પૂર્વધારણા કરીએ છીએ;
• અમે આ પૂર્વધારણાને ચકાસવા માટે એક પ્રયોગ કરીએ છીએ.

સરળ HTTP સર્વર આર્કિટેક્ચર

આ લેખ માટે આપણે ગોલાંગમાં નાના HTTP સર્વરનો ઉપયોગ કરીશું. આ લેખમાંથી તમામ કોડ મળી શકે છે અહીં.

જે એપ્લિકેશનનું વિશ્લેષણ કરવામાં આવી રહ્યું છે તે એક HTTP સર્વર છે જે દરેક વિનંતી માટે Postgresql નું મતદાન કરે છે. વધુમાં, એપ્લિકેશન અને સિસ્ટમ મેટ્રિક્સ એકત્રિત કરવા અને પ્રદર્શિત કરવા માટે પ્રોમિથિયસ, નોડ_એક્સપોર્ટર અને ગ્રાફના છે.

સરળ બનાવવા માટે, અમે ધ્યાનમાં લઈએ છીએ કે આડી સ્કેલિંગ (અને ગણતરીઓને સરળ બનાવવા) માટે દરેક સેવા અને ડેટાબેઝ એકસાથે જમાવવામાં આવે છે:

ધ્યેયો વ્યાખ્યાયિત

આ પગલા પર, અમે લક્ષ્ય નક્કી કરીએ છીએ. આપણે શું વિશ્લેષણ કરવાનો પ્રયાસ કરી રહ્યા છીએ? જ્યારે સમાપ્ત થવાનો સમય છે ત્યારે આપણે કેવી રીતે જાણી શકીએ? આ લેખમાં, અમે કલ્પના કરીશું કે અમારી પાસે ગ્રાહકો છે અને અમારી સેવા પ્રતિ સેકન્ડ 10 વિનંતીઓ પર પ્રક્રિયા કરશે.

В Google SRE બુક પસંદગી અને મોડેલિંગની પદ્ધતિઓની વિગતવાર ચર્ચા કરવામાં આવી છે. ચાલો તે જ કરીએ અને મોડેલો બનાવીએ:

• લેટન્સી: 99% વિનંતીઓ 60ms કરતા ઓછા સમયમાં પૂર્ણ થવી જોઈએ;
• કિંમત: સેવામાં ઓછામાં ઓછા નાણાનો વપરાશ થવો જોઈએ જે અમને લાગે છે કે વ્યાજબી રીતે શક્ય છે. આ કરવા માટે, અમે થ્રુપુટને મહત્તમ કરીએ છીએ;
• ક્ષમતા આયોજન: એકંદર સ્કેલિંગ કાર્યક્ષમતા સહિત, એપ્લિકેશનના કેટલા ઉદાહરણો ચલાવવાની જરૂર પડશે અને પ્રારંભિક લોડ અને જોગવાઈની આવશ્યકતાઓને પૂર્ણ કરવા માટે કેટલા ઉદાહરણોની જરૂર પડશે તે સમજવા અને દસ્તાવેજીકરણની જરૂર છે. રીડન્ડન્સી 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

અવલોકન

ટ્રાન્ઝેક્શનલ લોડ રનટાઇમ પર લાગુ કરવામાં આવશે. એપ્લિકેશન મેટ્રિક્સ (વિનંતીઓની સંખ્યા, પ્રતિસાદ લેટન્સી) અને ઓપરેટિંગ સિસ્ટમ (મેમરી, CPU, IOPS) ઉપરાંત, એપ્લિકેશનની પ્રોફાઇલિંગ એ સમજવા માટે શરૂ કરવામાં આવશે કે તેને ક્યાં સમસ્યાઓ છે, તેમજ CPU સમયનો ઉપયોગ કેવી રીતે થાય છે.

પ્રોફાઇલિંગ

પ્રોફાઇલિંગ એ માપનો એક પ્રકાર છે જે તમને એ જોવાની મંજૂરી આપે છે કે જ્યારે એપ્લિકેશન ચાલી રહી હોય ત્યારે CPU સમય ક્યાં જઈ રહ્યો છે. તે તમને ચોક્કસપણે નિર્ધારિત કરવાની મંજૂરી આપે છે કે પ્રોસેસરનો સમય ક્યાં અને કેટલો ખર્ચવામાં આવે છે:

આ ડેટાનો ઉપયોગ પૃથ્થકરણ દરમિયાન વ્યર્થ CPU સમય અને કરવામાં આવતા બિનજરૂરી કાર્યની સમજ મેળવવા માટે કરી શકાય છે. Go (pprof) પ્રોફાઇલ્સ જનરેટ કરી શકે છે અને સાધનોના પ્રમાણભૂત સમૂહનો ઉપયોગ કરીને તેમને ફ્લેમ ગ્રાફ તરીકે વિઝ્યુઅલાઈઝ કરી શકે છે. હું લેખમાં પછીથી તેમના ઉપયોગ અને સેટઅપ માર્ગદર્શિકા વિશે વાત કરીશ.

અમલ, અવલોકન, વિશ્લેષણ.

ચાલો એક પ્રયોગ કરીએ. જ્યાં સુધી અમે પ્રદર્શનથી સંતુષ્ટ ન થઈએ ત્યાં સુધી અમે પ્રદર્શન, અવલોકન અને વિશ્લેષણ કરીશું. ચાલો પ્રથમ અવલોકનોના પરિણામો મેળવવા માટે તેને લાગુ કરવા માટે મનસ્વી રીતે ઓછા લોડ મૂલ્ય પસંદ કરીએ. દરેક અનુગામી પગલા પર અમે અમુક ભિન્નતા સાથે પસંદ કરેલ ચોક્કસ સ્કેલિંગ પરિબળ સાથે ભાર વધારીશું. દરેક લોડ ટેસ્ટિંગ રન એડજસ્ટ કરેલી વિનંતીઓની સંખ્યા સાથે કરવામાં આવે છે: make load-test LOAD_TEST_RATE=X.

પ્રતિ સેકન્ડ 50 વિનંતીઓ

ટોચના બે ગ્રાફ પર ધ્યાન આપો. ઉપર ડાબી બાજુ દર્શાવે છે કે અમારી એપ્લિકેશન પ્રતિ સેકન્ડ 50 વિનંતીઓ પર પ્રક્રિયા કરે છે (તે વિચારે છે) અને ઉપર જમણી બાજુએ દરેક વિનંતીનો સમયગાળો દર્શાવે છે. બંને પરિમાણો અમને જોવા અને વિશ્લેષણ કરવામાં મદદ કરે છે કે શું અમે અમારી કામગીરીની સીમાઓમાં છીએ કે નહીં. ગ્રાફ પર લાલ રેખા HTTP વિનંતી લેટન્સી 60ms પર SLO બતાવે છે. રેખા બતાવે છે કે અમે અમારા મહત્તમ પ્રતિસાદ સમયની નીચે છીએ.

ચાલો ખર્ચ બાજુ જોઈએ:

પ્રતિ સેકન્ડ 10000 વિનંતીઓ / સર્વર દીઠ 50 વિનંતીઓ = 200 સર્વર્સ + 1

અમે હજુ પણ આ આંકડો સુધારી શકીએ છીએ.

પ્રતિ સેકન્ડ 500 વિનંતીઓ

જ્યારે લોડ પ્રતિ સેકન્ડ 500 વિનંતીઓ પર પહોંચે છે ત્યારે વધુ રસપ્રદ વસ્તુઓ થવાનું શરૂ થાય છે:

ફરીથી, ઉપરના ડાબા ગ્રાફમાં તમે જોઈ શકો છો કે એપ્લિકેશન સામાન્ય લોડ રેકોર્ડ કરી રહી છે. જો આ કેસ નથી, તો સર્વર પર સમસ્યા છે કે જેના પર એપ્લિકેશન ચાલી રહી છે. પ્રતિસાદ લેટન્સી ગ્રાફ ઉપર જમણી બાજુએ સ્થિત છે, જે દર્શાવે છે કે પ્રતિ સેકન્ડ દીઠ 500 વિનંતીઓ 25-40ms ના પ્રતિભાવ વિલંબમાં પરિણમી છે. 99મી પર્સેન્ટાઈલ હજુ પણ ઉપર પસંદ કરેલ 60ms SLO માં સરસ રીતે બંધબેસે છે.

ખર્ચની દ્રષ્ટિએ:

પ્રતિ સેકન્ડ 10000 વિનંતીઓ / સર્વર દીઠ 500 વિનંતીઓ = 20 સર્વર્સ + 1

બધું હજુ પણ સુધારી શકાય છે.

પ્રતિ સેકન્ડ 1000 વિનંતીઓ

મહાન લોન્ચ! એપ્લિકેશન દર્શાવે છે કે તેણે પ્રતિ સેકન્ડ 1000 વિનંતીઓ પર પ્રક્રિયા કરી હતી, પરંતુ SLO દ્વારા વિલંબતા મર્યાદાનું ઉલ્લંઘન કરવામાં આવ્યું હતું. આ ટોચના જમણા ગ્રાફમાં લાઇન p99 માં જોઈ શકાય છે. હકીકત એ છે કે p100 લાઇન ઘણી ઊંચી હોવા છતાં, વાસ્તવિક વિલંબ મહત્તમ 60ms કરતા વધારે છે. એપ્લિકેશન વાસ્તવમાં શું કરે છે તે શોધવા માટે ચાલો પ્રોફાઇલિંગમાં ડૂબકી લગાવીએ.

પ્રોફાઇલિંગ

પ્રોફાઇલિંગ માટે, અમે લોડને પ્રતિ સેકન્ડ 1000 વિનંતીઓ પર સેટ કરીએ છીએ, પછી ઉપયોગ કરો pprof એપ્લિકેશન CPU સમય ક્યાં વિતાવી રહી છે તે શોધવા માટે ડેટા મેળવવા માટે. આ HTTP એન્ડપોઇન્ટને સક્રિય કરીને કરી શકાય છે pprof, અને પછી, લોડ હેઠળ, curl નો ઉપયોગ કરીને પરિણામો સાચવો:

$ 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 અક્ષ સ્ટેકની ઊંડાઈ દર્શાવે છે, [ટોચ] પર શૂન્યથી ગણાય છે. દરેક લંબચોરસ સ્ટેક ફ્રેમ છે. ફ્રેમ જેટલી વિશાળ છે, તે વધુ વખત સ્ટેક્સમાં હાજર છે. ટોચ પર શું છે તે CPU પર ચાલે છે, અને નીચે શું છે તે બાળ તત્વો છે. રંગોનો સામાન્ય રીતે કોઈ અર્થ હોતો નથી, પરંતુ ફ્રેમને અલગ પાડવા માટે રેન્ડમ પસંદ કરવામાં આવે છે.

વિશ્લેષણ - પૂર્વધારણા

ટ્યુનિંગ માટે, અમે વ્યર્થ CPU સમય શોધવાનો પ્રયાસ કરવા પર ધ્યાન કેન્દ્રિત કરીશું. અમે નકામા ખર્ચના સૌથી મોટા સ્ત્રોતો શોધીશું અને તેમને દૂર કરીશું. ઠીક છે, આપેલ છે કે પ્રોફાઇલિંગ ખૂબ જ સચોટ રીતે દર્શાવે છે કે એપ્લિકેશન તેના પ્રોસેસરનો સમય ક્યાં વિતાવી રહી છે, તમારે તે ઘણી વખત કરવું પડશે, અને તમારે એપ્લિકેશનનો સ્રોત કોડ બદલવાની પણ જરૂર પડશે, પરીક્ષણો ફરીથી ચલાવો અને પ્રદર્શન લક્ષ્ય સુધી પહોંચે છે તે જોવાની જરૂર પડશે.

બ્રેન્ડન ગ્રેગની ભલામણોને અનુસરીને, અમે ઉપરથી નીચે સુધી ચાર્ટ વાંચીશું. દરેક લાઇન સ્ટેક ફ્રેમ (ફંક્શન કોલ) દર્શાવે છે. પ્રથમ લાઇન એ પ્રોગ્રામમાં એન્ટ્રી પોઈન્ટ છે, જે અન્ય તમામ કૉલ્સના પેરેન્ટ છે (બીજા શબ્દોમાં કહીએ તો, અન્ય તમામ કૉલ્સ તેમના સ્ટેક પર હશે). આગળની લાઇન પહેલેથી જ અલગ છે:

જો તમે કર્સરને ગ્રાફ પર ફંક્શનના નામ પર હોવર કરો છો, તો ડિબગીંગ દરમિયાન સ્ટેક પરનો કુલ સમય પ્રદર્શિત થશે. HTTPServe ફંક્શન ત્યાં 65% સમય હતું, અન્ય રનટાઇમ કાર્યો runtime.mcall, mstart и gc, બાકીનો સમય લીધો. મનોરંજક હકીકત: કુલ સમયનો 5% DNS ક્વેરીઝ પર ખર્ચવામાં આવે છે:

પ્રોગ્રામ જે સરનામાંઓ માટે જુએ છે તે પોસ્ટગ્રેસ્ક્લના છે. ઉપર ક્લિક કરો FindByAge:

રસપ્રદ રીતે, પ્રોગ્રામ બતાવે છે કે, સૈદ્ધાંતિક રીતે, ત્યાં ત્રણ મુખ્ય સ્ત્રોતો છે જે વિલંબ ઉમેરે છે: કનેક્શન ખોલવા અને બંધ કરવા, ડેટાની વિનંતી કરવી અને ડેટાબેઝ સાથે કનેક્ટ કરવું. આલેખ બતાવે છે કે DNS વિનંતીઓ, ઓપનિંગ અને ક્લોઝિંગ કનેક્શન કુલ એક્ઝેક્યુશન સમયના લગભગ 13% જેટલો સમય લે છે.

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

એપ્લિકેશન સેટ કરી રહ્યા છીએ - પ્રયોગ

અમે સ્રોત કોડ અપડેટ કરીએ છીએ, દરેક વિનંતી માટે Postgresql સાથે જોડાણ દૂર કરવાનો પ્રયાસ કરો. પ્રથમ વિકલ્પનો ઉપયોગ કરવાનો છે જોડાણ પૂલ એપ્લિકેશન સ્તરે. આ પ્રયોગમાં અમે ચાલો તેને સેટ કરીએ ગો માટે sql ડ્રાઇવરનો ઉપયોગ કરીને કનેક્શન પૂલિંગ:

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

if err != nil {
   return nil, err
}

અમલ, અવલોકન, વિશ્લેષણ

પ્રતિ સેકન્ડ 1000 વિનંતીઓ સાથે પરીક્ષણ પુનઃપ્રારંભ કર્યા પછી, તે સ્પષ્ટ છે કે p99 નું લેટન્સી લેવલ 60ms ના SLO સાથે સામાન્ય થઈ ગયું છે!

કિંમત શું છે?

પ્રતિ સેકન્ડ 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 નોંધપાત્ર રીતે ઓછા p60 સાથે 100ms કરતાં ઓછું છે!

જ્યોત ગ્રાફ તપાસો બતાવે છે કે જોડાણ હવે ધ્યાનપાત્ર નથી! ચાલો વધુ વિગતવાર તપાસ કરીએ pg(*conn).query — અહીં કનેક્શન સ્થાપિત થઈ રહ્યું હોવાનું પણ અમે નોંધ્યું નથી.

નિષ્કર્ષ

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

સોર્સ: www.habr.com