• Wir nutzen nun seit Ende Juli die Outlook App und haben schon ein paar E-Mails in Vertec abgelegt. Nach dieser kurzen Zeit fallen aber jetzt schon immense Performance Unterschiede beim Arbeiten mit Aktivitäten zu vorher auf.

    Wenn ich zum Beispiel in unserer normalen Aktivitätensuche (SQL-Ordner) nach allen Aktivitäten vom 1.6 - 30.6 suche, dauert das circa 2-4 Sekunden für ~ 3100 Einträge.

    Suche ich alle Mails vom 25.7 - 22.8 kommt erstmal der "Nicht genügend Arbeitsspeicher" Fehler der schon gemeldet wurde.

    Suche ich dann vom 1.8 - 15.8 braucht die Suche ~1:20min um mir ~1200 Aktivitäten anzuzeigen.

    Der SQL Server braucht laut Profiler "nur" 4 Sekunden davon. Was aber ja auch schon ein Anzeichen dafür ist wie viele Daten da direkt geladen werden müssen.


    Das kann doch so nicht die Zukunft für das Arbeiten mit Vertec und der Outlook App sein.

    Als erstes Problem fällt mir hier auf das das Content Feld direkt beim generieren der Liste geladen wird, was natürlich bei E-Mails mit größeren Anhängen sehr schnell sehr viele Daten sind.

    Gibt es hier evtl. Möglichkeiten das kurzfristig zu optimieren?

    Wir werden ab sofort erstmal wieder alle E-Mails über einen geplanten Task als eml abspeichern, aber das kann ja auch nicht die dauerhafte Lösung sein.

    • Offizieller Beitrag

    Wir haben in der Tat unterschätzt, wieviele (und wie grosse!) E-Mails Vertec Kunden mit der Outlook App vewalten wollen. Insbesondere die viele SEHR grossen E-Mails waren eine grosse Überraschung für uns.


    Aktuelle ist es so, dass sämtliche Daten direkt auf der Aktivität gespeichert sind und darum auch geladen werden müssen. Eine Aktivität mit einer E-Mail mit einem Attachement von 100MB belegt dann 100MB im Memory und muss auch erst von der Datenbank geladen werden.


    Wir haben diese Probleme schon im Frühjahr erkannt und die Lösung ist relativ einfach: wir trennen die effektive Datenspeicherung von der Aktivität. Leider können wir das erst mit den nächsten Major Release (6.6) ausliefern, weil das eine neue Datenbankstruktur benötigt.


    Bis dahin können Sie folgende Dinge optimieren:

    • bei den Aktivitäts-Linktypen (auf Firmen, Kontakten und Projekten z.B.) den Container auf immer anzeigen umstellen. So wird vermieden, dass alle Aktivitäten geladen werden müssen, nur um rauszufinden, ob ein Container angezeigt werden soll oder nicht.
    • Bei den langen E-Mail Listen ist eine Optimierung natürlich schwieriger, aber vielleicht kann man ja verhindern, dass man >1000 als Resultate bekommt? An solche Suchordner haben wir auch nicht gedacht, weil eine Navigation über den Kontext (Kontakt, Projekt, Erfasser) ja auch möglich ist. Welche Anforderung lösen Sie mit den Suchordnern?
  • Den ersten Punkt haben wir schon von Anfang an. Das macht für uns aber nicht wirklich einen Unterschied weil wir wenig mit diesen Containern arbeiten


    Der Hauptgrund für die SQL Ordner sind die besseren Filtermöglichkeiten und Anpassungen. In unseren größeren Projekten haben wir weit über 10.000 Aktivitäten über mehrere Jahre verteilt. Da findet man mit den Filtermöglichkeiten auf den Linktypen garnichts. Deswegen auch schonmal meine Anfrage nach mehr Filtern hier.

    Aber selbst wenn ich mich im SQL-Ordner auf ein Projekt beschränke gibt es schon deutliche Unterschiede. Ein Projekt in dem wir aktuell viele Aktivitäten generieren braucht für das Suchen vom 1.1 - 30.6 3 Sekunden(1600 Aktivitäten) vom 1.7 bis heute 23 Sekunden(400 Aktivitäten).


    Wenn da aber bis zur 6.6 keine Besserung in Sicht ist wird für uns die einzige Option bleiben den Content zu exportieren.