mysql e http su stessa macchina o no?

[EvolutionCrazy]

Ovviamente piu' è specializzata una macchina meglio e'... meno c'è cambio di contesto meglio e'.... se lo sceduler deve fare scelta semplici è meglio etc etc etc...

ma... anche se sono collegate in fibra su un sistema linux quanto puo' essere meno vantaggioso gestire una comunicazione tipo quella necessaria ad un server sql tramite lo stack tcp anziche' usare un socket?

in definitiva avendo macchine adeguantamente grosse (sovradimensionate e ovviamente multicore/multi cpu!) un sito avra tempi di generazione della pagine inferiori se tutto sta su una macchina sola o se si tiene la cosa su due macchine diverse (ben piu' piccole di quella unica da sola)?

puntando quindi ad avere il sito piu' veloce possibile nella generazione della pagine che abbia tempi di risposta mooolto bassi... ha senso separare le cose? oppure è una cosa assolutamente necessaria quando si punta a "risparmiare e si vuole sfruttare l'hw fino all'ultima goccia"?

[guest]

in definitiva avendo macchine adeguantamente grosse (sovradimensionate e ovviamente multicore/multi cpu!) un sito avra tempi di generazione della pagine inferiori se tutto sta su una macchina sola o se si tiene la cosa su due macchine diverse (ben piu' piccole di quella unica da sola)?

Secondo me due macchine piccole, entrambe con dischi SAS e magari connesse in rete direttamente tra loro con 2 o 4 ethernet gigabit ti daranno maggiori performance rispetto ad un singolo macchinone corazzato.

Le 4 ethernet ti permettono di arrivare a 4gbit di banda e speremere appieno i dischi SAS in RAID1/5 (2gbit potrebbero diventare un collo di bottiglia), due macchine distinte ti permettono di fare ottimizzazioni 'migliori' cosa che su una singola macchinona faresti fatica a fare ed inoltre avere dischi separati aiuta non poco le cose.

E credo che il costo delle due macchinine così configurate sia di poco superiore (se non uguale) a quello di un singolo macchinone biprocessore quadcore. Ed avresti sicuramente più rapidità in caso di espansione (aggiungi un processore ad entrambe, aggiungi dischi al RAID, aggiungi ram, ecc, senza doverti preoccupare di splittare le macchine in futuro)

Forse potresti arrivare ad un risultato simile facendo un macchinone biprocessore con 6 dischi, 3 in raid1 per il web e 3 in raid1 per il mysql ma dipende anche da quali performance vuoi ottenere, in letture, aggiungi dischi al raid e la velocità aumenta, ma maggiore è il numero di dischi nella catena peggiori sono le velocità di scrittura. E dipende anche dalla controller RAID.

[EvolutionCrazy]

il mio unico dubbio semplicemente "accademico" era immaginare macchine completamente scariche e provare a vedere cosa succede aprendo una pagina php che faccia una query... per quanti gbit (di banda) hai in rete, la latenza se usi ethernet e' comunque molto alta (rispeto al tempo di risposta che ti puo' dare un socket unix)... e mettere anche lo storage in rete non rallenta ulteriormente?

sono d'accordissimo che avere su una batteria raid solo sql con un pattern di accesso sempre standard risulta migliore che non avere anche http che ci accede, os etc... ma a macchine che lavorano praticamente all'1% delle loro possibilità non è piu' veloce accedere a mysql direttamente tramite socket unix anzichè fare un bel giro tcp su due macchine diverse?

non è una domanda rivolta ad un normale ambiente di produzione, ma sto solamente cercando un caso in cui si possa dire: si, un sistema unico ti serve prima la pagina rispetto ad un'infrastruttura spaziale con 4 link gbit :P

[WizOfOz]

secondo me non puoi prescindere da come è scritto il sw... se vuoi ottimizzare devi mettere mano anche al codice

[guest]

secondo me non puoi prescindere da come è scritto il sw... se vuoi ottimizzare devi mettere mano anche al codice

Esatto, PHP essendo un linguaggio interpretato, non potrà mai dare le performance di una applicazione scritta in C o ancora meglio in assembler.
La latenza ethernet, nel caso di una applicazione PHP, è secondo me trascurabile. Impiegherà sempre più tempo l'interprete PHP a processare la pagina che il pacchetto partire ed arrivare al server MySQL...

Discorso diverso in caso di applicazioni C/ASM/Altro_linguaggio_compilato, in tal caso potrebbe essere interessante valutarne le performance in entrambe le modalità. Però, si parla sempre di valori sull'ordine dei millisecondi. Nel 99.9% dei casi, ininfluenti data la natura di internet.

Devi anche considerare chi sta dall'altra parte del cavo, la sua connessione sarà di qualche ordine di grandezza (10, 100?) volte più lenta rispetto alla tua comunicazione su un canale a 2 o 4gbit tra una macchina database ed una web.

[Siggy]

non è una domanda rivolta ad un normale ambiente di produzione, ma sto solamente cercando un caso in cui si possa dire: si, un sistema unico ti serve prima la pagina rispetto ad un'infrastruttura spaziale con 4 link gbit :P

Se parliamo di ambienti completamente scarichi e/o comunque sovradimensionati rispetto al carico del lavoro, risulta migliore la soluzione su una singola macchina, perche' per quanto puoi fare la connessione veloce tra le due macchine risultera' comunque una latenza dovuta alla connessione (sia a livello fisico che a livello logico).

Quindi in questo caso la soluzione singola macchina (puramente da questo punto di vista e in questo specifico caso) risulta essere migliore.

[guest]

Se parliamo di ambienti completamente scarichi e/o comunque sovradimensionati rispetto al carico del lavoro, risulta migliore la soluzione su una singola macchina, perche' per quanto puoi fare la connessione veloce tra le due macchine risultera' comunque una latenza dovuta alla connessione (sia a livello fisico che a livello logico).

Quindi in questo caso la soluzione singola macchina (puramente da questo punto di vista e in questo specifico caso) risulta essere migliore.

Si, ma se il software che gira è PHP, per me la latenza tra le due macchine è trascurabile in ogni caso...

Comunque, dal punto di vista puramente teorico, si due macchine sono più lente rispetto ad una singola anche a causa della latenza ethernet.
Ma bisogna valutare anche l'utilizzo delle macchine ed il software che ci girerà sopra...

[Siggy]

Si, ma se il software che gira è PHP, per me la latenza tra le due macchine è trascurabile in ogni caso...

Comunque, dal punto di vista puramente teorico, si due macchine sono più lente rispetto ad una singola anche a causa della latenza ethernet.
Ma bisogna valutare anche l'utilizzo delle macchine ed il software che ci girerà sopra...

Si e' sicuramente trascurabile. Si ragionava solo in termini teorici.

Ovviamente il confronto va fatto a parita' di utilizzo delle macchine e di software utilizzato.

[guest]

Si e' sicuramente trascurabile. Si ragionava solo in termini teorici.

Ovviamente il confronto va fatto a parita' di utilizzo delle macchine e di software utilizzato.

Però anche in termini teorici bisognerebbe valutare il linguaggio utilizzato per la generazione delle pagine (PHP??), perchè come da post originale:

in definitiva avendo macchine adeguantamente grosse (sovradimensionate e ovviamente multicore/multi cpu!) un sito avra tempi di generazione della pagine inferiori se tutto sta su una macchina sola o se si tiene la cosa su due macchine diverse (ben piu' piccole di quella unica da sola)?

si presumono pagine dinamiche, ed in tal caso, con PHP, anche in termini teorici la latenza è trascurabile.

[Siggy]

Beh,
lo scopo era evidenziare la differenza tra le due soluzioni.
La latenza imposta dalla connessione fisica e' una delle differenze piu' importanti, trascurarla significa rendere inutile l'analisi. Bisognerebbe poi vedere la quantita' di dati trasmessi in quanto oltre una certa soglia il valore non e' piu' tanto trascurabile, in quanto puo' diventare un collo di bottiglia per l'esecuzione dello script PHP che resta in attesa dei dati necessari alla sua esecuzione.

[EvolutionCrazy]

gia'... capisco che php e' interpretato e tutto... latenza puo' essere bassa quanto vuoi... ma anche 0.5ms sono comunque superiori al tempo che impiega uno script php memcache ad andare in esecuzione ...

anche secondo me una macchina sola in grado di comunicare tramite socket puo' essere piu' veloce in una situazione (assurda) del genere... coinvolgere lo stack tcp oltre alla latenza introduce comunque carico, cambi di contesto etc...

[TheVice]

Secondo me se ragioniamo sulla/e macchine in locale allora si possono vedere delle differenze (la macchinona singola è più performante sugli accessi ai dischi ed alla fine genera meno IRQ e prende meno risorse di memory buffers)

Su un server di produzione penso che le due soluzioni siano abbastanza impercepibili dall'utente/client perchè vale il tempo di trasferimento dato dalla connessione che è sicuramente il maggiore dei tempi come ordine di grandezza.
Ovviamente sempre nelle ipotesi in cui la/e macchina/e non siano in overload.

[Marco Borromeo]

Credo che vada un filo contestualizzata la faccenda, perché restando così sul vago e generico è facile arrivare alla conclusione che mysql in localhost performa di più di uno su macchina separata.
Ma, come è stato giustamente detto, dipende dai carichi, etc etc etc.

Ci sono anche tecniche per migliorare e diminuire la latenza/uso di risorse nel caso volessimo usare un mysql su macchina separata, ad esempio usando le persistent connections di php (ma il tuo software dovrà essere scritto un *gran* bene), oppure usare techiche di connection pooling (il webserver tiene X socket aperti al db sempre costantemente, e php usa quelli; eviti l'overhead dell'apertura e chiusura del socket ad ogni page request), ma siamo già nell'hacking e necessita di un bel pò di test

Per quanto riguarda il confronto con memcache, non regge
Memcache, come mysql, necessita di un socket aperto, in locale o meno, quindi quell'overhead non lo aggiri Sarà più veloce, perché comunque memcache non è un db, fa cose molto più facili e che costano meno, ma il discorso "latenza" su connessione vale anche per lui


m2c

[guest]

Su un server di produzione penso che le due soluzioni siano abbastanza impercepibili dall'utente/client perchè vale il tempo di trasferimento dato dalla connessione che è sicuramente il maggiore dei tempi come ordine di grandezza.
Ovviamente sempre nelle ipotesi in cui la/e macchina/e non siano in overload.

E' esattamente quello che avevo detto (o avevo cercato di dire) qualche post fa.

Bisogna parlare su un qualcosa di più 'concreto'. A livello teorico è chiaro che l'applicativo in locale sia più performante rispetto ad uno via rete, ma senza avere dati più concreti si fa fatica ad affrontare un discorso simile..

[guest]

gia'... capisco che php e' interpretato e tutto... latenza puo' essere bassa quanto vuoi... ma anche 0.5ms sono comunque superiori al tempo che impiega uno script php memcache ad andare in esecuzione ...

Si parla di valori molto prossimi al 0.150ms, molto meno di 0.5ms.
Ora non so quanto tempo impieghi php ad interpretare la pagina, ma di certo non siamo su valori molto minori. E poi dipende molto dalla tipologia di pagina e dal codice in essa contenuto. Inoltre, è risaputo che PHP sia un linguaggio particolarmente poco performante...

Rimango della mia idea: a livello teorico, una applicazione sulla stessa macchina è per forza di cose più veloce rispetto ad una via rete, ma in applicazioni client/server (come ad esempio PHP+MySQL) salvo casistiche particolari (ambito scientifico?! Boh!), la latenza ethernet è altamente trascurabile. La pagina deve essere interpretata, il MySQL deve elaborare i dati, la pagina elaborata deve essere inviato all'utente, il browser deve renderizzare la pagina ecc. 0.150ms sono trascurabili.

Alessandro.