ውስጥ ስለ ዘዴው ተነጋገርን መጣጥፍ፣ በዚህኛው HTTPSን እንፈትሻለን፣ ነገር ግን ይበልጥ በተጨባጭ በሆኑ ሁኔታዎች። ለሙከራ የLes Encrypt ሰርተፍኬት አግኝተናል እና ብሮትሊ መጭመቅን ወደ 11 አስችሎታል።
በዚህ ጊዜ አገልጋይን በቪዲኤስ ወይም እንደ ቨርቹዋል ማሽን መደበኛ ፕሮሰሰር ባለው አስተናጋጅ ላይ የማሰማራትን ሁኔታ ለማባዛት እንሞክራለን። ለዚሁ ዓላማ፣ ገደብ በሚከተሉት ላይ ተቀምጧል፡-
- 25% - ከ ~ 1350 ሜኸር ድግግሞሽ ጋር እኩል ነው።
- 35% -1890 ሜኸ
- 41% - 2214 ሜኸ
- 65% - 3510 ሜኸ
የአንድ ጊዜ ግንኙነቶች ብዛት ከ 500 ወደ 1, 3, 5, 7 እና 9 ቀንሷል,
ውጤቶች
መዘግየቶች፡-
ኤችቲቲፒዲ መሳሪያዎች ለእያንዳንዱ ግለሰብ ጥያቄ አዲስ ተጠቃሚ ስለሚፈጥር TTFB በተለይ እንደ የተለየ ሙከራ ተካቷል። ይህ ሙከራ አሁንም ከእውነታው የራቀ ነው ፣ ምክንያቱም ተጠቃሚው አሁንም ሁለት ገጾችን ጠቅ ያደርጋል ፣ እና በእውነቱ TTFP ዋናውን ሚና ይጫወታል።
የመጀመሪያው፣ በአጠቃላይ የ IIS ቨርቹዋል ማሽን ከተጀመረ በኋላ የመጀመሪያው ጥያቄ በአማካይ 120 ms ይወስዳል።
ሁሉም ተከታይ ጥያቄዎች TTFP 1.5 ms ያሳያሉ። Apache እና Nginx በዚህ ረገድ ወደ ኋላ ቀርተዋል። በግል፣ ደራሲው ይህንን ፈተና በጣም ገላጭ አድርጎ ይቆጥረዋል እናም አሸናፊውን በእሱ ላይ በመመስረት ብቻ ይመርጣል።
አይአይኤስ መሸጎጫዎች ቀድሞውኑ የተጨመቁ የማይንቀሳቀስ ይዘት ስላለው እና በተደረሰበት ቁጥር ስለማይጨመቀው ውጤቱ የሚያስደንቅ አይደለም።
ለአንድ ደንበኛ የሚጠፋበት ጊዜ
አፈፃፀሙን ለመገምገም 1 ነጠላ ግንኙነት ያለው ሙከራ በቂ ነው።
ለምሳሌ፣ IIS በ5000 ሰከንድ ውስጥ የ40 ተጠቃሚዎችን ሙከራ አጠናቋል፣ ይህም በሰከንድ 123 ጥያቄዎች ነው።
ከታች ያሉት ግራፎች የጣቢያው ይዘት ሙሉ በሙሉ እስኪተላለፍ ድረስ ያለውን ጊዜ ያሳያል. ይህ በተወሰነ ጊዜ ውስጥ የተጠናቀቁት የጥያቄዎች መጠን ነው። በእኛ ሁኔታ፣ የሁሉም ጥያቄዎች 80% በ 8ms በ IIS እና በ 4.5ms በ Apache እና Nginx፣ እና 8% በ Apache እና Nginx ላይ የቀረቡት ጥያቄዎች እስከ 98 ሚሊሰከንዶች ባለው ጊዜ ውስጥ ተጠናቀዋል።
5000 ጥያቄዎች የተስተናገዱበት ጊዜ፡-
5000 ጥያቄዎች የተስተናገዱበት ጊዜ፡-
3.5GHz ሲፒዩ እና 8 ኮሮች ያለው ቨርቹዋል ማሽን ካለህ የፈለከውን ምረጥ። በዚህ ሙከራ ሁሉም የድር አገልጋዮች በጣም ተመሳሳይ ናቸው። ለእያንዳንዱ አስተናጋጅ የትኛውን የድር አገልጋይ መምረጥ እንዳለብን እንነጋገራለን ።
ትንሽ ወደ እውነታዊ ሁኔታ ስንመጣ፣ ሁሉም የድር አገልጋዮች ፊት ለፊት ይሄዳሉ።
ግብዓት
የመዘግየቶች ግራፍ በተመሳሳይ ጊዜ ከተገናኙት ግንኙነቶች ብዛት ጋር። ለስላሳ እና ዝቅተኛ የተሻለ ነው. የመጨረሻዎቹ 2% ከገበታዎቹ ተወግደዋል ምክንያቱም የማይነበቡ ያደርጋቸዋል።
አሁን አገልጋዩ በቨርቹዋል ማስተናገጃ ላይ የሚስተናገድበትን አማራጭ እናስብ። በ 4 GHz 2.2 ኮር እና አንድ ኮር በ 1.8 GHz እንውሰድ.
እንዴት እንደሚመዘን
የቫኩም ትሪኦዶች፣ ፔንቶድስ እና የመሳሰሉት የአሁን-ቮልቴጅ ባህሪያት ምን እንደሚመስሉ ካዩ፣ እነዚህ ግራፎች እርስዎን ያውቃሉ። እኛ ለመያዝ እየሞከርን ያለነው ይህ ነው - ሙሌት። ገደቡ የቱንም ያህል ኮሮች ቢጥሉ የአፈጻጸም ጭማሪው የሚታይ አይሆንም።
ከዚህ ቀደም፣ 98% ጥያቄዎችን በትንሹ መዘግየት ለሁሉም ጥያቄዎች ማስተናገድ፣ በተቻለ መጠን ኩርባውን ማቆየት አጠቃላይ ፈተና ነበር። አሁን, ሌላ ኩርባ በመገንባት, ለእያንዳንዱ አገልጋይ በጣም ጥሩውን የስራ ቦታ እናገኛለን.
ይህንን ለማድረግ, ጥያቄዎችን በሰከንድ (RPR) አመልካች እንውሰድ. አግድም ድግግሞሹ ነው፣ አቀባዊ በሴኮንድ የሚስተናገዱ የጥያቄዎች ብዛት፣ መስመሮች የኮሮች ብዛት ናቸው።
የNginx ሂደቶች እርስ በእርስ እንዴት እንደሚጠይቁ ትስስሩን ያሳያል። በዚህ ፈተና ውስጥ 8 ኮርሶች በተሻለ ሁኔታ ይሰራሉ.
ይህ ግራፍ Nginx በአንድ ኮር ላይ ምን ያህል የተሻለ (ብዙ አይደለም) እንደሚሰራ በግልፅ ያሳያል። Nginx ካለዎት፣ የማይለዋወጡትን ብቻ እያስተናገዱ ከሆነ የኮሮችን ብዛት ወደ አንድ ለመቀነስ ያስቡበት።
አይአይኤስ፣ በChrome ውስጥ በDevTools መሠረት ዝቅተኛው TTFB ቢኖረውም፣ ከ Apache ፋውንዴሽን ካለው የጭንቀት ሙከራ ጋር በተደረገ ከባድ ውጊያ በሁለቱም በNginx እና Apache መሸነፍ ችሏል።
ሁሉም የግራፎቹ ኩርባዎች በብረት ለበስ ይባዛሉ።
አንድ ዓይነት መደምደሚያ;
አዎ፣ Apache በ1 እና 8 ኮርስ ላይ የባሰ ይሰራል፣ ግን በ4 ላይ ትንሽ የተሻለ ይሰራል።
አዎ፣ Nginx በ 8 ኮር ሂደቶች አንድ በአንድ በተሻለ ሁኔታ በ1 እና 4 ኮርሶች ላይ ይጠይቃሉ፣ እና ብዙ ግንኙነቶች ሲኖሩ የባሰ ይሰራል።
አዎን, አይአይኤስ ለብዙ-ክሮች የሥራ ጫናዎች 4 ኮርሶችን ይመርጣል እና 8 ኮርሶችን ለአንድ ነጠላ ክር የሥራ ጫና ይመርጣል. በስተመጨረሻ፣ IIS በከፍተኛ ጭነት ስር ባሉ 8 ኮሮች ላይ ካሉት ሁሉም ሰው በመጠኑ ፈጣን ነበር፣ ምንም እንኳን ሁሉም አገልጋዮች በእኩል ደረጃ ላይ ነበሩ።
ይህ የመለኪያ ስህተት አይደለም፣ እዚህ ያለው ስህተቱ ከ +-1ms ያልበለጠ ነው። በመዘግየቶች እና ከ +- 2-3 ጥያቄዎች በሰከንድ ለ RPR.
8 ኮሮች የባሰ የሚሰሩባቸው ውጤቶች ምንም የሚያስደንቁ አይደሉም፣ ብዙ ኮሮች እና SMT/Hyperthreading ሙሉውን የቧንቧ መስመር ማጠናቀቅ ያለብን የጊዜ ገደብ ካገኘን አፈፃፀሙን በእጅጉ ያዋርዳሉ።
ምንጭ: hab.com