Newsgroup: it.comp.www.asp
Titolo: MySQL e ASP su due server

Salve a tutti.
Sto costruendo un sito in ASP che deve interrogare un database da circa
70.000 record ed essere aggiornato ogni 2 ore.
Ho scelto MySQL come base dati poiché più performante di SQL e l'utilizzo di
un server separato che possa fornire
dati a più server WEB. Dovrebbe essere una tema interessante da affrontare.
La struttura hardware/software utilizzata è la seguente:
SERVER "A"
OS: NT 4 server (SP6a)
WEB SERVER: WebSite Pro
ASP ENGINE: ChiliSoft
SERVER "B"
OS: NT 4 server (SP6a)
DB: MySQL 3.23.38
HW: PIII 500 - 512 RAM - UWSCSI
Per la connessione dei dati utilizzo, sul server A, MyODBC (2.50.37), anche
perchè non ho trovato modo
di impiegare con successo OLE DB su server separati (o provato anche con
MyOLEDB).
Per quanto riguarda l'interrogazione dei dati (dal server A al server B)
nessun problema: le query
vengono restituite in frazioni di secondo (3 tabelle relazionate).
Il problema è nell'aggiornamento dei dati.
Ogni ora viene lanciato un VBS che fa le seguenti operazioni:
- apre un file di testo e legge il record;
- viene interrogato MySQL (con MyODBC) per sapere se il record esiste;
- viene chiusa la connessione MyODBC;
    - se il record esiste lo aggiorno (con query SQL);
    - se il record non esiste lo inserisco (con query SQL);
- passo al record successivo;
Dopo ogni apertura MyODBC la richiudo.
Il problema è che la CPU (del server B) mi sta al 100% per tutta
l'operazione e
che per aggiornare inserire 2000 record ci mette 4 minuti.
Qualcuno può essermi di aiuto ?
Grazie in anticipo,
                                Lorenzo

                                 Lorenzo
La fase di aggiornemento da come hai scritto la fai in questo modo?
- apertura file con dati da modificare
- inizio ciclo di scansione file di dati
- apertura database MySQL
- controllo esistenza dati
- chiusura database MySQL
- se il dato esiste lo aggiorni:
    - apertura database MySQL
    - aggioro dati
    - chiusura database MySQL
- se il dato non esiste lo creo:
    - apertura database MySQL
    - creazione nuovo record
    - chiusura database MySQL
- continuo il ciclo di lettura file di dati
Ho capito giusto?
In questo caso c'è un effettivo spreco di risorse! L'apertura e chiusura
continua del database è inutile.
Dovresti riscrivere il codice con questa logica:
- apertura file con dati da modificare
- inizio ciclo di scansione file di dati
- apertura database MySQL
- controllo esistenza dati
- se il dato esiste lo aggiorni:
    - aggioro dati
- se il dato non esiste lo creo:
    - creazione nuovo record
- continuo il ciclo di lettura file di dati
- chiusura database MySQL
Come puoi notare l'apertura del database e la sua chiusura avvengono solo
una volta, all'inizio e alla fine.
Saluti,
Andrea Z.

Hai capito perfettamente.
La prima versione della procedura era proprio come deve essere,
ovvero come tu consigli. Ho poi aggiunto le aperture/chiusure ad
ogni operazione poiché presupponevo che esistesse un problema
di LOCKING delle tabelle o dei record.
Saluti,
                        Lorenzo


Non ci dovrebbero essere problemi a tenere tutto aperto, vai tranquillo!
Se noti che le prestazioni non aumentano di molto c'è un'altra soluzione.
Visto che hai i due server sottomano puoi provare a creare una pagina ASP
che passi tutto il database per controllare quali dati sono da aggiungere e
quali da cancellare, ma le varie stringhe di "insert" e "update", le
memorizzi tutti in un file di testo in modo da trovare alla fine della
pagina ASP il database ancora intatto ma con un file testo contenente:
insert ...
insert ...
update...
insert ...
per tutti i record (nel tuo caso 2000 records).
Quindi, direttamente sul computer dove hai installato MySQL dal Prompt dei
comandi, puoi mandargli in pasto tutto quel file di testo, penserà lui a
processarlo e a inserire tutti i vari comandi SQL:
bin/mysql -u root -p tua password -h localhost <file_di_testo_creato_da_asp
Prima di questo file di testo devi però effettuare una modifica, scrivere su
quale database MySQL deve lavorare:
use tuodatabase;
Le performance saranno sicuramente superiori anche se non ho mai fatto prove
a riguardo.
Ciao,
Andrea Z.