Das Notes Forum

Lotus Notes / Domino Sonstiges => Projekt Bereich => Help-Desk Applikation !!Help!! => Thema gestartet von: orgeler am 05.07.07 - 09:05:11

Titel: Performance Help Datenbank im WAN
Beitrag von: orgeler am 05.07.07 - 09:05:11
Hallo,

wir setzen !!Help!! seit Version 1.0.7 im Internen Support ein. Ich finde eine echt Super Sache. Aktuell verwenden wird Version 1.5.0 Nun soll das ganze auch für unsere Benutzer ( ca. 1400 Notes 6.5) verfügbar gemacht werden.

In der Diskussion ist auch die Verwendung von SAP Soulution Manager als Alternative.

Da nicht alle Supporter am Standort des Servers arbeiten muss die Datenbank zukünftig auch über das WAN funktionieren. Dies ist aufgrund der Performance momentan leider nicht möglich. Bei Replizierung auf die Clients funktioniert ja des Message Handling nicht.

Hat da jemand eine Idee, wie ich die DB so abspecken kann, dass dies auch über eine 1,5 MB Leitung funktioniert ?

Ich habe schon mal etwas an den @dblookup  - no-cache geschraubt, aber bisher keine wesentliche Verbesserungen erzielt.


Titel: Re: Performance Help Datenbank im WAN
Beitrag von: Thomas Schulte am 05.07.07 - 09:41:05
In der Version 1.6 hat Ulrich einiges getan um die Performance zu erhöhen.

Wobei ich jetzt bei mir mit der Version 1.5.3 keine Performance Probleme feststelle wenn ich über eine VPN Verbindung von daheim aus über eine DSL3000 Leitung zugreife. Allerdings habe ich diese Leitung für mich alleine.

Was das Message Handling bei der Arbeit mit Clients angeht, da habe ich eine Lösung eingebaut die die erstellten Dokumente erst einmal abspeichert und sie dann erst nach der Replikation mit dem Server versendet, wenn die mail.box lokal liegt.
Gibt es warscheinlich auch mit der 1.6 (vorausgesetzt unser interner Test läuft zufriedenstellend).
Titel: Re: Performance Help Datenbank im WAN
Beitrag von: orgeler am 05.07.07 - 10:00:31
Hallo Thomas,

danke für die schnelle Antwort. Ich habe das auch mit meiner privaten DSL2000 Leitung über VPN getestet, sowohl mit der produktiven 1.5.0 mit ca. 5000 Dokumenten als auch mit einer migrierten Testdatenbank mit update auf 1.5.3.
Das anlegen eines neuen Tickets dauerte über 60s im Wan, im Lan 1-2 s.

Ich nehme an, dass über die Historie eventuell noch Altlasten in den Konfigurationsdokumenten sind.
Ich werde nochmals eine neue Demo DB aufsetzen und damit nochmals testen.

mfg Ivo
Titel: Re: Performance Help Datenbank im WAN
Beitrag von: Thomas Schulte am 05.07.07 - 10:16:20
Wir haben hier etwas über 46000 Dokumente in der Datenbank und ich stelle über VPN eigentlich keine Verzögerungen fest die wirklich spürbar sind.
Titel: Re: Performance Help Datenbank im WAN
Beitrag von: orgeler am 05.07.07 - 11:21:43
Das läßt mich ja hoffen.

Dann passt bei uns grundsätzlich etwas nicht. Ich habe jetzt eine neue Datenbank aus der von mir signierten Schablone erstellt. Ein Kollege arbeitet gerade im homeoffice. Das manuelle erstellen eines neuen Tickets dauerte bei Ihm über 60s. Ich das heute abend nochmals verifizieren.

Danke
Titel: Re: Performance Help Datenbank im WAN
Beitrag von: Dr.Domino am 05.07.07 - 13:49:49
Hallo Ivo,

ich habe ein ähnlich gelagertes Problem ...

=> http://atnotes.de/index.php?topic=28843.0

Falls Du die "Lösung" findest, dann wäre ich daran
auch seeehr interessiert :-)!

LG
Titel: Re: Performance Help Datenbank im WAN
Beitrag von: orgeler am 05.07.07 - 23:13:04
Hallo,

den Thread hatte ich schon mal gelesen aber nicht mehr gefunden. Wie von Ullrich vorgeschlagen habe ich mal die nicht compilierten scripte gesucht und siehe da, ich komme auch zu dem Ergebnis

Note:
$ACTIONS    Action: TransferToMail (10) not compiled         
Note: $ACTIONS    Action: CancelCurrentDocument (11) not compiled 
Note: HD Anfrage    Action: TransferToMail (11) not compiled       
Note: HD Anfrage    Action: CancelCurrentDocument (12) not compiled
Note: HD Aufgabe    Action: CancelCurrentDocument (11) not compiled

In den shared Actions habe ich dann zum Test  die Zeilen auskommentiert:

'   holders = uidoc.document.LockHolders
'   If holders(0) <> "" Then
'      Forall h In holders
'         lockmessage = lockmessage & h & Chr(13)
'      End Forall
'      Messagebox lockmessage,, "Lock holders"
'      Exit Sub
'   End If   

Dann waren nur noch die Fehler in der Maske HD Anfrage fehlerhaft

Note: HD Anfrage    Action: Ticket\CancelCurrentDocument (10) not compiled
Note: HD Anfrage    Action: TransferToMail (15) not compiled
Note: HD Aufgabe    Action: CancelCurrentDocument (13) not compiled

Als nächstes war ich dann mal so frei, die Maske HD Anfrage zu löschen.

Und siehe da, alle performt auf bei Wa(h)nzugriff wie man das erwartet.

Eine Lösung ist das natürlich nicht,  denn ohne die Maske kommt man ja schlecht aus.

Die Actions Ticket\CancelCurrentDocument und TransferToMail habe ich gefunden und durch Kopien Ticket\CancelCurrentDocument1 und TransferToMail1 ersetzt

Aber wo ist die Action CancelCurrentDocument ?

Übrigens: Bei einer lokalen Replik sind alle Scipte compiliert und die performt auch wie man sich das wünscht.

Mal gespann wie das weitergeht.

orgeler
Titel: Re: Performance Help Datenbank im WAN
Beitrag von: eknori am 11.07.07 - 08:56:41
Kaum zu glauben. Ich habe die shared actions mal unshared. Das ist ein enormer Unterschied. Dann werde ich mal anfangen, das DBDesign dahingehend anzupassen ...
Titel: Re: Performance Help Datenbank im WAN
Beitrag von: Thomas Schulte am 11.07.07 - 10:20:01
Hmm das sind beides Lotus Script Aktionen. Könnte es sein das wir da das gleiche Problem haben wie bei Subforms?
Titel: Re: Performance Help Datenbank im WAN
Beitrag von: eknori am 11.07.07 - 13:35:22
Die Scripte kompilieren nicht, weil die Varialblen holders und lockmessage nocht deklariert sind. Option Declare meckert an der Stelle auch nicht.

Fügt mal die Zeilen

Dim holders as Variant
Dim lockmessage as String ein

kompilieren die Scripte nach dem Speichrn und das Tool zeigt hier auch keine Unregelmäßigkeiten an.

Die Zeilen fehlen in allen shared actions in denen die beiden Variablen verwendet werden...
Titel: Re: Performance Help Datenbank im WAN
Beitrag von: eknori am 11.07.07 - 18:00:34
Ich habe jetzt alle shared Actions so umgebaut, daß dort außer dem eigentlichen Funktionsaufruf kein Code mehr vorhanden ist, der irgendwie in die Suppe spucken könnte. Der eigentliche Code befindet sich in der lib.appl.functions ( erst einmal ).
Die scripte kompilieren jetzt auch einwandfrei. Die Datenbank ist in der Tat auch deutlich performanter. Gabe das im direkten vergleich mit einer nicht modifizierten Datenbank immer und immer wieder getestet.

Ich hoffe, daß es das jetzt zum Thema Performance gewesen ist. Nach all den Modifikationen, die ich unter dem Gesichtpunkt Performance an der Datenbank gemacht habe, fällt mir momentan nichts mehr ein, wo man noch etwas rausholen kann.
Titel: Re: Performance Help Datenbank im WAN
Beitrag von: orgeler am 13.07.07 - 06:37:22
Hallo,
ich habe die letzen Tage noch weitergeforscht warum das bei mir über die WAN Leitung so träge ist.
Bei etlichen Views ist mir in den Properties der Haken bei "Verbergen Formeln von Aktionen bei jedem Dokwechsel prüfen" aufgefallen.

Ich habe den mal zum Test bei den Sprach und Config Ansichten entfernt. Dadurch war das Navigieren in den Konfigansichten über die WAN Leitung und auch im lokalen Netz deutlich besser.

Ich habe mal die normale Mailschablone  durchgeschaut. Dort ist die Option nirgends aktiviert. Was ist der Hintergrund für die Aktivierung?

Gibt es eine Möglichkeit, die 1.5.4 (1.6?) als beta zu testen?

Titel: Re: Performance Help Datenbank im WAN
Beitrag von: eknori am 13.07.07 - 06:41:06
ja, das ist in der neuen Version auch raus. schicke mir mal deine mail adresse, bitte
Titel: Re: Performance Help Datenbank im WAN
Beitrag von: Thomas Schulte am 13.07.07 - 14:49:54
Der Hintergrund ist vermutlich das wir es beim Kopieren einfach vergessen haben.
Allerdings hat es bei den Ansichten bei denen über den "Bearbeiten" Button Dokumente direkt im Bearbeitungs modus geöffnet werden können den Sinn gehabt, das bei Dokumenten die nicht mehr aktiv sind der Button Bearbeiten nicht erscheint.

Ich weis. Security by Obscurity ist schlechter als schlecht aber so haben wir das halt gebaut.