|
| HOMEPAGE | INDICE FORUM | REGOLAMENTO | ::. | NEI PREFERITI | .:: | RSS Forum | RSS News | NEWS web | NEWS software | |
| PUBBLICITA' | | | ARTICOLI | WIN XP | VISTA | WIN 7 | REGISTRI | SOFTWARE | MANUALI | RECENSIONI | LINUX | HUMOR | HARDWARE | DOWNLOAD | | | CERCA nel FORUM » | |
27-07-2004, 00.10.35 | #1 |
Gold Member
Top Poster
Registrato: 18-07-2002
Messaggi: 6.399
|
Benchmark: come fare per evitare ritardi di set up?
Il linguaggio da utilizzare è Java (il sistema è già scritto in Java...) per la gioia di molti di voi Ho un sistema che si occupa di eseguire delle XQuery (query su documenti XML, ma potrebbero essere anche interviste a galline, poco importa) mediante vari QueryEngine, o motori di interrogazione. Attualmente il sistema è alquanto semplice: il programma piglia il testo della query, invoca una API del QueryEngine e ottiene il risultato. Se proprio proprio l'utente vuole farla complicata e richiede l'esecuzione remota, viene mandato un messaggio via SOAP ad una servlet che gira su un server remoto la quale chiama tramite API il QueryEngine del server, ottiene il risultato e lo rispedisce sempre via SOAP al richiedente. Quello che devo fare io è dotare il sistema di un meccanismo che permetta l'esecuzione della stessa query da parte di più QueryEngine, e ne confronti le prestazioni velocistiche. Sono quindi da evitare assolutamente fenomeni del tipo: Client: "Ehi QueryEngine, attento che ti sta arrivando una query!" QE: "Un attimo, ho ancora sonno... aspetta due minuti..." In sostanza non ci devono essere tempi di set-up del query engine che sballerebbero irrimediabilmente il benchmark. Ho messo giù una struttura di massima, ma visto che dovrei farla vedere ai miei committenti-relatori a breve, non vorrei aver fatto ca@@te irrimediabili, e da qui la richiesta di consiglio! Allora, la struttura che ho in mente è più o meno fatta così: Il programma, in avvio, crea una oggetto EngineManager che si occupa di istanziare degli oggetti che rappresentano le connessioni a tutti gli engine locali (saranno massimo una decina); ogni query, quando deve essere eseguita, chiama il metodo executeQuery() di EngineManager, il quale - dopo aver fatto alcune operazioni preliminari - si preoccupa di usare le connessioni prestabilite con i vari engine per eseguire le interrogazioni, vedere quanto tempo ci mette ogni engine, strutturare in qualche modo il risultato e restituirlo alla query o in generale al chiamante. In questo modo, poichè ogni query usa connessioni già stabilite, non sorgono problemi di "delay on set-up" poichè l'engine è già attivo. Anzi, di più: viene chiamato un engine alla volta, quindi non si hanno conflitti tra i vari engine che devono operare su uno stesso documento, e poichè il metodo executeQuery() di EngineManager sarà synchronized, solo una query alla volta potrà essere eseguita, per prevenire il solito utente bastardo che esegue 5 query contemporaneamente compromettendo i risultati Nel caso di esecuzione remota si invoca semplicemente un metodo di un'altra classe che non fa nient'altro che girare la richiesta alla servlet remota che a sua volta chiamerà l'EngineManager locale e così via... Ora vi chiedo: dall'alto della vostra esperienza decennale (giurassica? ) pensate che un'architettura del genere possa essere adatta allo scopo? Se non avete capito qualcosa - e sarà probabile perchè non so quanto chiaramente ho esposto il problema - chiedete! Grazie mille! (più una speciale per il Web ) |
27-07-2004, 10.34.42 | #2 |
Gold Member
Registrato: 07-01-2002
Loc.: Milano
Messaggi: 2.863
|
Ciao Dav,
... praticamente eviti il setup dell'engine lanciando preventivamente tutte le istanze... A grandi linee (imho) mi sembra ok .. tuttavia ho una perplessità su questa cosa... dovresti calcolare (anche approssimativamente) il temop di setup dell'engine .. che, molto probabilmente, sarà "lungo" la prima volta e non le volte successive, specialmente se lo stesso è scritto in Java e quindi cachato dal compilatore... Dato che la struttura di "lancio" delle query è synchronized .. hai comunque un collo di bottiglia in questa fase .. e quindi, se ho capito bene, dovresti a mio avviso farti questa domanda: Costa di più tenere dieci istanze (con relativo thread?) in memoria dell'engine che consumano ram oppure istanziarlo ad ogni volta sfruttando l'eventuale cache del compilatore?... dato che comunque le query vengono eseguite una alla volta... Bye |
27-07-2004, 11.26.31 | #3 | |||
Gold Member
Top Poster
Registrato: 18-07-2002
Messaggi: 6.399
|
Intanto grazie!
Quota:
Come "prima volta e non le successive" intendi: avvio il mio programma, vengono istanziate tutte le connessioni e prima di un tot secondi non potrò avere tutti gli engine operativi, quindi se faccio partire una query 3 secondi dopo aver lanciato il programma ottengo dei risultati sballati? Penso anch'io che sia così, perchè per tirar su delle robe scritte in Java ci vuole tempo Oppure pensi che anche dopo aver lanciato il programma, aspettato un tempo sufficiente, fatto la prima query Q1 su tutti gli engine (diciamo: Q1E1, Q1E2,.., Q1E10), al momento di chiamare la Q2 - magari dopo due o tre minuti - avrò lo stesso problema di un piccolo delay? Quota:
Correggimi se sbaglio: i tempi di esecuzione non ne sono afflitti... o meglio, ti spiego come prendo i tempi di esecuzione: Codice:
public class EngineManager{ int start = 0; int fine = 0; public synchronized QRes executeQuery{String text){ start = System.getTimeInMillis(); //chiamo il QueryEngine1 fine = System.getTimeInMillis(); tempoE1 = fine - start; //stessa cosa per gli altri QE } } Non vorrei che mi sfuggisse qualcosa però... Quota:
Che poi... quando ho pensato a questa struttura mi è sembrato di scoprir l'acqua calda... non mi vengono in mente altre idee magari migliori... Grazie |
|||
27-07-2004, 11.48.49 | #4 | |
Gold Member
WT Expert
Registrato: 09-01-2002
Loc.: None of your business
Messaggi: 5.505
|
Quota:
|
|
27-07-2004, 12.33.19 | #5 | |
Gold Member
Registrato: 07-01-2002
Loc.: Milano
Messaggi: 2.863
|
Quota:
Ma.. ehm .. .. io intendevo dire "cachato" .. cioè .. : messo in cache... l'inglesismo è bruttino .. ... Bye |
|
27-07-2004, 13.06.32 | #6 |
Gold Member
WT Expert
Registrato: 09-01-2002
Loc.: None of your business
Messaggi: 5.505
|
Io infatti ho letto "cacato" da buon italiano.
Lo so, è uscita una battuta infelice...pardon |
27-07-2004, 22.09.00 | #7 |
Gold Member
Top Poster
Registrato: 18-07-2002
Messaggi: 6.399
|
Bene, ho fatto qualche prova con uno dei QueryEngine (Sedna) con un database stupido e con una query ancora più stupida.
Faccio partire il server, il listener e carico il DB.. aspetto un po' che non si sa mai (anche se in task manager i processi del QE erano fermi da un po' ) e lancio qualche volta la query: la prima esecuzione impiega 64ms, le altre oscillano tutte tra i 14 e i 16 ms. Aspetto una decina di minuti durante i quali faccio altre cose col pc... lancio una query e ci mette 15ms Tutto avvenuto creando per OGNI ESECUZIONE una nuova connessione all'engine... Cavolo, se è veramente così non capisco dove abbiano toppato i due che hanno fatto sta tesi prima di me A sto punto, senza volersi fare troppo se@@e su connessioni varie, basta lanciare una query stupida prima di fare il benchmark per ogni QE... Ultima modifica di Dav82 : 27-07-2004 alle ore 22.38.41 |
27-07-2004, 22.09.41 | #8 | |
Gold Member
Top Poster
Registrato: 18-07-2002
Messaggi: 6.399
|
Quota:
Altro che il programma per intesa bci che fa sbarellare... |
|
Utenti attualmente attivi che stanno leggendo questa discussione: 1 (0 utenti e 1 ospiti) | |
Strumenti discussione | |
|
|
Discussioni simili | ||||
Discussione | Autore discussione | Forum | Risposte | Ultimo messaggio |
Cosa fare a Como quando sei morto.... | exion | Chiacchiere in libertà | 8 | 26-03-2007 21.58.39 |
cerco prg free x fare backup cartelle da server a pc.no cobian backup.non mi funziona | cippico | Software applicativo | 5 | 12-02-2007 11.17.51 |
Db mysql come fare il backup dei dati | bietolino | Programmazione | 3 | 17-01-2007 17.28.27 |
come fare per entrare nel forum..dinuovo | deniro | Chiacchiere in libertà | 22 | 02-05-2006 17.16.07 |
devo fare ghost di tutto il disco... | cippico | Software applicativo | 0 | 27-11-2003 10.21.08 |