Nagy látogatottságú weboldal üzemeltetése

Linux-haladó

Sziasztok!

Segítségre lenne szükségem azoktól, akiknek már van tapasztalata nagy látogatottságú oldalak üzemeltetésében.
Felmerülhet a kérdés mit jelent a nagy látogatószám. Ebben az esetben több ezer online felhasználóról lenne szó.
Az alkalmazás erőforrás igénye "minimális", ami lehet az cache-ből töltődik.

A kérdés az, hogy milyen irányba érdemes elindulni a web kiszolgáló tekintetében, illetve:
- Apache vagy Nginx? (Nginx inkább statikus fájlok kiszolgálására)
- Apache-ot milyen MPM-el érdemes futtatni?
- MPM megfelelő konfigurációja a magas látogatószámhoz
- Létezik -e működő megoldás szolgáltatás terheléses támadásokra (azonos ip címről érkező kérdések korlátozása, apache modul vagy iptables)

Az oprendszer Ubuntu 14.04, a hardver pedig egy Supermicro server, E3-1241v3 Xeon, 16 Gb ram, 2 db intel SSD raid 1-ben.

A válaszokat előre is köszönöm!

( _ventura_ v | 2015. 11. 24., k – 11:32 )

1 biztos ha szar az alkalmazas azon se az nginx se az apache nem fog segíteni :>
Ez a minimalis erőforrás szükséglet mit jelent ? Statikus oldal ?

Jó páran megfordultak itten, és béreltek nagy vasat (dual E5 cpu 64G ram SSD stb.), mert csillió látogató van nekik és lassú az oldal. Aztán persze feltettek egy joomlás/wp/stb oldalt mindenhonnan összeollózott modulokkal, aztán csodálkoztak mirét nem megy. Persze pár látogatótól, és nem az apache vagy nginx stb múlt. Aztán pár hónap és vége is lett.

A látogató szám is inkább afféle marketing, ami érdekes a requestek száma, sql queryk -ek száma. Mert lehet 1 látogató 1 kérést generál, de lehet hogy 500 at és baromira nem mind1.

Az 1 ip elleni támadásra akár iptables, vagy apache-nak is van modulja (evasieve)

Fedora 22, Thinkpad x220

Az oldal nem statikus, Opcache van fent. Webshop alkalmazásról van szó, egyedi fejlesztés.
A teszt szerveren, ami u.a. mint az éles az oldal betöltési ideje kb. 300ms böngészőben mérve. (összesen 26 request)

mod_evasive-t próbáltam már, volt aki itt hup-on azt írta, hogy nem az igazi.
Tesztelni érdemben a működését nem bírtam, vagy nem jól configoltam fel.

Hatalmas +1
Amikor a home oldal 51+ requestből jön le, az sírógörcs, és azon nem fog segíteni a vas.
Google féle mod_pagespeed, és egy nginx proxy a statikus tartalmak cache-elésével más URL-en viszont a szar appból is képes elég jót kihozni.
A _megfelelő_ beállítása viszont pilótavizsgás, mert könnyű úgy beállítani, hogy ne működjön az oldal - nem árt hozzá valóban ismerni is a kódot.
--
PtY - www.onlinedemo.hu, www.westeros.hu

( vl v | 2015. 11. 24., k – 11:55 )

A kérdés az, hogy milyen irányba érdemes elindulni a web kiszolgáló tekintetében

Ha totál statikus az oldalad, akkor kb. annyi a meló, hogy minél kevesebbet logoljon a rendszert, azt is aszinkron, pufferelve. Meg ahány párhuzamos kapcsolatot fenn akarnak tartani a klienseid, annyi socket bírjon nyitva lenni.
Az, hogy az alkalmazás nagyrészt "cache"-ből töltődik, az még nem határozza meg azért az alkalmazás architektúráját. Ha statikus fájlokat generál valami script, és csak azokat szolgálja ki a webszerver, akkor 'done', de bármilyen más megoldás esetén az alkalmazás terhelése nem nulla, és máris lényeges lesz az architektúra (pl. mi alapján dönti el, hogy mit ad cache-ből, mekkora erőforrást igényel a cache működtetése, stb.)

( Pene | 2015. 11. 24., k – 12:46 )

annyi a nagy kérdés, hogy ugyanazt a tartalmat akarod kiszolgálni a látogatóid nagy részének (pl. híroldal), vagy egyedi sessionök lesznek-e (bejelenkezett felhasználók egyedileg összeállított oldalakkal). ha előbbi, akkor raksz elé megfelelő cache-t (mondjuk varnisht), és kész. utóbbinál már nem ilyen egyértelmű a helyzet és részletek nélkül nehéz bármi okosat mondani.

az szerintem ízlés kérdése, hogy nginx vagy apache. mindkettő jó lesz vélhetően.

secu: amit még nem említettek fentebb: mod_security-re rákeresnék a helyedben, de szóba jöhet itt is elég sokminden (cloudflare-től kezdve bármi).

( gedez | 2015. 11. 24., k – 13:12 )

1. Egyedi fejlesztésű az oldal?
1.1. Ha igen, akkor milyen verziójú PHP-re van írva?
1.1.1. Milyen cache-eket használ?
1.1.2. Szoftveres átalakításra hajlandóak?
1.2. Ha nem, akkor milyen keretrendszert használ?
1.2.1. A keretrendszerhez jelenleg milyen cache megoldásokat/szoftvereket használnak?
1.2.2. Keretrendszerhez optimalizált beállításoknak jelenleg mit használtok?

2. Milyen adatbázist használ?
2.1. Ha valamilyen SQL-t használ, akkor a tábláknál milyen műveletek vannak, amik query cache-eket érvénytelenítik?
2.2. Milyen gyakran épít újra index-eket?
2.3. Mekkora az adatbázis?

3. Jelenleg mekkora a forgalma az oldalnak?

4. Milyen jellegű online felhasználóról van szó?
4.1. Ezek oldalletöltéseket jelentenek?
4.2. Websocket alapú online felhasználókról van szó?
4.3. Streaming, vagy egyéb nagyobb média anyag?

5. Egy kiszolgálós megoldásra terveztétek a szoftvert és a szolgáltatást, vagy későbbi igényként felmerülhet több kiszolgálós erőforrás igény is?

6. Mikorra és milyen forgalmi csúcsok vannak jelenleg, és tervezetten a jövőben?

7. Backup szerverre milyen módon és gyakran történik a mentés?

8. Milyen a belső hálózati kialakítás az említett kiszolgáló és a backup szerver között?

9. Mennyi idő alatt áll át a rendszer automatikusan vagy manuálisan backup kiszolgálásra?

Butított webshop alkalmazásról van szó. (lényegében a termékek listázása / kategóriák, belépés, kosár, fizetés)

1. Egyedi fejlesztés
1.1 PHP 5.5.9
1.1.1 Opcache
1.1.2 Persze a hajlandóság megvan
1.2 -

2. Mysql 5.5.46
2.1 Nem tudom pontosan mire gondolsz
2.2 Alkalmazás szinten gondolod?
2.3 Kb 30 tábla, legnagyobb táblában kb 15.000 sor, termékek ebből kb a 10%-a, a többi a kapcsolt attribútumok

3. Új oldal lesz, hirtelen nagy látogatószámmal fog indulni

4. Erre a pontra a webshop működése választ ad

5. Egy kiszolgálós

6. Az elején indul egy nagyobb dömping, erre a kiszolgálót fel kell készíteni (hirtelen nagy látogatószám)

7. Backup szerverre a hajnali órákban történik mentés

8. Egy szerverteremben vannak

9. Erre jelenleg még nincs kidolgozott terv

Remélem nem hagytam ki semmit!

1.
Teljesítmény tesztet kell végezni, hogy mennyit bír a jelenlegi beállítással tartósan. Milyen válaszidők és milyen generálási idők mellett.
Ha biztosra mész, akkor csinálsz pár oldalletöltést xdebug-gal, és megnézed a kimenetet, hogy hol van pazarlás.
Ha az oldalgenerálási idő 0.1s-nél nagyobb, akkor érdemes átnézni az oldalt, mert nagyobb látogató szám esetén probléma lehet.
A kiszolgálási módtól függően a statikus tartalmat (pl. menürendszer, termékek/árak) gyorsítótárban tárolni és onnan olvasni, esetleg ha megoldható akkor php futtatók közös memóriájában.
A keresőbarát URL-eket, hogy kezeli az oldal?

Eddig Nginx + PHP-FPM -re gondolnék.

Ha az oldalgenerálási idő, és az SQL lekérdezések indokolják, akkor megnézném mit tudok gyorsítótárazni pl. statikus fájlban, memcache(d) -ben, vagy shared memory-ban.

2.
2.1. Hol végez ügyfél oldali interakció miatt adatmódosításokat. Pl. ilyen szokott lenni a termékek megtekintésének számát a termékek táblába tárolják. Ezért minden egyes update-kor a query cache megy a kukába. Ez a nem megfelelő tervezés eredménye. Ez kis terhelésnél nem jön elő...
Jelenleg 15e sor, de a kérdés, hogy a tábla verziózott-e, ha igen, akkor hogyan viselkedik a tábla 100x ennyi sornál.
A lekérdezések során jön-e létre tmp tábla, esetleg a terhelés vizsgálatnál csinált-e temp táblát. Ha igen, akkor a MySQL konfigon módosítani kell.

5.
A webshop tulajdonossal mindenképp tudatni kell a kockázatot, hogyha a szerver meghal épp egy kampány közepén, akkor csak X idő múlva egy előre kidolgozott terv alapján a hajnali mentésre tudtok visszaállni, az addig módosult minden adat elveszik.
A biztonsági mentés megtörténtét ellenőrizni kell.

( andrej_ v | 2015. 11. 24., k – 13:18 )

Amik így elsőre eszembe jutnak:

- Nulladik körben itt megnézni a website-ot: http://tools.pingdom.com/fpt/
- Statikus tartalmat külön VPS-ekre tenni, vagy szerverre és nginx vagy lighttpd-vel kitolni ízlés szerint.
- A PHP-t FPM-ként használni, akár apache-workerrel vagy nginx-el.
- PHP-hoz mindenképp valamilyen opcode cache-t használni, nekem az xcache jött be.
- A CloudFlare free megoldását nézd meg, ha kevés, akkor lehet ajánlani a legkisebb fizetőset is.
- A szerverben a 16G memót érdemes 32-re bővíteni, ha nem jár teljes memó cserével.

- Nulladik körben itt megnézni a website-ot: http://tools.pingdom.com/fpt/

Bookmarked. Ez tenyleg jo cucc.

- Statikus tartalmat külön VPS-ekre tenni, vagy szerverre és nginx vagy lighttpd-vel kitolni ízlés szerint.

Hatalmas +1. Ha gaz van lehet szetdobalni vps-ekre, mert akkor altalaban ugyis a savszel a keves.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

( janoszen v | 2015. 11. 24., k – 13:25 )

Elek a gyanuperrel, hogy itt LAMP stackrol van szo. Ennek fenyeben, random cuccok amik hirtelen eszembe jutnak:

1. Ha teheted, akkor nginx + PHP-FPM, igy a statikus fajlok kiszolgalasa nem foglalja le az ertekes PHP szalakat. Ezt nyilvan a szoftvernek is tamogatnia kell minimalisan.
2. Ha muszaj Apache, erdemes LEHET ele tenni egy nginx-et.
3. Ha Apache es PHP, akkor csak es kizarolag a Prefork MPM jon szoba, a PHP nincs tul joban a threadekkel/
4. Monitorozni, monitorozni, monitorozni. Kulonos keppen a PHP-FPM szalak szamat, a mysql kapcsolatokat, stb. Ebbol fogod tudni idejekoran megjosolni ha hamarosan problema lesz.
5. Tulterheleses tamadas ellen IGAZABOL nem tudsz vedekezni. Lehet berhelni jo sok mindent, de ha ilyentol felsz, tegyel ele egy cloudfrontot. Ha ez nem opcio es / vagy nem vagy hajlando beletenni az energiat a kikiserletezesbe, fizessetek meg egy szakembert aki atnezi a rendszert.
6. Ha nem csak magyarorszagi a celkozonseg, akkor a CDN szinte kotelezo.
7. Ha sajat vasad van es csak egy darab van, azonnal add el es berelj, vagy vegyel hozza support szerzodest. Ha ez nem adott, beszarik a hardver es offline vagy ki tudja meddig.
8. Ketszer gondold meg mielott automatikus failovert epitesz. Ha kicsit is bizonytalan vagy a dolgodban, maradj a kezi failovernel, ugyanis eleg jo esely van ra hogy rosszul confolod fel es aztan szedheted szet az adataidat kezzel.
9. Biztositsd, hogy az alkalmazasod ne akarja helyi filerendszerre irni az adataidat. Helyette olyan helyre irja, amit tudsz skalazni igeny eseten tobb gepre is.
10. Ha nincsenek kooperativ fejlesztoid, mondj fel. Nagy latogatottsagu weboldalt csak ugy lehet uzemeltetni, hogy problema eseten a fejleszto is hajlando bemenni az eles gepre es megnezni mi a baj, majd azt javitani is. Nem art, ha nem most lat eloszor SSH-t vagy xdebug profilingot.
11. Ha MySQL es InnoDB, akkor file per table.

--
Pásztor János
Sole Proprietor @ Opsbears
Development Lead @ IXOLIT

Köszönöm a fentieket!

3. A többi modul-al mi a gond? Teljesítményben lenne probléma? Worker-t ajánlják magasabb látogatószám kiszolgálására.
5. iptables vagy mod_evasive sem nyújtana megoldást?

Első körben attól tartok, hogy a config nem lesz megfelelő és a webszerver nem fog tudni több kapcsolatot kiszolgálni új látogatók számára. (MPM config)

A worker MPM nemnagyon fog menni a PHP-val, ha modulként akarod használni. Ha a PHP FPM-es, akkor mivel fastcgi jellegű ezért menni fog.

A konfighoz mindenképp kelleni fog egy idő, mire beáll egy jó szintre, ez ilyen. Minden site-nak más és más mintájú látogatottsága és itt csak az általában bevált dolgokat fogjuk tudni megmondani, amik már egy jó alapot adnak majd a hangoláshoz.

Sokszor találkozom azzal, hogy ha nem megy a .htaccess, akkor felrobbannak az idegtől mert tudnak _azonnal_azonnal_most_ beállítani .htaccess-el valamit. Van, hogy inkább megkapják a zapacsot és kattogják, bár már eleve a .htaccess-ezés igen kellemes stat()-olással akasztja a "nagy forgalmat". :)

Ez meg megint csak a hozzaerto fejleszto kerdese. A .htaccess eleg jelentos teljesitmeny-romlast tud okozni, ugyhogy egy olyan sitenal ahol ez fontos, eleve ne nyukaljon bele a fejleszto.

Arrol nem beszelve, hogy egy normalisan megirt PHP alkalmazasnak egy azaz egy darab entry pointja van, es onnan a fejleszto azt csinal amit akar. Minden mas megoldas egyszeru taknyolas, a legrosszabb fajta berheles.

Egyszer epiteni kell egy olyan strukturat ami mukodik es utana nem kell hozzanyulni. Vagy ha hozzakell, akkor ugyis kell hozza a rendszergazda. Nalunk kb evente max ketszer kell hozzanyulni fejlesztoi keres miatt a webszerverhez, akkor is tervezetten, nem azonnal.

--
Pásztor János
Sole Proprietor @ Opsbears
Development Lead @ IXOLIT

Nálam ezzel nyitott ajtókat döngetsz. Elég nagy szórásból találkozom fejlesztőkkel. :) Minden esetre azért random előfordul, hogy jön a kérdés, hogy "a .htaccess nem megy, nem tudod mi lehet?", miután a kezdetekkor megállapodtunk, hogy lighttpd vagy nginx lesz fix szabályokkal. :)

Nalunk ezen a dokumentacio sokat segitett. Ra lehetett mutatni a megfeleloen megszerkesztett es sexyre megcsinalt alkalmazas dokumentaciora hogy a kerdezo a figyelmetlen. Mostanara sikerult tobb szaz oldal eleg jol megcsinalt doksit irni amit a kedves delikvens a munkaba allas utani elso honapban koteles elolvasni. Ha kerdez valamit, kiegeszitjuk a doksit mert lathatoan nem volt valasz a kerdesere.

Erre a kerdesre nekem az szokott egyebkent lenni a valaszom: mi okbol kifolyolag szeretnel Te a webszerver mukodesen valtoztatni a rendszergazdaval valo egyeztetes nelkul?

--
Pásztor János
Sole Proprietor @ Opsbears
Development Lead @ IXOLIT

Ha nincsenek kooperativ fejlesztoid, mondj fel. Nagy latogatottsagu weboldalt csak ugy lehet uzemeltetni, hogy

+1

szamos gif szuletett mar az 'en gepemen tuti jol mukodik' developer allatfajta szlogenjebol...

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

( _Franko_ v | 2015. 11. 24., k – 14:16 )

"a hardver pedig egy Supermicro server, E3-1241v3 Xeon, 16 Gb ram, 2 db intel SSD raid 1-ben"

Gombhoz a kabátot? :)

"Segítségre lenne szükségem azoktól, akiknek már van tapasztalata nagy látogatottságú oldalak üzemeltetésében."

Egyébként a meglévő rendszerrel mi a probléma? Van probléma? Vagy újonnan kerülne éles üzembe és nincs tapasztalat?

--
https://us.gacivs.info

Ha erősen ingadozó a terhelés és kampányszerűen kell tömegeket kiszolgálni, akkor legyen inkább rugalmasan bővíthető (több gépre skálázhatóan), minthogy végül legyen egy végletekig optimalizált termék, ami egy gépen tud csak futni és ott se skálázódik arányosan és/vagy egyéb fizikai akadályokba ütközik a skálázása...

Egy monolitikus kódhalmaz a termék vagy van lehetőség szétvágni horizontálisan (képes-e két tier egymást hívni különálló gépen futva) és/vagy vertikálisan (elosztott-e)? Ha monolitikus, akkor az már veszett fejsze nyele, alá tudsz tenni akkora erőművet, amit éppen lehet kapni, de csak addig a pontig lesz skálázható...

--
https://us.gacivs.info

ez jo, csak a kollega nem ezt kerdezte.
hany latogatot szolgal ki most, mekkora terheles mellett? az uj oldal hogy viszonyul a regihez szintetikus terhelesteszben? mekkora az adatbazis terhelese es szabad kapacitasa?
soha ne tuningolj, amig nem tudod, hogy mit.

arrol nem is beszelve, hogy ha igazan sikeres, akkor ugyis olyan lesz, mint egy DDOS es az lesz a kerdes, hogy hogyan viselkedik az alkalmazas tulterhelve.

remelem, nem a black fridayre keszulsz igy kedden:)

"már működő oldal átalakítás után"

Hopp, most megfogtalak, ez akkor nem ujonnan indulo oldal, valamilyen latogatopattern mar most is van...

Amig ezeket az adatokat nem tudod, addig ne is kezdj bele semmibe. Kerj hozzaferest a mostani GA-hoz, elemezd at a mostani latogatoszamokat, a patternt, mikor mekkora a peak, es kalkulalj ez alapjan. Anelkul senki sehova.
--
Blog | @hron84
Üzemeltető macik

( uid_6201 v | 2015. 11. 24., k – 15:37 )

Tapasztalatom szerint még egy-két dolog, amit fejlesztői oldalról rontanak el, így erre is célszerű odafigyelni:
- sokszor nem adatgyűjtéskor gondolkodnak, hanem adatkiszolgáláskor látogatónként dolgoztatnak sokat.
- SQL ... örök téma: "á, egy sorban leírható frappáns kifejezés". Teszt során nem okozott tempó problémát, aztán fél év során összegyűlt nagy mennyiségű adathalmaz miatt jön a kérdés: "nem lehetne valahogy nagyobb vasat alátolni?". Ezzel együtt kibukik, hogy a frappáns kifejezés mögött a valóságban verejtékes adatbázis-munka áll.

Továbbá nem minden célra az SQL az erőforráshatékony megoldás.

( klixnetwork | 2015. 11. 24., k – 16:29 )

"a hardver pedig egy Supermicro server, E3-1241v3 Xeon, 16 Gb ram, 2 db intel SSD raid 1-ben" ... ez egy korrekt irodai kiszolgáló vagy workstation :-)

( Danber | 2015. 11. 24., k – 19:51 )

Köszönöm az eddigi válaszokat!

Tegyük félre az alkalmazásból adódó szűk keresztmetszetet.
Magas látogatószámhoz milyen Apache2 MPM prefork configot, paramétereket érdemes használni, hogy ne kelljen a felhasználóknak várniuk nyitott kapcsolatra (Maxclient, serverlimit)
Ne forduljon elő, hogy a szűk keresztmetszetet maga a rosszul konfigurált kiszolgáló adja.
Nginx + PHP-FPM-nél szintén kíváncsi vagyok ezekre a beállításokra.
Tegyük fel 2000 online userről van szó egy időben.

Illetve milyen eszközökkel, beállításokkal érdemes korlátozni az egy ip címről érkező sorozatos kérdéseket (terheléses "tamadás")
iptables / vagy apache modul

Ha tudtok konkrét beállításokat írni útmutatás szempontjából.

2000 request parhuzamosan vagy 2000 user az oldalon? Ha az utobbi, akkor azt nem neveznem nagy terhelesnek ha nem agyatlanul van megirva az alkalmazas. Fogj egy apache benchmarkot es usd 100-200 szalon a gepet. Nezd a logokat es tekergesd addig amig mar nincs hiszti arra hogy kifogyik valamibol. Ha ez megvan, nezd meg terheles alatt bongeszobol terheles alatt.

Kesz configot azert ne varj, mert hiaba adunk, 1. a Te alkalmazasodra valszeg nem fog mukodni 2. ha no a terheles, nem lesz meg a szukseges tapasztalatod hogy hogyan kell tuningolni. Illetve adhatol kesz configot, ha utana hozzam jossz tanacsadasra ha bajban vagy, oraberben. Viccen kivul, kuzdj meg vele, hasznodra lesz.

Az optimalizalasrol meg annyit, hogy mar a nulladik idopillanatban verd ki a fejlesztoidbol hogy csomagoljak ossze a CSS-t es JS-t, a statikus tartalmakat meg kivetel nelkul tegyek verziozott URL-re egy masik vhoston. Igy barmikor be tudsz kapcsolni agressziv cachelest vagy egy CDN-t az egesz hobelebanc ele, nem akkor kell a kodban pancsolni.

Ha van API-d, azt eszedbe ne jusson a WWW aldomain ala tenni, mert a mindenfele DDoS vedelmi szolgaltatok ott massziv hibakat tudnak okozni.

--
Pásztor János
Sole Proprietor @ Opsbears
Development Lead @ IXOLIT

Ha igenybe veszel egy DDoS szuro szolgaltatot, a technologia legtobbszor mintaelemzesen alapul es altalaban rosszul regalnak arra, hogy ha egy kliens nagy szamu requrestet kuld azonos URL-re. Az API-k viszont jellemzoen ilyen viselkedest mutatnak, ami problemakat okoz.

API-t a www aldomainre rakni egyebkent is iszonyatosan nagy baromsag, mert abban a pillanatban a weboldaladhoz kototted, soha nem fogod tudni ertelmesen masik szerverre rakni ugy hogy a forgalom ne menjen at a www aldomaint kiszolgalo szerveren. (Tudom, van reverse proxy, de egy csomo helyzetben nem megoldas.) Egy SSL cert manapsag nem kerul annyiba, ne ezen muljon.

--
Pásztor János
Sole Proprietor @ Opsbears
Development Lead @ IXOLIT

"Tegyük félre az alkalmazásból adódó szűk keresztmetszetet."

Nem lehet félretenni...

Írtál egy 300ms válaszidőt és azt, hogy van 30 darab adatbázis tábla, maximum 15e sorral... az maximum 450e sor, ha minden egyes sorban van 20kB adat (amit erősen kétlek), akkor is elfér a teljes adatbázis a 16GB memóriában, de szerintem bőven 1GB (sőt, inkább 100-200MB) alatt van a teljes adatmennyiség. Ha ezek mellett egy oldal kiszolgálása 300ms, akkor az alkalmazás lesz a szűk keresztmetszet, bármekkora kaput is akarsz nyitni elé az Apache oldaláról, szarrá fogják terhelni a legcombosabb szervert is...

...de mérések nélkül ezt senki meg nem mondja.

"...hogy ne kelljen a felhasználóknak várniuk nyitott kapcsolatra (Maxclient, serverlimit) [...] Illetve milyen eszközökkel, beállításokkal érdemes korlátozni az egy ip címről érkező sorozatos kérdéseket (terheléses "tamadás")"

Ez is erősen függ az alkalmazástól...

...érdemes megnézni, hogy a kliens mennyi és milyen jellegű kapcsolatot épít a szerver felé... van-e keepalive, van-e websocket, van-e polling és a többi. Ha van, akkor egy rossz beállítással agyon tudod vágni az alkalmazást, miközben a szerver lötyög a maradék terhelés alatt, a felhasználók meg anyáznak, jogosan.

"Ha tudtok konkrét beállításokat írni útmutatás szempontjából."

Általánosságokat lehet csak írni... de terheléses és stressz tesztek elvégzése és kiértékelése nélkül nem lehet megmondani, hogy hol érdemes változtatni a beállításokon...

...így látatlanban azt mondanám, hogy ezt beszoptad... :)

--
httsp://us.gacivs.info

"A PHP kód 50ms alatt lefut."

Az erős közelítéssel akkor kb. 20 kérés / CPU mag / másodperc... ebből indulj ki, hogy ez elég lesz-e.

"Általánosságokra lettem volna kíváncsi"

Hmm... és hogy érted az általános konkrét beállításokat? :)

"de köszönöm az építő jellegű beszoptad részt."

Nézd, ha ennek a cuccnak idén ezt a terhelést el kell vinnie és Te/Ti ott tartotok, hogy még egy combosabb terheléses tesztet se futtattatok le megmérve, hogy milyen use-case - bottleneck párok vannak a rendszert illetően, akkor erre csak azt tudom mondani, hogy beszoptad. :/

--
https://us.gacivs.info

Apache benchmark-al mértem tesztet egy landing page-re, az alábbi értékeket mutatta.

Server Software: Apache
Server Hostname: ...
Server Port: 80

Document Path: ...
Document Length: 50409 bytes

Concurrency Level: 400
Time taken for tests: 116.808 seconds
Complete requests: 100000
Failed requests: 0
Write errors: 0
Total transferred: 5085300000 bytes
HTML transferred: 5040900000 bytes
Requests per second: 856.11 [#/sec] (mean)
Time per request: 467.230 [ms] (mean)
Time per request: 1.168 [ms] (mean, across all concurrent requests)
Transfer rate: 42515.35 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 5 64.2 0 1001
Processing: 19 462 113.1 454 1789
Waiting: 15 448 110.6 440 1787
Total: 20 467 128.5 455 1904

Vagyis kb. statikus tartalom...

Végig kellene gondolni (esetleg lemérni), hogy egy tipikus use-case hogy néz ki... landing page, lapoz, lapoz, kattint, visszalép, lapoz, kattint, visszalép, kattint, kosárba tesz, visszalép, kattint, kosárba tesz, vásárol, kifizeti, stb-stb. És azt megnézni, hogy mit okoz 2000 ilyen session egymás mellett... mert teljesen más lesz az eredmény, mint egy kvázi statikus tartalom kiszolgálásakor.

--
https://us.gacivs.info

Tegyük félre az alkalmazásból adódó szűk keresztmetszetet.

az 1. hiba

Tegyük fel 2000 online userről van szó egy időben.

a 2. hiba. El kene mar szakadnod az apache-tol ill. a prefork modelletol

milyen eszközökkel, beállításokkal érdemes korlátozni az egy ip címről érkező sorozatos kérdéseket (terheléses "tamadás")

jellemzoen a ddos szokott fajni, nem a maganyos tamado.

Ha tudtok konkrét beállításokat írni útmutatás szempontjából.

google. Ott talalsz egy csomo indulo konfigot, amivel el tudsz indulni. Aztan eressz ra valami benchmark-olo cuccot, es figyeld, hogy reagal ra a szerver, ill. az alkalmazas.

En egy (statikus) banner szervert csinaltam a kozelmultban, ami egyidejuleg 8-9000 parhuzamos kerest szolgal ki. Mondjuk ott a https adja a dolog bukejat, ami elegge cpu intenziv muvelet. Igy most ott jarunk, hogy 4 cpu van a gepben, 4 nginx worker processzel. Ja, es a loggolas ki van kapcsolva.

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

"Nginx + PHP-FPM-nél szintén kíváncsi vagyok ezekre a beállításokra."
"Ha tudtok konkrét beállításokat írni útmutatás szempontjából."

A DOS / DDOS-t csak úgy tudod kivédeni ha kiszolgálod.

ha adsz ssh-t akkor megcsináljuk helyetted, hogy neked, csak a fizetést és az elismerést kelljen felvenni.

( Sempi | 2015. 11. 24., k – 20:44 )

Egy fizikai szerverre tenni mindent, nem jó terv.
Én megfontolnám az AWS szolgáltatásokat is.

Elastic load balancer, Beanstalk, Elasticache az alkalmazásnak.
Alkalmazáslog, metrkia Cloudwatch-ba, arra alertet konfigurálva az autoscaling tudja növelni, csökkenteni az instance-ok számát.
Statikus tartalmak mehetnének S3-ból, kérdés, hogy mennyi van. Esetleg meg lehetne nézni a varnish-t EC2-n, hogy az S3 költségét csökkentse.
Adatbázisnak meg RDS.
Backup szintén S3, archivum Glacier, meg persze DVD/ HDD a páncélszekrénybe :-)

Ha jók az AWS előre gyártott legókockái, akkor azt használnám, ha pedig nemjók, még mindig össze lehet állítani EC2-n.

Ha a nyitó és egy fentebbi hozzászólásából indulunk ki, akkor még nincs akkora gond, csak ez tényleg időbe fog telni. Ezt nem lehet megúszni, itt nincsenek tuti tippek (nem neked írom). Mindenesetre 2000 user egy webshopra nem olyan halálosan sok, ezt egy bontott lemp stack is elviheti erős cache mögött. Itt viszont egy darab vas van, ami azért kevés lehet, ha sok lesz a bejelentkezett júzer vagy egyéb egyedileg generáltatott tartalom (random termékmegjelenítés; lokáció vagy előzmény-alapú termékajánlás stb.). Erős tippre az adatbázis oldal lesz a leggyengébb láncszem.

Itt szerintem nincs más hátra (ha nincs több erőforrás), minthogy felépítik az alaprendszert, és utána tesztelnek, mérnek, tuningolnak. Az Apache-ot elfelejteném, az oly annyira vágyott konkrét beállítási útmutatásokat pedig nem fogjuk tudni megmondani. Venni kell egy Google által dobott találatot, aztán az opcache, nginx, sql, php-fpm, varnish stb. monitoring/státusz felületein lépésről lépésre csiszolni a rendszert. Ha meg kiderül, hogy mégis kevés a vas, akkor teszem azt kitenni az adatbázist/bármilyen más neuralgikusnak tűnő részt ideiglenesen vhová, és tovább tesztelni, mérni, tuningolni :D Ehhez jó tool lehet pl ez: http://jmeter.apache.org/ Akár szimulálni is lehet a felhasználók szinte minden "mozdulatát". Pöpec kis tool.

Viszont abban igazad van, hogy az mindenképpen az AWS mellett szól, hogy általában az ilyen webshopokat nem úgy tervezi a menedzsment, hogy ugyanannyi terméket/vevőt vonz majd az idők során, ergo ha növelni kell a kapacitást, annál egyszerűbb dolga nem lehet, minthogy a rendszer önmagát építgeti/menedzseli az AWS bizonyos szolgáltatásaival (ELB, AS etc.).

https://www.blitz.io/
(eleg komoly araik vannak:)

https://loadimpact.com/
(beregisztraltam, es lecsekkoltam az egyik oldalamat 100 virtualis userrel.
ennyi a max, amit fizetes nelkul engedelyeznek).

Es konstataltam, hogy 12%-os processzorterheltseg mellett, a 100Mbit-et teletomtem. Bar a generalt grafikonok ellentmondasban vannak egymassal.
Teszt kozben 18 MB/s -et irt ki sebessegre, ami 144Mbit/s. A grafikonon meg 18-24Mbit/s van amit a vegen csinalt.

Ha csak 24Mbit-et tolt ki magabol a szerver, akkor az nagyon gyer.
Utana kene szamolni...

Igazabol tokre megnyugodtam, hogy nincs gaz a fejlesztes alatti weboldalammal, igy a harmadikat meg se neztem :)

Majd egy het mulva eloveszem ujra a temat, es osszehasonlitom ezzel:
https://www.online.net/en/dedicated-server/dedibox-scg2

Igazabol olyat mondjatok, amivel lehet ingyen 1000, 2000, 5000 egyideju felhasznaloval tesztelni :)) Vagy nem 240USD/teszt az ara...

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Marmint ugy erted, hogy
telepitesz egy kontenerbe egy JMetert, megirod a konfigot, es elinditasz 10ezer peldanyt belole az amazon cloudjaba, monjuk 5 percre?

Es kifizeted az 5 perc dijat...

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Te tényleg ennyire nem érted, mit ír, vagy csak nem akarod érteni?
Localhoston összerakok egy konténert, ami indulás után, egyből csinálja, amit csinálnia kell. Ezzel elbaszok napokat.
Amazon:
- konténer install
- konténer start
- 5 perc vár
- egészet lelőjjük a francba.
--
blogom

Tény, hogy nem ismerem az árakat, de azt tippelem hogy a 10.000x öt perc díja azért nem annyira a csóró kategória.
És egyébként azért munkás dolog 10,000 valódi konkurens felhasználót előállítani (stabilan, úgy, hogy ne az legyen a szűk keresztmetszet, hogy a tesztmasina maga alá fosik). Már persze ha tényleg van erre szükség.

Ha egy oldal eleg szarul van osszerakva, akkor mar 30-50 parhuzamos lekerdezesbe beledoglik, azt meg meg a sajat gepemmel is meg tudom nezni, hogy erre jo-e. Ez a resze ingyen van. Persze, ha tobbszaz v tobbezer _parhuzamos_ lekerest kellene tesztelnem, vagy barmilyen szinten valos terhelest kellene mernem, akkor en is Amazon clusterrel probalkoznek. De itt boven nem ez a problema, egyszeruen csak meg kell nezni, hogy 10-30-50 parhuzamos lekeressel mit tudunk kezdeni. Meg csak az idoadatok se feltetlenul lenyegesek.

Kulonben ennyi erovel az ab sincs ingyen, hiszen ahhoz is el kell inditani az Amazon clustert, ha ertelmes mereseket akarsz folytatni. Arra, amire az ab, arra a JMeter is tokeletes, plusz, a JMeter megteszi azt a szivesseget, hogy le tudja szedni az asseteket is, tehat erre is lehet vele tesztelni - az ab-hoz ehhez ossze kell szedni a megfelelo URL-eket es meghivni.
--
Blog | @hron84
Üzemeltető macik

Jogos.
Nekem mar az is eleg volt, hogy a login oldal mennyi terhelest bir. 4500session/perc eseten 150ms valaszido atlag.

Es teszteltem vele, hogy mennyit csokkent ezen a kovetkezok kikapcsolasa: log, reszletes log, autoloader, modphp, htaccess.

Most jon a dontesi fazis, hogy tenylegesen mit kapcsoljunk ki es milyen aron.

( _Franko_ v | 2015. 11. 27., p – 10:23 )

Na, bírja a terhelést vagy már a karácsonyi akciókra készültök? :)