[SQLite] Abfragen und Programm zu langsam

WorldRacer

Erfahrenes Mitglied
Hallo zusammen,

arbeite momentan an einem etwas Umfangreicheren Projekt, nämlich einem EMail-Client mit Organizer und Plugins sowie einer Multi-MEssengerfunktion.

Klappt ja alles soweit so gut. Kurz zum Aufbau: Das Programm verwaltet seine Daten innerhalb einer SQLite Datenbank. D.h. Emails, Accounts, Ordner usw sind in den jeweiligen Tabellen einsortiert. Mails Abrufen und senden funktioniert wunderbar, arbeite mit der OpenPop.NET (hpop) Klasse und der SmtpClient Klasse auss dem Framework.

Folgendes Problem tritt nun auf:

Wenn ich meine Mails aus der Datenbank abrufen will, und in einem bestimmten Ordner (den ich über das Interface anklicke, um die Mails aufzulisten) mehr als, sagen wir 30 Mails, existieren, braucht das Programm bestimmt 3 Sekunden und noch länger für den Abruf und die Auflistung in einer ListView. Das wird für den späteren Benutzer sehr lästig sein. Thunderbird hat das irgendwie besser gelöst, doch die haben ja TextFiles als MailDatenbank, da kann ich mir also nichts abgucken.

Allerdings denke ich schon die Ursache gefunden zu haben. Ich habe meine Verwaltungsklassen (in diesem Fall Classes.Mail.MailDirectory und Classes.Mail.MailMessage) so programmiert, dass beim Abruf eines Attributes eine SQL-Abfrage (SELECT) ausgeführt wird. Da das bei jeder Mail bestimmt 10 Mal vorkommt, habe ich knapp 300 Abfragen in einer Kurzen Zeit. Dazu kommt noch der Abruf der EMail-Liste durch Classes.Mail.MailDirectory->MailsInDirectory, was ebenfalls nochmal 30 Abfragen verursacht. (id der jew. Email wird abgerufen)

Wie kann ich das umgehen? Gibt es Caching-Möglichkeiten ohne dass das Programm gleich wortwörtlich den Arbeitsspeicher mit Rumpf und Stumpf auffrisst?

Gleich hier mal eine kleine Kostprobe eines Attributes:

Code:
/// <summary>
        /// Gets or sets the status of the message. If the message has been read, set it to true.
        /// </summary>
        public bool IsRead
        {
            get
            {
                if (DBConnected)
                {
                    // Init Query and select emails table
                    DataBase.DataBaseSelectQuery DirectoryQuery = new DataBase.DataBaseSelectQuery("emails");


                    // Select IsRead-Field
                    DirectoryQuery.SelectFields(new string[] { "IsRead" });
                    DirectoryQuery.AddWhereClause("id = '" + EmailID.ToString() + "'");

                    // Execute the Query.
                    DataBase.DataBaseResult Result = DataBaseHandler.Query(DirectoryQuery);

                    return Convert.ToBoolean(Result.ResultSet[0][0].Value);
                }
                return false;
            }
            set
            {
                        // [...]
            }
}

Vielen Dank schonmal im Voraus!
 
Zuletzt bearbeitet:
Hi

Du kannst Cache entweder temporär halten im RAM oder persistent z.B. in einer Datenbank.
Letzteres ist eher langsam. Du musst dich alao entscheiden.
Vielleicht solltest du aber erstmal versuchen, die Datenbank abfragen zu reduzieren. 10 Abfragen für ein Mail halte ich für definitiv zu viel!
 
Hallo,

danke für die Tipps. Gibt es sonst eine Möglichkeit, die Geschwindigkeit zu optimieren? Denn wenn ich den Cache in die Datenbank schreibe, hab ich ja wieder Abfragen, die Zeit brauchen. Da kann ich das ganze ja im Endeffekt zu lassen. Die Datenbank in den RAM zu schreiben ist unklug, denn eine Maildatenbank könnte durchaus bis zu 4-5GB groß werden :)
 
Hi

Halte nur die Infos im Cache, die du da auch brauchst! Also die Infos, die angezeigt werden, ohne das der Anwender ein Objekt öffnet. In solchen Fällen kannst du dann eine zusätzliche Abfrage ausführen.
 
Die Datenbank in den RAM zu schreiben ist unklug, denn eine Maildatenbank könnte durchaus bis zu 4-5GB groß werden :)

Auch wenn mit SQLite GB-Große Datenbanken möglich sind, denke ich, dass man hier besser auf einen richtigen SQL-Server (z. B. MySQL, PostgreSQL, Firebird, MS SQL etc.) setzen sollte. Die Performance dürfe, bei dieser Größe und Menge an Daten, sicher auch besser sein.

Gruß
 
Hallo zusammen,

@RudolfG: Ich wollte meinen Benutzern eigentlich nicht zumuten, für ein E-Mail Programm einen MySQL-Server zu installieren. Zum einen sind das unnötige Services, die das Allgemeinbefinden des Anwenderrechners verschlechtern, zum anderen ist die Sicherheit eigentlich kein Problem, da es keine Netzwerk-Datenbankapplikation ist.

Gibt es eigentlich noch andere Datenverwaltungsmethoden, abgesehen von XML- und Text-Dateien, die dieses Programm beschleunigen könnten?

Vielen Danke für eure Hilfe!
 
Du wirst nicht viele Optionen haben.

Aber nochmal: Aktuell macht es den Eindruck, dass du entweder alles in den Speicher laden willst oder für jeden Information an die Datenbank gehst.
Beides ist von der Herangehensweise suboptimal (wie du ja schon gemerkt hast). Halte nur die Daten im Speichern, die aktuell für die Präsentation notwendig sind (z.B. Absender, Betreff, Datum, Priorität). Den Rest kannst du laden, wenn die Daten benötigt werden.

Ich kann mir nur nicht vorstellen, das deine Anwendung in Umgebungen mit einer Postfachgröße von 5 GB zum Einsatz kommt. Die Größe solcher Postfächer kommt für gewöhnlich nur Unternehmen vor und da werden Archivierungstools verwendet, um die Postfächer klein zu halten (z.B. Enterprise Vault)
 
Ich kann mir nur nicht vorstellen, das deine Anwendung in Umgebungen mit einer Postfachgröße von 5 GB zum Einsatz kommt. Die Größe solcher Postfächer kommt für gewöhnlich nur Unternehmen vor und da werden Archivierungstools verwendet, um die Postfächer klein zu halten (z.B. Enterprise Vault)

^^Da muss ich dich leider Enttäuschen, denn Ich habe bereits eine Postfachgröße (in Thunderbird) von 7GB. Teilweise kommen bei uns in der Redaktion auch Prostfachgrößen von 20GB vor.
 
Dann solltet ihr ernsthaft über Email-Archivierung nachdenken! Bei solchen Mengen hat jeder Mail Client Probleme

Oder wenn es wirklich notwendig sein sollte, dass man immer E-Mails haben/sehen muss, auf einen SQL-Server zu setzen. Dieser kann/sollte dann auf euren zentralen Redaktions-Server laufen und somit von jeder Arbeitsstation erreichbar sein.

Allerdings fällt mir jetzt auch kein Grund ein, immer auf alle E-Mails Zugriff haben zu müssen.
 

Neue Beiträge

Zurück