Apache optimalizálása sok látogatóhoz

Hálózatok egyéb

Sziasztok,

abban kérném a segítségeteket, hogy van egy Wordpress alapú weboldal, amit hostolok és van, hogy percenként 3000-4000 user is megnézi (napi 200-700k oldalletöltés), ekkor a CPU load 90-95%, ami eléggé növeli a válaszidőt és néha a MySQL is behal egy-egy pillanatra. A load felugrik 50-70-re is. Ha a cloudflare nem lenne, valószínűleg ki sem tudná a szerver szolgálni a látogatókat...

A kérdésem az, hogy hogyan lehet optimalizálni egy apache webszervert ilyen nagy forgalomhoz? Valamint mostanság már 1000-1400 usernél is ezeket a tüneteket produkálja, valami nagyon nem lehet jó. Sajnos webszerverekben nem vagyok nagyon otthon, aki rám bízta, még ennyire sem. :)

Mi lehet a probléma?

A szerver: Core i5-2300 (4 mag), 16G DDR3 ram és egy SATAII-es HDD (10% körül van a disk load), Debian 6.0, apache2-mpm-prefork + php 5.3.9 (debian csomagokból telepítve)

Apache conf illetékes (?) része:

StartServers 120
MinSpareServers 15
MaxSpareServers 30
MaxClients 256
ServerLimit 250
MaxRequestsPerChild 3000

Előre is köszönöm a segítségeteket!

  • 19148 megtekintés

( haga | 2012. 01. 18., sze – 19:08 )

mod-php + mpm-prefork helyett mpm-worker + php-fpm, ha már apache (aztán a szokásos timeout-os dolgokat végigzongorázni pl., ha ott van szűk keresztmetszet).
Ha nem akkor nginx + php-fpm.
Tényleg kemény egy darab diszk van benne?

Mi miatt van 50-70-es load amúgy? Érdemes lenne végignézni, mert így kb lof.sz amit leírsz. prefork rész kb szintén felesleges. Mondjuk lehet emelni, a spareservers-en, ha sok a látogatószámban az ugrálás. Tehát ha egyszer mondjuk 10r/s van, aztán meg mondjuk 100.
Érdemes a mysql-t is megnézegetni, de tényleg először ki kéne találnod, hogy mi is az ami megfogja a gépet. Az az oldalletöltés, meg nem olyan hú de nagy.

( kcs | 2012. 01. 18., sze – 20:11 )

Az egyke sata disk db-t és a html-t is kiszolgálja, továbbá a logolást (os, db, access, stb) is ?
Ha igen akkor ott is lehet szűk keresztmetszet véleményem szerint..

( mauzi v | 2012. 01. 18., sze – 20:30 )

Egyetlen SATA diszk? Az kemény :)

( zwei | 2012. 01. 18., sze – 20:49 )

A MaxRequestsPerChild túl kicsi. Legalább 10 szer ennyi legyen.
Nem valószínű, hogy memleak van benne, így meg a kelleténél gyakoribb a fork. (de inkább ne prefork legyen)

egy diszk erre a feladatra vicc, az a 10% diskload sztem. nem igaz.

A mysql tmp területét érdemes átrakni /dev/shm-re, csakúgy mint a php session fájlok helyét.
(ha repair table-t kell futtatni, akkor visszarakni diszkre, hacsak nem fér bele bármelyik tábla a /dev/shm-be.)
Apache logolást minimalizálni, vagy éppen kikapcsolni.
a web documentroot file rendszerét noatime-el mountolni.

meg a többi, amit már előttem elmondtak.

http://www.etymonline.com/index.php?term=fork
a fork szo nem csak az evoeszkozt jelenti, eredetileg a latin elagazas szobol ered.
csodalkozom hogy hup olvasokent nem talalkoztal meg ezzel a szoval it-s kornyezetben.
szokas hasznalni pl. arra is, hogy "forkoltak a projectet" azaz szetvalt a project fejlesztese, es a ket csapat kulon uton folytatja.
a masik it-s jelentese, ami itt most hasznalva volt:
http://en.wikipedia.org/wiki/Fork_(operating_system)
azaz a processzek elagaztatasa: a unix like rendszereken ez azt jelenti, hogy a fork hivas helyen letrejon egy "masolat" az adott processzbol egy uj piddel.
a tovabbi leirasert lasd a linket.

az apache webszerverben tobb MPM(MultiProcessing Modules) is elerheto, ezek kozul az egyik a prefork: http://httpd.apache.org/docs/2.2/mod/prefork.html
gyakorlatilag ez azt csinalja, hogy az altalad megadott parameterek alapjan indulaskor forkol N darab peldanyt a vegrehajto processzbol, mivel a kiszolgalas elott hozza letre a forkokat, ezert hivjak pre-fork-nak.

Tyrael

ami azert van, mert a PHP ugyan onmagaban ugyan thread safe, de vagy egy csomo extension(pl. gettext), ami nem az, es ezert threaded kornyezetben igen csunya hibakba bele tudsz futni.
ha te tudod, hogy nem fogsz ilyen extensiont hasznalni, akkor meg lehet probalni valamilyen threaded mpm-et, de ezt automatizalni mar ugy tunik tul nagy melo lett volna a debian reszerol (plusz ahogy elkezdesz pecl-bol telepiteni extensionoket, onnantol mar a debian nem tudja/tudhatja hogy biztonsagos-e a threaded mpm hasznalata).

Tyrael

+1 (cache, cache, cache)
A lényeg, hogy amit lehet, cache-ből próbálj kiszolgálni.

WP cache modul (ha van ilyen) + apache cache (memcache).
Sőt érdemes a mod_expires-t is bevonni a játékba, hogy a nem változó tartalomat (pl. a WP alap képei, a js és css állományok) le se kérjék a gyakran visszalátogató kliensek.

Wordpress alatt a W3 Total Cache plugint használom, és az oldalakat és az adatbázist cacheli. Egyelőre a lemezre cachelés tűnik a leggyorsabbnak, de hamarosan kipróbálom a többit is.

Melyik lehet a legjobb megoldás? http://www.imageserve.info/img_store/2012/01/18/f/f2c6e6f20a08e5de1f7f6…

szer.: mod_expires van, memcached-et most próbálom

Az xcache, mert annak van változó és opcode cache része is. Az oldalra hangolásával azért el kell tölteni majd egy kis időt, szóval sokat fogsz statisztikákat bújni. A MySQL fronton egyébként már pl. mysqltuner.pl -el megnézted, hogy nem lehetne-e javítani a helyzeten? A W3 Total cacheben a cache timeoutokat is érdemes feljebb venni, ha nem változik sűrűn a tartalom. Ha 5.2-es PHP-t használsz, akkor az 5.3-asra érdemes lehet upgradelni.

Ha sok statikus forgalom is van a cloudfare-en kívül, akkor esetleg a lighttpd+php-cgi megpróbálható.

Szerk: az önmagában nem gond, ha magas a load.

IMHO ezekkel olyan nagyot nem lehet szakítani (pár százalék), ha viszonylag jól van megírva az alkalmazásod.

Ezt viszont érdemes megnézni, bár a cloudfare valószínűleg sok funkciót átvesz, így kevésbé érvényesülnek az apache "nyers" beállításai (pl. timeout-ok):

http://httpd.apache.org/docs/2.2/misc/perf-tuning.html

Inkább a túlterhelés okait kellene megtalálnod, ahogy "haga" írta (a mysql alaptelepítésben szinte egyáltalán nincs optimalizálva, ott sokat lehet faragni).

( Proci85 v | 2012. 01. 18., sze – 23:37 )

Tapasztalatom szerint apache 2300 aktív kapcsolat (established) után mehhal.
Ilyenkor bedobtam az nginx-et, 13.000 aktív kapcsolattal még elvolt.

Wordpresshez erősen ajánlott nginx+spawn fcgi esetleg nginx+php-fpm.
Továbbá hatékony cachelő megoldás.
Nem próbáltam még, de a legjobb sebességet a hyper-cache-el értek el.
Releváns link
Már egy super-cache is látványosan tud javítani a történeten. De tény az, hogy a wordpressnek igen elcseszett sql kérései vannak. Főleg az sql-t hajtja meg. AKár külön szerverre is tehető a db a terhelés elosztása miatt.

update: ha 1-1 diszk van alatta akkor az is eléggé szűk keresztmetszet.
raid10 dukálna alá jó pár vinyóval.

Megpróbálom az nginx+spawn fcgi párost, nginx+php5-fpm párossal nagyon durva CPU terhelést értem csak el... W3 Total Cache-t lecseréltem a Hyper Cache-re, meglátjuk a nap folyamán, terhelésnél hogy fognak viselkedni.

Sajnos a disk témával nem tudok mit kezdeni, a hardver az fix. Személy szerint én is legalább RAID10-be tükrözött hdd-kkel csinálnám...

Te milyen hardveren alkalmaztad ezt a megoldást?

Köszönöm a tanácsokat!

ui.: azt hittem az apache jó, hiszen a "nagyok" is azt használják.

Hello

php5-fpm-nél létrehoztad a pool-t és ott dinamikus vagy statikus módot állítottad be?
Tudsz játszani az induló & bent lévő processzekkel. Továbbá, hogy adott processz hány kérést szolgáljon ki. Ha kellő nagyra emeled, nem nyit új processzt, sokáig él így a memóriában marad. Ezt legjobban élesben lehet kipróbálni, rögtön látod a változást.
Elvileg az fpm a legjobb.

Csak, hogy egy nagyot említsek: az index.hu is nginx-et használ :)

Jaj bocs félreértettem, sorry.
Azt valóban nem fogja megoldani az opcode cache.
Viszont az, amit már fentebb is ajánlottam, ha jól van belőve nagy valószínűséggel igen:
http://httpd.apache.org/docs/2.2/caching.html
Illetve ugyanez az nginx-nél.
Hidd el nem véletlen mondom.

Vagy esetleg már próbáltad és nem segített?

Miért ne oldaná meg az opcode cache a cpu "overloadot"? Pont az a lenyege szvsz.

Egyebkent:
nginx + php-fpm + apc kombo mehet a php -nak (APC csak shm -et hasznaljon; ha a /tmp-be pakolja a cuccait, esetleg tomoritessel, akkor adtal a szarnak egy pofont - iowait)

statikus kiszolgalashoz nginx + memcached a statikus cuccoknak (design elemek; js, css, etc).
Itt megemlitendo a sprite -ok hasznalatanak elonye

Ennek erdemenyet nem artana osszehasonlitani a mostanival.
A kiszolgalasnal a php-fpm static modban menjen; kulonvalasztott poolokkal a kulonfele feladatokhoz; ez biztonsagi szempontbol is erdekes; lasd php_admin_value.

Figyeljunk oda a files/directory ertekekre is (es itt ugye ha pl kepeket szolgalsz ki, nagyon sokat jelent a megfelelo konyvtarstruktura).
Kepek eseten kulon raid10 pl. jfs -el; konyvtarstruktura szempontjabol pedig nem omlesztett, hanem strukturalt kiszolgalas: pl: van napi 2000 feltoltesed, azt ertelemszeruen a mai napnak megfelelo datumkent szervezve:
/images/2012/01/22/10/23 konyvtarba mehet minden a 2012-01-22 10:23 datummal feltoltott fajl.

Kis kepek kiszolgalasa mehetne sql -bol; ezzel megsporoltal egy rakat fajlrendszer muveletet.
SQL eseten rossz indexeles lassu lekerdezest eredmenyezhet, ami miatt lassabb lesz a kiszolgalas a (esetunkben) php-fpm child iranyaba; user ideges, nyomkodja az f5 -öt; kesz a tulterheles.

Es itt meg nagyon sok mindent fel lehet sorolni; kezdve a hostname lookup -on keresztul a logolas formajan es mennyisegen at...

Update:

Ami nelkul ertelmetlen az egesz:
mysql: raid10 -rol; SAS diszkeken; XFS, noatime opcioval mountolva
statikus kiszolgalas: raid10 -rol; SAS diszkeken; noatime opcioval mountolva
Web kiszolgalas (forrasfajlok): raid1 (itt ugye nem lesz sok statolas; hacsak nem nezegeti folyamatosan az apacs a htaccess fajlokat)

Ez nem feltetlen igaz. Tobb kiszolgalast vegzunk igy, bikoz sokkal nagyobb iowaitet eredmenyez 7000 user egyideju kiszolgalasa 1.5M kepbol barmilyen fs -bol, mint egy 10Gb -os tabla (ami raadasul tmpfs-en van; termeszetesen csak replikacio) -bol torteno kiszolgalas egy szimpla select -et kovetoen. Amikor maskent csinaltuk, ereztuk a hatasat; a userekrol nem is beszelve. A userek kiszolgalasa itt emellett 20 kep/kliens; minden oldalfrissitesnel, etc. valtozik (ez volt az igeny).

Ez nem normális. Mármint nem te, hanem amit mondassz! :)

Mivel tmpfs-en van az adatbázis, gondolom az egész working set belefér a RAM-ba (az adatbázis overheadjével). Akkor viszont miből jött az iowait? noatime?

Az ext3 dir_index nélkül cefet lassú volt egy mappában néhány tízezer fájlnál, illetve ha párhuzamosan/lassan töltötted fel a mappát akkor szénnéfregmentálta a fájlokat, de ezt a pár sarokpontot leszámítva szerintem: fájlokat fájlrendszeren kell tárolni.

Az iowait abbol jon, hogy masodpercenkent tobbezer fajlt kell kiszolgalnod, random konyvtarbol; fs cache meg nem jatszik, mivel a nagyobb kepek is innet lettek kiszolgalva (igen, alul volt meretezve).
Amugy kis fajlokhoz reisert szoktunk hasznalni notail, noatime opciokkal; de itt ez nem igazan segitett.
Egyszeruen ugy gyorsabb volt; barmennyire is hihetetlen mindenkinek (sot, mind a mai napig hasznaljuk ezt a technologiat, megelegedessel). Meggyozodesem (tapasztalatom), hogy ez a megoldas megfelelo lehet; io szempontbol mindenkepp (http loadtime magas mivolta eseten nem magyarazhatom meg a szomszed irodaban ulo fonokomnek, hogy dehat a fajloknak a fajlrendszerben a helye.)

Elhiszem, sőt, így már a magyarázat is megvan. Szóval a drága, apró fájlokat kiütötték a page cacheből az olcsóbb(an betölthető) nagyok, mert a page cache nem tesz különbséget aszerint, hogy melyket mennyi izzadtságba kerül belapátolni.

Amikor az apró fájlokat kiszelektáltad és DB-be toltad, tulajdonképpen kiajánlottad nekik a page cache egy részét, mert a mysql heapen cache-el, amit a kernel nehezen vesz el (azaz swappel ki), helyette inkább a pagecachet fojtogatja (ahol a nagy képek maradtak).

Ehhez ma már nem kell MySQL. A Cgroup memory controller-el processzenként felosztható/izolálható a page cache (is), amivel így ahhoz hasonló eredményt lehet elérni, mint amit a MySQL bevezetésével elértél.

Aztán nehogy kioktatásnak vedd, mert:
a., Szerintem alapvetően jól döntöttél, mert a MySQL megoldotta a problémát és ez a lényeg.
b., Tévedhetek. Nyilván sokkal több részletet az esetről tudsz mint én.
c., A Cgroups memory controller viszonylag új dolog, talán meg se vót még akkor.
d., Csak jószándékkal szerettem volna rámutatni, hogy esetleg van más magyarázat is mint az, hogy a fájlrendszerek rosszul kezelik a fájlokat. :)

( saxus | 2012. 01. 20., p – 10:15 )

"A szerver: [...] egy SATAII-es HDD [...]"

Hogy micsoda? :)) Ez egy vicc, nem szerver.

Tippre iowait elviszi az egész gépet.

----------------
Lvl86 Troll

( Dudu94 v | 2012. 01. 20., p – 20:39 )

Ahogy elnéztem mindenki nginx+php -t ajánlott, és nem vált be.
Esetleg lighttpd + php5-cgi? php5-cgi

( Mico v | 2012. 01. 23., h – 00:01 )

Hi!
Írtak fent jó dolgokat meg sok okosságot is. Szerintem neked egyszerűen az a bajod, hogy kevés a vas arra, amit akarsz csinálni, ezen nem sokat lehet segíteni, max. törekedni egy optimálisabb állapotra.
256-os maxclients szerintem sok egy ilyen gépre, (10-20x ekkora gépeken állítok ilyet - kódtól függ mondjuk), simán tizedelném, azzal viszont az a gond, hogy a statikus és egyéb tartalmat is ezeknek a slotoknak kellene kiszolgálnia. Erre jó megoldás egy nginx elé. Az lenne a cél, hogy a PHP-t futtató processzeket tartsd kordában, erre alkalmas a fenti nginx-php megoldás, de gyorsabbnak nem lesz gyorsabb a php futás, cserébe felvet egyéb problémákat (apache kompatibilitás htaccess stb, attól függ mennyi mindent kell hostolnod). Ha beraksz pl. egy nginx-haproxy-apache kombót, az nginx csak a PHP requesteket engedné a haproxy-n keresztül az apache-ra, az egy egyszerű módszer, mert a haproxy-ban a concurrency, request queue, stb könnyen állíthatók. írod, hogy a mysql nem ludas, ebben nem lennék annyira biztos és megnézném, hogy mit csinál, ha elszalad vele a ló, az mindenre kihatással lehet, meg kell nézni, nincsenek-e konkurrencia problémák esetleg. A prefork helyett threading modell is segíthet, memória használaton mindenképp, de még mindig ott tartunk, hogy vannak thread safety issue-k, ezért ez max. akkor jön szóba, ha egyetlen letesztelt alkalmazást kell kiszolgálni csak. Rakjál be valami APC jellegű dolgot, sztem többet segít.
De összességében úgy gondolom, neked nagyobb vas is kéne.

ilyennel szivtam én is, kezdetben. aztán megoldottam. q6600as procival kiszolgáltam majdnem ennyit. nem kevés a mostani gép. 1 disk az tuti kevés. egyszerre teszi: loggol, képet szolgál, mysql lekérdezés egyszerre disk tmp táblába írás, mert tuti swappol az sql... iostat és vmstat outputot toljál már be.

( uid_228 | 2012. 01. 24., k – 08:50 )

Az ilyen okosságokat, hogy a MySQL tmp table könyvtárát rakd /dev/shm-re inkább hagyd ki, tuningold magát a MySQL-t, de ésszel: memórialimiteket emeld meg (ha van még szabad memória a gépben), lehetőleg ne is csináljon tmp táblát. Az Andrej által említett mysqltuner.pl jó támpontokat ad ebben, illetve az extended status változóinak beható bogarászása. Slow query-ket naplózd, majd vizsgáld be (explain ...), ahova szükséges, ott gyárts indexet külön - bár ha valami stock blogmotort használsz, akkor azért arról feltételezném, hogy ilyenekre odafigyeltek az írói, de ki tudja... :)

Amúgy threaded Apache, MaxRequestsPerChild-ot fölemelni, PHP opcode cache.

Ha fölugrik a load és figyeled közben a vmstat-ot, mit mond, mire várakoznak leginkább processek?

Az 1 db. SATA2-es lemez is elég merész, viszont a 16 GB RAM már nem rossz, próbálj minél több dolgot cache-elni.

--
Java apps are nothing more than sophisticated XML-to-exception converters.

Hiába vizsgálja a lekérdezéseket, ha ez egy wordpress, ami a következő frissítésnél felülvágja a módosítást. A másik, hogy az index-ekkel csinján kell bánni, mert egy insertkor ha frissíteni egy masszívabb táblán levő indexet építeni az nem túl vidám.

Btw a topikindító megtehetné, hogy az aktuális állapotot beírja, mert szerintem már nginx-en megy a site. :)

A temp táblák nem azért képződnek a diszken, mert kevés a ram. pl. régebi mysql verziók esetén ha TEXT tipusú oszlopon kerestél, akkor minden esetben létrejött egy 1-2K nagyságú temp tábla diszken.
A temp táblák max mérete szabályozható (egyébként meg pár kb. az egész), és jellemzően kevesebb mint 1, vagy max 1-2 másodperc az élettartamuk (átlagos LAMP szervert figyelembe véve).

Az egyetlen egy probléma azzal, hogyha a /dev/shm-re rakod a temp táblát, hogy pl. repair-table esetén kifuthat a rendelkezésre álló ramból.
Egyébként teljesen jó a temp táblákat a /dev/shm-be rakni, ha van elég memória a vasban.

Adott esetben (sok temp tábla használat), látványosan gyorsulhat az adatbázis.

Abban igazad van, hogy a query-ket kell tudningolni, de vannak olyan esetek, amikor ez nem, vagy csak lassan oldható meg.

Amire ügyelni kell, hogy repair table esetén egy temp táblában redezi újra az adott táblát.

Ha az adott tábla túl nagy, akkor az fel tudja falni a memóriát, ha a ramdisk mérete nincs limitálva.
Ha meg limitálva van, akkor a repair table nem fog lefutni, és az adatbázis áll...

( STP | 2012. 03. 01., cs – 11:49 )

OK, olvastam, hogy apache. De.
Nem akarod nginx-szel kipróbálni?

( hrgy84 | 2012. 03. 01., cs – 15:09 )

Biztos volt mar tippben: az nginx jobban teljesit statikus fajlok kiszolgalasaban, mint az apache. Valamint, ha nem tul valtozo tartalmad van, akkor benyomhato cache is.

Szoval sorrendben:
- Bovitsd fel a gepet legalabb plusz 2 winyoval, a rendszer menjen kulon diszkre, arra jo valami ocskabb is (jo esetben csak felbootol rola a gep, illetve a logok mennek ide), ez melle meg tegyel meg egy ugyanilyet, es RAID, akar szoftveres is.
- Tedd el az apache-t magasabb portra, es hasznal nginx-et ele. Nagyon eros cache van benne, nagyon jo statikus fajlok kiszolgalasaban, drasztikusan tudja csokkenteni az apache fele aramlo forgalmat. Igy ki tudod hasznalni a mod_php elonyeit, de megkapod az nginx josagait.
- Konfigold be az apache-t ennek megfeleloen. Nezd az az apache doksit alaposan, hogy mit hogyan erdemes tuningolni, van benne jopar tipp, illetve a neten az "apache tuning" keresoszavakra rengeteg oldal es cikk foglalkozk a kerdessel. Ha van statisztika szamolas is, figyelj arra, hogy az apache localhostos IP-t kaphat. Van erre is megoldas (mod_rpaf pl), illetve az nginx is raveheto Apache formatumu logolasra.
- Trivialisnak tunik, de tartsd mindig frissen a WordPress-edet. Rengeteg memleakes meg egyeb problemara jon ki folyamatosan bugfix.
- Masik trivialis: tiltsd le es torold ki az osszes nem hasznalt modult.
- Esetleg erdemes elgondolkodni (csak elgondolkodni!) egy CMS cseren. Tobbektol hallottam mar, hogy Drupal-ra valo atteres megoldotta a performanciaproblemakat. Nekem konkretan nincs ilyen tapasztalatom, de egy merest mindenkeppen meger.
- Erdemes meg kiprobalni az eAccelerator nevu PHP modult. Nekem sok esetben csokkentette a problemakat, bar nyilvan nem ultramegoldas.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Köszi a tippeket és mindenkinek úgyszintén, aki foglalkozott a dologgal.

Azóta valamennyire megoldottuk a problémát. Beesett a képbe az apache+nginx páros, a varnish és a memcached is, ahogyan a CloudFlare is. Rengeteget levesz az oldal terheléséből és legalább a támadók kóstolgatását sem kell elviselnie a szervernek, mivel az igazi IP-cím úgymond rejtett marad.

Most már napi 600-900k az oldalletöltések száma, processzorhasználat már csak max. 50%.

Egyébként látom, eléggé felkapott a téma, nem csoda, hiszen van egy szám, ami felett azért erősen piszkálni kell a rendszert. :))

Még egyszer köszönöm mindenkinek a tanácsokat!

nem mondtam, hogy gond van vele, kérdeztem, hogy minek. hogy megértsem. én egy apacheval ki tudtam szolgálni 400e oldalletöltést, és mellette nginix a static fileokat, több domainre lebontva. assets, thumbs, static. a thumbs mondjuk egy másik server, de az apacheos gépről proxyzza, ramdriveba kesselve. akkor a thumbson 7millio req volt egy nap. Szal valami ott nagyon el van főzve... vagy gyenge a rendszer. igaz nálam erős a gép, de mégse klud

( ppenta | 2012. 03. 07., sze – 20:57 )

érdekel

----------------------------------------------------------------------------------------------------
Hármas........alá............kettes.........................egyest írtam be.

( csardij v | 2012. 03. 07., sze – 21:13 )

wordpress-hez vannak nagyon jó cache pluginek, az sokat segít.

Én személy szerint a wp-super-cache-t szoktam használni, ez statikus html-t generál re, amit az apache rewrite rulejai segítségével szolgál ki (php érintése nélkül).

Ha az, hogy statikusan megy az oldal gyakorlatilag nem okoz gondot, érdemes megnézni.

( SCOPE | 2012. 03. 15., cs – 14:44 )

Szerintetek ebből mennyit lehet kihozni, szerintetek mekkora látogatottságot bír el ?
(jelenleg napi 3-4 K látogató van)
A vas IBM, PIII 2db 1250Mhz-s CPU, 3GB RAM,
10Gigás vinyó rendszernek, és egy 640 gigás SataII a tartalomnak.
(Debian 6 opr.)

Jelenleg Apache 2 és php 5.3 van, de fastCGI módban, chroot-olás miatt.

Feltéve a
apache2-mpm-worker,
apache2-suexec-custom,
libapache2-mod-fcgid,
apache2-utils,
apache2.2-bin,
apache2.2-common,
php5,
php5-cgi,
php5-mysql

vannak,
a honlap nagyjából csak egy statikus, sima html, amiben a php
csak annyi, hogy iframe használata helyett, az index.php
hóz be file_get_contents-el a html állományokat,
valamint a galériánál listázza a mappát, és egymás után rakosgatja
a képeket,
tehát nem egy nagy, bonyolult php fut rajta,
későbbiekben szeretném SQL-be rakni a jelenlegi html tartalmat,

gondolom lehet, hogy ez esetben egy kicsit lassíthat rajta,
mint írtam nem egy komoly vas van alatta.
Vagy egyáltalán lenne-e értelme SQL-be tenni ?

Az apache2.conf:
Timeout 300
MaxKeepAliveRequests 100
KeepAliveTimeout 15

StartServers 2
MinSpareThreads 25
MaxSpareThreads 75
ThreadLimit 64
ThreadsPerChild 25
MaxClients 150
MaxRequestsPerChild 0

Illetve még cél lenne valamilyen DoS elleni védelem is,
pl valami olyasmi, hogy hogyha ugyanazt a lekérést kapja
a webserver, 1mp-n belül, 1IP-ről, 1000-nál többször,
akkor csak egy nagyobb timeout után válaszoljon,
ez megvalósítható, van-e ennek értelme ?

Ha a lap nem muszáj hogy változzon userenként, hanem lehet neki adni 1s, 5s, 600s TTL-t, akkor én elé tenném a http://www.cloudflare.com/ -ot (korrektül ki kell tölteni a http headereket a php-ban), és az sokat lökhet rajta. Hasonlóan helyesen be kell állítani a képek paramétereit, hogy lehessen cache-elni, és úgy akár egész sok kérés is átmehet rajta.

Tipikusan ez az, amire pazarlás hostingba gépet rakni (főleg ilyen ezer évest) és be kellene virtualizálni. Igaz, azt nem írtad, hogy a 640G mennyire van telítve. (Amúgy az komoly, hogy egy-egy db vinyó van ebben és semmi raid? Másrészt sztem az a 10G-s is lassabb már, mint bármely mai SATA-s desktop disk.)

----------------
Lvl86 Troll