Firefox Nightly: vier Content-Prozesse, verbesserte Prozess-Auswahl
Knapp zwei Monate, nachdem Mozilla den Startschuss für mehrere Content-Prozesse in der Nightly-Version von Firefox gegeben hat, wurde nun die Anzahl der Content-Prozesse auf vier verdoppelt. Außerdem wurde die Prozess-Auswahl verbessert.
Firefox wird seit Version 48 erstmals mit einer Multiprozess-Architektur für einen Teil der Nutzer ausgeliefert, welche unter dem Namen Electrolysis, oder kurz: e10s, entwickelt wird. Seit dem gab es mit jeder neuen Firefox-Version Verbesserungen an dieser sowie die Auslieferung an immer mehr Nutzer. Allerdings findet nach wie vor nur eine Trennung zwischen Browser- und Content-Prozess statt, wobei sich alle Tabs einen gemeinsamen Content-Prozess teilen. In der Nightly-Version von Firefox 54 hatte Mozilla erstmals zwei Content-Prozesse aktiviert.
Nun ist Mozilla knapp zwei Monate später einen Schritt weiter gegangen und hat die Anzahl der Content-Prozesse in der Nightly-Version von Firefox 55 auf vier erhöht.
Bereits vor zwei Wochen war eine Änderung gelandet, welche die Prozess-Auswahl von Firefox verbessert. Bislang hatte es komplett auf Zufall basiert, in welchem Prozess neue Tabs landen. Nun erfolgt die Auswahl des Prozesses auf der Basis, welcher Prozess zum gegenwärtigen Zeitpunkt die wenigsten offenen Tabs beherbergt. Diese Änderung wurde kurz nach der Implementierung in Firefox 55 nachträglich in Firefox 54 integriert.
Langfristig soll die Prozess-Auswahl intelligenter erfolgen, in der Zwischenzeit ist dies aber ein Fortschritt gegenüber der vollständig zufälligen Prozess-Auswahl.
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.
Schön, dass es da jetzt so schnell weitergeht 🙂
Schade nur, dass man noch keine Lösung gefunden hat, wie das Erstellen neuer Contentprozesse nicht den Mainthread blockiert. Zuletzt wurde im entsprechenden Ticket sogar angezweifelt, ob es dafür überhaupt eine Lösung geben kann.
Ich habe zwei Fragen:
1. Ist es geplant, die Zahl der Content-Prozesse zwar immer weiter zu erhöhen, aber immer bei einer Zahl x zu belassen und wenn dann mehr Tabs offen sind, werden immer mehrere Tabs in einem gemeinsamen Content-Prozess sein? Oder ist auch geplant, dass irgendwann jeder Tab seinen eigenen Content-Prozess hat, egal wieviele Tabs man öffnet? So wie man das von anderen Browsern kennt.
2. In Bezug auf den ersten Kommentar: haben andere Browser dasselbe Problem oder wie lösen die das? Würde ein kompletter Wechsel auf Servo das Problem beheben oder liegt das Problem, den Mainthread zu blockieren anderswo?
Es ist vorerst nicht geplant, über vier Content-Prozesse hinauszugehen. Bei dieser Anzahl Content-Prozesse bleibt auch der Speicherverbrauch weiterhin niedriger als der von Chrome. Dafür gibt es (bzw. teilweise muss es heißen "wird es geben") zusätzlich eine ganze Reihe spezieller Prozesse, z.B. für den Zugriff auf lokale Dateien, Service Workers usw.
Auch andere Browser wie Chrome haben übrigens ein Limit an Content-Prozessen. Ich weiß nicht, wo das liegt, höher als bei vier ist es im Fall von Chrome in jedem Fall. Ich habe mal was von maximal 35 Prozessen gelesen, aber das ist schon so lange her, dass diese Zahl längst überholt sein kann.
Ich Wechsel der Engine würde dieses Problem vermutlich nicht lösen, wobei ich auch nicht weiß, wie ernst das Problem überhaupt ist, da ich die Diskussion zu diesem Thema momentan gar nicht im Kopf habe. Ich kann auch nicht viel zu anderen Browsern sagen, da ich dort die Entwicklung gar nicht aktiv verfolge. Aber grundsätzlich betreibt Mozilla derzeit viel Profiling, um alle möglichen Flaschenhälse zu finden und zu beheben, so dass ich guter Dinge bin, was die Performance im Gesamten betrifft.
Was spräche denn dagegen, jeden Tab in einen eigenen Prozess zu packen? Das wäre doch für Sicherheit und Stabilität optimal. Oder würde das zu viel Ressourcen verbrauchen?
Der RAM-Verbrauch würde explodieren und das wäre extrem schlecht für die Stabilität. 😉