Portalt szetvagni 2 szerverre, es https gondolk egy kezdonel

Internet: PHP, CGI, stb.

Kezdo vagyok az ilyen dolgokban, most keszitek egy eleg bonyolult es osszetett oldalt ami remenyeim szerint ha beindul eleg nagy terhelest fog generalni ezert mar a tervezes (keszites) fazisaban ugy iteltem meg hogy az egeszet 2 szerverre teszem fel, az egyiken lessz a mysql es ezen a gepen generalodnak le a php -s dinamikus dolgok ez legyen pl a valami.com , a masik szerverre lesznek a statikus fajlok, kepek, js fajlok, ikonok, css, stb... Ez legyen mondjuk a static.valami.com

Igy, mondjuk ra, hogy az egy gepre eso terheles is valamelyest eloszlik mert a fo gepen amin az adatbazis lekerdezesek is mennek ami valojaban csak a dinamikus oldalakat hozza letre nem kell foglalkoznia az egyszeru statikus fajl keresek kiszolgalasaval nem terheli a gepet es a savszelesseget sem ... (Halkan megjegyzem hogy kispenzu projektrol van szo, es a szerverek, savszelesseg stb. is erosen korlatolt)

Azt szeretnem kerdezni hogy egyaltlan jo-e ez az elkepzeles igy? Igy (is) szokas megoldani a dolgokat vagy ez nem jo ut?

A masik gondom az hogy a fo gepen a valami.com melett lessz egy secure.valami.com -is ami https -szel szolgalja ki a klienseket, itt nem minden oldal lessz csak a kritikusabb oldalak mint pl. bejelentkezo oldal, regisztracio, es hasolnlo szemelyes adatokat tartalmazo reszek ... Vegeredmenyben ez mukodik is de zavaro hogy pl. a firefox panaszkodik hogy az oldal tartalmaz reszeket amik nem a https -szel mennek at a neten ... Konkretan arrol van szo hogy pl a https://secure.valami.com/login.php az rendben is van de a login.php -ben levo kepek pl. a static.valami.com -rol jonnek hozza ...Ez ekkor mar az oldal tartalmaz nem biztonsagos elemeket is ... Mi erre a jo megoldas? Azon kivul hogy a secure -re is ra kell raknom az osszes kepet meg minden egyebet?

  • 2782 megtekintés

( sj | 2010. 03. 07., v – 13:23 )

az oldal tartalmaz nem biztonsagos elemeket is ... Mi erre a jo megoldas? Azon kivul hogy a secure -re is ra kell raknom az osszes kepet meg minden egyebet?

Pl. a masik gepre is certificate-et venni. Vagy wildcard certificate, azaz *.valami.com. Persze ez dragabb, mint a sima.

A 2 gep felosztasa kapcsan a legjobb tanacs az, hogy meg kell becsulnod, hogy a site kiszolgalasa mekkora terhelest eredmenyez az egyes komponenek szamara (pl. db, webszerver, diszk, net, cpu, ram, ...). Majd ennek ismereteben szetdobni a feladatokat a 2 gep kozott. Mar most szolok, arra is kene egy terv, ha bekakal az egyik gep. Ha egy x feladatot csak az egyik visz, akkor a teljes site-od lehal. Viszont ha a gepek kulon-kulon mindent csinalnak, akkor legfeljebb lassabb lesz a site, de nem hal meg, ha kidol az egyik gep. Merlegelni kell ezt is, ill. azt is, hogy ez utobbi felallas egyaltalan jarhato-e (nalad).

Szoval valoszinuleg az egyik gep (php+mysql) terheltebb lesz, mint a masik. Altalaban a db muveletek szoktak lenni a szuk keresztmetszet (ha tenyleg olyan nagy lesz a latogatottsag). Ezert baratkozz meg a memcached nevu cuccal, ami a db loadot (ha ugyanazt az adatot sokszor le kell kerdezni) lejjebb tudja vinni.

Ha a statikus adatok (kepek, css, js file-ok) osszmerete nem (tul) nagy, akkor beranthatod oket a memoriaba (webszerver specifikus a dolog), igy nem kell mindig diszkrol olvasni ezeket. Ez vagy jarhato nalad, vagy nem.

Ill. en meg egy olyat is el tudnek kepzelni, hogy az erosebb gepen fut a webszerver + db + memcached, a masik mep meg egy reverz proxy lesz elotte. A lenyeg az, hogy at kell gondolni, merlegelni kell, majd a legjobb konfiguraciot valasztani.

SPAMtelenül - MX spamszűrő szolgáltatás, ahogyan még sosem próbálta

Ugy erted hogy a static.valami.com -ra is tegyek certifikacot? es akkor az a http://static... es a https://static.... kereseket is kiszolgalja?

Nekem az a legfobb gondom ezel az hogy az egesz index.php?command=valami_paracs szeru oldalakbol all es az egyesz ugy nez ki hogy pl. a login egy index.php?command=login oldallal jon le es ijenkor ez https, de mondjuk az index.php?command=vendegkonyv csak sima http, es mindket oldalnal a kepek stb. mind arrol a masik static aldomainrol jonnenek le de a php -ben ott nincs benne hogy https legyen.

A felosztast igy kepzeltem el legegyszerubben :) ha a fo gep bedoglik akkor bedoglott (ez ugyanugy gond lenne akkor is ha nem vagyom szet az egeszet 2 reszre) ezel nem foglakozom nagyvonaluan :) A static -ot meg ha ugyjon egyszeruen a DNS kiszolgalonal roudrobin -nal (gondolom igy hivjak, irjak) ha aktualis lessz valamenyire tudom tehermentesiteni ...Meg talan a kiesesektol is valamelyest kivedeni ...

En egy gepre tennem az osszes https tartalmat. A yahoo webmail pl. ugy csinalja, hogy a login/pw-t https-en kuldi el, majd visszakuld sima http feluletre. Naluk tehat nem kell semmilyen 'sallangot' https ala tenni. Ha nalad is csak authentikalni kell ssl-en, akkor egy kis atszervezessel sokkal egyszerubb lehet a setup-od.

SPAMtelenül - MX spamszűrő szolgáltatás, ahogyan még sosem próbálta

En is ugy indultam neki hogy csak az login/pw -t kuldtem https -en de aztan attettem az egesz index.php?command=login -t a https -re meg a regisztracios oldalt meg meg par erzekenyebb oldalt, arra szamitva hogy a firefoxnal pl. az URL elott megkapom azt a kek vagy zold mezot ... De a sallangok miatt nem mukodik... Ha pl egy sima txt fajlt nyitok meg akkor mukodik is mert ott ugyebar nincs semmi sallang csak maga az az egy fajl.

Nekem az a legfobb gondom ezel az hogy az egesz index.php?command=valami_paracs szeru oldalakbol all

Mna az a .php nem okos dolog, ha sok latogatora szamitasz, en mar most Javaban (esetleg .NET..?) gondolkodnek. PHP prociigenyesebb es sokat kell hegeszteni ahhoz, hogy skalazodjon, Java ebben startbol jobb. Persze erteni is kell hozza, ha ki akarod hasznalni az elonyeit...

----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"

Azert jopofa dolog sulhet ki abbol, ha kimered, hogy hol mennyi idot tolt el a rendszer, mire a kliens megkapja az adatot. Lehet, hogy a script 'egy csomo' ideig var, hogy megkapja az adatokat a backend-tol. Masreszt, ha sebessegre gyursz, akkor hasznalhatsz a php-hoz opcode cache-t. Te amugy vegeztel php vs. java osszehasonlitast? Csak mert a java (is) bytekod, tehat ebbol a szempontbol forma-forma (elvileg)....

SPAMtelenül - MX spamszűrő szolgáltatás, ahogyan még sosem próbálta

A prog.hu-n vegzett egyszer az egyik tag egy osszehasonlitast, sima PHP vs Java kozott sebessegben par nagysagrendig kulonbseg jott ki. itt talaltam egy osszehasonlitast hasonlo eredmenyekkel.

Lehet PHP-t gyorsitani mindenfele csodaval, erre irtam, hogy sokat kell hegeszteni, mindenfele 3rd party cache-t meg optimalizalot kell telepiteni. Ez nekem gany megoldasnak tunik, tobb munka van vele, attekinthetetlenebb, megbizhatatlanabb a sok, kulonbozo forrasbol szarmazo komponens miatt. Pl. eleg ciki, amikor eAccelerator atkuldi a kliensnek a sima PHP kodot...:^| Javanal csak telepited a JRE-t es belovod a parametereit.

De valoban lehet, hogy nem az uzleti logikaban lesz a szuk keresztmetszet...

----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"

Te komolyan egy for ciklusra alapozva mondod, hogy a Java nagyságrendekkel gyorsabb?

A linkelt oldalon a kod amivel teszteltek azert tobb egy for ciklusnal...

A Java nem csoda, hogy gyorsabb az oop-ben, hiszen eleve arra készült a PHP meg csak az 5.x-ös szériától tudja.

Kit erdekel a miert..?

----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"

Jó igazad van nem egy sima for ciklus. Létrehoz ~4.000.000 objectumot amiket listára feltesz, ezt nem nevezném életszerű tesztnek. A teszt nem foglalkozik a memória felhasználással, a kód fordítás sebességével, ...

"Kit erdekel a miert..?"
Ez kb. olyan mintha kijelentenéd, hogy a motorbicikli azért jobb az autónál, mert kevesebb kereke van, ez is szempont, de nem az egyetlen.

Off

"Kit erdekel a miert..?"
Ez kb. olyan mintha kijelentenéd, hogy a motorbicikli azért jobb az autónál, mert kevesebb kereke van, ez is szempont, de nem az egyetlen.

Ha ket alma kozul kell valasztanom, nem erdekel, hogy az egyik azert nem edes, mert Bulgariaban rovid volt a nyar...

----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"

és ugye akkor a pénzügyi része: mi az olcsóbb: egy java fejlesztő, vagy egy php fejlesztő plusz kicsit több gép...

facebookék is megmondták, hogy lehet, hogy szar a php, de olcsóbb a php fejlesztő, és még úgy is jobban jönnek ki, ha több gép kell. plusz csináltak hihopot is

Igazából a "Jesszusom" nem konkrétan arra vonatkozott, amit mondtál, hanem a hozzáállásra és a hasonlítgatás módjára.
Egyrészt miről is beszélünk? Java? Java Applet? Javascript? JSP? Mindegyik lehet jó, mindegyik lehet rossz. Ennyi infó alapján, amit kaptunk, eldönteni, hogy mi lenne a jobb!? Ez szerintem még kevés ahhoz, hogy konkrét véleményt mondjon az ember... Tehát értsd úgy, hogy az nem "tetszett", hogy ennyi infó alapján máris véleményt mondtál.

Ui.: azért vicces dolog, mikor pl az egyre terjedő Atom(szar) procis gépek AJAX -os és JavaScript gyűjteményes oldalak láttán már dobják is a hátast. Java Appletekről ne is beszéljünk... Főleg mikor a user nem érti, hogy mi az az ablak az orra előtt, és mit miért kellene engedélyeznie, meg mit honnan töltsön le!? :P És mé' nem jelenik meg semmi?
Mint korábban írtam, mindegyiknek van előnye, hátránya - de ennyi infó alapján én még nem döntenék egyértelműen

+1 a proxynak. a statikus allomanyokat ki lehet szolgalni egy az apache-nal gyorsabb kiszolgaloval, mint pl az nginx vagy thttpd. ez futhat azon a gepen is, amivel a dinamikus oldalakat generalod csak mas porton. a proxy meg cache-elje el oket jo sokaig. igy kesobb, ha tobb penzetek lesz a projektre vehettek meg egy szervert a proxy moge es eloszthatjatok a terhelest a ket gep kozott.
a memcached is hasznos dolog am, kesobb ennek is lehet dedikalt gepet uzembe helyezni, aztan a db-nek is, stb...

udv, sbalazs.

luxus vagy sem, tobb frontend eseten celszeru kozos helyen tarolni a mar legeneralt oldalakat, adatbazis resultset-eket, satobbit. persze ki lehet ezt a feladatot osztani az egyik frontendnek is, de akkor meg a loadbalance-ot nehez megoldani, hiszen az egyik vas jobban lesz terhelve a tobbitol erkezo cache query-k altal.

>,majd bedobni a 'kozosbe'.
ezt sajnos nem tudtam ertelmezni. :(

udv, sbalazs.

a memcached is hasznos dolog am, kesobb ennek is lehet dedikalt gepet uzembe helyezni

Memcached-nek tok ertelmetlen dedikalt gep, keveset hasznal a procibol. Az olyan gepekre szokas telepiteni, amelyeken van szabad RAM...

----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"

>Memcached-nek tok ertelmetlen dedikalt gep, keveset hasznal a procibol.
ez volna amiert ertelmetlennek tartod a dedikalt cache szervert? nem gondolod, hogy attol meg, hogy egy masik gep elbirja ezt a feladatot is - egy vagy tobb mas mellett - nem ez a legmegbizhatobb megoldas?

nem azt irtam, hogy a keves penzzel indulo webapphoz allitsanak uzembe plusz egy vasat, sot irtam is, hogy kesobb johet jol. szvsz nem szerencses tobbfele szolgaltatast egy gep nyakaba akasztani, mert:
1. ha kiesik a gep, akkor vele a tobb funkcio is kiesik.
2. memcached-nek memoria kell, masnak inkabb proci, megint masnak i/o -> megis mennyibe kerul osszedobni egy(!) olyan gepet, ami mindezeket maximalisan es megbizhatoan nyujtja?

udv, sbalazs.

Vegeredmenyben azthiszem ertem a memcached lenyeget, es akkor ezt a logikat kovetve valoban ugy latom enis hogy ha valamikor ha valoban beindul az oldal akkor lehet hogy majd erdemes lessz egy 3. gepet beuzemelni ami pl nem muszaly hogy prociban stb valami csucsmodel legyen csak legyen benne sok sok ram egy kis hardal amin valojaban csak az oprendszer van. Talan meg valami olcsobb hasznalt vas is megtenne...

Ha elromlik, stb. vegeredmenyben minden megy tobabb csak a lassabb lesz az egesz. Jol ertem?

Tehat ha ilyen memcached dologban gondolkozok akkor elso kerben a sebesseget a jo sok rammal birom majd novelni vagy ujabb memcached gep bevezetesevel.

A "statikus" gepre vajon mit tegeyek? Ha mar irtam hogy ott foleg parszaz kilobajt nagysagu kepek lesznek mongyuk ugy 300.000 drb. Azokat hogyan erdemes tarolni? A fajlrendszerben szetdobalva sok sok mappaba vagy tegyek arra is egy mysql -t es ott is memcacheljem a dolgokat?

Folosleges a memcached kedveert dedikalt gepet beallitani. A danga-sok (ok csinaltak a memcached-et) azt mondjak, hogy van van egy (mar hasznalatban levo) geped, amiben van szabad ram, akkor dobja fel ra memcached-et.

Ha elromlik, stb. vegeredmenyben minden megy tobabb csak a lassabb lesz az egesz. Jol ertem?

Lassabb, mint amilyen lehetne, de nem lassabb, mintha nem lenne ott a cache.

A fajlrendszerben szetdobalva sok sok mappaba vagy tegyek arra is egy mysql -t es ott is memcacheljem a dolgokat?

Elobbi. Kepeket ne tegyel mysql-be, csak a hivatkozasukat. A filerendszer azert gyorsabb szokott lenni, mint az sql szerver. Az pedig nagyon fontos, hogy a nagy halom kep ne 1 konyvtarba legyen behanyva, hanem strukturaba szervezve, pl. a/ab/abc/abcdefg123.jpg

Ha en csinalnam a nullarol, akkor a kepek nevei szamok lennenek (pl. 123456.jpg), es ugy hasitanam a neveket, hogy egy dir-ben max. 100 bejegyzes legyen. Pl. 10000/100/15.jpg vagy 10000/1500/1526.jpg

A kepeket folosleges memcache-elni, imho azzal jol elboldogul egy pehelysulyu webszerver, esetleg a rev. proxy.

SPAMtelenül - MX spamszűrő szolgáltatás, ahogyan még sosem próbálta

Most kb. éppen a képek tárolásánál tartok, vagyis azt a részt irom. Igen azt tudom, irtam is hogy nem egy hanem sok sok konyvtarba rakom. Akkor fájlrendszerben lessz tárolva. Pl. valami ilyesmi lessz: ab/cd/ef/gh/ij.jpg ahol a betuk egy-egy szamjegy igy tudok tarolni pl. 9999999999 kepet es a "fa strukturahoz" szepen csak beszurom a / jeleket. a szamot meg az sql auto incrementje adja majd meg ...ahol letarolom a kepek neveit...

Vagy ab/cd/ef/gh/ij,jpg helyett inkabb abcd/efgh/ij.jpg legyen? Ha a konyvtarban csak ujabb konyvtarak vannak akkor is csak max 100 legyen vagy ott lehet tobb is?

A betukkel az lehet a gubanc, hogy egyenetlen eloszlas is letrejohet. Pl. ha sok i*jpg-ed van, de csak keves o*jpg, akkor az 'i' konyvtarban egy nagy halom entryd lesz, mig az o alatt keves. Ha szamokat hasznalnal, ott nem lenne ilyen problema, mert barhol max. 100 lenne. A 100 amugy hasrautes alapjan jott, siman jo lehet a 256 is.

SPAMtelenül - MX spamszűrő szolgáltatás, ahogyan még sosem próbálta

Nem betukre gondoltam hanem szamokra vagyis szamjegyekre csak nem akartam x -eket vagy ? jeleket rakni ...szamjegyek lesznak mert a fajlnevek eleve egy mysql tablaban lesznek letarolva a kuncs is szam auto increment es akkor csak stringe alakitom es a megfeleo hejekre beszurom a / jeleket es mar meg is van a fajlrendszerben a heje a kepnek...

kepek:
id | nev | akarmi tobbi
------------------------
1 | 00/00/00/01.jpg| xxxxxxxx
2 | 00/00/00/02.jpg| xxxxxxxx

Ha igy tarolom akkor a dinamikus gep egyszeruen csak lekerdezi a nev mezot (SELECT nev FROM kepek WHERE id = 2) es meg a / jeleket sem kell beszurkalni neki a nevbe...
a html -ben meg valami ilyesmi lessz <img src="static.foo.bar/00/00/00/02.jpg">

De ahogy elneztem a pound -ot meg azt sem muszaly megcsinalnom hogy kulon aldomain -t hozok letre csak egyszeruen a *.jpg a "statikus" gepen levo nginx -en marad egyszeuen... Vagy ez igy nem all?

egyszeruen csak lekerdezi a nev mezot (SELECT nev FROM kepek WHERE id = 2) es meg a / jeleket sem kell beszurkalni neki a nevbe...

jonak tunik, csak utolag mar nehez lesz igy atdizajnolni a konyvtarhasitast (ha egyaltalan szukseges), ha a path is a tablakban van. Azaz, en a path infot kihagynam a nev mezobol.

De ahogy elneztem a pound -ot meg azt sem muszaly megcsinalnom hogy kulon aldomain -t hozok letre csak egyszeruen a *.jpg a "statikus" gepen levo nginx -en marad egyszeuen... Vagy ez igy nem all?

De all. Az nginx-ben (mindentol fuggetlenul) erdemes egy kulon vhost-ot definialni a statikus cuccoknak (static.aaa.fu), de a pound (ha jol ertettem a kerdesed) kepes az url alapjan a megfelelo helyre (pl. a kepeket tarolo nginx-ed fele) tovabbitani a kereseket. Pl. minden jpg file a static.aaa.fu-ra/rol.

SPAMtelenül - MX spamszűrő szolgáltatás, ahogyan még sosem próbálta

Igen ezt kerdeztem, de akkor attol fuggetlenul hogy a pound megtudna csinalni kulon static.foo.bar nelkul is, megis inkabb legyen meg az a static.foo.bar aldomain es a html fajlokban mar renedssen arra hivatkozzak? <img src="http://static.foo.bar/00/00/00/01.jpg">

utolag mar nehez lesz igy atdizajnolni a konyvtarhasitast (ha egyaltalan szukseges), ha a path is a tablakban van

Szerinted lehet ra szukseg hogy modositani kell a konyvtarhasitason? Ha meg egy gep nem birja elvinni a statikus reszt akkor mar ugyis annyira beindul az aldal hogy nem lessz gond meg egy gepet berakni statikusnak es akkor a pound csak elossza a terheles egy reszet az ujabb statikusra ... Vagy bevezetek egy statikus kiszolgalo azonosito mezot az sql tablaban es a kepek egy reszet atrakom az ujabb gepre ...

(SELECT nev FROM kepek WHERE id = 2) egy ilyen egyszeru lekerdezest is erdemes memcachelni? Az id a primary key es kb. 4-5 sor a valasz a lekerdezesre vagyis 4-5 kep. Vagy folosleges mert ezeket a mysql is konnyen kezeli?

megis inkabb legyen meg az a static.foo.bar aldomain es a html fajlokban mar renedssen arra hivatkozzak?

imho igen

Szerinted lehet ra szukseg hogy modositani kell a konyvtarhasitason?

Ha jol megcsinalod, akkor valoszinuleg nem. De ha valamiert megis, akkor nehezebb lesz a dolgod.

(SELECT nev FROM kepek WHERE id = 2) egy ilyen egyszeru lekerdezest is erdemes memcachelni?

Mindent erdemes (amit 1-nel tobbszor lekerdeznel).

SPAMtelenül - MX spamszűrő szolgáltatás, ahogyan még sosem próbálta

Na akkor a static -ra majd a nginx lessz a http keresek kiszolgalasara. Probakeppen mar fel is raktam az itthoni gepemre es majd tanulmanyozom. Ha jol sejtem siman megfer most a apache2 mellett probakeppen, es az nginx lessz a static.valami.com mig az apache2 lessz a valami.com es a secure.valami.com

Reverz proxy -nak mit ajanlasz? Debian lessz a gepen mert az itthonin is az van.

Megneztem,beleolvastam a pound-ba szoval akkor a pound az amihez a ugyfelek csatlakoznak es ha statikus dologrol van szo pl. *.jpg stb. akkor a keres magad a statikus gepen es a pound atadja a kerest az nginx -nek ha meg https akkor kibontsa es megy a pasik gepre a keres tovabb ... Ha meg csak szimpla *.php akkor meg csak atdobja a masik gepnek a kerest. Emelett a statikus gep meg besegit a dinamikusnak a memcached -del...

Igy ezzel az elkepzelessel ha jol sejtem (valamikor, ha ugy jon) egyszerubben be tudok dobni meg ujabb backend webservert is. Ha a dinamikus gep kevesnek bizonyul...

( jusztin | 2010. 03. 07., v – 14:42 )

Megsaccolasom szerint (ha az egesz bevalik, mert kulonben az egesz targytalan) ...

A static -on kb 100.000-300.000 kep lenne mondjuk ugy 200kByte nagysaguak, ezekbol lekert oldalankent az oldal jellegetol fuggoen 0 tol max 4-5 kep lenne. A lekert oldalak tobbsege ilyen 4-5 kepes oldal lenne...

A static -on lennenek meg az oldalak kinezesehz a sallangok is (css, js, jpg, png, gif, ...)

A masikon a fo gepen lenne a kb. 10.000 felhasznalo, aki kattingat ide oda :) Es modjuk peldanak okaert kulonbozo "halakat nezeget" azok lennek a static -rol azok a kepek.

Mivel kezdo vagyok, az az elkepzelesem hogy igy szetvalasztva az egeszet statikus es dinamikus resze ha ugyjon kulon kulon mindkettot konyebb lesz tehermentesiteni vagy redundansa tenni, es ez foleg a static -ra lenne konnyu, mivel ott aranylag ritkan valoznak a dolgok ...mongyuk ra hogy csak (lassan) ujabb kepek kerulenk fel es a regiekbol idovel le is kerulnek ...

A dinamikus reszet, a fo servert meg ha ugyjon megtoldom egy kulon mysql szerverrel es 2 gepbol all majd, a meglevo marad a mindenes a masik meg atveszi tole a mysql terhet.

Nagyon buta ez az egesz elgondolasom?

Mongyuk 2 ilyen vagy ehhez hasonlo gepbol megoldhato lenne ez? HP PROLIANT 360 G3 I-XEON 2800x2 8192GB RAM

Mongyuk 2 ilyen vagy ehhez hasonlo gepbol megoldhato lenne ez?

A tarskereso oldaladon levo fel TB-nyi kep onmagaban nem sok info, inkabb a konkurens latogtok szamat kene megbecsulni. Ha pl. napi 200 latogatod van, akkor a desktop pc-den futo VMware image is elviszi. Ha masodpercenkent van 200 latogatod, akkor mar kell az a 2 HP gep :-)

A statikus tartalom kulonvalasztasa mindenkeppen jo otlet. Altalaban igaz az, hogy jol osszerakva a dolgokat egy szerenyebb kepessegu konfigbol is sokat ki lehet hozni, mig ha valahova gyenge lancszem (=rosszul konfiguralt cucc) kerul, akkor 2 paripa gep is csak karesz teljesitmenyt produkal.

Azt mondom, probald ki azt elso korben, hogy a 'static' gepre teszel egy lightweight webszervert (ld. fentebb, esetleg lighttpd) + teszel ra memcached-et. A masik gep kezeli a dinamikus tartalmat (php+mysql), es hasznalja a masik gepen levo memcached-et. Ehhez persze a php cuccokat is modositani kell(het, de megeri, mert a db load-ot nagyon le tudja vinni).

A dinamikus reszet, a fo servert meg ha ugyjon megtoldom egy kulon mysql szerverrel es 2 gepbol all majd, a meglevo marad a mindenes a masik meg atveszi tole a mysql terhet.

memcached. Nem kulon gep, hanem memcached. Ha vazolod, hogy milyen adatok jonnek majd a db-bol, akkor megmondom, be tudod-e tenni memcached-be.

SPAMtelenül - MX spamszűrő szolgáltatás, ahogyan még sosem próbálta

Nem tarskereso oldalrol van szo :) A kepek valojaban arucikkek kepei. Ha igy nezzuk egy internetes aruhazhoz inkabb hasonlit mint egy tarskeresohoz.

A statikus resznek vegeredmenyben arra gondoltam hogy nezek valami szolgatatot a kezdetekhez itt hazamban volna is egy ami valami gyos cluster -ra rakna fel ha statikus a dolog szoval az nem apache, es ha alakul akkor idovel lecserelnem egy sajat gepre. Gondolom megoldhato lenne hogy a masik gep valahogy felrakja a kepeket (talan ftp -vel) arra a clusterra. Az csak uj arucikk bevitele kor tortenik es ha az arucikk torlodik ... Mongyuk saccoljuk meg hogy percenkent 1 insert es 1 delete. Azt nezzuk ugy mintha egy kozonseges tarhely szolgatato lenne ...

A 2 hp geprol a kerdest meg inkabb megforditom, ha beindulna egy ilyen oldal akkor az a 2 gep kb mennyit birna el igy latatlanbol? Mongyuk hogy 200 an nezik az oldalt egyszerre folyamatossan? Mert akkor lehet hogy erdemes lenne mingyart igy indulni...

( eax | 2010. 03. 07., v – 15:31 )

Vagy vegyel az amazon ec2-nel 3 db small instance-t (egy proxy, egy webszerver, egy db), az kijon mindennel egyutt evente kb. 2000 usd-bol, es ha keves, akkor akar terhelestol fuggoen automatikusan, scriptbol is novelheted. A static motyo meg mehet cdn-re (pl. amazon cloudfront).

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

( zeller | 2010. 03. 07., v – 16:03 )

A statikus/dinamikus szétválasztás dicsérendő elképzelés. A statikus tartalmakat kitoló vas várhatóan I/O-ban lesz jóval terheltebb, cpu-ban kevésbé, ergo ott lehetne termináltatni a másik kiszolgálóhoz tartó ssl-es forgalmat, hogy az adatbázisos oldalnak (ahol a CPU-terhelés alapból nagyobb) az ssl-lel ne kelljen foglalkoznia.

A static.foo.bar helyben végződik, a dynamic.foo.bar is oda (egy másik IP-re) érkezik, de ott csak az ssl ki/be csomagolás történik, a kibontott http-kérést dobja tovább a másik gép felé, ahol a dinamikus tartalmakat generáló webszerver csücsül, sima http-n. A static.foo.bar lóg az interneten, egy másik hálókártyáján meg felhúzol egy 10-es privát címet, és arra dugod rá a dinamikus cuccot generáló gépet.
Vagy a másik lehetőség, hogy a static-on fut a webszerver, de szintén külön lábára rádugva a másik gépre kerül az adatbázis, amiből az oldalak tartalmát generálod. (azaz a webszerver és az adatbázis kerül két vasra szétbontásra).

Akkor ha jol ertem a http://static.foo.bar es a https://secure.foo.bar keresek is ugyanarra a "statikus" gepre erkeznek csak kulon ip cimre de pl lehet fizikailag ugyanaz az eth0 peldaul. A static.foo.bar -t peldaul az nginx szolgalja ki, mig a https nel valami szolgaltatas kibontja az ssl -t es az eth1 -en atkuldi a "dinamikus" gepre amin az apache2, php, mysql, postfix, stb. van?

Mi az ami kibontja az ssl-t? :)

Es persze a "statikus" gepre meg megy a memcached ami az eth1 porton figyeli a "dinamikus" kereseit...

A "dinamikus" gepen szinten pl. az eth0 az interneten van mig az eth1 a masikakkal Crossover -rel oszevan kotve.

Mi az ami kibontja az ssl-t? :)

A reverse proxy, frontend, ami lehet maga az nginx is.

Es persze a "statikus" gepre meg megy a memcached ami az eth1 porton figyeli a "dinamikus" kereseit...

Memcached-be bepakolhatod a statikus tartalmat is, hogy a memoriabol rantsa elo az ngin-x, ne a lemezrol. Es nem kell foltetlenul (csak) a statikus gepre rakni memcached-et...

----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"

( Fisher v | 2010. 03. 08., h – 10:23 )

Nos, leginkább ötletelésnek egy olyan, amit nemrég raktam össze: 


                                        --------
               /--[apache http, php]---|mysql   |
[apache, https]---[apache http, php]---|nfs     |
               \--[apache http, php]---|miegyéb |
                                        --------

Az első apacs csinálja https-http fordítást, a terhelés elosztását, illetve cache is van benne a css, jpg, png, js, azaz a statikus fájlokhoz, az alkalmazás gépek mögött meg van egy mysql db és egy nfs szerver. Elég jól skálázható, de az látszik, hogy az első apacsot le fogom majd cserélni, mert nem igazán loadbalancernek való.

Leginkább azért van több alkalmazásszerver, hogy az esetleges redszerfrissítéseket esély legyen megcsinálni leállás nélkül.

( sibidiba | 2010. 03. 08., h – 20:14 )

Biztos vagy abban, hogy ez így jó neked?

Az optimalizáció első számú főszabálya, hogy ne csináld. A második szabálya - csak haladóknak - pedig az, hogy Tényleg ne csináld (még).

Ameddig nem tudod milyen típusú terhelésed lesz, hogy hol lesznek a szűk keresztmetszeteid, ritkán van értelme ilyen megoldásoknak, mert csak nem létező problémákat szülsz vele, mint amit te is írsz.. Inkább megoldanám egy szerveren a tényleges feladatot először, és utána tenném fel a kérdést 1) meddig akarom az elkészült oldalt skálázni (ekkor már ki is mérheted ezt) 2) Hogyan tudom értelmesen, szépen ezt elérni.

Ha már van pénz/igény két szerverre, inkább hearbeat/backup-ban gondolkoznék, az legalább valami többet is nyújt.

--
The Net is indeed vast and infinite...
http://gablog.eu

Vegeredmenyben elso korben az egesz szetvalasztasa a statikus es dinamukus reszre ugynezem elkerulhetetlen lessz. Mert igy tudom legegyszerubben el legolcsobban is megoldani az egeszet. Foleg azert is mert igy a sok sok kep tarolasat es kiszolgalasat ki tudom tenni egy masik gepre vagy (esetleg) egeszen masik szolgaltatora is es a tobire igy nagyobb eroforras marad ...

Masodsorban arra gondolok hogy ha mar a tervezes, keszites folyaman is figyelembe veszem egy esetleges bovites lehetoseget akkor ha valamikor elkerulhetetlen lessz, sokkal konyebb lessz megoldanom ...

"Az optimalizáció első számú főszabálya, hogy ne csináld. A második szabálya - csak haladóknak - pedig az, hogy Tényleg ne csináld (még)."

Csak epp ez nem optimalizacio, hanem architektura tervezes. Arra egy masik szabaly vonatkozik, ami valahogy a kovetkezokepp hangzik: "ha nem csinalod meg idoben, akkor utolag mar ordas szopas lesz".

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

Ez igaz, de felesleges bármilyen architektúrát tervezni amíg a programból csak annyi van meg, hogy egy nagy látogatottságú portál lesz (egyszer/majd/valamikor/talán). Persze lehet, csak az ne arról szóljon, hogy két vagy három sql szervert tegyek a rendszerbe?! amikor még egy select sincsen kész.

Legyen meg a program, jól elszeparált részekkel, hogy egy-egy módosítást könnyen át lehessen vezetni az egész programon. Pl. a képek elérési útját egy meghatározott függvény generálja, így ha másik szerverre kerülnek a képek könnyű módosítani
Ilyeneket van értelme filózni

Szerintem a fo hangsuly eppen ilyeneken is van. Visoznt az hogy 2 gep lessz az mar most nyilvanvalo es az a kerdes hogy mit es hogyan osszak szet. Es melyik gepre mi keruljon. Nagyvonalakban.

A nagyvonalak alatt azt ertem hogy pl nem foglalkozunk azzal hogy levelezes is lessz, meg monitorozas, meg kitudja mi nem kell meg majd oda ...Tulajdonkeppen most ezt a kepes reszet csinalom vagyis mar nagyabol az is megvan es ebben ezert is jott most elo ez a szetvagasos dolog. Gondolom es itt megint hozzateszem hogy ha beindul :) akkor lessz majd kismilio mas kisebb nagyobb nem elorelatott gond es baj, ezt viszont mar most latom es ugy nez ki aranylag jol es konyen megoldhato ezzel a szetvagassal akkor ugyerzem miert is me most oldjam meg? Foleg tekintettel arra hogy amit eddig csinalta php+mysql az kozonseges ingyenes tarhejre is elfert. Ezert is irtam hogy eleg kezdo vagyok ilyesmiben.

Igen sajnos az is igaz hogy irtam: egyszer/majd/valamikor/talán de azert egyreszt remenykedni kell, masreszt meg nem indulhat neki az ember egy ilyen munkanak ugy hogy ugysem lessz belole semmi mert akkor nem is kelett volna nekifognom, meg ide irni sem, mert minek idegesitesk itt segitokesz embereket egy olyan valamivel ami nekem pl tul nagy falat, vagy egyszeuen csak majd nem jonnek ossze a dolgok...

Azert egy ket select -tol mar tobb keszen van ... mongyam ra hogy ugy fele az egesznek, es mar jooideje az osszes szbadidom csak erre a projektre aldozm.

Meg egy kis magyarazat:

Az egesz szetvagas otlete onnan indult hogy a savszelesseget igy talan megbirom duplazni (igaz ha az itteni elkepzelest kovetem akkor es elesik) mert a sok kep letoltogetese nem veszi el a savszelesseget, es arra gondoltam hogy az oldalak is gyorsabban megnyilnak majd az ugyfeleknel, mert csak egyreszt 2x savszelesseg lenne meg a 2 gepen a terheles is kisebb lenne.

Ha azt nezem hogy legyen 100Mbit a savszelesseg egy gepen az legyen ugy 10MB masodpercenket ugyebar ezt egy szinte akarmilyen mep is ki tudja szolgalni, addig az ideig mig a disk feje meg odaert a megfeleo adathoz az nem nagy ido azt konyen kivarja az ugyfel :) Kozben a gep azert foglalkozik a tobbi keres feldolgozasaval, meg stb ...
Vagyis ha ugyjon ott a teljes savszelessegel mehetnek ki a kepek, es az a savszelesseg akkor nem terheli le a masik gepet. Gondolom ennek a gepnek meg ebben az esetben is lenne szabad kapacitasa (a kimeno savszelesseg) melett masra is ...Pl lehet rajta hej a menteseknek...De ezt most hagyuk figyelmen kivul, majd ha aktualis lessz.

Igy a masik gepen amit itt dinamikusnak nevezek maradnanak a php fajolk ami vegeredmenyben nem nagy meret, meg a levelezes (ezzel nem foglalkozok most), meg persze a mysql igy a diszket (diszkeket) foleg az sql hasznalna es nem zavarna a kepek lekerdezgetese...

Persze mint irtam tapasztalatom nincs, es foleg csak talalgatok, meg probalok osszeolvasni dolgokat a netrol...

Az egeszbol csak annyi a nagyon lenyeges dolog hogy mar az indulo oldalnak jobbank kell lenni a konkurenciatol :) Es menet kozben is SOKKAL kevesebb gond szabad hogy legyen vele mit a konkurencianak volt, foleg mig nem szoknak oda az emberek, foleg nem lenne szabad akadozni - lassunak lenni. Na es persze minnel kevesebb penzbol :) Ezert is irom en es nem fogadtam fel valami ceget aki megirta volna az egeszet. Es ezert nem fogok managed servert berelni vagy mittudom en odadni valami segnek hogy ez kell hogy mukodjon es tegek fel annyi gepre meg ugy ahogy csak akarjak ...

Szoval olyan kezdo megoldas ...Marad a munka meg az internet...Meg a segitokesz emberek a tanacsival. Akik mar eddig is sokat segitettek, KOSZONOM!!!
Pl. a memcached -rol eddig meg csak halottam es ugy nez ki hogy hasznalni is fogom a php-ban.

A statikus tartalmat könnyen lehet skálázni. Mivel portálról van szó, alighanem lesz egypár viszonylag népszerű része, ami a lekérések bő felét - vagy akár többet is - viszi mondjuk egy-egy órában, ám ennek az adatmennyisége pár tíz max. pár száz kép. Ezt egymás mellé tett apacsokkal (vagy inkább thttpd, lighthttpd és társai) remekül ki lehet tolni, a terheléselosztást pedig eleinte rá lehet bízni a DNS-re (később, ha dől a lé, akkor lehet gondolkozni okosabb lb megoldáson).
A php-mysql páros pedig... ez csak akkor fog látszódni, ha már kész az alkalmazás, de valószínűleg az lesz a legegyszerűbb, ha évente új vasat tolsz alá, ugyanannyi pénzért 1.5-2x akkora teljesítményűt.
Amiért _én_ elkerülném a memcahed és társait (pláne webszerver oldalon): plusz réteg ami elromolhat. És ami elromolhat, az el is romlik (bug, emberi hiba, stb. miatt). Minél egyszerűbb valami, annál nehezebben romlik el.

Amiért _én_ elkerülném a memcahed és társait (pláne webszerver oldalon): plusz réteg ami elromolhat. És ami elromolhat, az el is romlik (bug, emberi hiba, stb. miatt). Minél egyszerűbb valami, annál nehezebben romlik el.

nem ismered a memcached-et igaz? En a daemontools-szal futtatom, nincs rajta konfigolni valo, elinditod aztan el is feledkezhetsz rola (kb. mint a dnscache-rol). Ha meghal a processz, akkor a daemontools ujra elinditja, tehat az mindig menni fog, amig a gep szalad. Plusz retegnek ugyan plusz, de alkalmazas (itt: php) oldalon nagyon egyszeru a hasznalata, es ha ha valami ugyes db absztrakciot hasznalsz, akkor gyakorlatilag transzparens a dolog. Nyerni pedig nagyon sokat lehet majd vele, nem kell az sql szervert lecserelni 2x akkorara. Olvasd csak el a livejournal success sztorijat...

SPAMtelenül - MX spamszűrő szolgáltatás, ahogyan még sosem próbálta

ha valami ugyes db absztrakciot hasznalsz, akkor gyakorlatilag transzparens a dolog

Erre mondasz valami peldat? En eddig ilyesmit nem hogy nem hasznaltam de meg nem is nezegettem ilyesmiket. En eddig mindeg direkt hasznaltam a mysql -t a php -bol. Ez valami kozbeekelodo ize lehet gondolom .... Szerinted melyiket nezzem meg?

Sot akkor mar gondolom a kwrite -nel is van valami jobb szerkeszto amivel azeket a php es html fajlokat erdemes szekeszteni? Persze amiben tudom hasznalni a mar megirt fajljaimat is, mert nem szeretnem az egeszet elorol kezdeni... Mongyuk ra valami olyasmit kepzelnek el mint a mysql -nel az a MySQL Workbench ...csak valami szovegszerkesztovel es esetleg ha kozben latnam a megirt dolgot egy bongeszoablak szerusegben css -el egyutt :)

olyasmire gondolom, hogy irsz egy wrapper fv-t az sql lekerdezesekre. pl. http://pastebin.com/EKcx3Jrp

Azaz megnezi, hogy az adat a cache-ben van. Ha igen, akkor keszen vagyunk. Ha nem, akkor lekerdezzuk az sql-bol, ill. betesszuk a cache-be.

Meg annyi, hogy update/delete eseten a megfelelo entry-t torolni kell a memcached-bol. Nem egy nagy ordongosseg...

a kwrite -nel is van valami jobb szerkeszto amivel

En vi-jal szerkesztem a file-t, es firefox-szal nezem :-)

SPAMtelenül - MX spamszűrő szolgáltatás, ahogyan még sosem próbálta

Az egyik hozzászólásomban pont erről beszéltem én is. Ezt lehet/érdemes tervezni, még akkor is ha nincs megcsinálva. Ezt úgy értem, hogy a cache részt elsőre kihagyod. Vagyis minden esetben azt adja vissza, hogy nincs a cache-ben, így a program előbb készen lesz és ha szükséges hozzá lehet fejleszteni a cache-t, viszont ez már a program többi részére nézve nem jelent változást.

Igen ertem a logikat, meglatom, valoszinu hogy nem csak sql -t fogok cachelni benne ... Majd elgondolkozok ezen az egeszen meg de elsokorben az sql is jo, ha bar ha egy egesz oldalt betolok a cache -ba akkor ott (annal az oldalnal) mar az sql-t nem is kell kulon cachelni, es az az oldal meg gyorsabban letrejon akkor...

Ezzel az egesz memcaches dologgal csak az nem vilagos teljesen hogy ha van 2 gepen is memcache akkor azok gondolom egymassrol nem tudnak vagyis nekem tudni kell hogy mit leyik gepen cachelek ugye? Vagyis akkor ket teljesen kulonallo egymastol fugetlen cachem van ugye?

A masik dolog az hogy ahogy olvasgattam az nginx tudja hasznali a memcached -et viszont nekem kell az adatokat betoltenem a cacheba. Ezt jol tudom? Ha a statikus gepet teljesen kulonallokent kezelem a kepek ott lesznek a salyat fajlrendszereben ...Akkor vajon mivel es hogyan tolcsem fel a http keresektol fugoen a memcached -et? A keresket ugybar az nginx kapja meg megnezi a memcached -ben ott nem talaja es a fajlrendszerbol kiolvassa es kikuldi a netre de akkor mi rakja be a memcached -be?
Ha meg csinalok valami php megoldast ami valaszolgat a http keresre es ha nincs a memcachedben a kep akkor betolti oda akkor mar vegeredmenyben a netre is kitolhatja...
Letezik hogy ennyire nem ertem?

ha van 2 gepen is memcache akkor azok gondolom egymassrol nem tudnak vagyis nekem tudni kell hogy mit leyik gepen cachelek ugye?

A 2 memcached nem tud egymasrol, hanem a te memcached kliensed a lekerdezendo kulcsbol egy hasht keszit, es az alapjan fogja tudni, hogy mit melyik cache-ben kell keresnie.

A masik dolog az hogy ahogy olvasgattam az nginx tudja hasznali a memcached -et viszont nekem kell az adatokat betoltenem a cacheba.

Ez (http://www.igvita.com/2008/02/11/nginx-and-memcached-a-400-boost/) alapjan az URI szolgal kulcskent, azaz az oldalt magat cache-eli. Azert at kell gondolni, hogy az jo-e, ld. a cikkben...

SPAMtelenül - MX spamszűrő szolgáltatás, ahogyan még sosem próbálta

Igen nagyabol ertem is :)

Nalam a sessionid az cookie -ben van, emigy legyen pl. egy bejovo uzenet olvasasa egy ilyen url: index.php?command=read_messae&id=1 legelso lekereskor legeneralodik az oldal es egyeb letarolodik a memcached-ban is meg a neten megkapja az ugyfel is ugyebar. Legkozelebb ugyanaz a keres es persze ugyanazz a session alkalmaval mar a memcached-ben lessz az oldal es onnan kapja meg az ugyfel. Ha az ugyfel torolte az uzenetet akkor torlom a kesbol is.

Jol ertem a logikajat ugye? Nalam viszont ezzel az a gond hogy konkretan a html oldal felso reszeben es az alsoban is allandoan mas mas tartalom lessz meg akkor is ha o ugynazt az oldalt nezi meg pl egy konkret bejovo uzenetet nyissa meg tobbszor is. Es igy az allandan valtozo reszt vagy iframe vagy valami mas megoldassal kell akkor beraknom oda vagy lemondok az egesz oldal memcacheleserol. De peltaul mar akkor is elesik ha az oldal elejere teszek egy szamot hogy meg hany olvastlan uzenete van...Igy ha elolvas egy uzenetet is az oszes keselt uzeneteit torolnom kell a kesbol mert fent a szam mar nem fog egyezni ...Persze ajax -al is betolthetnem az ilyen dinamikus dolgokat ...Sot talan meg az lenne a legjobb viszont akkor sokmindent ujbol at kellene dolgozni ...

Lehet hogy nem kellene anyira elbonyolitani az egeszet? Van ra esely hogy mindenfele ilyen trukkozesek nelkul is elbirna az a 2 gep az egeszet (HP PROLIANT 360 G3)? Vagy arra kicsi az esely es elobb utobb megis muszaly lessz ezekkel foglalkoznom?

Nem kotelezo az egesz oldalt cache-elni nginx-szel, nyilvan lehet olyan dolog is, ami folyamatosan valtozik, es azt nem lehet cache-elni. (Az meg mas kerdes, hogy valoban nem lehet-e....)

En azt mondom, indulj el az sql adatok cache-elesevel, aztan nezd meg, hogy birja a latogatokat. Ha jo, akkor jo. Ha nem, akkor tovabb kell optimalizalni.

Az ajax jo, viszont megdob(hat)ja a szerver load-jat, ha sok kapcsolatot nyit a szervered fele a hatterben. (Es nyilvan nem a static.aaa.fu fele fogja).

A lenyeg az, hogy igyekezz modularisra epiteni a 'boltodat', mert akkor ha kimered, hogy az oldal eloallitasa soran x modulban szuk keresztmetszet van, akkor a tobbi komponens birizgalasa nelkul is at tudod dolgozni a problemas reszt.

SPAMtelenül - MX spamszűrő szolgáltatás, ahogyan még sosem próbálta

Koszi ertem mar hogy mi is az a wrapper :) Nem lett volna muszaly megirni de azert ezt is koszonom :)

Akkor maradok a kwrite -nel meg az iceweasel ... Mar megszoktam es akkor nem cserelem le masikra, habar en valami integralt valamire gondoltam, olyan minden egy programba, mint pl a win -re a Dreamweaver ami rendelkezik WYSIWYG szerkesztővel, habar arrol csak halottam hasznalni sosem hasznaltam ...

( wladek1 | 2010. 03. 08., h – 20:40 )

Nem olvastam el, mit irtak a többiek, de javaslom, hogy statikus tartalmakhoz, illetve konkrétan a webroot -hoz is nyugodtan szanj 1-1 Gb tmpfs -t, így aztán nem sok probléma lesz io -val. Tapasztalatból mondom, hogy ilyen esetekben egy másik vason futó SQL szerver terhelése is csökken. Azon nem gondolkoztam még, vajon miért is(semmi nem indokolja, a hálózati kapcsolat sem...).
Más esetekben: gyakori oldallekéréseknél nagyban megterhelő tud lenni, pláne egy rosszul beállított Apache2 -vel (inkább nginx, ha nagyobb terhelésre számítasz). 

die(DIE_HARD);

azenoldalamponthu

500GB gondolom nem lessz, az a szam egy esetleges maximum lenne, de gondolom akkor mar az sem lenne gond hogy ujabb vasat tegyek be az egeszbe. Elobb is hasznot kellene mar hogy termeljen :)

Utanna szamoltam a kepek nagysagank es ez lett az eredmeny:

1.) legyen oszesen 100.000 tetel es tetelezzuk fel hogy mindegyiknek van 4 kepe (lehet hogy eppen 4 lessz a maximum amit megengedek)
2.) minden egyes kep megvan 3 meretben a legnagyobbra engedjek meg 350kB a kozepsot en kicsinyitem le a feltoltott kepbol legyen 100kB a legkisebb meg legyen kb. 40kB
Az oszesen ugy korulbelul 196 Giga, legyen mongyuk 200G

A lekert kepek sem lessznek teljesen random eloszlasuak, vagyis lesznek amiket szinte sosem neznek meg, lesznek amiket gyakrabban kernek majd le. Na meg persze ezeknek a kepeknek a 2 lekicsinyitett valtozatat toltik le (azokat egyszerre minden kepnel, tehat egy oldalon akkor legyen 4 kozepes es 4 legkisebb) es a legnagyobb kepeket csak akkor toltik le ha az ugyfel rakattint a kisebb kepre az oldalon...

Feljebb emlitette az egyik hozzaszolo hogy a memcached -et is adjam oda a nginx -nek ami a statikus gepen a kepeket szolgalja ki de errol hirtelen meg nem talatam sok olvasni valot ....

location ~* \.(jpg|png|gif)$ {
access_log off;
expires max;
set $memcached_key $uri;
memcached_pass 127.0.0.1:11211;
error_page 404 = /fetch;
}

Csak ennyi eleg? Az a 2 sor? Es hogy kerulnek bele az adatok a memcached -be?

Egy masik dolog az is hogy a kepek szinte nem valtoznak vagyis amikor felkerulnek ott lesznek meg le nem torlodnek, es az egyes latogatoknal a bongeszo cacheli a kepeket es ujabb latogatas alkalmaval nem tolti le ujbol a kepet a kiszolgalo csak a http fejleceben dob neki egy valaszt hogy a kep nem valtozott ... Az apache ezt tudja is, en is megtudom csinalni ezt php+mysql de feljebb irtak hogy a kepekbol hagyam ki a mysql -t mert az folosleges oda ... Gondolom az nginx is tudja az ilyesmit :)

A 2 legkisebb kepet ugy gondoltam hogy mindeg ugyanabba a mappaba rakom mert ha az egyik kell akkor kell a masik is es igy talan jobban keznel lessz mig a harmadikat masik mappaba (esetleg valamikor masik diskre) hogy a kisebb kepek kozott ne zavarjon a helyfoglalasaval ...

Azt is gondolom hogy itt jol jonne a kepeknek egy SSD is (plane a 2 kisebb kepnek) de az csak ha mar jobban beindulna az oldal akkor lenne aktulais ...

( jusztin | 2010. 03. 09., k – 16:03 )

Egy picit mas dolog viszont az hogy az egeszet eddig ugy csinaltam hogy van egy index.php fajl es szinte minden ezzel kezdodik index.php?command=parancs&parameterek... Lattam is mar oldalakat amik szinten igy vannak megoldva, visoznt most igy fejlesztes kozben egyre csak ugy erzem hogy jobb lett volna ha mind kulon php lenne mongyuk login.php, logout.php, inbox.php stb...

Vannak itt valami alap iranyelvek amiket erdemes lett volna a legelejetol kovetnem? Nekem most van az az index.php abban van az oldal kinezese es a kulonbozo valtozo reszek attol fuggoen hogy az oldal mit csinal ugy includolom be? Pl index.php?command=login nal a bejelentkezo reszt inkludodlom be (persze sok mas aprosagot is).

A masik ut meg az lett volna hogy van a login.php es ebbe includodlom be a kinezetet pl a fejlecet lablecet meg ilyeneket es maga a bejelentkezes benne lett volna a login.php -ban.

Gondolom a dizajnt kellett volna valahogy szevegnom a logikatol de errol nem tudom semmit. igy ez elesik.

Konkreten az egesz gond ott jott elo hogy az index.php egy bizonyos reszen feldolgozom a $_GET['command'] tartalmat amitol fuggoen beincludolom a megfelelo reszt, legyen az mongyuk bejovo uzenetek olvasasa, viszont most kiderult hogy annak a beincludolt renszek modositani kellne az elotte mar legeneralt reszt igy a get command feldolgozasat elobbre kell tennem, viszont akkor meg az eddigi jo resze mozdul el ....

Megprobalom elmagyarazni:

index.php:
<head>
<title>oldal cime</title>
</head>
<body>
if($_GET['command'] = indulj)
include("indul.php');
</body>

indul.php:
<?php
echo "indulok";
?>

Na most viszont a title -be is jo lett volna beirni valamit (pl. indul - foo.bar) viszont arrol mar lekestem...Ha a GET command feldolgozasat egeszen a title ele teszem akkor azzal nincs gond de akkor meg valami ilyesmit kapok ami nekem nem tetszik:

index.php:
if($_GET['command'] = indulj)
include("indul.php');
<head>
<title><?php echo indul_fugveny_1();?></title>
</head>
<body>
<?php echo indul_fugveny_2();?>
....
<?php echo indul_fugveny_3();?>
...
<?php echo indul_fugveny_4();?>
</body>

indul.php:
<?php
function indul_fugveny_1()
function indul_fugveny_2()
function indul_fugveny_3()
stb
?>

Nemtudom menyire volt ez ertheto, es nem kell szintaktikailag nezni ... Csak a logikara akartam ramutatni...

Gondolom a dizajnt kellett volna valahogy szevegnom a logikatol de errol nem tudom semmit. igy ez elesik.

MVC: model-view-controller

Nemtudom menyire volt ez ertheto, es nem kell szintaktikailag nezni ... Csak a logikara akartam ramutatni...

Ha 2-3 php scripted van, akkor elmegy a dolog. Egy komplexebb site eseten azonban exponencialisan no a kezelhetetlenseg....

SPAMtelenül - MX spamszűrő szolgáltatás, ahogyan még sosem próbálta

Van eleg sok php ... Habar eddig eleg jol tudtam kezelni oket csak latom hogy hosszabb tavon nem ez a jarhato ut. Ezt mostmar kikinlodom igy ahogy kezdtem de ha esetleg lessz egy ujabb valami projektem akkor muszaj lessz az a MVC. Van errol valami jo olvasmany valahol a neten magyarul mert azert ezt nem mernem bevallalni angolul..?

Ha raerzel az mvc izere, kesobb mar nem is akarsz mashogy programozni. En mar szornyulkodve tekintek vissza, hogy csinalhattam site-okat korabban mashogy ... :-)

Magyar nyelvu leirashoz hasznald a google-t, en angolul abszolvaltam a lecket + az opencart projekt attekintesevel.

SPAMtelenül - MX spamszűrő szolgáltatás, ahogyan még sosem próbálta

drupal, joomla ezkre gondolsz? Vagy nem tudom mi az a keretrendszer?

Vegeredmenyben nincsen fix hatarido mert ez a salyat dolgom lenne, da ha mar most keszlenne az nagyon jo lenne. Nem szetenem nagyon huzni eleg sok ideje csinalgatom mar (persze amikor van ra folosleg szbadidom) de mostmar szeretnem max 1-2 honap alatt teljesen keszretenni. Gondolom attenni valami keretrendszerre szinte elorol kellene kezdenom ...

Hat valoszinuleg ujra kene irnod az egeszet, de rengeteget tanulnal es az uj valtozat minosegben is jobb lenne az eredetinel. Atlathatobb lenne a kodod, sok dolgot, amit jelenleg magadnak kellett megoldanod, megold a keretrendszer.

pl. Kohana, Synphony, cakePHP, Zend FrameWork, stb.

----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"

A nepszerusitesere vannak terveid? Attol, hogy uzembe helyezed, nem lesz par nap alatt napi >100k latogatod! Ha hasznos lesz a portalod, bele kell majd pumpalnod par milliot, hogy nepszeru is legyen...

----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"

Ja feltehetem egy ingyenes tarhejre is ezzel az erovel :) Es aztan majd hol ezert hol azert nem lessz elerheto ... Meg majd pakolaszom egyik hejrol a masikra... Azert azt nem szeretnem, ha mar elkezdem akkor azert induljon rendesen, persze hogy azert indulasban nem lessz nagy terheles. De szerintem indulaskor barmelyiknek kicsit az eroforras igenyei... Nem ezert vagy azert de a face...k is igenytelenul indult gondolom ott sem volt halomszamra vas ... Persze nem ahhoz akarom magamat hasonlitani ...A 2 gepen azert gondolkozok mert azert szeretnem minnel gyorsabban felfuttatni es kozben nem szeretnek ilyesmikkel folgalakozni ...Akkor arra kell oszpontositani hogy beinduljon az egesz es ne kelljen optimizalnom kozben meg migralni ide oda ...

Meg nincsenenk meg... sot valoszinuleg hogy berelt szerverek lesznek. ugyertem hogy a vas a szolgaltatoe lessz ...Talaltam egy nemet ceget es nekeik van ilyen root server kinalatuk ...Igy nem kell utaznom nemetbe. Kishazamban sajnos nem tudok ilyen szolgaltatot ...

És honnan vársz rá jelentősebb forgalmat? Ha itthonról, akkor b/6-od a németországban hostolt cuccot, az innen nézve nemzetközi forgalmat generál, amire a hazai szolgáltatóknak jóval-jóval vékonyabb drótja van, mint belföldi irányokba. Ja, az ingyenes tárheLY nem minden esetben azonos a pistikepéhápéhostingbété egy szerveres cuccával rendelkezésre állásban...

"Nem nemetorszagbol, es nem magyarorszagrol"
Akkor honnan vagy?

Egyébként nem hiszem el, hogy nincs valamelyik helyi szolgáltatónak ilyen szolgáltatása. Másrészt szerintem első körben egy virtuális szerver is bőven elég lenne, azt tényleg lehet dinamikusan növelni és nagyságrendekkel olcsóbb mint szervert és helyet bérelni.

Szerk.: Persze ha megvan már most az 500G fénykép akkor almás.
És mi az a root szerver?

Vajdasagbol vagyok, tudtommal szerbiaban nincs, vagy ha van is akkor az olyan arban van hogy kint valamerre sokkal olcsobb...Nem szamolom akik itt csak aruljak a szolgaltatasokat de a hosting az kulfoldon van ...

a root az az olcsobb megoldas :) enekem kell adminisztralni (vagy fizetek valakinek) ok nem foglalkoznak vele...Ok adjak a vasat ami naluk van savszelesseg stb ...Szoval nekem nem kell megvanni a szervert toluk berlem azt is ...Es azt teszek ra amit akarok meg persze tudok :)

Mert nincs tapasztalatod ezen a teren es szakmai ismereteid is nagyon gyerek hsz-eid alapjan...

Nem kell elcsuggedni, szerintem megerte megnyitni ezt a topicot, rengeteget tanultal, es kinyiltak a szemeid. Inkabb dolgozz meg az otleten legalabb 1 evet, vagy ha van penzed keress egy profi tarsat!

----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"

Igen, az teny hogy sokat tanultam! Hallottam itt par olyan dologrol is amikrol sejtelmem sem volt. Vegeredmenyben ezert is irtam...
Mindenesetre nem adom fel, ahogy lessz idom csinalgatom es ha kesz lessz majd megprobalom valahogy bejaratni is. Addig csak idobe kerul, akkor meg megkockaztatom a servert vagy a 2 servert es majd kiderul, hogy hasznom lessz vagy bukok rajta ...

A tanulas akkor is valamilyen haszon lessz meg ha emigy bukok is ...