Multiprozess-Firefox: Mozilla weitet Beta-Test von e10s aus
Bereits während der Beta-Phase von Firefox 44 gab es per Telemetrie-Experiment erstmals einen Test der kommenden Multiprozessarchitektur Electrolysis, oder kurz: e10s, in einer Beta-Version von Firefox. In der Beta-Phase von Firefox 45 folgen zwei weitere Tests, dieses Mal mit mehr Nutzern.
Unter dem Namen Electrolysis, kurz: e10s, arbeitet Mozilla bereits seit einiger Zeit an einer Multiprozessarchitektur für Firefox. Bislang ist diese ausschließlich in der Nighly-Version sowie Developer Edition von Firefox standardmäßig aktiviert. Während der Beta-Phase von Firefox 44 gab es erstmals einen Beta-Test per Telemetrie-Experiment.
Das damalige Telemetrie-Experiment mit einer maximalen Laufzeit von 15 Tagen erreichte 15 Prozent der Beta-Nutzer, wovon die Hälfte als Kontrollgruppe mit deaktiviertem e10s zählte. Effektiv fand also eine Aktivierung von e10s für 7,5 Prozent der Beta-Nutzer statt.
Mit den Verbesserungen aus weiteren sechs Wochen Entwicklung wiederholt Mozilla nun das Telemetrie-Experiment mit der Beta-Version von Firefox 45. Dieses Mal nehmen 50 Prozent der Beta-Nutzer am Telemetrie-Experiment teil, wobei wieder die Hälfte der Nutzer zur Kontrollgruppe gehört, womit eine effektive Aktivierung von e10s für 25 Prozent der Beta-Nutzer von Firefox erreicht wird. Nutzer des Add-ons LastPass in Version 3.x werden von dem Telemetrie-Experiment ausgeschlossen.
Im Laufe der Beta-Phase von Firefox 45 ist noch ein zweites Telemetrie-Experiment angedacht. Im Unterschied zum ersten Telemetrie-Experiment werden bei diesem alle Nutzer mit installierten Add-ons ausgeschlossen.
Nach derzeitiger Planung soll Electrolysis erstmals mit Firefox 46 in einer finalen Version von Firefox ausgeliefert werden. Allerdings nur für Nutzer ohne Add-ons, für Nutzer ohne aktivierte a11y-Features (dazu zählen neben Screenreadern oder einer Bildschirmlupe unter anderem auch Geräte mit Touch-Bildschirmen, virtuelle Maschinen oder Anwendungen, um den Computer aus der Ferne zu steuern) und nicht für Nutzer, die Firefox in einer Sprache nutzen, in welcher von rechts nach links geschrieben wird.
Sören Hentzschel ist Webentwickler aus Salzburg. Auf soeren-hentzschel.at informiert er umfassend über Neuigkeiten zu Mozilla. Außerdem ist er Betreiber von camp-firefox.de, der ersten Anlaufstelle im deutschsprachigen Raum für Firefox-Probleme aller Art. Weitere Projekte sind firefox.agenedia.com, firefoxosdevices.org sowie sozone.de.
Ich bin ja mal gespannt ob e10s wirklich in Firefox 46 final aktiviert wird, wenn ich sehe wie viele Probleme das noch hat, bezweifle ich es eher.
Um welche Probleme geht es dir denn ganz konkret, wenn du bedenkst, für wen e10s in Firefox 46 deaktiviert bleiben wird? Add-ons, a11y-Features und RTL-Sprachen fallen als Problemquellen ja komplett weg, da all dies zur Nicht-Aktivierung von e10s führt.
Größtes Problem ist bei mir die Performance, auf meinem Desktop läuft es sehr flüssig, aber auf meinem alten Core2Duo-Notebook sehe ich mit der Implementation in 46.0a2 ständig den Ladekreis beim Tabwechsel.
Immer wieder verdeckt auch der alte Tab den Inhalt des neuen, gerade wenn Inhalte wie Videos im Spiel sind.
Es fühlt sich einfach noch nicht wirklich polished an. Andererseits kenne ich niemanden der nicht wenigstens ein Addon aktiviert hat, von daher dürften es Viele überhaupt zu Gesicht bekommen.
Auch vollkommen ohne Add-ons? Denn Add-ons sind derzeit noch der Haupt-Flaschenhals bei e10s, nicht grundlos wird e10s in Firefox 46 nur für Nutzer ohne auch nur ein einziges Add-on aktiviert.
40 Prozent der Firefox-Nutzer haben kein einziges Add-on aktiviert.
https://bugzilla.mozilla.org/show_bug.cgi?id=1229949#c8
Das mit den Addons müsste ich tatsächlich mal ausprobieren. Ich war bisher der Meinung, dass nur Addons, die Gebrauch von bestimmten compatibility layers machen, stark ausbremsen.
Ich glaube, dass noch einige Add-ons sogenannte CPOWs nutzen:
https://developer.mozilla.org/en-US/Firefox/Multiprocess_Firefox/Cross_Process_Object_Wrappers
Und die bremsen stark aus, siehe Abschnitt "Limitations". Innerhalb von Firefox selbst hat Mozilla die Verwendung in den letzten Monaten stark reduziert.
Auf meinem Notebook bin ich mit der Performance auch nicht ganz zufrieden. (Ich benutze keine Addons auf dem Notebook)
Der Unterschied zu Firefox ohne e10s wird zwar immer kleiner, ist aber immer noch da. Am Desktop habe ich dagegen trotz Addons keine Probleme.
Das größte Problem sind trotzdem Addons. Ich habe zwar für alles was ich brauche eine e10s kompatible Alternative gefunden, allerdings werden normale Nutzer eher Firefox beschuldigen wenn der Browser auf einmal langsamer wird.
Man kann nur hoffen, dass Addon Entwickler möglichst bald ihre Addons optimieren. Wegen den neuen WebExtensions befürchte ich allerdings, dass viele Entwickler eher abwarten werden.
Wie kann man denn feststellen, ob man in der Kontrollgruppe oder e10s tatsächlich aktiviert ist?
Der Multi-process Firefox A/B Test erscheint bei mir zwar unter Experimente, im Windows-Taskmanager findet sich jedoch nur ein Firefox-Prozess.
about:support hat ganz am Ende eine Kategorie für Experimente. Dort liefert die Spalte "Zweig" die Information.
Wie sieht es mit e10s eigentlich bei der Android Version aus? Wird es das dort auch in absehbarer Zeit geben? Irgendwie liest man über die Änderungen des mobilen Browsers eigentlich viel zu wenig – bzw. weiß ich immer nicht, was jetzt auch dafür gilt und was nicht…
Dann bin ich wohl in der Experimentgruppe =). Und gerade wollte ich schreiben, dass ich bisher absolut keinen Unterschied feststellen konnte, da stell ich fest, dass die Eingabe eines @ Firefox zum Absturz bringt (hängt 100%ig mit einem Add-on zusammen). Aber sonst bisher super, Speicherverbrauch scheint sich auch nicht geändert zu haben.
"Sollen" denn in Zukunft wie bei Chrome auch nur einzelne Tabs abstürzen, wenn es unerwartete Fehler gibt?
Und ich wollte gestern schon rumnölen, dass es bei mir wieder seit Wochen unverständlicherweise wegen angeblichem a11y deaktiviert wurde, wo dann auf einen Bugzilla-Beitrag ohne Logik verwiesen wird. Und siehe da, es läuft wieder. Wobei ich mittlerweile gar keinen Unterschied zum normalen merke. Zuvor waren da ja immer kurze Ladescreens wenn man den Tab wechselte.
Ich kanns offiziell auch nicht deaktivieren, da die Checkbox dort gesetzt und dann disabled wurde ? Kann man aber mit dem HTML-Inspektor austricksen… ?
Interessanter Beitrag, aber 1 (Pflicht)Add-on in Form eines Werbeblockers ist für mich unabdingbar. Wenn 40% der Nutzer gänzlich "Ohne" unterwegs sind, so ist das auch für mich eine große Übereraschung.
Gerade unser geliebter Fuchs, als einer der einfachsten "Baukästen", verleitet ja beinahe von selbst dazu.
Für mich bleibt Firefox in Kombination mit Win 10 übrigens weiterhin die ganz klare Nr.1. Keiner hat eine bessere, fehlerfreiere Seitendarstellung und Geschwindigkeitsnachteile kann ich, vergleichsweise mit den Mitbewerbern auch nicht bemerken.
@katze_sonne:
Nein, wird es nicht. Firefox für Android war ein Multiprozess-Browser, als Firefox für Android noch XUL-basiert war. Aber dann wurde Firefox für Android ganz neu geschrieben und das wurde sein gelassen, auch um die Speicher-Anforderungen zu reduzieren. Es gibt keine Pläne, daran etwas in absehbarer Zeit zu ändern. Aufwand / Gewinn wären hier in keinem so guten Verhältnis. 😉
Das Wenigste gilt gleichzeitig für den Desktop und für Android, da es sich bei Firefox für den Desktop und Firefox für Android um vollkommen voneinander unabhängige Produkte handelt. Die Gemeinsamkeit ist nur die Gecko-Engine.
@Anon:
Mittelfristig ja, aber nicht in der ersten Version e10s, welche in einer finalen Version von Firefox ausgeliefert wird und derzeit per Telemetrie-Experimenten getestet wird. Da gibt es nur einen einzigen Content-Prozess für alle Webseiten zusammen, es geht also erst einmal nur darum, Content und Chrome (also die Firefox-Oberfläche) voneinander zu trennen. Wenn das erst einmal gut läuft, ist es zu verschiedenen Content-Prozessen auch nicht mehr ganz weit entfernt, aber bevor es mit einem Content-Prozess nicht gut genug läuft, hat das überhaupt keine Priorität. Sobald das kommt, wird natürlich auch der Speicherverbrauch etwas höher sein.
@petzichen:
Ist die Frage, ob das sinnvoll ist, denn für die Deaktivierung gibt es normalerweise Gründe. Wenn nicht einmal Mozilla davon überzeugt ist, dass es unter deiner Konfiguration gut genug läuft, würde ich warten, bis sich das ändert. 😉
@Sören: Ich finde es ja in Ordnung, dass man es nicht aktivieren kann, wenn es Probleme noch gibt, aber wenn es aktiviert ist, möchte ich in einer Vorabversion die Möglichkeit weiterhin nutzen können um es zu deaktivieren. Eine gesetzte Checkbox die dann nicht gelöscht werden kann, verfehlt ihren Sinn; zumindest hier.
Bist du dir denn sicher, dass e10s aktiviert ist? Das glaube ich nämlich nicht, wenn die Checkbox deaktiviert ist, selbst wenn der Haken sichtbar ist.
Meinst Du, dass e10s deaktiviert ist obwohl das Häkchen gesetzt ist? Glaube ich auch (siehe erster Kommentar von mir). Wenn ich über den Inspektor das disable auf false setze kann ich es ändern. Ich bekomme die Meldung "Muss neu gestartet werden" und "es wird eine Feedback-Seite geöffnet". Danach ist das Häkchen auch weg. Auch kann man es ganz normal bedienen 😀 Wenn man es nun aktikviert und neustartet, fängt das Spielchen von vorne an.
Ist aber vielleicht nur ein temporärer Bug. 😉
Temporär mit Sicherheit, alleine deswegen, weil irgendwann der Punkt kommen sollte, an dem jeder e10s erhält. 😉
Was genau sind denn die (verbliebenen) Vorteile von e10s? Ich lese hier, die Performance geht runter (oder zumindest nicht rauf). Ich dachte aber immer, Performance dank Lastverteilung auf mehrere Threads (und damit im Idealfall auch mehrere CPU-Kerne) sei einer der Hauptgründe für e10s.
Und wenn zunächst Add-Ons ausgeschlossen sind, und auch die Plugin-Fähigkeit immer weiter ausstirbt (NPAPI tot, Flash haben immer weniger, Sun will das Java-Browser-Plugin loswerden, sonst gibt es kaum noch was), dann bleibt ja auch kaum Anwendungsspielraum für die Abstursicherheit (bei Plugin-Absturz würde nur dessen Thread abstürzen).
Was bringt e10s denn nun konkret im großen Stile für mich als Endnutzer, mit Add-Ons?
Hauptsinn von e10s sind eine verbesserte Sicherheit, eine erhöhte Stabilität sowie eine verbesserte Reaktionsfreudigkeit. Das meint nicht Performance, sondern dass das Hängenbleiben eines Scripts beispielsweise nicht mehr wie ohne e10s den kompletten Browser ins Stocken bringt. Mehrere Threads nutzt Firefox eh, dazu braucht es keine Prozess-Separation.
Firefox mit e10s soll natürlich nicht langsamer als Firefox ohne e10s sein, sondern mindestens genauso flott (schneller sein ist kein explizites Ziel), aber natürlich ist der Aufwand mit e10s deutlich höher, so dass es entsprechend vieler Optimierungen braucht, um die damit verbundenen Defizite zu kompensieren. Die Performance wird immer besser, ist aber noch nicht im Idealzustand. Das gilt besonders, wenn Add-ons verwendet werden, welche nicht für e10s optimiert sind und damit blockieren. Performance war die meiste Zeit der e10s-Entwicklung einfach überhaupt keine Priorität, sondern ausschließlich die Funktionalität. Performance kam erst in den letzten Monaten als Entwicklungsfokus dazu. Und die Entwickler von Add-ons werden auch erst nach und nach mitziehen.
Für Endnutzer mit Add-ons bringt e10s genau das Gleiche wie für Endnutzer ohne Add-ons. Nutzer mit Add-ons erhalten e10s halt später, wenn sowohl Firefox weiter optimiert ist als auch mehr Add-ons optimiert sind. Es geht darum, e10s zunächst einmal überhaupt an Nutzer auszuliefern, an die es auslieferbar ist, statt e10s für alle zurückzuhalten, bis es für alle nutzbar ist. Besser ein Teil der Nutzer profitiert als kein Nutzer.
Update: Auch Nutzer des Skype Click-to-Call Add-ons werden mittlerweile im derzeitigen Telemetrie-Experiment ausgeschlossen.