Dva strežnika za eno stran

16 naročnikov

Imam vprašanje. Trenutno imam zakupljen VPS z WHM/cPanel nadzorno ploščo - CentOS. V zadnjih dneh se mi je obisk povišal iz 2000UV/dan na ~10000UV/dan, kar predstavlja veliko obremenitev za strežnik. Ker trenutno še nebi šel na Dedicated, bi naročil še en VPS z isto konfiguracijo.

Se da nekako povezat, da bi si VPS-ja delila obiskovalce? Sem že nekaj bral o DNS Loading balance. Obstaja še kakšna druga možnost?

LP

Offtopic: Kako pa si prišel do takšne mase obiskovalcev? Namreč, danes ima že vsak 3. mulc svoj web proxy in je zelo težko uspeti...

Pa veš da sploh ne vem. Pred dvemi leti in pol sem začel na SEO sceni in sem naletel na proxy-je. Zamisel se mi je zdela zanimiva in zato sem naključno dobil to domeno hidemy.......org. In sem začel. Najprej na domačen serverju, nato na eni optiki in nato naprej. Začel sem onpage optimizacijo in nato offpage. Prvi rezultat je bila ključna beseda browse anonymously, katero sem dosegel. In tako se je pot nadeljevala. Stran sem od časa do časa zanemarjal, mi je pa redno prinašala denar, že od začetka, ko je imela le 100UV/dan. Strani nisem nikoli imel za primarne, ker je slabo plačana. Mi pa pomaga za lastno učenje offpage optimizacije. Pa tudi domena ni tako slaba.

Torej, kako do takšne mase obiskovalcev? Dokler ni prišel ta "traffic-boom", sem večinoma dobival traffic iz parih ključnih besed. Sedaj pa dobim poleg Googlovega traffica še Baidu-ov, ki ga pokriva cc. 75%.

Na te strani sem preizkušal vsa SEO orodja ;)

Nekega SEO načrta za to stran/projekt nisem imel. Dobil sem tudi že več ponudb za domeno cenovnega ranga od 500-1500$ preko DP, vendar mi stran kar malo pomeni ;)

Ker ne morem več urejati, ti povem še podatek, da mi je ključna beseda Total official website Palace danes prinesla 240UV ;)

Manjka ti Ram-a, iz apache procesov, ki ti jih kar zmanjkuje, pa sumim na gumblarja na tvojem VPS-ju. Preveri ali je to res. Sam sem imel še bolj "prekinjene" apache procese, ko smo ga fasali na nekem strežniku.

Poizkusi disejblati dns resolving v apacheju, saj lahko pri taki strani ta stvar upočasni sistem kar precej. Poizkusi z Keep-alive No instrukcijo, da boš čimmanj podatkov hranil v spominu, bolj "kuril" CPU...

Definitivno ne razmišljaj o clusteringu, ker finančno ne boš prišel skozi za tako spletno stran.

Ce ti je vseeno kje je server, gres lahko na Amazon ali kak Rackspace, kjer placas po porabi oz. resoursih. Se posebej Amazon je sedaj zanimiv, ker so startal Amazon Micro Intance.

Jest celo uporabljam oboje, Rackspace in Amazon EC2. Velika prednost je ta, da velikosti enostavno prilagajaš trenutnim potrebam.

Baje ti zmanjkuje RAMa zaradi Apache procesov. Kombinacija Apache+PHP običajno pomeni apache-prefork + mod_php, zato bi ti mogoče koristilo, če namestiš apache-threaded + fastcgi. Razlika je v tem, da so potem apache procesi večnitni in jih potrebuješ veliko manj za isti efekt. Recimo 10x manj :)

netsis: a lahko poveš malo cenovno kako to izgleda na Amazon EC2? Kolikor sem pred časom gledal ti omogočajo da svojo virtualno mašino objaviš pri njih. So kakšne omejitve glede tega ker tole bi bilo zanimivo za eno zadevo, ki jo razvijam pa e malo več konkretnih informacij zanima.

Če gre za http proxy je par stvari zelo specifičnih.

Najbrž ne rabiš nobenih resnih sharanih podatkov (baze), tako da lahko vps-je zelo z lahkoto paralelno dodajaš.

To tudi pomeni da baza (ki pri večini webappov je) pri tebi sigurno ni performance problem.

Pri http proxy aplikaciji večino časa CPU čaka na podatke iz strani na katere proxijaš in jih pošilja naprej. Tako da je v osnobi popolnoma IO omejena (in zahteve trajajo več časa kot ponavadi, tkao da je v danem trenutku odprtih več kot klasično po mojem). Videl sem da proxy laufa na Apache in PHP kar je po mojem oboje zelo neprimerno za proxije.

Apache je narejen za hitro serviranje kratkih req., in je ravno zelo slab za "čakanje" za več hkratnih requestov. Slab zato ker uporablja en proces (al thread) na request kar pomeni veliko porabo RAM-a pri več hkratnih requestih.

Za to potrebuješ nekaj kar uporablja network asinhrono(event) ali pa ima neke light threade/procese. Poglej si npr primerjavo v porabi rama med apache in nginx (drugi graf):

http://blog.webfaction.com/a-little-holiday-present

Php ne vem točno kako laufa samo predstavljam si da je spet en proces na req. kar spet pomeni veliko rama. Če najdeš kakšno http proxy rešitev z nginx, node.js, erlang, ali kakršnemkoli async frameworku v pythonu, ruby, ... boš po mojem lahko na tem serverju laufal še več kot x10 prometa.

Kaj pa če kr uporabiš squid? al rabiš kakšno logiko zraven.
http://patchlog.com/general/how-to-set-up-an-anonymous-proxy-on-debian/

http://www.nineteenlabs.com/2007/08/24/high-anonymous-proxy-squid-25/

@Ledi:
V detajle s cenami ne bom šel, lahko vse prebereš na njihovi strani in si izračunaš tukaj. V osnovi gre pa tako, da posebej plačaš:
- navidezni strežnik
- disk (če imaš EBS)
- prenos podatkov
- backup na S3 (ko delaš zaporedne snapshote diska, se na s3 shranijo samo razlike, inkrementalni backup torej)

Na voljo imaš virtualne strežnike vse od micro (600 MB ram) do extra large (15 GB), vzporedno s tem se povečujejo tudi procesorske moči. Na voljo so pa tudi instance s poudarkom na CPU ali s poudarkom na ramu (68.4 GB).
Virtualni strežnik postaviš iz vnaprej pripravljenih image-ov, vseh vrst in oblik. Pri tem je treba pazit na izbiro med 32 in 64 bitnimi, npr. small instance podpira samo 32-bitne, micro 32 ali 64...
Pod "scalable" si amazon predstavlja predvsem dodajanje novih virtualnih strežnikov, ki jih povezuješ med sabo. Da se pa tudi povečat že obstoječe, če so združljivi (32-bit, 64-bit).

temu se reče cloud computing, moraš pa vedeti da latency ni dober. poleg tega mora software, ki se izvaja na tem "oblaku" podpirati paralelno izvajanje, drugače imaš moč računalnika le toliko kolikor je najmočnejši računalnik pri njih. Tudi varnosti delikatnih podatkov ni. To so recimo slabe strani cloud computinga. Dobre ti bodo itak vsi natresli iz rokava takoj :)