Firefox Nightly 54: Mozilla aktiviert mehrere Content-Prozesse
Die neue Multiprozess-Architektur von Firefox hat bereits einige Nutzer erreicht. Dabei findet eine Trennung zwischen Browser- und Content-Prozess statt, wobei sich alle Tabs einen gemeinsamen Content-Prozess teilen. In der Nightly-Version von Firefox 54 hat Mozilla nun mehrere Content-Prozesse aktiviert.
Die Ausrollung der neuen Multiprozess-Architektur von Firefox, die auf den Namen Electrolysis, oder kurz: e10s, hört, befindet sich in vollem Gang und erreicht mit Firefox 51 weitere Nutzer. Noch laufen dabei aber alle Webseiten in einem gemeinsamen Content-Prozess.
In der aktuellen Nightly-Version von Firefox 54 kommen erstmals zwei Content-Prozesse zum Einsatz. Dies sollte im Idealfall für noch mehr Reaktionsfreudigkeit und Stabilität sorgen. Zu einem späteren Zeitpunkt werden mehr als zwei Content-Prozesse aktiviert werden, die genaue Anzahl ist bislang noch nicht klar.
Die Fortschritte für die Aktivierung mehrerer Content-Prozesse in der Developer Edition von Firefox können in diesem Ticket verfolgt werden, für die Beta-Version hier und für die finale Version von Firefox an dieser Stelle.
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, mozilla.de, firefoxosdevices.org sowie sozone.de.
Spricht was dagegen die Prozesszahl jetzt schon zu erhöhen, wenn man ein ausreichend potentes System hat, bei dem einem der Arbeitsspeicherbedarf weitgehend egal sein kann?
IMO wird Firefox nochmal deutlich responsiver wenn man die Prozesszahl erhöht.
Es spricht meiner Meinung nach nichts dagegen, wenn du dir darüber im Klaren bist, dass du eine nicht offiziell unterstützte Konfiguration nutzt und du bei Problemen testen solltest, ob das Problem auch mit der Standard-Konfiguration auftritt.
Grundsätzlich gibt es noch ein bisschen was zu tun, damit mehrere Content-Prozesse einwandfrei unterstützt werden, siehe Abhängigkeiten in den Tickets. Ich denke aber, dass von einem auf zwei Content-Prozesse die Hürde wesentlich größer war als es dann von zwei auf noch mehr sein wird. Ich rechne da also nicht mehr unbedingt mit großen Verhaltensunterschieden, denn mit zwei Content-Prozessen muss Firefox ja bereits mit mehr als einem umgehen können.
Speicherverbrauch hast du angesprochen. Du musst davon ausgehen, dass der noch nicht besonders optimiert ist für viele Content-Prozesse.
In jedem Fall solltest du es nicht übertreiben. Mehrere Content-Prozesse haben definitiv ihren Vorteil, wenn du aber zu viele Content-Prozesse aktivierst, kann sich das auch ins Gegenteil umschlagen. Wenn du 50 Content-Prozesse aktivierst, wirst du vermutlich alleine durch den hohen Speicherverbrauch Performance-Probleme bekommen.
100 Content-Prozesse und selbst der GPU-Prozess funktionieren bestens.
100 Content-Prozesse sind kontraproduktiv, aus so vielen Content-Prozessen kannst du kaum einen Vorteil ziehen. Du würdest vermutlich mit deutlich weniger auch sehr gut auskommen.
Bist du dir sicher, dass der GPU-Prozess bestens funktioniert? Den Schalter layers.gpu-process.dev.enabled gibt es nämlich gar nicht mehr, der heißt jetzt anders. Das heißt, dein genannter Schalter ist damit wirkungslos und macht gar nichts. Der Entwicklungsfokus liegt zudem bislang auf Windows, nicht auf Linux. Es ist auch nur auf Windows standardmäßig aktiviert. Und da dein genannter Schalter wie gesagt ja gar nicht mehr funktioniert…
Du weißt, wofür der Schalter dom.ipc.processCount.webLargeAllocation (ich meine nicht dom.ipc.processCount!) ist? Das glaube ich nämlich nicht, wenn du den auf 100 setzt und auch gar nicht dom.largeAllocationHeader.enabled in dem Zusammenhang erwähnst.
Bei dom.ipc.cpows.allow-cpows-in-compat-addons hast du leider den Wert vergessen. Hast du das auf true oder false stehen? 😉
Ich finde die Vorstellung, dass ein Tab nicht gleich alles mit runterreißt, sehr positiv. Bei 16 GB RAM kann Firefox bei 80 Tabs auch ruhig mal ordentlich etwas schlucken. Kommt doch eh selten vor. Und schnell ist es sowieso.
Der GPU-Prozess taucht(e) in meinem KDE-Systemmonitor auf und verbraucht(e) auch ein paar Prozente mehr CPU, wenn in einem Tab ein Video läuft oder sich sonst irgendetwas (aufwändiger) durchgehend bewegt.
Nun ist auf about:support auch tatsächlich der "Kill GPU Process"-Button verschwunden, der gerne den Desktop crashen lies, als ich ihn klickte. Aber sonst lief alles wunderbar. Dann muss ich mal schauen, wie man ihn wieder aktiviert. Danke für den Hinweis, dass man mich dieses Tests beraubt hat 😉
Kennst du den neuen Wert zufällig? Habe bisher nur https://bugzilla.mozilla.org/show_bug.cgi?id=1314711 gefunden.
"dom.ipc.processCount.webLargeAllocation" fand ich hier https://bugzilla.mozilla.org/show_bug.cgi?id=1147911#c80
und möchte keine Ausnahmen, wenn alles auch so läuft.
Der eine leere Wert ist ein String mit Addons gewesen. Ich möchte keinerlei Ausnahmelisten vorfinden. Entweder es läuft ein Addon in meiner "ideellen Umgebung", oder es fließt raus.
Mein Punkt ist der, dass wenn du den Speicherverbrauch zu stark steigen lässt, Firefox davon eben nicht mehr profitiert, sondern wieder langsamer wird. Man sollte hier einen gesunden Wert finden. Zumal die Prozess-Auswahl für Tabs derzeit ja noch purer Zufall ist und noch keiner besonderen Logik unterliegt.
Der neue Name ist layers.gpu-process.enabled.
Da geht es um den Large-Allocation Header:
https://groups.google.com/forum/#!topic/mozilla.dev.platform/WAaqNIo9Fvc
Abgesehen davon, dass dieser Header in der Praxis noch gar nicht genutzt wird, ich glaube nicht, dass du dafür wirklich 100 Prozesse erlauben möchtest, um Webseiten gigabyteweise die Speicher-Allokierung zu erlauben.
Hast Recht, das ist ein String-Schalter und kein Boolean-Schalter, das hatte ich falsch im Kopf.
Also Tababstürze á la Russisch Roulette 😀
Ich warte gespannt auf die harten Grenzen, Tab=Prozess.
Dankeschön! Beweis: http://www0.xup.to/exec/ximg.php?fid=18220536 ("gpu" statt "tab" als Parameter) Trotzdem habe ich die Hoffnung, dass es auch hier genutzt und verbessert wird. Ein VDPAU (wie mpv -hwdec=vdapau -vo=opengl) kommt ja hoffentlich auch irgendwann mal (https://bugzilla.mozilla.org/show_bug.cgi?id=1210729#c14).
Ich begreife meine Übertreibung, die du offengedeckt hast. Herrje, das und WebGL, ungebändigtes Canvas, WebRTC, Beacons, […] sollten genauso wie ein Mikrofonzugriff hinter einer temporären Permission über das i-Symbol liegen. Aber leider erlaubt das Menü keine spontanen Rechteeinstellungen.
Tab = Prozess wird es bei Firefox ganz bestimmt nicht standardmäßig geben. Das würde den Speicherverbrauch viel zu stark in die Höhe treiben.
Die Masse der Nutzer hat nicht so viel RAM wie du: 😉
https://metrics.mozilla.com/firefox-hardware-report/#detail-ram
Im Idealfall kann das von der Konfiguration des Gerätes abhängig gemacht werden, wie viele Prozesse maximal genutzt werden, ansonsten muss man eben entsprechend niedriger ansetzen. In jedem Fall sind 100 Prozesse bei 100 offenen Tabs als Standard-Konfiguration von Firefox sehr unwahrscheinlich.
Zur Info: In dem Kommentar heißt es "I suggest you try Firefox 51 (developer edition) and try again; as OpenGL accelerated layer are now turned on by default." – Das stimmt leider nicht. Zunächst einmal war das nur auf Nightly-Versionen limitiert, zum anderen wurde vor ca. einem Monat die Beschleunigung für Linux selbst in den Nightly-Versionen wieder deaktiviert.
Ich hoffe, dass das als Scherz gemeint war. Wesentliche Webstandards sollten bitte keine Berechtigung benötigen. Das wäre ja furchtbar, wenn ich für Google Maps eine Berechtigung erteilen müsste.
Ja, die Flags sollten standardmäßig auf die Mehrheit ausgerichtet sein.
Den allgemeinen Hinweis, dass VDPAU mit OpenGL ginge, fand ich auch besser: https://bugzilla.mozilla.org/show_bug.cgi?id=1210729#c6
Und VDPAU wurde bisher eh nicht genutzt.
Kein Scherz. Ist der TorBrowser ein Scherz? Nein. Es ist persönliches Ermessen, wieviel man einer automatischen Datenanalyse offenbaren möchte.
Hau dir das mal in ein Profil; da dürftest du richtig unglücklich mit werden: https://privacy-handbuch.de/handbuch_21u.htm
Auch mit deaktiviertem WebGL und https://addons.mozilla.org/firefox/addon/canvasblocker/ funktioniert Google Maps ganz gut.
Ein ungebedändigtes Canvas oder Beacons (also mit Tab-Schließung noch einen Request abschicken, dessen Antwort man garnicht erwartet) sind ja ein feuchter Traum fürs Fingerprinting/Tracking.
Ein WebRTC wird von uMatrix/uBlock Origin sowieso deaktiviert, wenn man sorgsam die Einstellungen durchgeht. Eine Website sollte nicht nach belieben die IPv4 aus dem internen Netzwerk auslesen können und in sein Fingerprinting einfließen lassen. Da müsste man ja ansonsten sein DHCP auf 15 Minuten stellen. https://www.perfect-privacy.com/german/webrtc-leaktest/
Zu WebGL fand ich den Hinweis sinnvoll, dass dies ja binären Shader hätte, aber trotzdem irgendetwas in dem closed source Grafiktreiber ansprechen könnte, was einem nicht so genehm sein könnte: https://blog.fefe.de/?ts=b32cb04e
Da ich ausschließlich freie Treiber für die RX480 nutze, könnte ich WebGL vertrauen. Das scheint richtig zu sein.
Ich bin mir einfach noch zu unsicher, was zu dem Thema Tracking meine Meinung bezüglich der Abwehrmethoden sein soll(te). Daher schalte ich so etwas erst ein, wenn ich es benötige.
Ich kenne das. Abgesehen davon, dass es ziemlich veraltet ist (einige Optionen existieren längst nicht mehr und andere fehlen dafür in dieser Übersicht), sind einige dieser Einstellungen hochgradig fragwürdig und reduzieren teilweise sogar die Sicherheit von Firefox. Daher kann ich vor diesem Schmarn nur warnen. Einige der Optionen haben mit dem Thema Privatsphäre auch nicht das Geringste zu tun, wo ich mich dann schon frage, ob der Autor dieses Werkes überhaupt versteht, was er da macht, immerhin steht das Ganze unter der Überschrift Privatsphäre.
Google Maps funktioniert ohne WebGL. Das ist aber nicht das, worum es mir geht. Die WebGL-Version ist sehr viel performanter und keinesfalls etwas, auf was zu verzichten ich bereit wäre.
Mein Setup läuft mit 8 Prozessen sehr stabil und ohne bemerkbare Fehler. Der Vorteil von so vielen Prozessen ist, das wenn ich ein Tab schliesse auch der ganze RAM wieder freigegeben wird (und der ist auf einem 32bit System halt schon begrenzt).