Pronarët e faqeve që kanë një problem me ngarkesë të lartë shpesh na kontaktojnë në "Revision". Situata kur pronari merr një "letër lumturie" nga hoster, e cila është paralajmëruese e bllokimit të faqes, nuk është aspak e rrallë, absolutisht çdo pronar ose botues i faqes mund të përballet me të, kështu që ne vendosëm të shqyrtojmë në detaje shkaqet dhe zgjidhjet e këtij problemi.
Zakonisht botuesit mësojnë për ngarkesën e tepërt nga hostët e tyre, të cilët rregullojnë dhe kontrollojnë në mënyrë rigoroze procesin e konsumit të kohës së CPU-së dhe, në nivelin e planit tarifor, vendosin ngarkesën e lejuar që mund të krijojë një llogari (zakonisht matet në% të një vlere të caktuar të lejuar ose në minuta CP / CPU).
Hoster përpiqet të shpërndajë në mënyrë të barabartë burimet e procesorit midis të gjithë klientëve të serverit. Nëse llogaria e pritjes së dikujt "ha" 90% të burimeve të procesorit, pjesa tjetër do të marrë vetëm 10%. Prandaj, në raste të tilla, pronari i një llogarie që tejkalon kufijtë do të marrë një paralajmërim. Dhe në rast të shkeljeve sistematike, llogaria bllokohet në mënyrë që të mos ndërhyjë në punën e vendeve të tjera të vendosura në të njëjtin server. Dhe kjo, në asnjë mënyrë, nuk është një përpjekje për të "shpërndarë" klientin për një tarifë më të shtrenjtë, siç mendojnë disa webmastera, pasi nuk është faji i hosterit që faqja ka kërkuar më shumë burime për disa kohë.
Le të përpiqemi të kuptojmë se me çfarë mund të lidhet rritja e ngarkesës së pritjes dhe si mund ta zgjidhim këtë problem.
Importantshtë e rëndësishme të theksohet se ngarkesa e lartë mund të jetë për shkak të të dyve të jashtmedhe të brendshme në lidhje me sitin dhe faktorët e pritjes.
Faktorët e jashtëm
Faktorët e jashtëm që krijojnë një ngarkesë të lartë janë gjithçka që nuk varet nga konfigurimi i pritjes, puna e skripteve dhe procesi i administrimit të faqes. Ky është rezultat i kërkesave të jashtme për sitin nga shërbime të ndryshme, bot ose faqe të tjera. Ka shumë faktorë.
- Skanoni sitin për dobësitë, kërkoni për "skedarë të ndjeshëm", kërkoni për panelin e administratorit.
Çdo faqe, faqet e së cilës indeksohen në motorin e kërkimit mund të bëhet një "shënjestër" për hakerat dhe botët, çdo ditë dikush do ta skanojë atë, do të kërkojë "vrima", do të përpiqet ta hakojë atë. Impossibleshtë e pamundur të ndalosh këtë proces, por mund t'i kundërvihesh.
Kërkesat e faqes, veçanërisht nëse ato kryhen intensivisht dhe duke përdorur metodën POST, konsumojnë shumë burime të procesorit. Prandaj, procesi i skanimit të një faqe me një skaner të jashtëm shprehet në një rritje të ngarkesës. Nëse, si rezultat i skanimit, një sulmues zbulon një dobësi ose një variant të piraterisë së faqes, atëherë ka shumë të ngjarë që ai të ngarkojë një kod të dëmshëm në faqe ose të kryejë disa veprime shkatërruese. Nëse nuk identifikohen probleme sigurie si rezultat i skanimit, faqja do të vazhdojë të funksionojë normalisht dhe ngarkesa do të kthehet në normale. Deri në skanimin tjetër ... - Supozimi i fjalëkalimit nga paneli i administratorit të faqes (sulmi i forcës brutale).
Një nga sulmet e popullarizuara, qëllimi i të cilit është të fitojë akses administrativ nga sulmet me forcë brutale ndaj kombinimeve të njohura të emrave të përdoruesit / fjalëkalimeve të administratorit, është një sulm i forcës brutale. Bot hacker përdor një fjalor të veçantë me kombinime të njohura TOP1000 (admin / admin, admin / 123456, ...) dhe përpiqet të futet në panelin e administratorit me ta. Vetë procesi i forcës brutale e rrit ngarkesën, pasi që kërkesa të vazhdueshme bëhen në faqen e panelit administrativ dhe kërkesat ekzekutohen nga metoda POST që kërkon shumë burime. - Regjistrimi i përdoruesit me shumicë ose dërgimi me shumicë i postës së bezdisshme përmes formave të pasigurta të komenteve.
Shpesh faqet përdorin forma reagimesh ose forma të regjistrimit të përdoruesve me mekanizma të dobët mbrojtës anti-bot. Goodshtë mirë nëse forma ka të paktën një lloj kapjeje nga seriali "provo që nuk je bot". Nëse një sit është përfshirë në bazën e të dhënave të spammers, por nuk ka asnjë "captcha" ose mekanizëm tjetër mbrojtës kundër "http përmbytjes", atëherë fillon regjistrimi masiv i përdoruesve me profile spam, dërgimi i postës përmes një formulari, etj. E gjithë kjo krijon një ngarkesë në pritje, dhe përveç kësaj, ajo mund të provokojë postë spam, për të cilën kompania pritëse fik shërbimin e postës ose bllokon faqen plotësisht.
Duhet të theksohet se për momentin të gjithë mekanizmat e thjeshtë mbrojtës janë lehtësisht të menaxhueshëm nga botët modernë, kështu që duhet të instaloni menjëherë diçka serioze, për shembull, Google Recaptcha2.
- Indeksimi i faqes nga botët e kërkimit.
Ndonjëherë, me një indeks kërkimi mjaft të madh (kur një numër i madh faqesh bien në bazën e kërkimit të Yandex dhe Google), procesi i rindeksimit mund të zgjasë shumë dhe të krijojë një ngarkesë të madhe në server. Nëse faqja juaj ka vetëm një duzinë faqe, ju gjithashtu mund të hasni një problem të ngjashëm, për shembull, nëse faqja u hakua dhe priti një portë me 50,000 faqe që godasin rezultatet e kërkimit. Ose, indeksi i kërkimit mund të spamohet nga një konkurent i cili përfitoi nga gabimet në skenarët në faqen tuaj. Ka shumë mundësi këtu.
- Marrja dhe pastrimi i përmbajtjes.
Pronarët e përmbajtjes unike duhet të shqetësohen për problemin e shkarkimit të përmbajtjes nga faqja (pastrimi dhe rrëmbimi). Kjo mund të bëhet nga robotë të veçantë që zvarriten faqet e faqes dhe kopjojnë tekste dhe fotografi të postuara në sit në mënyrë që të krijojnë klone. Nëse procesi i zvarritjes së faqes tuaj është i rregullt dhe faqja ka shumë faqe, kjo mund të krijojë një ngarkesë mbresëlënëse në pritje.
- Importi i të dhënave (burimet, shkarkimi i artikujve të mallrave).
Shpesh burimet e tregtisë elektronike përdorin një mekanizëm të shkëmbimit të të dhënave me shërbime të jashtme. Për shembull, një listë e artikujve të mallrave mund të shkarkohet nga dyqanet në internet, të dhënat nga 1C mund të ngarkohen në to, faqet e lajmeve mund të eksportojnë rregullisht burime të lajmeve, etj. Nëse përmbajtja nuk është statike, atëherë secila kërkesë e tillë do të krijojë një ngarkesë të lartë në server.
- Përdorimi i fotove ose lidhjeve në faqen tuaj.
Një nga momentet jo të dukshme që krijojnë një ngarkesë mund të jetë vendosja e një lidhjeje në sit ose përdorimi i një imazhi nga faqja në një burim më të vizituar. Një nga burimet e problemit është e ashtuquajtura "habraeffect", kur faqja nuk mund të përballojë rrjedhën e vizitorëve nga një burim më i popullarizuar. Opsioni i dytë është kur dikush (ose ju vetë) postoni një fotografi nga faqja juaj në blogun që vizitoni (për shembull, në komente), dhe ngarkohet nga secili vizitor dhe krijon një ngarkesë në pritjen tuaj. Kjo veçanërisht mund të krijojë probleme serioze nëse fotografia gjenerohet nga skenarë (për shembull, i shkallëzuar duke përdorur skriptet timthumb / phpthumb). - Sulmet në faqet e tjera (për shembull, një dobësi në xmlrpc.php).
Shpesh faqet që përmbajnë dobësi përdoren nga hakerat për të kryer sulme ndaj burimeve të tjera. Ndonjëherë një sulmues nuk ka nevojë as të hakojë sitin për këtë. Për shembull, pronarët e versioneve jo më të fundit të Wordpress (sulmi përmes skedarit xmlrpc.php) mund të hasin këtë problem. Në këtë rast, faqja juaj do të veprojë si një lidhje e ndërmjetme, dhe puna e skenareve të faqes do të krijojë një ngarkesë të madhe në server.
- Sulmi DDOS
Nëse ka një sulm DDOS në sit, atëherë nuk do të jetë e mundur të përballeni me të pa lidhur mjete speciale teknike që krijojnë trafik (shërbimi i pritjes ose shërbimi i mbrojtjes DDOS). Shtë e vështirë të mos vëresh DDOS. Për shkak të ngarkesës së madhe në server, hoster-i mund të bëjë gjëra të ndryshme: të ofrojë një shërbim mbrojtjeje DDOS, të zhvendosë sitin në një server tjetër, ose ta bllokojë (çaktivizojë) plotësisht faqen. Prandaj, për t'u mbrojtur nga DDOS, këshillohet që të keni një zgjidhje të përgatitur paraprakisht, në mënyrë që kur të shfaqet një problem, të zgjidhet shpejt. - Rritja e trafikut
Nëse trafiku është organik, atëherë kjo është arsyeja më pozitive për rritjen e ngarkesës. Do të thotë se është koha për të shkallëzuar sitin dhe për të menduar për optimizimin e skenareve për trafik më të lartë.
Për të gjeni arsyen e ngarkesësgjeneruar nga faktorë të jashtëm, ju duhet të analizoni regjistrat e serverit web. Për ta bërë këtë, mund të përdorni aplikacione të veçanta ose një kombinim të komandave në tastierën SSH.
Në rezultatet e analizës, duhet të shikoni kërkesat TOP 20 sipas metodës POST, kërkesat TOP 20 nga metoda GET / HEAD, TOP 20 adresa IP sipas numrit të goditjeve, TOP 20 faqet referuese sipas numrit të goditjeve. E gjithë kjo do t'ju lejojë të identifikoni burimin dhe llojin e trafikut, si dhe pikat e hyrjes në sit ose skriptet që quhen më shpesh. Më shumë gjasa ato do të jenë shkaku i ngarkesës së lartë.
Për të zvogëluar ngarkesën në rast të sulmeve të jashtme ose kërkesave intensive, në shumicën e rasteve është e mjaftueshme për të mundësuar mbrojtje nga përmbytja http (për shembull, "cookie-t në klient + ridrejtim me verifikim") ose të lidhni faqen me shërbimet e prokurimit të trafikut që do të bllokojnë të rrezikshme ose kërkesa shumë aktive, por të mira dhe legjitime - anashkaloni. Për më tepër, përmbajtja statike (imazhe, skenare dhe stile) nuk do të shërbehet nga faqja juaj, por nga serverat CDN, të cilat gjithashtu do të zvogëlojnë ndjeshëm ngarkesën.
Mund të provoni të lidhni një shtojcë të memorizimit në një CMS ose një shërbim të memorizimit në një host, por në rastin e faktorëve të jashtëm që ndikojnë në ngarkesë, kjo mund të mos ndihmojë.
Faktorët e brendshëm
Faktorët e brendshëm përfshijnë gjithçka që ndikon në performancën e faqes në nivelin e skripteve dhe cilësimeve. Kjo është, diçka që mund të kontrollohet nga webmasteri (pronari i faqes).
- Skripte të papopimizuara dhe një bazë të dhënash të gjerë.
Për shkak të një arkitekture të dizajnuar dobët të një aplikacioni në internet ose zbatimit joefikas të skripteve nga zhvilluesit e papërvojë, është e mundur që thjesht hapja e faqes fillestare ose shfaqja e rezultateve të kërkimit në faqe mund të ngarkojë seriozisht serverin. Dhe rritja e vëllimit të bazës së të dhënave (për shembull, një rritje në numrin e artikujve të mallrave) me çdo azhurnim të faqes do ta ngadalësojë atë gjithnjë e më shumë, duke rritur ngarkesën në hostim. Faqet individuale të një faqe me një numër të madh të blloqeve të informacionit mund të dërgojnë dhjetëra kërkesa në bazën e të dhënave, të kryejnë në mënyrë të përsëritur të njëjtat operacione me skedarët, dhe ndonjëherë edhe të bllokojnë funksionimin e elementeve të tjerë të faqes. Shpesh përballemi me një problem të ngjashëm me dyqanet në internet që funksionojnë në versionin e vjetër të Joomla me shtojcën Virtuemart. Në disa raste, bëhen më shumë se 100 pyetje të bazës së të dhënave kur hapni një faqe katalogu. - Infektimi i faqes me viruse
Hacking dhe infektimi i një faqe në internet me skriptet me qëllim të keq është një shkak mjaft i zakonshëm i ngarkesës në rritje. Ajo rritet për shkak të aktivitetit viral që rrjedh nga futja e fragmenteve me qëllim të keq në skenarët e faqeve të ligjshme, fillimi dhe funksionimi i proceseve rezidente, si dhe lidhja e skriptave me burimet e jashtme në momentin e hapjes së çdo faqe të faqes. - Lidhjet e jashtme legjitime me burimet e palëve të treta
Pak njerëz marrin parasysh ngarkesën e krijuar nga lidhjet me burimet e jashtme të informacionit (widget, informatorët e motit dhe kursit të këmbimit, burimet e lajmeve, etj.). Shpesh, të dhënat që shkarkohen nga faqet e tjera nuk ruhen në memorie lokale, dhe sa herë që hapet faqja, ato lidhin dhe ngarkojnë përmbajtje nga një server tjetër. Nëse për ndonjë arsye burimi i jashtëm ndalon së reaguari shpejt, kjo do të ndikojë në ngarkesën dhe shpejtësinë e ngarkesës në vendin kryesor. - Gabime në skenar
Kur ekzekutoni skripta, mund të ndodhin gabime që nuk u shfaqen vizitorëve, por shkruhen në regjistrin e serverit në internet ose regjistrin e php. Nëse faqja vizitohet ose ka shumë gabime, kjo gjithashtu mund të rrisë ngarkesën në pritje. Më shpesh, gabimet fillojnë të gjenerohen kur faqja kalon në një version më të ri të PHP, me të cilin skriptet nuk janë në përputhje. Ose kur jo të gjithë përbërësit e faqes azhurnohen dhe lindin konflikte midis bërthamës së re CMS dhe versioneve të vjetra të shtojcave.
Për të analizuar problemin e ngarkesës së lartë të shkaktuar nga faktorë të brendshëm, duhet të kontrolloni sitin për kod të dëmshëm (për shembull, kontrolloni faqen falas) dhe, nëse nuk gjendet ndonjë kod i dëmshëm, atëherë profilizimi i skripteve duke përdorur xhprof ose xdebug modulet
Për të zgjidhur problemin e ngarkesës së lartë të shkaktuar nga aktiviteti i kodit me qëllim të keq, është e nevojshme të dezinfektoni faqen dhe të instaloni mbrojtje nga pirateria e përsëritur. Do të jetë më mirë nëse faqja është e dezinfektuar dhe e mbrojtur, dhe jo nga zhvilluesit e faqeve të internetit.
Nëse shkaku i problemeve është në arkitekturën e faqes ose gabime, atëherë optimizimi i faqes nga një zhvillues me përvojë në internet do të ndihmojë. Një nga zgjidhjet e rikthimit për rastin e dytë është instalimi i një shtojce caching, e cila në disa raste mund të zvogëlojë konsumin e burimeve të procesorit (ngarkesa e pritjes) dhe të përshpejtojë sitin.
Kohëzgjatja
Si përfundim, unë do të doja të konsideroja një veti tjetër të ngarkesës së procesorit - kohëzgjatjen e saj. Mund të jetë ose një shpërthim afatshkurtër në tabelë gjatë ditës, ose një rritje konstante për një kohë të gjatë.
Nëse shihni një rritje të njëhershme në grafikun e konsumit të CPU-së, atëherë mos u shqetësoni. Practshtë praktikisht e padukshme, nuk ndikon në disponueshmërinë e faqes dhe nuk ndërhyn në fqinjët pritës. Worseshtë më keq nëse grafiku zvarritet për një kohë të gjatë ose tregon ngarkesën maksimale (ose tejkalon kufirin) e procesorit për disa ditë. Çfarë të bëjmë në këtë rast? Shtë e nevojshme të kontrollohen faqet në llogari siç përshkruhet më sipër, duke kontrolluar faktorët e jashtëm dhe të brendshëm që shkaktojnë probleme.
Shërbimet tona të sigurisë së informacionit
Promovimi "2 për çmimin 1"
Promovimi është i vlefshëm deri në fund të muajit.
Kur lidheni me shërbimin "Site nën mbikëqyrje" për një faqe, e dyta në të njëjtën llogari lidhet falas. Faqet pasuese në llogari - 1500 rubla në muaj për secilën faqe.
Një situatë që mund t'i ndodhë çdo pronari të një siti në zhvillim me një ngarkesë në rritje -marrja e një paralajmërimi për tejkalimin e kufirit të burimeve.
Nëse ofruesi juaj i pritjes ju informon për ngarkesën në procesor, por jeni i sigurt që duhet të keni burime të mjaftueshme, përpiquni të kuptoni se cila mund të jetë arsyeja e kësaj ngarkese. Duke ditur arsyen, mund ta rregulloni shpejt problemin.
Ngarkesa e CPU-së kur ekzekuton skriptet PHP ose Perl
Në raste të tilla, hoster nuk mund të thotë gjithmonë qartë se cili skenar po shkakton problemin, dhe do të duhet ta përcaktoni vetë. Nëse jeni duke përdorur një CMS modulare, për shembull Joomla, Wordpress ose Drupal, atëherë arsyeja mund të jetë funksionimi jo korrekt i një moduli të veçantë.
Pothuajse gjithmonë, lidhja problematike në sistemin e faqes tuaj mund të përcaktohet duke krahasuar kohën e problemit me regjistrat e kërkesave në faqen tuaj në atë moment në kohë. Zakonisht mund të merrni akses në regjistrat e serverave të internetit në panelin e kontrollit të pritjes, edhe pa u kontaktuar me ofruesin.
Ngarkesa e procesorit dhe / ose sistemit të diskut nga serveri Apache në internet
Ngarkesa e tepërt mund të krijohet nga serveri Apache i internetit kur faqja po shërben një sasi të madhe grafike dhe statike të tjera. Arkitektura e Apache-së është krijuar në mënyrë të tillë që vetëm një kërkesë të përpunohet nga një fije apo proces. Prandaj, nëse faqja juaj ka shumë informacion grafik, atëherë një sasi e madhe e paarsyeshme e procesorëve dhe burimeve RAM do të shpenzohen për kthimin e saj. Ngarkesa në diskun e serverit do të jetë gjithashtu e konsiderueshme.
Në këtë rast, mund të përdorni serverin e internetit Nginx si pjesën e përparme të Apache. Nginx, për shkak të arkitekturës së saj asinkrone, ju lejon të trajtoni mijëra lidhje brenda një procesi të vetëm dhe ofron përmbajtje statike shumë më të lehtë dhe më të shpejtë. Problemi i vetëm është se në shumë shërbime të pritjes vetëm Apache përdoret si një server në internet, dhe paketa Nginx + Apache përdoret rrallë.... Sidoqoftë, kur kaloni në një VPS, mund ta konfiguroni këtë pako pa probleme. Zakonisht, transferimi i faqeve në një VPS nga një pritje dhe vendosja e softuerit të nevojshëm mund të kryhet nga ofruesi juaj i pritjes edhe pa asnjë pagesë shtesë.
Kërkesat e tepërta të faqes
Një numër i madh i kërkesave të ngjashme për një sit nga një IP ose adresat e shumta IP është e ashtuquajtura përmbytje HTTP, një nga llojet e sulmeve DDoS. Bllokimi i IP-ve problematike në skedarin .htaccess duke përdorur direktivën "mohoj nga" mund të ndihmojë.
Nëse pritja përdor vetëm Apache dhe hoster nuk është në gjendje të pasqyrojë kërkesat e problemit me të njëjtën Nginx dhe sulmi është intensiv, hoster mund të bllokojë llogarinë tuaj në server dhe t'ju kërkojë të transferoni faqet në një VPS ose një server i dedikuar.
Nëse një sulm ndodh për herë të parë, atëherë është logjike të kontaktoni me ofruesin e pritjes për ndihmë në zmbrapsjen e tij, ose të paktën të kërkoni që llogaria të zhbllokohet dhe mundësia e vazhdimit të punës me pritjen menjëherë pasi sulmi të ndalet. Nëse një problem i tillë ndodh në mënyrë sistematike, atëherë kalimi në një VPS ose server dhe konfigurimi i tij kompetent për funksionimin tolerant të defektit të faqes (për shembull, instalimi i skenareve për bllokimin automatik të adresave IP të makinave bot bazuar në analizën e regjistrit, instalimi i Nginx si front- fundi i Apache dhe filtrimi i kërkesave të problemeve në nivelin e tij) me të vërtetë ka kuptim.
Rritje e ndjeshme e pjesëmarrjes në projekt
Me zhvillimin e faqes, rritja e trafikut të saj është një fenomen natyror, dhe herët a vonë faqja mund të bëhet vërtet e ngushtë në planin aktual tarifor. Kjo është normale për zhvillimin e projekteve. Në shumicën e rasteve, në një pritje të rregullt të përbashkët për faqet dinamike, pragu i trafikut është 2000-4000 vizitorë unikë në ditë.
Nëse trafiku i faqes suaj të internetit është afër këtyre shifrave, atëherë kalimi në ose do të jetë vendimi i duhur, i cili do të ketë ndikim pozitiv në zhvillimin e mëtejshëm të tij.
Ngarkesa e procesorit dhe sistemit të diskut nga ana e MySQL
Koha normale për të përfunduar një pyetje në një bazë të dhënash MySQL konsiderohet të jetë disa dhjetëra milisekonda. Pyetjet që zgjasin më shumë (sidomos më shumë se 0,5 sekonda) shpesh vendosin ngarkesë të tepruar si në sistemin disk të serverit ashtu edhe në procesorin e tij. Nëse hoster ju paralajmëron për një problem të ngjashëm, kërkoni atë për regjistrat e pyetjeve të ngadalta dhe optimizoni strukturën e bazës së të dhënave, si dhe pastroni bazën e të dhënave nga informacione të parëndësishme.
Përdorimi intensiv i shërbimit të pritjes për posta masive të menjëhershme për qindra ose mijëra marrës mund të shkaktojë një ngarkesë të konsiderueshme në server. Për këtë arsye, shumica e ofruesve vendosin kufizime të caktuara për dërgimin e postës - zakonisht 25-50 letra në orë, ose rreth 500-1000 letra në ditë. Ky kufizim ka për qëllim luftimin e postave të padëshiruara dhe zvogëlimin e ngarkesës në nënsistemin e postës së serverit. Për punë normale me postë në sit, kufizime të tilla zakonisht janë të mjaftueshme, dhe për postat masive është më mirë të përdorni strehimin e postës, shërbimet e postës së çastit ose të përshtatni një VPS për këtë qëllim.
Duhet të kuptoni që një mbajtës mund të përballet me dhjetëra e qindra probleme të ngjashme me tuajat çdo ditë, që do të thotë se ai mund t'ju ndihmojë t'i zgjidhni ato. Hoster është aleati juaj, jo armiku juaj, në luftën kundër problemeve të tilla.
Moreshtë më fitimprurëse për një ofrues pritjeje që të ndihmojë në zgjidhjen e një problemi dhe të mbajë një klient sesa të refuzojë të ofrojë shërbime, ndërsa jo vetëm të humbasë fitimet, por edhe të dëmtojë reputacionin e tyre.
Nëse ofruesi ofron një kalim në një tarifë më të lartë ose një shërbim të klasit më të lartë, specifikoni se çfarë do t'ju japë saktësisht kjo. Vlen të dëgjohen argumentet nëse ato janë vërtet me peshë.
Zgjedhja e një pritjeje, ju ndoshta e kuptoni se cila do të jetë ngarkesa. Sot, ekzistojnë vetëm dy opsione që janë rezistente ndaj ngarkesave të mëdha, si dhe plotësojnë kërkesat e performancës: një zgjidhje cloud ose kllaster. Si njëri ashtu edhe tjetri janë mjaft të denjë, kështu që çmimi ka më shumë të ngjarë të luajë një rol këtu.
Zgjedhja e pritjes më të mirë
Cili është ndryshimi midis një grumbulli dhe një reje?
Zgjidhjet e grupeve krijohen në bazë të dy ose më shumë serverave të dedikuar, zakonisht fizikë. Për më tepër, pajisjet e serverit përdoren vazhdimisht, dhe kur ngarkesa rritet, ata marrin me qira një numër shtesë të serverave ose blejnë më shumë.
Zgjidhjet e grupeve zakonisht faturohen çdo muaj.
Zgjidhjet Cloud gjithashtu bazohen në një numër serverash virtualë. Sa servera janë të përfshirë në një kohë të caktuar varet nga ngarkesa. Në nivele të larta - një numër i madh dhe në nivele të ulëta - serverat që nuk janë të përfshirë thjesht janë të fikur.
Pritja e reve shpesh paguhet në bazë orare. Një orë e funksionimit të secilit server individual në cloud ngarkohet domosdoshmërisht. Shuma e pagesës varet tërësisht nga ngarkesa. Nëse është e lartë, atëherë shuma që duhet paguar është më e lartë, dhe nëse nuk ka ngarkesë, atëherë pagesa është minimale.
Duke krahasuar kostot e parave të gatshme për orë të ekzekutimit të serverave të ngjashëm në cloud dhe në një grup, do të shihni se grupet janë disi më të lira. Në të njëjtën kohë, pas një analize të mirë të përqindjes së përgjithshme të përdorimit efektiv të burimeve të paguara, bëhet mjaft e qartë se është më e lartë në "retë".
Me një pritje të tillë, ju paguani ekskluzivisht për konsum aktual, ndërsa në një grup, faturimi vlen edhe për pajisjet pa punë.
Me re pritja me e mire në kushtet e shpejtësisë së shkallëzimit tejkalon tufën. Për më tepër, i jep vetes automatizimin. Ndërtimi i një kllaster është më shumë kohë, ka shumë më pak operacione automatike.
Le të ndalemi në disa tipare të tjera të secilës prej zgjidhjeve të përshkruara të pritjes.
Tufa
Hostimi i grupeve duhet të zgjidhet nëse ngarkesa është e lartë gjatë gjithë kohës ose po rritet vazhdimisht.
Në rrethana të tilla, të gjitha burimet e grupeve përfshihen vazhdimisht, kështu që pajisjet nuk janë boshe. Kështu, ka kohë për shkallëzim (duke rritur numrin e serverave). Kjo ndodh gradualisht - ndërsa ngarkesa rritet.
Më shpesh, kllaster zgjidhet nga shërbimet e internetit, dyqanet online, aplikacionet e biznesit, rrjetet sociale.
"Retë"
Pritja e re në Evropë është e justifikuar për faqet e ngjarjeve, ekspozitave, promovimeve speciale dhe të tjera, të cilat kanë trafik të ulët shumicën e kohës, por në kohë të caktuara mund të rriten ndjeshëm.
Me fjalë të tjera, ne po flasim për faqet ku kërcimet e ngarkesës janë të lidhura ngushtë me aktivitetin e marketingut ose ajo ngrihet si një ortek, dhe nuk ka kohë për të vendosur një grup. Në këtë rast, çmimi më i lartë për orë të punës kompenson faktin se pajisjet nuk janë në punë.
Kështu, një nga avantazhet e pritjes në renë kompjuterike është se "reja" zvogëlon kohën e vendosjes, si dhe të tregut të projekteve dhe aplikacioneve.
Produkti
Sigurisht, do të ketë kundërshtarë dhe mbështetës të të dy zgjidhjeve. Sidoqoftë, meqenëse ato ekzistojnë, shërbejnë për një numër të madh të projekteve, atëherë ato janë një rrugë e justifikuar për në Ueb. Se cili do të shkojë varet nga ju.
Siç u përmend më lart, hosting cloud në Ukrainë është i përshtatshëm për ngarkesa periodike të larta dhe një rritje të paparashikueshme të numrit të vizitorëve në të njëjtën kohë.
Zgjidhjet e grupeve përdoren nën ngarkesa të larta konstante ose rritje të parashikuar sistematike të trafikut.
Duke u përqëndruar në faktorë kaq të thjeshtë, zgjedhja do të jetë shumë më e shpejtë dhe më e lehtë.
