Mal wieder DB mal schnell, mal langsam

1. offizieller Beitrag

    Hallo zusammen,


    ich habe da mal eine etwas allgemeine Frage zur Performance eins Vorgehend mit @Formel.


    Zur Ausgangssituation:


    In einer meiner Datenbanken gibt es eine Maske, mit welcher logischerweise Dokumente erstellt werden.
    Nun gibt es zu den Dokumenten jeweils ein Antwortdokument, wo diverse Statuswerte gespeichert werden und diese als Icons ins Ansichten angezeigt werden. Diese Antwortdokument können nicht vom normalen User bearbeitet werden.


    Auf meinem Hauptdokument können diverse Personen für Berechtigungen (leserechte) eingetragen werden. Nun müssen diese Personen zwangsläufig auch in das Antwortdokument geschrieben werden, damit das auch für die neuen Leute ersichtlich wird.
    Also mache ich in der Maske des Hauptdokument vor dem Speichern eine Routine, welche in dem Antwortdokmuent ein ComputeWithForm macht. Denn in dem Antwortdokument steht in den Feldern, welche für die Leserechte zuständig sind, etwas in etwa so:


    @GetDocField($REF, "MeinLeseFeldImHauptDokument")


    und das insgesamt 9 mal, da es soviele Felder gibt.


    Nun habe ich das Problem, dass bei manchen Benutzer die Anwendung langsam ist und bei anderen nicht. Die Vermutung, welche ich habe ist die, dass das ComputeWithForm in meiner Hauptmaske und die daraus resultierenden @GetDocFields... die Sache ausbremsen.
    Jetzt wäre ja die Möglichkeit, im hauptdokument vor dem speichern, kein ComputeWithForm des Antwortdokuments zu machen, sondern per Script dort direkt die Lesefelder richtig zu setzen.


    Was meint Ihr?
    Wäre die Scriptmethode performanter als das Compute mit den Formeln?


    Aber vielleicht probiere ich das einfach mal aus. Bin allerdings doch auf Antworten gespannt :)


    Gruß

    Auf jeden Fall ist das schneller, da bei einem ComputeWithForm immer die ganzen Felder neu berechnet werden, während bei einem Durchschreiben eben nur das jeweilige Feld neu gesetzt wird (ohne Berechnung).


    Und mit einer DocumentCollection kannst du das ja sogar für alle auf einmal machen.
    Ist also meiner Meinung nach definitiv der bevorzugte Weg

    • Offizieller Beitrag

    Welche 6.x oder 6.5.x Version setzt Ihr ein?
    Mit einem StampAll hatte ich schon Probleme, wenn ich diesen 2 mail auf die gleiche DocumentCollection ausgeführt habe. Der 2. StampAll machte nichts, obwohl im Debugger die DocumentCollection noch die Dokumente hatte.
    Unter 6.5.4 tritt der Fehler zumindest nicht mehr auf.


    Gruß
    Dirk

    Rein logisches Denken verschafft uns keine Erkenntnis über die wirkliche Welt.
    Alle Erkenntnis der Wirklichkeit beginnt mit der Erfahrung und endet mit ihr.
    Alle Aussagen, zu denen man auf rein logischen Wegen kommt, sind, was die Realität angeht, vollkommen leer.
    Albert Einstein

    Die Sache ist halt die, dass in dem Antwortdokument nur die Felder für die Leserechte erechnet sind und sich eben die Werte aus dem Hauptdokument ziehen. Alles andere sind "normale" Felder, welche durch Hintergrundagenten gesetzt werden.
    D.h., das setzen per Script und die Neuberechnung der Felder durch @Formel hat die selbe Anzahl der Felder zur Folge.


    Eine Documentcollection ist nicht notwendig, da zu jedem Hauptdokument auch nur eins und zwar genau ein Antwortdokument existiert.


    Diali:


    Daher fällt StampAll aus dem Rennen, da es keine Collection gibt.
    Kam vielleicht aus meinem ersten Posting nicht ganz hervor.


    Eingesetzt wird Notes 6.5.4.


    Da ich bisher immer den Eindruck hatte, dass @Formel wesentlich performanter als Script sind, hatte ich die Lösung gewählt.
    Aber augenscheinlich ist es wohl doch sinnvoller hier komplett auf Script und nicht auf ComputeWithForm inkl. @Formel zu setzen.

    Grundsätzlich hast du schon recht, daß Formelsprache schneller ist.
    Bei so einer Konstellation ist es auf jeden Fall mit Script schneller.


    Denn du musst dir nur mal den Unterschied anschauen in dem was effektiv getan wird:


    Formel:


    - Antwortdokument wird neu berechnet
    - Feld 1 macht einen Lookup um sich das Hauptdokument und den Feldwert zu holen
    - Feld 2 macht einen erneuten Lookup um sich das Hauptdokument und den Feldwert zu holen
    ...


    Script:


    - Hauptdokument wird geholt
    - Feld 1 holt sich Feldwert
    - Feld 2 holt sich Feldwert
    ...


    Im Formelfall macht du 9 interne Lookups auf das Hauptdokument, im Scriptfall nur ein einziges Mal.


    Und da diese Lookups von den Aktionen hier die meiste Zeit brauchen hast du so ungefähr den Zaitaufwand auf das 9-fache erhöht

    Hallo zusammen,


    ich müsste das Thema Performance noch mal öffnen.
    Und zwar gibt mir diese Anwendung keine Ruhe, so dass ich mal wieder eine allgemeine Frage habe.


    Es haben sich mal wieder einige Benutzer beschwert, dass die Anwendung ab und zu langsam ist.


    Mal angenommen ein Benutzer arbeitet in einem Antwortdokument. Wenn er dieses speichert, soll ein Wert aus dem Hauptdokument geholt werden und je nachdem, welcher Wert darin steht, wird eine Mail gesendet oder auch nicht.


    Um das durchzuführen, mache ich im PostSave des Antwortdokuments das hier:


    Code
    set mainDoc = view.getDocumentByKey(respDoc.Nummer(0))


    und dann ein


    Code
    if mainDoc.Deaktiviert(0) = "nein" then... sende mailend if


    Nun kann es sein, dass das mainDoc aufgrund von Anhängen mehrere MByte gross ist.
    Jetzt habe ich den Eindruck, dass wenn die if-Zeile ausgeführt wird, das komplette mainDoc (also die ganzen MByte) auf den Client des Benutzers gezubbelt wird. Das kann dann mal je nach WAN-Leitung ein wenig dauern.


    Ich hatte schon die Idee mit einem


    Code
    res = Evaluate({@GetDocField("}+mainDoc.universalid+{";"Deaktiviert")})


    zu arbeiten. Dumm nur, dass ich das nicht bei mir teste kann, da es da ohnehin schnell ist.


    Oder bringt mir das auch nichts, da mainDoc.universalid eventuell auch schon das Dokument rüberzieht?


    Hat jemand eine Idee, was ich da optimieren kann?


    Ausser keine Anhänge zuzulassen. ;)

    Ja, denn zumindest müssen ja mal alle Eigenschaften gelesen werden, unter anderem auch welche Attachments dranhängen.


    Noch performanter wäre es natürlich wenn du über ViewEntries gehen würdest, denn diese greifen nur auf den Ansichtsindex zu und nicht auf die dahinterliegenden Dokumente