Domino 9 und frühere Versionen > ND6: Entwicklung

FT Index einer DB regelmässig kaputt

<< < (2/2)

m3:

--- Zitat von: DAU-in am 11.06.07 - 09:54:56 ---In einer Applikation, die ich betreue, wird sehr viel mit Dokumentlöschungen gearbeitet.
--- Ende Zitat ---


--- Zitat ---Deleting a document and then recreating “the same” document is three times as bad in terms of performance, as just modifying the existing document.
--- Ende Zitat ---
Andre Guirard in "Performance basics for new developers"

Ich würde hier ein Redesign andenken.

DAU-in:

--- Zitat von: m3 am 12.06.07 - 09:24:23 ---
Ich würde hier ein Redesign andenken.

--- Ende Zitat ---

Lieber nicht.
Fürs erste werde ich mich aufs Beten verlegen, und dreimal täglich den Server streichelnn

Gandhi:
Um das ganze mal ein bisschen aufzulösen (schliesslich bin ich der Verbrecher, der das ganze entwickelt hat)

- Die Löschungen sind tatsächlich konzeptbedingt
- Domino war in dem Fall das einzig verfügbare System mit entsprechenden Ressourcen (mir)

Die Löschungen sind aus folgendem Grund notwendig:
Es soll von mehreren Personen gleichzeitig auf das gleiche Dokument (via Browser) zugegriffen werden. Alle diese Personen greifen dabei auch auf gleiche Felder zu.
Hierzu wird dann für jeden Anwender eine Arbeitskopie des Dokumentes für einen Teilbereich erstellt. Bestimmte Felder benutzen wie gesagt alle gleichzeitig.
Beim Speichern dieser Kopie werden die Felder aus dem Bereich in das Original übertragen, die Werte der gemeinsam genutzten Felder (z.B. History) an die Felder des Originals angehängt.
Die Arbeitskopien werden in einen nichtsichtbaren Status versetzt und dann mittels eines periodischen Agenten gelöscht.
Man kann natürlich auch alle Daten auf dem Dokument löschen und einen Pool von leeren Dokumenten halten, die dann wieder als Arbeitskopie benutzt werden können.
Das war in der Phase, in der ich entwickelt habe schlicht nicht nötig - da es zum einen noch keinen FTI gab und zum anderen keine Performance- bzw. Stabilitätsprobleme aufgetreten sind.

Da ich zwischenzeitlich den Arbeitgeber gewechselt habe bin ich nicht mehr auf dem allerneuesten Stand - aber:
- ich bezweifle, dass der FTI überhaupt notwendig ist
- die Applikation ist lange sehr stabil gelaufen (nicht besonders performant aber stabil)
- ich vermute eher, dass die Probleme mit dem Serverumzug zu tun haben - vorher wars ja relativ ruhig. Da gibt es schon einen signifikanten zeitlichen Zusammenhang oder?

Btw.: Die DB ist wirklich SEHR komplex. Xanthi hat das mehr oder weniger unfreiwillig übernommen - grösseres Redesign ist nicht zu empfehlen wenn dann schon eher ein Neuaufbau mit einem anderen, mächtigeren System (J2EE, .NET) - wobei das Teile des Kunden sicherlich nicht freuen wird.

DAU-in:
Seit dem Serverumzug ist jetzt gerade Ruhe (vermutlich die vor dem Sturm).

Ich habe inzwischen den Verdacht, dass eine Kombination aus dem FTI und den nicht löschbaren Dokumenten der Auslöser war.
Aber ich starte jetzt keine Versuchsreihe für die Verifikation dieser Theorie.

Edit: die Servercrashes waren auf dem alten Server. Die Admins konnten immer 2 DBs (mit FTI und immer wieder nicht löschbaren Dokumenten) als Schuldige identifizieren.  Die dritte nahezu identische DB (mit FTI, ohne unlöschbare Dokumente) hat nie einen Servercrash ausgelöst.

Navigation

[0] Themen-Index

[*] Vorherige Sete