Firefox / performance check

Firefox melyik kiegészítője vagy weboldala viszi el a legtöbb erőforrást? Nyisd meg az alábbit. Egészen egyszerű és jól áttekinthető felületet ad.

about:performance

További beállítások:

about:about

Hozzászólások

Ha már performance: mi azt vettük észre, hogy a Firefox indítása után gyakran hosszú ideig "balra pörög a mosógép", amikor meg akarunk nézni egy weboldalt. Ilyenkor a Safebrowsing adatbázisát frissíti, néha akár 15-20 másodpercig is. Amíg meg nincs a frissítés, addig nem töltődik be a weboldal. A Safebrowsing kikapcsolásával instant jön minden, ahogy feljön a böngészőablak.

Biztos nagyon jó dolog az a Safebrowsing, de a felhasználónak nem biztos hogy megér minden böngésző-indítás után többezer I/O műveletet. (Meg-trace-eltük: ugyanazt a pár tucat fájlt nyitja-írja-csukja csillió alkalommal. I/O optimalizálás nemrulez?)

Nálam szemmel láthatóan lagol a kurzor gépelés közben a legtöbb textbox-ban, gmail és facebook a legzavaróbb. Nem tudom mitől lehet, de fura így 2016-ban.

az megvan, hogy amikor elmegy a net(gyenge a wifi pl., es le fol kapcsolodik), akkor neha a firefox rakapcsol es eszi a procit teli szajjal?

Ilyenkor mindig elkepzelem, higy ezt is ugy fejleszthetik, hogy bemegy a csakokam, berugja a gepet reggel, iszik egy kavet majd tolja a kodot a legkondis irodaban, ami persze tripla 10gbites optikai halon logmeg tovabbi 2 radios backuppal, es csak a hecci kedveert meg 2 hotspot is be van allitva.

Konkretan valoszinubb, hogy az irodajaban van internet minthogy van aram.

Persze hazamegy, es nyitja meg a safarit az ipaden....

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

es ezt mind eszrevehetne magarol...

self check, vagy valami ilyesmi. Nem akarom osztani az eszt, de pl.
en szoktam olyat csinalni, hogy netet ellenorzok, memoriat ellenorzok es osszehasonlitom az elmult 10 ellenorzesem atlagaval. Ezt percenkent a webszerver sajat magarol (esetemben node.js).

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Bizony, van olyan amikor a csigabigát állítják be a Formula One időmérő bírójaként.
Talán értelme is van, de nem sok. :)

Hát igen, ez a megközelítés jobb lenne. Sajnos ezzel nagyon használhatatlanná válik a web, ha rengeteg új oldalt kell megtekinteni a munkához. Így én jelenleg mindent engedélyezve tartom, és kézzel folyamatosan tiltom le az oldalakat. Így a visszatérő oldalaknál nincs sebesség probléma.

Tán off valék. ;)
Csak arra az élményre gondoltam, amikor egy routert szólítottam meg valami primitív brózerrel, és megdöbbentem a sebességén. Egészen odáig elfogadtam, hogy a routerbe belegyömöszölt webszerver nem egy táltos. Ettől kezdve elfogadom, hogy a mai oldalakat megjeleníteni képes izék borzasztó lassúak. Minden "én 20 vagy 50 százalékkal gyorsabb vagyok a másiknál" csak erőlködés ennek a technológiának a népszerűsítésére.

De ez már régi történet. Tizenéve részt vettem egy "vékony kliens" alapú fejlesztésben. Sok küzdelem után kiderült, hogy az oldal megjelenítése >>90 százalék, miközben a hálózati forgalom, program futás, sql lekérdezések, egérkettintás beérkezése a szerverre elhanyagolható. A végeredmény egy saját fejlesztésű (C++) kliens lett - csak ne kelljen brózert használni! (Nem én írtam!)

Szóval hasznos, ha azt szeretnéd tudni, hogy a behúzot kézifékkel álldogálló autódat még mi lassíthatja. :)

Ha meg az oldalak szempontjából nézem, akkor sem nagy segítség. Egyszerűen kirakok az oldalra egy-két nagy listát, vagy gyenge szerver mellett jó nagy képeket átméretezve és megáll az élet. Persze, ha ezt lehet tesztelni az sem az utolsó.

Elfogadom amit írsz. Hiába, a böngészőben futó cucc már az n. réteg, már a mátrix mátrix-ában fut vm-en basic-ben.. :)

Amiért nekem jó a teszt, hogy a sok vemhes anyatetűt (weboldalt) összehasonlítsam egymással, és megállapítsam, hogy melyiken kell tiltani a js-t és így nyerjek 20 ms-ot az 5 másodperces betöltéshez :)

Ubuntu, i5 proci, 16GB memória, 3 profil párhuzamos futtatása, profilonként 10-40 fül, 1-2 erőforrásigényesebb oldalal (pl. FB, Youtube, google képkereső) = 1-2 órán belül merevre fagyasztja az egész gépet úgy, hogy még a ping-re sem válaszol, marad a hard reset. Performancia? Engem meggyőzött :D

A probléma forrása: a profiladat-mentések összeakadása masszív IOwait-et okoz.
Megoldás1: profiladat-mentések periódusának jelentős megnövelése (fagyás/leállás esetén az utolsó pár perc adata elvész), így kisebb valószínűséggel akar több profil egyszerre lemezre írni
Megoldás2: FF profil ramdrive-on, onnan rsync-elni vissza a felhasználó könyvtárába, csak a különbségeket (mellesleg SSD-kímélő is)

Én is ezt tapasztalom, de csak egy ideje. Vagyis a nagy IO terhlést egy időre alkalmanként - egy komolyabb SSD-m van 600 MB írás és olvasással Sata3-on 80 ezer IO/sec sebességgel, és nekem is megakasztja.

Ennek utána fogok nézni jobban hogy mi okozhatja és hogyan lehetne kiiktatni. A profil mentésnek nem szabadna így megakasztania- Ennél sokkal izmosabb dolgokat futtatok ami az összes magot kihasználja (párhuzamos tömörítés), mellete VM stb, és ezek sem akasztják meg úgy, mint mikor csak egyetlen FF fut.

Régebben ez nem volt nálam.

Mi okozza:
Alapbeállítás szerint 15 másodpercenként menti az összes fül aktuális adatait (sessionstore), valamint minden változásnál a sütik, előzmények (...) frissített adatait is. Elég pl. a facebook.com periodikus oldalfrissítése ehhez - gondolj bele mi van akkor, ha egyszerre 10 FB oldal van nyitva...
A csúnyaság az, hogy ilyenkor nem csak a megváltozott adatokat írja ki, hanem újra nulláról az összeset, ami nem túl optimális, mellesleg eléggé SSD-gyilkos tud lenni. Ha egy alapból is magas IO-terhelés mellett ha nem sikerül befejezni az előző műveletet (pl. sok megnyitott oldal esetén a sessionstore adatait), örülhetsz ha csak elszürkül a böngésző ablaka, de a gép működőképes marad.

Mekkora adatmenyiségről, adatterhelésről beszélünk:
Ha nem törlöd a letöltések listáját és az előzményeket, valamint egyszerre sok fül van nyitva, hamar összejön 100+MB, ráadásul nem egymás után írja ki az adatokat intelligensen, hanem konkurál az oldalmegnyitással/újratöltéssel járó változásadatok kiírása a 15 másodpercenkénti session adatok mentésével is.
Ez egy aktív profil, kevés fül és még mondjuk egy szövegszerkesztő használata esetén nem probléma. Több profil, és/vagy virtuális gép indítása/használata, vagy más erőteljesebb IO-terhelés esetén garantált a fejreállás.

A lusta megoldás: session adatok mentési periódusának jelentős megnövelése, disk cache kikapcsolása, kevés fül használata, sok periodikus frissülést tartalmazó oldalak minimalizálása.

Az igazi, bár némi molyolást igénylő megoldás: gép indulásakor a FF konfig. könyvtárát átmásolni ramdrive-ra, majd azt szinkronizálni vissza a háttértárra intelligens módon, különbözeti másolással csak a változások pár kbyte-os adatait frissítve (pl. rsync). Erre van jónéhány leírás a neten.

15sec-->25min?
Az első fagyásnál gondoltam újra én is, amikor épp az utolsó pár percben találtam sok mindent, és pont azok vesztek el...
Bár ha nem használod annyira, még akár be is jöhet. Igaz az SSD-t akkor sem fogja kímélni.
Ha mégsem jön be, akkor meg jöhet a következő szint :)

Ramdiszkről nyugodtan szinkronizálhatsz 15 másodpercenként, mivel az intelligensen csak a változásokat érvényesíti, tehát maximum pár KB adat mozog ha épp aktívan böngészel :)
Emellett az oldalfrissítések ugyanúgy akár 5 másodpercenként kezdeményezhetik a profil újramentését - szerintem ez okozza a nagyobb IO-terhelést, a session mentése csak az utolsó csepp a pohárban.

Ami sokat segít még: a disk-cache teljes kikapcsolása, helyette a ram-cache beállítása.