ugrás a tartalomhoz

webszerver win2008-ra

Nigi · 2015. Már. 31. (K), 21.53
Sziasztok,

a segitsegeteket kernem a kovetkezohoz:
Adott egy eleg modern 2x6Xeon, 48GB RAM, 4xSSD, win2008std szerver, savszelesseg: 10TB;
erre kene stabil, gyors webszerver+php+mysql;
lekerdezesek szama (kivulrol): kezdetben 4000-8000 / sec, kesobb 40-80000/sec; a lekerdezett/elkuldott adatok picik, legtobbszor nehany bajt, ritkan nehany kilobajt;
a futo alkalmazasok kritikusak, nem toleralt a visszautasitas, kesleltetes stb, az a par bajt "azonnal" kell.

Hogy erdemes ezt kivitelezni? Gondolom egy xampp/wamp nem a legjobb erre.
Erdemes tobb virtualis gepre osztani a terhelest, vagy az uj webszerverek mar masszivan parhuzamositottak?

Elore is koszonom a valaszokat.
‹ Apache szerver telepített modul hiánya xampp elérése wifi nélkül ›
 ■
1

Bocs :)

szabo.b.gabor · 2015. Már. 31. (K), 22.24
10TB sávszél? az vagány :D

amúgy nem tudom, de kíváncsi vagyok, hogy mit ajánlanak a többiek. ilyen peremfeltételekkel gyanítom azt, hogy használj más 'szoftverréteget'
2

PHP

janoszen · 2015. Már. 31. (K), 23.10
A PHP alapvetoen nem mukodik tul jol Windowson, a PHP-ban irt kulonbozo modulok meg meg annyira sem. Eroteljesen javasolnam a *NIX rendszereket erre a feladatra, a Windowszal nem leszel boldog.

Ami az alkalmazasodat illeti, ha nem toleralt a visszautasitas vagy kesleltetes, akkor jobb ha eloveszed a vastagabbik penztarcadat, mert egy vasrol soha nem fogsz tudni 100% vagy kozel 100% uptime-ot elerni, hiszen minimum biztonsagi frissiteseket futtatni kell.

Arrol nem is beszelve, hogy az internet nem ugy mukodik. Ha pl. elveszik egy csomag, akkor eleve csak 3 masodperc mulva probalkozik ujra a kliens. Ha ilyen szinten realtime megoldas kell, akkor nem a PHP es nem is az internet a megfelelo csatorna, hanem a redundans dedikalt berelt volnal es low level halozati protokollok. De gyanitom, hogy nem ettol nem leszel boldog.

Mivel a postodrol ordit az, hogy soha meg csak nem is lattal olyan rendszert mint amit itt vizionalsz, nagyon szivesen beszelgetek veled egy orat Skype-on a feladat megvalositasrol Skypeon, hatha sikerul nehany fogalmat tisztaba tenni.
3

Én nagyon izgatottan várom a

spapp · 2015. Ápr. 1. (Sze), 08.32
Én nagyon izgatottan várom a megoldási elképzeléseket a 40-80000 kérés/sec-re. :)
4

Webszerver

Poetro · 2015. Ápr. 1. (Sze), 10.05
Megfelelő webszerverrel, mondjuk Nginx lehetséges ennyi statikus tartalmat kiszolgálni. Dinamikus tartalom esetén egy szerverrel a PHP automatikusan kiesik, ugyanis nem képes ekkora sebességet produkálni, főleg, ha összetett kód van mögötte. Valami fordított nyelv, node.js, és Erlang esetén, amik clusterben működnek, azért elérhető a sebesség, ha nem hagyományos adatbázisból jön a tartalom, hanem valami memória alapúból, és nem kell az adatokkal semmit sem csinálni.
5

Whatsapp backend leirás

tlof · 2015. Ápr. 1. (Sze), 13.14
Itt egy elég jó leirás arról, hogy a whatsapp hogyan éri el ezt a brutális request számot, és mivel szolgálják ki.

http://www.quora.com/What-is-the-technology-stack-behind-WhatsApp
6

Quora

Poetro · 2015. Ápr. 1. (Sze), 13.19
Ez a Quora milyen országban működik? Mert a UK-ben nem (403. Forbidden.). US proxy segítségével kiderült azért, hogy Erlang van az egész mögött.
7

Na

janoszen · 2015. Ápr. 2. (Cs), 07.16
Na, a dolog vége annyi lett, hogy a kedves kollégának igazából egy pub-sub rendszerre van szüksége, amire az Nginx megfelelő modulját javasoltam kipróbálásra.
8

S valójában mennyi lett az a

spapp · 2015. Ápr. 2. (Cs), 09.28
S valójában mennyi lett az a 80k req/s?
9

Pub-sub

Poetro · 2015. Ápr. 2. (Cs), 14.32
A Redis pub-sub egy notebookon is képes több mint százezer req/s-re, az ajánlott nginx-ről nem tudok adatokat, de hasonló lehet. Egy szerver gépen ugyanez lehet több százezer is.