Newsgroup: it.comp.www.php
Titolo: consiglio costruzione sistema payxclick

Siamo in fase di ottimizzazione di un sistema di payxclick cha gia numerose
volte č andato down per le troppe
richieste mysql (non ha retto proprio benissimo)
quando un utente clicca su un banner esiste un file .php che si occupa di
collegarsi al db effettua alcuni controlli
(per eventuale truffe) se č tutto ok registra il click e trasporta l'utente
al sito di destinazione.
Quindi questo file prima  si collega al db e fa prima 2 query e poi arriva a
destinazione.
Purtroppo da un attenta analisi tra il momento del click e il momento
l'apertura della pagina un 5% (abbondante) degli utenti non guingono a
destinazione
e cmq il file link.php penso sia troppo pesante.
Allora avevo pensato di fare in modo che il file link.php trasporti solo le
variabili (ip , id account , data etc)  verso la pagina di destinazione dove
verrano anche effettuati i controlli e registrati i click , cosi da avere il
file link.php + veloce(non devo effetturare 1 connesione al mysql  e 2
query) e da perdere meno click.
Voi come la vedete ?
scusate se non sono un pň OT ma leggo qui post di persone molto preparate e
mi piacerebbe avere una vostra opinione
Grazie

volte č andato down per le troppe richieste mysql (non ha retto proprio benissimo)
Mmm. Dovrei vedere quel file, per darti una risposta, e anche sapere
vitamorteemiracoli del server dove gira "link.php". E' dedicato? Che
hardware ha? OS? Memoria? Carico medio? Numero di click "gestiti" al
secondo?
Da quel po' che so e senza violare alcun NDA :-), un server da circa
3000 EUR (dedicato) si spupazza allegramente 2-300 click al secondo,
e credo ci stia largo; poi fai te.
Leonardo
-- 
Time's angles, mages tell, conceal a place
incredible, beyond the mundane mind;
night-shrouded and between the seas of space
dread creatures drift in the ageless winds.

Bisogna vedere come è stato organizzato il database, alla fine è tutto li,
se è stato disegnato bene non avrai problemi, se è stato disegnato una
schifezza il progetto fallirà miseramente, io ho fatto sistemi simili e devo
dire che mi funzionano abbastanza bene anche con milioni di accessi al mese.
Ho visto nascere e morire sistemi simili, e devo dire che i miei sistemi
sopravvivono ancora, ormai alcuni hanno superato l'anno di vita e fanno
girare milioni e milioni di pagine al mese.
Più sono grosse le tabelle e più pesanti diventano le query, quindi il mio
primo consiglio è di creare una tabella per ogni utente e non inserire tutti
i dati dei click in una unica grossa tabella, il sistema scoppierebbe in
questo modo, se invece crei delle tabelle per ogni utente, ti ritroveresti
con centinaia di tabelle molto più piccole alcune delle quali magari non
vengono mai interrogate per ore, si capisce subito il vantaggio, le query
diventano più veloci.
Altro trucchetto che ti posso svelare è quello di non usare i campi datatime
o data o peggio ancora campi string, oltre a consumare spazio rendi le
operazioni di ricerca su stringhe, il che è lento, io uso gli interi per
memorizzare le date, con 1 intero a 32 bit puoi memorizzare le date da
adesso per i prossimi 100 anni e passa.
Certo fra 100 anni gli script che ho fatto non funzioneranno più, ma chi se
ne frega, non penso che camperò altri 100 anni :-)
e tantomeno penso che che fra 100 ci sarà qualcuno che ancora userà gli
script che sto facendo :-P magari se accadesse che qualcuno sarà ancora in
funzione sarò sicuramente responsabile del Millennium Bug dell'anno 3000.
Quindi il mio consiglio è di usare gli interi per memorizzare le date,
meglio se usi gli interi a 32 bit, stessa cosa, l'IP, una cosa è memorizzare
l'ip sotto forma di stringa di 16 caratteri e poi fare ricerche sulla
stringa, una cosa è se memorizzi l'IP come Intero e poi fai le query su
Interi, penso che si capisce la differenza, a parte lo spazio risparmiato,
ne guadagni sicuramente anche in prestazioni nella velocità delle ricerche
:-)
Confrontare 2 interi è sempre una operazione più semplice rispetto a quella
di confrontare 2 stringhe.
Altro trucco, usare interi anche per registrare browser e sistema operativo
se ti servono.
Altra cosa da controllare è che il sistema non abbia le pagine degli sponsor
sullo stesso server, altrimeni con centinaia di accessi contemporanei si
crea un collo di bottiglia e qui non ci puoi fare nulla, puoi solo mettere
pagine dello sponsor più leggere.