Newsgroup: it.comp.www.php
Titolo: Progetto PHp & MySQL grossa mole di visitatori - Consigli e Precauzioni

Buongiorno, mi trovo di fronte ad un progetto particolare.
devo sviluppare un sito internet di e-commerce, con tanto di back-office 
personalizzato, scritto in php ( con MySQL e in ambiente linux ) da zero 
perch� � richiesta del cliente non utilizzare nessun open source esistente 
sul mercato.
Il risultato dovr� essere un software leggero, stabile e performante, ma il 
sito attualmente fa 1.200 visitatori unici al giorno e 18/20.000 page view 
al giorno (peso pagina media 0,4 MB).
Consuma banda per 7 GB / giorno circa e le previsioni di crescita sono 
notevoli. Ci saranno inoltre diverse chiamate al database per ogni minuto di 
attivit�. E' intenzione del cliente mettere il tutto in un datacenter 
professionale presente sopra il MIX di Milano e utilizzare un cloud server 
dedicato (2 server fisici dedicati con switch per il load balance e 4 
Virtual machine per ripartire le prestazioni secondo le diverse funzioni del 
software - front end; back office; approfondimento schede tecniche; area 
formazione).
Ora vi chiedo, quali accorgimenti o precauzioni devo prendere nel disegnare 
l'architettura del database?
Come faccio si che il software realizzato si presti bene a questo genere di 
configurazioni professionali?
Altri consigli?
Un responsabile tecnico di sistemi e reti parla per esempio di non far 
scrivere le sessioni del database su disco.
Grazie a tutti.
Giovanni Artiglio 

 Giovanni Artiglio
che devi ottenre il minore numero di righe per esecuzione di pagina
quindi a mio parere
1 scordati gli ogettoni tuttofare da php
2 vai di ajax con oggetto tuttofare
3 select * va dimenticata devi fare select nomecampi
4 evita immagini inutili
5 dividi il codice tra php e html e js (il js non devi crearlo da php se 
non 1a volta
**abusa di ajax**
poi a progetto finito comprimi i php, js (togli tutti spazi indentature 
ecc...)
ho una tabella con 1 gb di immagini uso personale pero le immagini le ho 
li subito a tempi di click-clik
vuoi una mano ?
cosina che mi stavo facendo:
http://imagebin.org/170485

 scrivere le sessioni del database su disco.
...nel secondo caso, la vedo dura seguire questo consiglio.
Potresti usare un DB distribuito come mongodb per salvare le sessioni. 
Mongodb, di suo, usa memorymapped-files, quindi finche` c'e` RAM tiene i 
dati li`, e con un replicaset tieni bilanciata la sincronizzazione in 
modo semi-automatico (non si sincronizza immediatamente a meno che non lo 
forzi, ma perdi prestazioni. Di contro, se va giu` un nodo che aveva 
informazioni non sincronizzate, perdi la sessione, ma lo vedo come una 
cosa poco importante: al massimo l'utente rifa` il login).
Probabilmente lo stesso fa anche couch.
Per le sole sessioni puoi pensare anche a un DB key-value (visto che l'id 
di sessione e` un'ottima key) come Redis o il solito MemcacheDB.
Poi dipende da cosa fa questa applicazione.
Se devi bilanciare i dati ti servira` anche un DB distribuito o almeno 
replicato. Puoi usare il suddetto Mongo o affidarti a roba SQL come MySQL 
o PostgreSQL con replica master-slave o master-master (con i pro e contro 
del caso).
Se devi gestire anche la replica di file su disco diventa ancora piu` 
complicato, e forse conviene rivedere l'architettura hardware con NAS o 
server in "RAID in rete" (tipo DRBD).
In ogni caso, quel numero di visite e di pageviews (anzi, circa il 
doppio) le faccio normalmente su un singolo server quad-core con siti 
scritti in Zend Framework e database PostgreSQL sulla stessa macchina 
(virtuale). Il carico medio e` 0.12
Certo, dipende dai calcoli e dalle query che fa la tua applicazione, ma 
penso che fino a 100.000 pageview/giorno tu stia tranquillo anche con un 
singolo server.
Bye.

 Giovanni Artiglio
Prevedere di utilizzare la cache delle pagine e la cache degli opcode 
(con alternative php cache, per esempio, che però attualmente è un 
modulo a parte).
Per quanto riguarda il database, ci sono diverse possibilità di 
ottimizzazione in teoria. Per esempio, quando effettui delle query con 
join, siccome la join stessa richiede di incrociare diverse tabelle, 
nella select vanno messe prima quelle clausole che riducono la 
dimensione della tabella al minimo, così il database non deve incrociare 
grandi tabelle fra loro. Cerca su google, credo che alcuni database 
facciano già qualcosa di simile quando possono carpire semanticamente il 
significato di una clausola.
In alternativa puoi pensare di utilizzare le viste materializzate se i 
tuoi dati vengono spesso letti e raramente aggiornati, e se il tuo 
database le supporta (mysql però non le supporta, ma ho letto che si 
possono simulare usando i trigger): si tratta di viste che però 
risiedono su disco. In pratica ti evitano di fare diverse join fra tante 
tabelle a run-time, ma sono costose da gestire quando nelle tabelle 
incriminate i dati cambiano. Se le scritture sono molto poche rispetto 
alle letture, possono essere interessanti.
Il suggerimento del tecnico è un compromesso particolare: non scrivendo 
i dati immediatamente su disco si velocizza in modo notevole la 
transazione, ma in caso di crash del database rischi di perdere delle 
transazioni recenti. E comunque velocizza solo le scritture.

 Consuma banda per 7 GB / giorno circa e le previsioni di crescita sono
sei sicuro di sto conto?
Perchè vuol dire ogni pagina ha 400k di contenuti sempre diversi, non si 
cacha mai nulla, ne immagini del tmplate del sito, ne js, ne nulla di 
nulla...
A me pare strana sta cosa...
Oppure i 400k li hai calcolati facendo 7gb/18-20k?
Attualmente il sito come sta girando di architettura?
-- 
Z.

 significato di una clausola.
postgre di certo.
Io infatti solitamente uso viste (non materializzate, postgre non le ha 
ancora) e uso il where solo su di loro. Empiricamente il tempo di 
escuzione è lo stesso di una query con clausola prima(o assieme) al join.
Di fatto sposto molta logica sul db, non so dire se sia bene o male (ci 
sono scuole di pensiero e ognuno è convinto della propria verità), però 
mi trovo molto bene nella manutenzione/evoluzione (contando uso anche un 
framework per cui l'orm si aggiorna da solo).
-- 
Z.


Si infatti anche io in un mio progetto che dovrebbe avere a regime del 
traffico sostenuto ho previsto delle viste. In fondo una vista non è poi 
la fine del mondo, si tratta di evitare di fare query con join e 
clausole sempre uguali. Poi le abbiamo ste viste, semplificano un po' il 
lavoro, vale la pena usarle...

 Giovanni Artiglio
Ciao
Il cliente vuole proprio che tu parta proprio da zero sapccato?
Io sto facendo una cosa simile anche se un pelo più generica e sono 
partito da Symfony 2 che mi sta velocizzando molto. Anche il mio cliente 
vuole andare su una licenza closed e questo Symfony lo permette che io 
sappia
IMHO punterei su un codice ben organizzato e mantenibile. Per la 
velocità poi fra nginx, acceleratori vari e macchine più pompate di 
solito riesci senza grossi problemi. Ho esperienza diretta di un singolo 
apache, non particolarmente ottimizzato che con ezPublish tiene su un 
sito di un grande comune + are intranet, quindi non mi fascerei subito 
la testa
Un altro consiglio che potrei darti è di partire da postgres e non da 
mysql. Mysql non scala molto bene per mia esperienza
Marco
-- 
I fatti mi cosano

 di attività. E' intenzione del cliente mettere il tutto in un datacenter 
