Abbiamo osservato il codide dei clienti per molti anni in agenti, vistem formule, nelle formule inserite in un campo e cosi via...In base alla nostra esperinza i problemi tendono ad essere molto noiosi nelle front-end performace che nelle back-end performace per svariati motivi
- i processi in back-end sono monitorati più rigorosamente
- i processi in back-end non hanno problemi legati al traffico (ovvio perchè non colloquiano con il server ma vengono gestiti dallo stesso)
- i problemi in front-end possono essere difficili da capire. Gli utenti spesso non sono sicuri quali action sono imporanti, causando richieste al Vostri help-desk di cose poco importanti (tutto quello che può essere gestito in back meglio farlo da lì..)
Ma senza osservare come il codice sia stato scritto, penso che se troviamo qualcosa che è lento e proviamo ad aprirlo molto probabilmente le cose comuni saranno:
- Il codice stabilisce certi controlli prima di essere useguito, come username, stato del documento in cui è l'utente, la today e così via
- Il codice ottiene una collezione di documento dal database corrente o da un'altro database
- Il codice legge da o scrive a questi documenti
Dai test eseguiti in questi divesi anni abbiamo riassunto che il primo punto è molto veloce e penso non debba essere migliorato, il terzo punto è spesso lento, ma purtoppo non e' molto elastico, questo poichè dipende molto dal set (la collezione) di dati che dovete leggere o scrivere.
Per esempio se dovete salvare la data di oggi in un campo chiamato DateToday, potreste utilizzare uno dei seguenti metodi:
****************************************
1 - Extended class
Set Doc = dc.getfirstdocument
Do while not ( Doc is Nothing )
Doc.DateToday = Today
Call Doc.Save
Set Doc = dc.getnextdocument ( Doc )
Loop
2 - ReplaceItemValue
Set Doc = dc.getfirstdocument
Do while not ( Doc is Nothing )
Call Doc.ReplaceItemValue ( "DateToday", Today )
Call Doc.Save
Set Doc = dc.getnextdocument ( Doc )
Loop
3 - StampAll
Call dc.StampAll ( "TodayDate", Today )
******************************************
Dai nostri test non abbiamo trovato notevoli differenze tra i primi due esempi presenti, anche se in teoria sembrerebbe più rapido il primo esempio che il secondo, in quanto il primo aggiorna direttamente il campo mentre il secondo dove "interrogare tutti i campi" presenti nella FORM per poi fare l'assegnazione. Cmq sia la pratica dimostra che non ci sono differenze tra i due.
Il terzo metodo è più veloce se si debbono aggiornare molti documenti con un singolo valore come nell'esempio precedente. In alcune vecchie relase questo metodo era davvero lento, ma con la relase 6.5 e 7 di domino è stato notevolmente migliorato.Tuttavia esistono spesso dei controlli da fare prima di assegnare un valore e quindi tale metodo non è spesso applicabile.
Per quanto riguarda decidere quale dei tre metodi effettuare la scelta, la nostra esperienza dice che l'esempio di ReplaceItemValue (che ottiene una raccolta di documenti) è il numero uno. Risulta che questo è spesso, di gran lunga, il più grande pezzo di tempo usato dal codice e fortunatamente, il più compressibile. Questo sarà l'elemento focus dei nostri test che verranno discussi nel resto di questo articolo.
TESTING
La nostra metodologia difficile doveva generare una grande database con documenti del formato ragionevolmente costante (approssimativamente 2K) e con lo stesso numero di campi (circa 200). Ci siamo assicurati che i documenti avessero alcune differenze con attenzione programmate, di modo che abbiamo potuto effettuare DBLOOKUP su tutto il numero di documenti.
Nello specifico, ci siamo assicurati di poter fare una DBLOOKUP su 1, 2, 3, ... 9, 10 documenti; ed anche 20, 30, 40, ... 90, 100; ed anche 200, 300, 400, ....900, 1000; e così via.
Ciò ci ha dato un numero tremendo di punti di riferimento che ha permesso di verificare che non stessimo vedendo le buone prestazioni attraverso soltanto una banda stretta.
Per esempio, db.search è un esecutore eccellente su un grande numero di documenti in un database, ma un esecutore povero contro un piccolo numero.
Abbiamo fatto funzionare le prove per molte ore alla volta, scrivendo i risultati in un file di testo che abbiamo importato successivamente nei fogli elettronici e nei programmi di presentazione allo scopo di progettare i diagrammi di XY. Dopo molte ripetizioni e dopo aver provato database molto piccoli (10.000 documenti ) e grandi (4 milione documenti), vi forniremo una guida di riferimento che pensiamo sia utile allo sviluppatore di applicazioni Notes.
QUALE METODO E' IL MIGLIORE?
La via piu' veloce per ottenere una collezione di documenti per leggerci e scriverci è quella di usare db.ftsearch o view.getAlldocumentbyKey.
E' risultato che altri metodi risultano essere vicini per alcuni set di documenti (discussi successivamente in questo articolo) ma non è possibile associare questi metodi sia per le piccole che grandi set di documenti. Elechiamo qui di seguito i metodi con una breve descrizione che verrà ripresa successivamente in dettaglio.
- View.GetAllDocumentsByKey ottiene una collezione di documenti basata su una chiave in una Vista, per interagire con la collezione va usato set doc = dc.GetNextDocument ( doc ).
- db.ftsearch ottien e una collezione di documenti basandosi su una ricerca full-text all'interno del database, per interagire con la collezione va usato doc = dc.GetNextDocument ( doc ).
- view.ftsearch ottiene una collezione di documenti basandosi su una ricerca full-text sulla vista corrente. Per interagire con la collezione va usato set doc = dc.GetNextDocument ( doc ).
- db.search ottiene una collezione di documenti non basandosi su di una ricerca full-text. Per interagire con la collezione va usato set doc = dc.GetNextDocument ( doc ).
- view.GetAllEntriesByKey ottiene una collezione di una vista leggendo i valori dalla prima colonna ordinata e bisogna accedere al documento attraverso l'entry (l'elemento) della vista. Per interagire con la collezione va usato set entry = nvc.GetNextEntry ( entry ).
Se si ha una piccola collezione di documenti (10 elementi) e piccoli database (10.000 documenti) non si hanno grosse differenze di performance tra un metodo e l'altro a meno che esso non venga richiamato piu' volte nelle vostre applicazioni.
Tuttavia potrete trovare piccole differenze se dovete ottenere molti collezioni di documenti, di conseguenza di coseguenza ruberete una frazione di secondo ogni volta che il vostro codice diventerà significante.
In aggiunta se la vostra è un'applicazione veramente grande, allora troverete grosse differenze significanti.
Ad esempio questi ho questi due clienti:
Il primo schedula un agente che gira molto frequentemente(ogni qualche minuto oppure ogni volta che viene creato, modificato un documento)
il codice interagisce ogni volta che viene salvato un documento per ottenere il criterio di ricerca e le operazioni di ricerca sono basate appunto su questo criterio.Se ci saranno 10 nuovi documenti la ricerca agirà su 10 documenti, se ci sarannno 100 nuovi documenti esso agirà su 100 documenti. Per questo cliente se potessimo togliere 0,5 secondi nel momento in cui viene richiamata una collection, tale valore verra' moltiplicato per 10 ricerche e se 100 a seconda di quanti nuovi documenti vi siano in base allla frequenza di esecuzione dell'agente. Si potrebbero utilizzare facilmente molti minuti in un ora durante il giorno che potrebbe un risparmio rilevante di tempo.
Un'altro caso è quello di avere una FORM che ha nel POSTOPEN e QUERYSAVE eventi l'esecuzione di tale codice, se si lavora o si salva per più di un'ora un documento moltiplicherete 0,5 secondi di risparmio ottenuto fino a diventare un risparmio notevole.
PRO E CONTRO DI OGNI METODO
Quando abbiamo spiegato ai colleghi o clienti perchè alcuni di questi metodi sono più veloci o più facili da usare che altri metodi, ci siamo agganciati spesso in un simpatico dibattito, completiamo con " uno sulla mano" e "uno sull'altra" discussione. Nostra grande soddisfazione grande, sarà quella di chiarire le discussioni. Tenteremo di comunicare che lo stesso spirito in questo articolo con due avversari dibattenti my, Prometheus ("pro " per i suoi amici) ed il suo collega scettico Connie (a.k.a" Con").
Prometheus: view.getalldocumentbykey ho visto che è molto veloce. Penso sia il caso di usarla d'appertutto se possibile
Connie: Certo sicuramente, mio amico ma cosa mi dici quando la ricerva deve essere fatta nella Domino Directory? Non hai l'autorizzazione di creare viste facilmente
Pro : Ottima osservazione, in applicazioni dove controllo il database posso usare questo metodo?
Con: Oh? finendo col generare 10 viste aggiuntive sul database...è ancora un buon metodo? Pensa a tutta l'indicizzazione supplementare che richiede
Pro:Allora ciò potrebbe risultare fastiodoso, ma se sviluppassi le viste convertite probabilmente gli incremeneti si sposterebbero di 100 millisecondi ogni 15 minuti quando funziona l'operazione di aggiornamento. Sicuramente possiamo risparmiare cento millisecondi ogni minuto?
Con: Come convertirai queste viste? E' difficile?Richiederà molta manutenzione?
Pro: Non a tutto. Per convertire una vista di ricerca, prima di tutto bisogna raffinare il criterio di ricerca. Ciò riducerà le dimensioni dell'indice della vista, il tempo di incizzazione ed il tempo di ricerca. Succesivamente bisogna pensare a come ricercare nella vista. Se si vuogliono ottenere tutti i documenti, basta semplicemente ordinare tutti gli elementi creando la prima colonna con "1" che sarà la chiave di riceca, Se si ha bisogno di ricercare anche un altro campo basta aggiungere un'altra colonna con una sola Ricerca.
La ricerca è veloce se il totale dei dati ritornati è lo stesso
Con:Potrebbe essere un buon metodo, ma anche db.ftsearch è molto veloce, non sono sicuro ma pronto ad usare questo metodo.Sembra che esso richieda una tipo particolare di infrastruttura
Pro:Vero l'uso di db.ftsearch è realizzabile nel tuo codice e per fare ciò è necessario attivare la full-text index nel database ed essere sicuri che il server domino abbia impostato FT_MAX_SEARCH_RESULT=n dove N è il numero massimo di risultati che ritorna la collezione. Senza di questo parametro sei limitato a 5000 documenti
Con: E cosa accadrebbe se l'indicizzazione non viene effettuata velocemente?
Pro:In questi casi dovrai aggiungere nel tuo codice db.UpdateFTindex per forzare l'indicizzazione
Con:Dai miei test risulta che questo richiede consuma del tempo, molto lontano dal concetto di migliorare le prestazioni. Cosa accadrà se non viene rigenerato l'indice FT?
Pro:Se il database ha meno di 5000 documenti, un indice temporaneo sarà crato al volo dal sistema per te
Con:Ho due problemi con questa cosa: primo: il FT temporaneo non è efficente poichè viene aggiorato dopo il funzionamento del codice. secondo: 5000 documenti sono veramente pochi. cosa devo fare se ci sono più di 5000 documenti nel database?
Pro:In questo caso devi usare db.UpdateIndex(true) che creerà un indice permanente
Con:Ma creando un indice FT per grandi database richiede molto tempo. So anche che l'indice verrrà genato seu il databae è locale rispetto al codice , cioè sullo stesso server dove il codice risiede
Pro:Vero, anche se fortunamente Lotus Notes/Domino 7 ha certi comandi avanzati come la possibilità di utilizzare il DDM(Domino Domain Monitoring) per tracciare come le FTsearch rispetto alla basi senza FTindex stanno lavorando.Qui di seguito un esempio di messagi genrati calla console di domino:
Agent Manager: Full text operations on database 'xyz.nsf' which is not full text indexed. This is extremely inefficient.
mm/dd/yyyy 04:04:34 PM Full Text message: index of 10000 documents exceeds limit (5000), aborting: Maximum allowable documents exceeded for a temporary full text index
Con: Ho notato che non hai parlato di view.ftserach, view.getallentriesbykey o db.search, ma penso di aver sapereil perchè.
La prima è rapida su alcune condizioni, ma se la vista non è organizzata in modo che i dati incrementano nella parte inferiore le ricerche possono essere lente. Db.search invece tende ad essere molto lento qualora si gestica una piccola collection.
Pro: Tutto quello che dici è vero. db.search è motlo efficace in ricerce sensibili date/time dove non desideriate realizzare una vista con date/time e dove non volestre realizzare un FT index. Inoltre qualora vi serva solo per ricerche non sotto il tuo controllo e se questi database non sono indicizzati è possibile che db.search sia l'unica reale possibilità per ottenere collezioni di documenti
Qui di seguti ci sono alcune tabelle utili per misurare i punti preceding fatti da Pro. Queste tabelle mostrano quanto tempo occorre per ottenere semplicemente una raccolta di documenti. Niente è letto da questi documenti e niente è scritto su di essi.
Questa è un'applicazione della prova nel nostro ambiente di TEST, in modo da i numeri assoluti dovrebbero essere presi come un grano di sale.Tuttavia, i rapporti fra i vari metodi dovrebbero essere costanti con quello trovereste nel vostra situazione.
Nella figura 1, db.ftsearch e view.GetAllDocumentsByKey sono virtualmente indistinguibili a vicenda, entrambi sono gli esecutori migliori. Entrambi con un legame per il primo posto. Un terzo vicino sarebbe view.GetAllEntriesByKey, mentre view.ftsearch lo si vede verso l'esterno , ma peggiora velocemente con il numero di documenti colpiti (40 circa).
Figura 1. Collezioni del documento, viste ottimizzate (fino a 100 documenti)
Nella figura 2, l'unica differenza degna di nota rispetto alla figura 1 è che db.search sembra migliorare mentre il numero di documenti aumenta. Risulta quella a circa 5 - 10 per cento dei documenti in un database, db.search sarà altrettanto veloce quanto i corridori precedenti. Abbiamo visto già nella figura 1, view.ftsearch sta ottenendo il risultato peggiore più aumenta il numero di documenti
Figura 2. Collezioni del documento, documenti di viste (100 - 1.000) ottimizzati
Nella figura 3, le viste più non sono ottimizzate per generare i risultati verso la parte superiore. Questo nel casso che stiamo ottenendo una raccolta semplice di alcuni documenti, allora nel nostro ambiente di TEST, abbiamo avuto la possibilità di provare a dare ai risultati una direzione obliqua assicurandosi quei pochi documenti siamo o verso l'alto o verso il basso della vista di ricerca.
Nella figure 1 e 2, quei documenti sono sempre stati verso la parte superiore della vista, ma nella figura 3, quei documenti sono alla parte inferiore. Per tre dei metodi usati, questo è ininfluente (db.search, db.ftsearch e view.GetAllDocumentsByKey).
Tuttavia, per view.ftsearch e view.GetAllEntriesByKey, questo cambiamento è catastrofico in termini di le prestazioni. La scala di misura presente nelle figure 2 e 3 è stata cambiata -- anziché l'asse y che andava fino a un secondo, ora deve andare fino a sei secondi!
Figura 3. Collezioni del documento, viste non-ottimizzate
CONCLUSIONI
Ovunque sia possibile utilizzate view.getAlldocumentBykey per ottenere una raccolta di documenti.
Se dovete ricercare all'interno di campi Rich-Text ed il vostro database è già indicizzato db.ftsearch è un metodo eccellente. Assicuratevi però che i vostri risultati siano sempre inferiori a 5.000 documenti o utilizzate il parametroFT_MAX_SEARCH_RESULTS=n nel file NOTES.INI del server.
0 Commenti:
Nessun Commento Trovato