Posts Tagged ‘Performance’

Freitag, 29. September 2017

iOS 11 bereitet meinem iPhone (und mir) Kopfschmerzen

Link zu diesem Artikel

Normalerweise warte ich bei Major-Releases von iOS jeweils die Version X.0.1 ab, bevor ich meinen Gerätepark auf die neue Version des mobilen Betriebssystems „lüpfe“. Diese Woche hielt ich mich nicht an meine eiserne Regel — unter anderem, weil die Medienberichterstattung nicht von gravierenden Problemen berichtete. Ein Fehler, der aber auch nicht mit Abwarten auf X.0.1 Linderung gebracht hätte.

Leider kämpfe ich auf meinem iPhone SE (Kaufdatum: April 2016) mit folgenden permanenten oder sporadisch auftretenden Problemen:

  • Das Gerät ist spürbar langsamer als unter iOS 10 — sowohl das Betriebssystem selber als auch die Applikationen. Wenn ich Podcasts höre und dann Applikationen öffne oder bediene, höre regelmässig verzerrtes Audio, als würde die Podcast-Applikation mit der laufenden Applikation um Systemressourcen kämpfen. Mit der Haptik und der Reaktion fühlt sich das UI eher wie Android als iOS an. Furchtbar! Derzeit tippe ich Probleme mit dem Netzwerkstack (Bauchgefühl, kann ich nicht belegen).
  • Das Thumbnail für soeben gemachte Screenshots wird einige Male nach einem Reboot des Geräts angezeigt, dann nicht mehr. Nach einer Weile macht das Telefon nicht nur kein Geräusch, wenn ich den Bildschirm abfotografiere, sondern das Thumbnail zur Nachbearbeitung wird auch nicht mehr angezeigt. Das Photo selber landet aber anstandslos im Photoalbum. Dabei wäre dies eine der besten Produktivitätssteigerungen mit diesem iOS-Release.
  • Heute verschwand die Statusanzeige (Empfangsstärke 4G/WiFi, Uhrzeit, Batterieanzeige) ganz oben am Bildschirm, wenn der Homescreen und alle anderen Springboard-Screens angezeigt wurde. In den Applikationen selber wurde die Statusanzeige ohne Probleme angezeigt. Ein Neustart behob das Problem.
  • Mail.app hängt regelmässig, wenn ich meine Mails über IMAP und Gmail abrufe. Das Spinning-Icon dreht und dreht, ohne dass die Unified INBOX je aktualisiert wird. Ich muss dann jeweils Mail.app gewaltsam schliessen und neu starten, damit die neuen Mails heruntergeladen werden.
  • Vor einigen Tagen zeigte Waze nach dem Start nur einen schwarzen Bildschirm an. Ich konnte die App nicht starten.
  • Die Sonos-App zeigt nach der Ankunft Zuhause während mehreren Minuten den Splash-Screen an, und stürzt dann urplötzlich ab.

Es bleibt zu hoffen, dass Apple der Ursache des Problems auf der Spur ist und bald mit X.0.2 Abhilfe schafft.

PS: Das Problem beschränkt sich nicht nur auf mein iPhone SE — meine Frau klagt auch mit ihrem iPhone 6s ebenfalls über spürbare Performanceprobleme.

Tags: , , , , , , , , , , ,
Labels: Apple

Keine Kommentare | neuen Kommentar verfassen

Dienstag, 1. November 2016

upc cablecom Performance an der Melchtalstrasse im Breitenrain

Link zu diesem Artikel

Eine Bekannte von mir hat sich vor einigen Wochen darüber beschwert, dass die Performance ihrer Internetverbindung von upc cablecom (Quadruple Play Kabel-Anbieter hier in der Schweiz) in ihrer Wohnung an der Melchtalstrasse im bernischen Breitenrain gelegentlich zu wünschen übrig lässt.

Sie war sich sicher, dass die in ihrem aktuellen Internet-Abo als Best Effort versprochene 200 MBit/s Downloadgeschwindigkeit und 20 MBit/s Uploadgeschwindigkeit während den angesprochenen Phasen nie und nimmer erreicht werden.

Ich habe ihr deshalb Anfangs Oktober 2016 einen Linux-Laptop (Lenovo X200s mit Gigabit-Ethernet, welcher mit Cat 5e-Kabel direkt am Router TP-LINK WNDR3600 hängt) ins Netzwerk gehängt, welcher jede Stunde einen Ookla Speedtest mit dem Fiber7-Server durchführt und mir die Werte zurückmeldet.

Nach drei Wochen Monitoring verfestigt sich das Bild, dass mit der Internet-Anbindung tatsächlich etwas faul ist. An praktisch jedem Tag zeigt sich im RRDtool-Graph dasselbe Bild: Ab ca. 18 Uhr bricht die Downloadgeschwindigkeit von annähernd 200 MBit/s zunehmend ein, erreicht mit ca. 40 MBit/s den Tiefpunkt und erholt sich ab 22 Uhr langsam wieder:

upc-cablecom-melchtalstrasse-bern-tag

upc-cablecom-melchtalstrasse-bern-woche

Meine Vermutung: Im Breitenrain könnte die Studentendichte sowie die Dichte der Yuppies sehr hoch sein. Diese schauen nach Feierabend nicht TV, sondern werfen sich Netflix & Konsorten (vielleicht sogar Bittorrent?) an und streamen sich die TV-Sendungen und Filme ihrer Wahl. Was dafür spricht: Am letzten Wochenende war der Einbruch noch dramatischer als unter der Woche. Der Graph zeigt, dass ausserhalb der Stosszeiten die versprochenen Bandbreiten erreicht werden.

Und nein, meine Bekannte sabotiert sich nicht selber: Sie hat unregelmässige Arbeitszeiten (Früh- und Spätschicht, manchmal auch an Wochenenden), weshalb sie in vielen Fällen von den Geschwindigkeitseinbrüchen gar nichts mitbekommt.

Und was tut der ISP, der hoffentlich über ein viel, viel ausgeklügelteres Monitoring verfügt als ich? Nichts. Wie für unsere Halunken-ISPs hier in der Schweiz so üblich versteckt man sich hinter der Vertragsklausel Best Effort, überbucht das Netz gnadenlos und lenkt den Umsatz nicht in den Ausbau des Netzes, sondern lässt diesen in die Taschen der grosskapitalistischen Shareholder in Übersee fliessen. Und natürlich hofft man darauf, dass der dumme Benutzer nicht auf die Idee kommt, regelmässig Geschwindigkeitsmessungen durchzuführen.

upc cablecom, bitte aufwachen! Im Breitsch braucht es eine grössere Leitung, aber bitte zack zack!

Tags: , , , , , , , , , , , , ,
Labels: Schweiz

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 20. März 2016

Ookla Speedtest für Fiber7 respektive Init7 konfigurieren

Link zu diesem Artikel

Damit der Ookla Speedtest bei mir sauber funktioniert, habe ich mir ein Benutzerkonto angelegt und folgende Einstellungen gemacht:

Ookla Speedtest Fiber7 Settings

Von grösster Wichtigkeit ist es, folgenden Server als Standardserver auszuwählen:

Winterthur [CH] - Init 7

(Gemäss dem HTML-Quellcode handelt es sich um den Server mit der Ookla-ID 3026)

Nur so testet man die theoretisch verfügbare Geschwindigkeit zwischen dem eigenen Router, der Telefonzentrale, in welche das Fiber- respektive das Kupferkabel führt, und dem ISP-internen Netzwerk.

Auf der Test-Oberfläche ist dann der Button „BEGIN TEST. YOUR PREFERRED SERVER“ zu wählen:

Ookla Speedtest Begin Test Preferred Server

Nachtrag

Noch einfacher geht es für uns Linux-Geeks von der Kommandozeile. Ein findiger Zeitgenosse scheint das Ookla Speedtest-Protokoll reverse engineered und seine Erkenntnisse in einem Python-Script zusammengefasst zu haben.

Nachdem man das Script heruntergeladen und ausführbar gemacht hat, misst man die Geschwindigkeit zum Init7/Fiber7-Speedtest-Server folgendermassen:

$ ./speedtest-cli --server 3026
Retrieving speedtest.net configuration...
Retrieving speedtest.net server list...
Testing from Init7 (Switzerland) Ltd. (85.195.234.162)...
Hosted by Init 7 (Winterthur) [117.24 km]: 3.615 ms
Testing download speed........................................
Download: 584.35 Mbit/s
Testing upload speed..................................................
Upload: 498.04 Mbit/s

Tags: , , , , , , , , , , , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Dienstag, 13. Januar 2015

WordPress vor dem Ausreizen des RAM-Speicher bewahren

Link zu diesem Artikel

Seit einigen Wochen finden sich in meiner php.err täglich Einträge wie den folgenden:

...
[12-Jan-2015 14:19:24 UTC] PHP Fatal error:  Out of memory (allocated 9699328) (tried to allocate 78720 bytes) in /blog/wp-includes/script-loader.php on line 528
[12-Jan-2015 14:19:24 UTC] PHP Fatal error:  Out of memory (allocated 8126464) (tried to allocate 49152 bytes) in /blog/wp-includes/comment-template.php on line 2163
[12-Jan-2015 14:19:24 UTC] PHP Fatal error:  Out of memory (allocated 1572864) (tried to allocate 3072 bytes) in /blog/wp-includes/functions.php on line 3514
[12-Jan-2015 14:19:24 UTC] PHP Fatal error:  Out of memory (allocated 6291456) (tried to allocate 3072 bytes) in /blog/wp-includes/post.php on line 670
[12-Jan-2015 19:59:36 UTC] PHP Fatal error:  Out of memory (allocated 19660800) (tried to allocate 8 bytes) in /blog/wp-includes/pomo/mo.php on line 237
[12-Jan-2015 19:59:36 UTC] PHP Fatal error:  Out of memory (allocated 23592960) (tried to allocate 32 bytes) in /blog/wp-includes/pomo/mo.php on line 243
[12-Jan-2015 19:59:36 UTC] PHP Fatal error:  Out of memory (allocated 16252928) (tried to allocate 49152 bytes) in /blog/wp-content/plugins/stop-spammer-registrations-plugin/stop-spammer-registrations.php on line 163
[12-Jan-2015 19:59:36 UTC] PHP Fatal error:  Out of memory (allocated 22544384) (tried to allocate 32 bytes) in /blog/wp-includes/pomo/mo.php on line 237
[12-Jan-2015 19:59:36 UTC] PHP Fatal error:  Out of memory (allocated 18350080) (tried to allocate 1920 bytes) in /blog/wp-includes/default-widgets.php on line 914
[12-Jan-2015 19:59:36 UTC] PHP Fatal error:  Out of memory (allocated 22806528) (tried to allocate 94 bytes) in /blog/wp-includes/pomo/mo.php on line 250
[12-Jan-2015 19:59:36 UTC] PHP Fatal error:  Out of memory (allocated 22282240) (tried to allocate 32 bytes) in /blog/wp-includes/pomo/mo.php on line 243
[12-Jan-2015 19:59:36 UTC] PHP Fatal error:  Out of memory (allocated 20709376) (tried to allocate 12288 bytes) in /blog/wp-content/plugins/wptouch/themes/foundation/modules/sharing/sharing.php on line 126
[12-Jan-2015 19:59:36 UTC] PHP Fatal error:  Out of memory (allocated 20971520) (tried to allocate 12288 bytes) in /blog/wp-content/plugins/wptouch/themes/foundation/modules/social-links/social-links.php on line 54
[12-Jan-2015 19:59:36 UTC] PHP Fatal error:  Out of memory (allocated 21495808) (tried to allocate 12449 bytes) in /blog/wp-includes/pomo/streams.php on line 113
...

Egal, ob ein WordPress-Update, eine Aktualisierung eines Plugins oder Überbuchungen meines Hosting-Servers durch Cyon der Auslöser war — ich wollte mein Log vor solchen Einträgen bewahren.

Nachfolgend eine Anleitung, wie ich vorgegangen bin:

TPC! Memory Usage

Als erstes installierte ich das Plugin TPC! Memory Usage, welches die Speicherauslastung bei jedem Aufruf eines WordPress-Artikels aufzeichnet und im Administrations-Dashboard anzeigt.

Ca. 120 vom Plugin innerhalb weniger Minuten automatisch generierte und versendete E-Mails später hatte ich dann auch herausgefunden, dass ich in der Administrationsoberfläche im schwarzen, vertikalen Menubalken unter Memory Usage > Einstellungen > Notify if memory usage exceeds: den Schwellenwert von 32MB auf 64MB erhöhen musste, um von der Mailflut verschont zu werden.

Der Schwellenwert ist übrigens auch in der Datei tpcmem-core.php hardkodiert, falls jemand den Wert vor dem Upload der Dateien in die WordPress-Installation anpassen möchte:

...
add_option('tpc_memory_usage_email_high_usage', 32);
...

P3 (Plugin Performance Profiler)

Nachdem ich mit dem Plugin und den automatisch versendeten E-Mails die hohe Speicherauslastung durch meine WordPress-Installation bestätigt hatte, stiess ich mit einer Google-Suche auf folgenden Artikel:

How to monitor and reduce WordPress memory usage by plugins

Ich entschied mich, das in diesem Artikel erwähnte Plugin P3 (Plugin Performance Profiler) zu installieren und auszuführen. Beim ersten Durchlauf wurde ich wieder mit TPC!-Notifikations-E-Mails eingedeckt, die Speicherauslastung lag regelmässig über 80 MB.

Die erste Auswertung sah folgendermassen aus:

WordPress Plugin Profile Report
===========================================
Report date: Dienstag, 13. Januar 2015
Theme name: 
Pages browsed: 31
Avg. load time: 2.1364 sec
Number of plugins: 13
Plugin impact: 79.58% of load time
Avg. plugin time: 1.7001 sec
Avg. core time: 0.5284 sec
Avg. theme time: 0.0218 sec
Avg. mem usage: 86.89 MB
Avg. ticks: 88,114
Avg. db queries : 70.94
Margin of error : -0.1139 sec

Plugin list:
===========================================
P3 (Plugin Performance Profiler) - 0.0073 sec - 0.43%
Akismet - 0.0147 sec - 0.86%
Better WordPress Minify - 0.0540 sec - 3.18%
Google Sitemap Generator - 0.0035 sec - 0.21%
Jetpack von WordPress.com - 0.8103 sec - 47.67%
Limit Login Attempts - 0.0257 sec - 1.51%
Simple Lightbox - 0.4993 sec - 29.37%
Stop Spammer Registrations Plugin - 0.0092 sec - 0.54%
SubToMe - 0.0065 sec - 0.38%
Tpc Memory Usage - 0.0311 sec - 1.83%
WP Permalauts - 0.0327 sec - 1.92%
Wp Super Cache - 0.0138 sec - 0.81%
WPtouch Mobile Plugin - 0.1919 sec - 11.29%

Deaktivierung von Jetpack

Eine Google-Suche zeigte, dass ich offenbar nicht der einzige WordPress-Benutzer bin, dessen Jetpack-Plugin mehr als die Hälfte der Ladezeit eines Blog-Artikels ausmacht.

Deshalb entschied ich mich kurzerhand dazu, Jetpack zu deaktivieren. Der nächste Benchmark mit P3 lieferte folgende Zahlen:

WordPress Plugin Profile Report
===========================================
Report date: Dienstag, 13. Januar 2015
Theme name: 
Pages browsed: 17
Avg. load time: 1.2534 sec
Number of plugins: 12
Plugin impact: 60.86% of load time
Avg. plugin time: 0.7629 sec
Avg. core time: 0.4815 sec
Avg. theme time: 0.0994 sec
Avg. mem usage: 76.41 MB
Avg. ticks: 91,763
Avg. db queries : 56.94
Margin of error : -0.0904 sec

Plugin list:
===========================================
P3 (Plugin Performance Profiler) - 0.0014 sec - 0.19%
Akismet - 0.0098 sec - 1.28%
Better WordPress Minify - 0.0315 sec - 4.13%
Google Sitemap Generator - 0.0071 sec - 0.94%
Limit Login Attempts - 0.0108 sec - 1.42%
Simple Lightbox - 0.5075 sec - 66.53%
Stop Spammer Registrations Plugin - 0.0040 sec - 0.52%
SubToMe - 0.0146 sec - 1.92%
Tpc Memory Usage - 0.0284 sec - 3.72%
WP Permalauts - 0.0231 sec - 3.03%
Wp Super Cache - 0.0087 sec - 1.14%
WPtouch Mobile Plugin - 0.1159 sec - 15.20%

Deaktivierung von Simple Lightbox

Das Plugin Simple Lightbox dient dazu, verlinkte Bilder im Grossformat als Overlay über der aktuellen Seite anzuzeigen. Doch war die Funktionalität es wert, über eine halbe Sekunde auf das Plugin zu warten? Ganz klar: Nein.

Ich deaktivierte auch dieses Plugin und führte die Messungen ein drittes Mal durch:

WordPress Plugin Profile Report
===========================================
Report date: Dienstag, 13. Januar 2015
Theme name: 
Pages browsed: 17
Avg. load time: 0.8826 sec
Number of plugins: 11
Plugin impact: 39.13% of load time
Avg. plugin time: 0.3454 sec
Avg. core time: 0.4266 sec
Avg. theme time: 0.1072 sec
Avg. mem usage: 28.44 MB
Avg. ticks: 5,251
Avg. db queries : 55.35
Margin of error : 0.0034 sec

Plugin list:
===========================================
P3 (Plugin Performance Profiler) - 0.0082 sec - 2.36%
Akismet - 0.0118 sec - 3.42%
Better WordPress Minify - 0.0467 sec - 13.53%
Google Sitemap Generator - 0.0064 sec - 1.87%
Limit Login Attempts - 0.0258 sec - 7.46%
Stop Spammer Registrations Plugin - 0.0064 sec - 1.86%
SubToMe - 0.0215 sec - 6.24%
Tpc Memory Usage - 0.0347 sec - 10.05%
WP Permalauts - 0.0271 sec - 7.84%
Wp Super Cache - 0.0110 sec - 3.19%
WPtouch Mobile Plugin - 0.1457 sec - 42.20%

Bravo! Die Zeiten für das Laden der Plugins lag nun durchgehend im Hundertstel-Sekundenbereich, im Fall von WPTouch Mobile im Zehntelssekundenbereich.

Positiver Nebeneffekt: Auch die RAM-Auslastung brach markant ein:

Ursprungszustand 86.89 MB
Ohne Jetpack 70.94 MB
Ohne Jetpack, ohne Simple Lighbox 28.44 MB

Um die doch wirklich nützliche Lightbox-Funktionalität nicht zu verlieren, installierte ich stattdessen folgendes Plugin:

CSS3 Lightbox

Es handelt sich um eine rein CSS-basierte Lösung; der Einfluss auf die PHP-Renderzeiten von WordPress-Seiten ist vernachlässigbar.

Tags: , , , , , , , , ,
Labels: Web

Keine Kommentare | neuen Kommentar verfassen

Donnerstag, 22. August 2013

Midori auf Raspberry Pi von jQuery-Effekten entlasten

Link zu diesem Artikel

Mein Raspberry Pi, welcher ein 24″ Dashboard speist, hat sich in den letzten Tagen vermehrt aufgehängt. Dies mag mit einer Aktualisierung der Dashboard-Software zusammenhängen, insbesondere wohl mit Anpassungen am JavaScript-Code.

Ich setze jQuery als JavaScript-Framework ein und steure damit einige visuelle Gimmicks; beispielsweise schwarze Eselsohren an aktualisierten Tiles, welche innert 30 Sekunden nach der Aktualisierung verblassen und dann ganz verschwinden. Auch wird das Doppelpunkt der Zeitanzeige (HH:MM) so animiert, dass es jede zweite Sekunde ausgeblendet wird.

Dies scheint dazu geführt zu haben, dass die schwachbrüstige CPU des Raspberry Pis voll ausgelastet war. Der Browser Midori, welcher als Vollbild läuft, beanspruchte teilweise bis zu 50% CPU-Last und auch das X-Window-System wieso ähnlich hohe Werte auf. Die Load Average des Raspberry Pis war über 1.

Ich entschied mich deshalb, in den JavaScript-Code eine Weiche einzubauen, welche die grafischen Animationen für schwachbrünstige Browser/Systeme auf ein Minimum beschränkte.

Leider hatte die jQuery-eigenen Konfigurationseinstellung Kollateralschäden zur Folge, weshalb ich den Code selber optimieren musste:

jQuery.fx.off = true;

… funktionierte nicht zufriedenstellend.

Nachfolgend einige Konstrukte, die seit gestern Abend in der Produktion laufen:

Browser-Weiche

var browserIsPerformant = true;
if(navigator.userAgent.match(/(Midori)/)) {
	browserIsPerformant = false;
}

Delay statt FadeOuts

An den zwei Orten, wo ich schnelle (250ms – eine Viertelsekunde) und langsame (30000ms – 30 Sekunden) FadeOuts implementiert hatte, baute ich mit der Variable browserIsPerformant eine Weiche ein. jQuery kennt die .delay()-Funktion, mit welcher Aktionen für eine benutzerdefinierte Zeit (Millisekunden) hinausgezögert werden können. Damit konnte ich sicherstellen, dass die Effekte sowohl in der abgespeckten als auch in der Vollversion des Dashboards zur selben Zeit endeten.

Leider kann .delay() nicht auf .toggle(), .show() und .hide() angewendet werden.

Eselsohren

	if(browserIsPerformant) {
		$(obj).children('.updated').fadeToggle(30000);
	}
	else {
		$(obj).children('.updated').delay(30000).fadeOut(1);
	}

Indem ich im else-Abschnitt den Delay auf 30 Sekunden setzte und den fadeOut auf 1 Millisekunde, ergab sich unter Midori neu keine Performance-Einbusse mehr.

Sekundenanzeige (Doppelpunkte)

	if(browserIsPerformant) {
		$('.separator').fadeTo(250,clockSeparatorMap[opacity]);
	}
	else {
		$('.separator').delay(250).fadeTo(1,clockSeparatorMap[opacity]);
	}

Auch hier arbeite ich mit der .delay()-Funktion, setze sie hier aber „nur“ auf 250 Millisekunden. Anschliessen wird der FadeOut innert 1 Millisekunde gemacht.

Nachtrag

Obwohl Midori nach diesen Anpassungen vorerst stabil lief, fror der Browser nach ca. 10 Stunden erneut ein.

Ich entschied mich deshalb, statt Midori auf Chromium zu setzen:

# apt-get install chromium

… und den Google-Browser folgendermassen zu starten (/etc/xdg/lxsession/LXDE/autostart, via Raspberry PI kiosk mode with Chromium.):

@xset s off
@xset -dpms
@xset s noblank

@chromium --kiosk --incognito http://domain.tld/dash

Auch Chromium (Version 22) hat Probleme mit den opulenten jQuery-Animationen, weshalb ich den JavaScript-Code noch ein wenig anpassen musste:

var browserIsPerformant = true;
if(navigator.userAgent.match(/(Midori)/) || navigator.userAgent.match(/(armv6l)/)) {
	browserIsPerformant = false;
}

Chromium trägt aktuell auch die Prozessorplattform im User Agent-String, im Falle von Raspberry Pi ist das ARM.

Tags: , , , ,
Labels: Web

2 Kommentare | neuen Kommentar verfassen

Sonntag, 10. März 2013

Thunderbird effizient mit einem IMAP-Server und zehntausenden E-Mails verwenden

Link zu diesem Artikel

Neben der lokalen Ablage der Logs meines Linux-Servers unter /var/log leite ich Resultate von Cron-Läufen auch an eine E-Mail-Adresse auf einen in einem Rechenzentrum stehenden IMAP-Server weiter. Einerseits stelle ich so sicher, dass ich im Falle eines verheerenden Hacks auf dem IMAP-Server möglicherweise Informationen extrahieren kann, welche mir bei der Forensik helfen. Ob diese Lösung wirklich das Gelbe des Eis ist sei hier dahingestellt (heute würde ich mich wohl für eine Lösung wie Splunk entscheiden).

Nach langer Zeit habe ich heute wieder einmal per Web-Mail in diesen Account hineingeschaut und musst feststellen, dass sich in zwei IMAP-Ordnern je über 50’000 Mails angesammelt haben. Ich entschied mich, diese Ordner zu säubern. Hierzu verwendete ich aber nicht die vom Hoster angebotene Web-Mail-Lösung Roundcube, sondern Mozilla Thunderbird.

Nachfolgend einige Tipps, wie man mit der riesigen Flut an Mails umgeht:

Alle IMAP-Nachrichte herunterladen

Einerseits habe ich unter

  1. Thunderbird
  2. Preferences
  3. Advanced
  4. General
  5. Config Editor

den Wert von mail.server.default.check_all_folders_for_new auf true gesetzt. Ob dies etwas bewirkt, kann ich leider nicht sagen.

Andererseits habe ich auch bemerkt, dass man alle E-Mails in einem Ordner mittels Command-A auswählt und dann mittels Rechtsklick über die Option „Get Selected Messages“ herunterladen kann.

IMAP-Nachrichten auf dem Server durchsuchen

Unter

  1. Edit
  2. Find
  3. Search Messages…
  4. [x] Run search on server

In meinem Fall funktionierte diese Methode aber nicht; es wurden nur die Bodies derjenigen Mails durchsucht, welche sich bereits lokal auf meiner Festplatte befanden.

Zehntausende E-Mails rasch löschen

Nachfolgende Option verhindert, dass Thunderbird während Minuten nicht mehr reagiert, einen Spinning Beachball anzeigt und in Mac OS X‘ Activity Monitor rot als „not responding“ markiert wird:

  1. Tools
  2. Account Settings…
  3. Server Settings
  4. When I delete a message: (x) Remove it immediately

Dies verhindert, dass zu löschende Nachrichten von Thunderbird im Hintergrund in den Ordner „Trash“ verschoben werden, aus welchem man diese danach noch mittels „Empty Trash“ löschen muss.

Tags: , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen