Zu den Ansichten: da der Agent einmal wöchentlich (ich vermute am Wochenende) läuft, können die Ansichten in der einen Datenbank mit einem Programmdokument aktualisiert werden (updall). Wenn das Programmdokument am Sonntag abend oder am Montag morgen läuft, ist der Ansichtsindex aktuell wenn die Benutzer darauf zugreifen.

Auch wenn die Anwender dann per CSV-Export damit arbeiten, muss der erste Anwender der exportiert dann nicht 30m warten bis der Index aktuell ist.

Test-DB (ND14, ODS 55) mit einer Maske (10 Felder) und einer View (4 Spalten, eine Sortierung) angelegt.

Mit einem Agenten (20-Zeiler) nacheinander 100, 1.000, 10.000, 100.000, 1.000.000 und zuletzt 10.000.000 Dokumente samt Inhalten erzeugt. Zwischendurch auch ein paar gelöscht.

Testergebnis
Dokumente: 10.111.000 (zzgl. ca. 150 Deletionstubs)
Größe DB (physisch): 5GB (4.994.105.344 Bytes ohne Index, da ausgelagert)
Größe des Viewindex: 2GB (2.001.334.272 Bytes eine View mit allen(!) Doks und 4 nicht sortierbaren Spalten, ausgelagert per NIFNSF)

Die Test-Dokumente haben je 10 (gefüllte) Felder, davon 2 x Date/Time, 4 x Text und 4 numerische Felder gemischt mit ganzen und Gleitkommawerten. Ca. 200-250 Bytes je Dokument.

Index (der einzigen View) komplett neu aufbauen braucht ca. 7 Minuten, reine Updates brauchen natürlich weniger, hab ich aber nicht gemessen.

Die Zeit zum Anlegen/Schreiben von Dokumenten war bis 10.000 kaum bis gar nicht messbar, erst bei 100.000 brauchte der Agent etwa 30-35s und für je 1 Mio brauchte das Script weitere 5-6 Minuten.

DB öffnen, Dok öffnen (oder ändern und speichern), Scrollen, Sprung zum ersten oder letzten Dokument (bei aktuellem Viewindex): alles unter 1s

Ich habe an diversen Stellen bei der DB natürlich Dinge abgeschaltet, die die Performance negativ beeinflussen, wie z.B. Unread Marks, Activitylogs oder automatische Viewupdates. Andere Dinge, wie z.B. Dok-Komprimierung, Translog oder NIFNSF habe ich dafür wieder bewusst eingeschaltet.

Auch nicht ganz unwichtig: der Server hierbei ist ein reines Testsystem (Win2k19), nichts besonders Performantes aber dafür auch keine Nutzer oder Hintergrundaktivitäten die bremsen.

Was mir bei deinem angefragten Szenario fehlt sind die Erwartungen, also was für wen und wie oft genau soll die DB eigentlich abliefern. Guckt da einmal im Jahr einer rein und exportiert die Statistik nach Excel oder wollen 500 Kunden täglich live ihre Statistiken per HTTP rausholen.
Die von dir geschilderten Schreibvorgänge sind für sich genommen kaum der Rede wert - siehe weiter oben, selbst bei über 1000 neuen Dokumenten schreiben war der Agent schneller fertig als ich Käsekuchen sagen könnte.

Viel interessanter ist das, was danach kommt, also das, was du NICHT gefragt hast

HTH, Carsten

Wenn für jeden der 500 Kunden ein Dokument für jeden Tag im Jahr erstellt werden soll, dann sind das in Summe

365 x 500 = 182500 Dokumente pro Jahr


Ob der Agent dann täglich läuft und somit jeden Tag für jeden Kunden ein Dokument erzeugt (500 x 1 x 365 = 182500)

oder ob er wöchentlich läuft und somit jede Woche für jeden Kunden 7 Dokumente erzeugt (500 x 7 x 52 = 182000) macht im Endeffekt keinen großen Unterschied.

Wie dabei unterm Strich jedoch knapp 9,5 Millionen Dokumente pro Jahr entstehen sollen, erschließt sich mir noch nicht.

Problem war das aktivierte Autoprocessing in der Mail-DB.
Das läuft anscheinend vor "Before new mail arrives"..
Jetzt klappt es.

Hallo zusammen,

vor einigen Tagen habe ich mir auf einem Client bei der Suche nach einem anderen Problem irgendwie dieses Fenster mit dem Titel "Arbeitsbereichprotokoll" eingeblendet. Leider finde ich keine Stelle, um es wieder loszuwerden.

Auch wenn es vermutlich nichts mit der Version zu tun hat, Client ist ein 14.0FP3
Kann mir da bitte jemand auf die Sprünge helfen?

Carsten