b1gMail6 ist zwar mehrsprachig, einige Texte konnten jedoch nur allgemein definiert werden. Zum Beispiel so gut wie alle Texte, die unter „Einstellungen“ anpassbar waren.
In b1gMail7 können solche Texte nun auch abhängig von der Sprache unterschiedlich definiert werden, sodass z.B. englische Benutzer nun auch wirklich alles auf English sehen – auch ihre Termin-Erinnerungs-E-Mail usw.
Die MySQL-Tabelle, welche den E-Mail-Index speichert (bm60_mails) wurde stark optimiert und hat statt 27 Feldern (b1gMail 6.3.1) nun nur noch 18 Felder. Außerdem werden die Mails nun mittels der Benutzer-ID statt der E-Mail-Adresse einem Benutzer zugeordnert.
Diese Maßnahmen sparen Speicherplatz und entlasten somit den MySQL-Server bei großen Mail-Index-Tabellen bedeutend.
Oft wird eine E-Mail über mehrere Seitenaufrufe hinweg gebraucht, z.B. wenn man sie erst öffnet um sie zu lesen, dann um einen Anhang zu öffnen, dann um darauf zu antworten o.ä.
Bisher hat b1gMail die E-Mail dann bei jedem Seitenaufruf neu eingelesen und geparst. Das kostet natürlich immer recht viel Rechenzeit im Vergleich zu anderen Routinen. b1gMail7 bietet als neues Feature die Funktion, die E-Mail nach dem ersten Einlesen und Parsen im geparsten Zustand in einen Cache zu speichern. Wenn die E-Mail daraufhin erneut eingelesen und geparst werden müsste (z.B. weil ein Anhang oder der HTML-Text der Mail angefordert oder gantwortet wird), wird dann einfach das geparste E-Mail-Objekt aus dem Cache geladen.
Wird die E-Mail eine einstellbare Zeitspanne (standardmäßig 15 Minuten) nicht verwendet, wird sie wieder aus dem Cache entfernt, bis sie ggf. irgendwann erneut verwendet wird.
Die Folge: Die Serverlast, die durch einen Benutzer beim Aufrufen, Verwalten und Lesen seiner Mails generiert wird, sinkt erheblich.
Nebenbei noch ein interessantes Ergebnis zum neuen Mail-Parser: Eine 7,9 MB große E-Mail parst dieser – selbst mit angehängtem PHP-Profiler – in ca. 1-1,5 Sekunden. Ein lokales E-Mailprogramm (Apple Mail) braucht dafür auf dem selben Computer 4-5 Sekunden. 🙂 Die Parsing-Geschwindigkeit ohne angehängten Profiler dürfte sogar noch wesentlich besser sein.
