Newsgroup: it.comp.appl.notes-domino
Titolo: Prestazioni?

Ho fatto un db notes tempo fa, in realta' poteva essere qualsiasi altra
cosa, ma ora ha qualche decina di migliaia di doc e quindi rimane cosi'.
Il fatto e' che diventa sempre piu' lento ad aprire il primo documento,
nel senso che quando l'utente apre il db il primo documento a cui accede
ci mette circa 10 secondi (PIII 256MB ram, W2k), anche se il db e' in
locale. Il db e' indicizzato ed e' piuttosto semplice. Contiene 2
moduli(di cui uno viene usato solo per i doc risposta ed attualmente
neanche uno), 7 sottomoduli (di cui due per le risposte) 11 viste di cui
4 categorizzate ed una @all, praticamente tutti i documenti hanno 22
campi per un totale di circa 1000 byte, poiche' li scrive un task sul
server. Il fatto che l'indice ci sia o no non cambia gran che', nel
senso che una volta visualizzata la vista scelta, ad  aprire il primo
documento ci mette lo stesso tempo. Il tempo che perde (visto con il
debug e' praticamente tra l'ultima istruzione dell'evento QueryOpen e la
prima del PostOpen. Da notare che Query open fa praticamente niente:
Sub Queryopen...
	Set session = New NotesSession
	user=session.UserName
	If Isnewdoc Then
...qui c'e un po' di codice ma viene eseguito solo se si crea un nuovo
documento... e li' va bene!
	End If
End Sub
Cosa fa' in mezzo? 
Cosa puo' essere a fargli perdere tanto tempo?
-- 
Dr. Ugo Gagliardelli, Modena, Italy
Spaccamaroni andate a cagare/Spammers not welcome
Spamers iros a la mierda/Spamers allez vous faire foutre
Spammers loop schijten/Spammers macht Euch vom Acker

Il punto in cui resta fermo è proprio dopo aver eseguito tutto lo script
della QueryOpen?

 della QueryOpen?
Si'


 Si'
La freccina gialla rimane ferma su End Sub


 La freccina gialla rimane ferma su End Sub
Se prima di aprirlo forzi il refresh di tutte le viste?

 La freccina gialla rimane ferma su End Sub
Ti diro' di piu', ho messo un istruzione in ogni query open di ogni
sottomodulo in modo da poter mettere uno stop di debug sull'istruzione
(su end sub non si ferma), il tempo lo perde tra la fine della QueryOpen
del modulo principale e la prima QueryOpen successiva che incontra, cioč
quella del primo sottomodulo che compare nel documento. 


 ha scritto nel messaggio
news:oatp7.56054$F45.5...@news1.tin.it...

Anzi, anzi, domanda idiota, non esiste nessuna DBLookup nel modulo, vero?
E i sottomoduli sono calcolati in base ad una formula o fissi?
Profili ci sono?


Stessi tempi.


 quella del primo sottomodulo che compare nel documento.
Quindi non č decisamente una questione di calcolo interno al modulo...
Comunque hai fatto la prova dopo aver aggiornato tutti gli indici?
Appro... il DB ha un FTIndex?

 Stessi tempi.
Allora vale la domanda sotto per il FTIndex.

 Profili ci sono?
No



Si' ce l'ha, ma non sembra influire un gran che', ho cancellato
l'indice, le viste compaiono sempre in modo immediato ma il PRIMO,
vorrei sottolineare, documento ci mette i soliti 10 sec., gli altri sono
immediati.


 ci mette circa 10 secondi (PIII 256MB ram, W2k), anche se il db e' in
.........
La butto li'...
Nel documento c'e' un interrogazione tramite DB Column o Db Lookup... magari
la formula di qualche campo.
Questa e' secondo me la causa...
La spiegazione... ma qui mi sto davvero sbilanciando e' che se hai delle
viste categorizzate, salvate senza richiedere l'esplicta compressione delle
categorie in apertura, specie se fai uso intensivo dei campi lettori (nel
senso che si sono molti documenti e molti lettori ognuno dei quali puo'
leggere POCHI documenti del totale) si crea un incredibile rallentamento x'
domino deve scorrere quasi tutta la vista alla ricerca dei pochi documenti
accessibili al current user.
OldSmobile

 E' brutto?
Non è brutto, è che se c'è stata la creazione di un pacco di docs da pa rte
del task senza il refresh degli indici delle viste da parte sua, quando vai
ad aprire il tuo doc, anche se la vista da cui l'hai aperto è stata
aggiornata, la DBLookup contenuta deve aspettare l'aggiornamento dell'indice
(della vista) su cui si basa prima di poter procedere.
Vista la tua situazione non so se sia questo il caso, ma basta che togli la
DBLookup una volta per fare la prova...
Ora scusa ma mi reclamano a letto. Ci si risente domani sera (domani sono
fuori da un cliente) per continuare se non sei arrivato a niente.
Baci, Juda.

 immediati.
Il fatto che le viste compaiano immediatamente non vuole necessariamente
dire molto se quella che usi (non mi pare, perň...) nella lookup č una vista
nascosta.
Se non sono stato chiaro la spiegazione a domani.
Ciriciao gente!
PS anche te fatti vede' un po' prima, che č tutto il giorno che c'č un
mortorio e ti presenti con qualcosa di interessante ora che sono richiesto
;-)

 accessibili al current user.
Opzione interessante da valutare, ma se le viste gli si aprono
immediatamente come dice... lo user è lo stesso anche per la lookup.
'notte.

 OldSmobile
-- 


 all'apertura del db.
Hummm... come e' fatta la formula di selezione della vista?
Ha delle parti 'cattive' (tipo dataDoc < @Now)?
OldSmobile


Fai come me... mansa la moglie 2 week ad un corso con residency... magari
riceverai meglio la radio ma poi lavori di bestia! :-))

 Baci, Juda.
Vai a fare i compiti invece di baciare me! :))


 ;-)
Prima ho smadonnato un po', tanto per non farmi cogliere impreparato.


 immediati.
Vorrei precisare: le viste non categorizzate balzano piu' o meno
immediatamente sempre, quelle categorizzate invece senza l'ftindex
impiegano un po', la somma dei quattro tempi per visualizzare le 4 viste
categorizzate (senza ftindex) mi sembra compatibile con il tempo per
aprire il primo documento, che ci mette piu' o meno lo stesso tempo
anche nel caso in cui l'indice c'e'.


Altra idea... le DB Lookup funzionano anche se stai aprendo il DB in
Lettura... sebbene poi non vengano usate (di solito le usi solo in Edit
mode... prova ad incapsulare le DBLookup e Le DBColumn in un costrutto del
genere...
@If(
  @IsDocBeingLoaded & !@IsNewDoc;
    @Unavailable;
  @DbLookup(""; Server : Dbase; Vista; Key; 1)
)

 Ha delle parti 'cattive' (tipo dataDoc < @Now)?
no, no, no...



Se ne frega. Pero' ho potuto constatare che in effetti e' colpa della
dbcolumn, infatti nel modificare i campi nel modulo, ho sbagliato a
scrivere il nome delle viste, per cui aprendo il primo documento non le
ha trovate e quindi il documento e' comparso immediatamente. Sul momento
ho pensato: "Cazzo che drago sto' OldSmobile!" poi andando in edit sul
documento, cercando di scegliere un nuovo valore per il campo dalla
lista mi ha detto "...la vista non esiste...". Quindi ora il punto e'
capire perche' non usa l'indice gia' pronto e se lo costruisce tutte le
volte, perche' alla fine penso di aver capito che e' questo che succede.


 Ora scusa ma mi reclamano a letto.
Appena tornato leggo questo  Ma cxentra con il subject del thread? :-P
Fulvio

 volte, perche' alla fine penso di aver capito che e' questo che succede.
Gia'... e' molto strano... pero':
Nelle proprieta' della vista, 'avanzate' (quelle con il cappellino, per
capirci) c'e' la proprieta' che gestisce l'indice (es. 'discard after each
use' non sarebbe il massimo :) e' gia' impostata a never?

 use' non sarebbe il massimo :) e' gia' impostata a never?
Si'.


 per scorrere i valori. O no?
Sembra che se lo cachi comunque...


Ch'azzecca, ch'azzecca eccome!
:))


 Ha delle parti 'cattive' (tipo dataDoc < @Now)?
Questa più che cattiva è stronza, visto che deve buttare via l'indice tutte
le volte e rifarsi da capo.

 Sembra che se lo cachi comunque...
Per cacare vi caca alla grande...
Fatevi rispettare! ;-)
E adesso posso andare a fare i compiti :-P
...a stasera.

e' tutto normale.
Ma sul server si comporta allo stesso modo?
Ciao.
--
Zio Ciano.


Si', anche peggio.


 ha scritto nel messaggio
news:f%Bp7.48358$7Y3.3...@news2.tin.it...

Ho incontrato anche quello! :-((


Eh...stassera! aspetta pure!
Faccio il punto della situazione:
La colpa e' del dbColumn, quindi ho risolto cosi'
ho creato un modulo con un solo campo a valori multipli ed una vista che
seleziona solo quel modulo, non ordinata, nascosta con unica colonna il
campo suddetto. Tale modulo origina un solo documento che viene
aggiornato quando l'utente inserisce nuovi valori dal campo a lista dove
e' rimasto il dbcolumn ma invece di scegliere dalla vista categorizzata
sceglie dalla nuova vista. Il problema dell'ordine degli elementi nella
lista l'ho risolto schedulando un agente che fa il sort dei valori
multipli ogni tanto. A tal proposito mi servirebbe un algoritmo di sort
un po' piu' efficente di quello che ho fatto io (due for nidificati con
scambio per maggiore), per esempio il quick-sort. Con queste modifiche
il tempo di accesso si e' ridotto a zero.


Eh...stassera! aspetta pure!
Qua siamo tutti matti....
Ma non ti stupire se ti risponde potrebbe essere normale.
Sul serio Buona Notte a tutti.
Zio Ciano.

 il tempo di accesso si e' ridotto a zero.
QS?
http://www.iti.fh-flensburg.de/lang/algorithmen/sortieren/quick/quick.htm
http://ciips.ee.uwa.edu.au/~morris/Year2/PLDS210/qsort.html
http://www.hetland.org/python/quicksort.html
http://java.sun.com/applets/jdk/1.0/demo/SortDemo/SortAlgorithm.java