×

De mit adott nekünk a Facebook? – mélyvíz

De mit adott nekünk a Facebook? – mélyvíz

Manapság egyre inkább divattá vált utálni a̶ ̶r̶ó̶m̶a̶i̶a̶k̶a̶t̶ a Facebook-ot, pedig jópár csodaszép dolgot köszönhetünk nekik.

Úgyhogy a teljesség igénye nélkül szeretnék felsorolni ezek közül párat. Ha azt hiszed, hogy sejted, miről lesz szó, akkor elmondom, hogy ha arra gondolsz, amire én gondolok, hogy gondolsz, akkor rosszul gondolod.

zstd, azaz z-standard tömörítés. Ez egy realtime, azaz valós idejű, vagy úgymond on-the-fly veszteségmentes tömörítő algoritmus, ami alapvetően nem archiválásra van. (tehát nem rar, az nem ilyen) Már jópár ilyen létezett eddig is (a legismertebb a zlib, ami szinte 1:1-ben zip), és van is sok jelentkező, de most úgy érzem, hogy a zstd lesz az iránymutató etalon ebben a szektorban. Nagyon jó aránnyal tömörít, miközben meglehetősen gyors is. Itt egy táblázat alant, amivel a többihez hasonlítva láthatjuk a teljesítményét:

Tömörítő algoritmus Tömörítési arány Sebesség betömörítéskor és kitömörítéskor
zstd 1.3.4 -1 2.877 470 MB/s 1380 MB/s
zlib 1.2.11 -1 2.743 110 MB/s 400 MB/s
brotli 1.0.2 -0 2.701 410 MB/s 430 MB/s
quicklz 1.5.0 -1 2.238 550 MB/s 710 MB/s
lzo1x 2.09 -1 2.108 650 MB/s 830 MB/s
lz4 1.8.1 2.101 750 MB/s 3700 MB/s
snappy 1.1.4 2.091 530 MB/s 1800 MB/s
lzf 3.6 -1 2.077 400 MB/s 860 MB/s

De mégis mire jó ez? Sokmindenre. A google is megcsinálta ebből a saját verzióját brotli néven (aminek a file kiterjesztése erdetileg .bro volt, csak akkor a feminácik egyből a “brother“-re asszociáltak belőle, ezért az óriáscég kénytelen volt ezt megváltoztatni .br-re. ), de az nem muzsikál ennyire jól – láthatjátok a táblázatból. A brotlit például eredetileg a webfontok offline tárolására használták, hogy a brózered a cache-elt fontokkal ne foglaljon sok helyet, mégis gyorsan be tudja tölteni – ez is csak egy példa, hogy mire jó egy on-the-fly tömörítőalgoritmus. Én speciel ramdisk-et tömörítek most zstd-vel, ezzel spórolok 400megát az lz4-hez képest, és csak minimálisan (=észrevehetetlenül) lassabb.  Pár hónapja már a vanilla kernel része lett, ami kimondottan nagy szó, mert ehhez Linus nagyúr rábólintása is kellett, és annak a valaminek márpedig ahhoz igen jónak kell lenni, hogy ez megtörténjen. Sőt: még az initrd-t is lehet zstd-vel is tömöríteni, még sőtebb: arról is szó volt a elmúlt hetekben, hogy a Linux kernel alapértelmezetten ezzel tömörítse saját magát a mostani alapértelmezett xz helyett! Ezt a felsorolt tömörítők közül eddig csak a zlib tudta kiharcolni, de az már közel 30 éves, és nem volt más alternatívája akkoriban.


Lassan tényleg valószínű, hogy szabvánnyá válik, és a brózerek is elkezdik támogatni, amik jelenleg csak az őskövület gzip-et támogatják, mint tömörítés. Érted: minél kevesebb adatforgalom legyen közted és az adott weboldal között – így mobilneten 10-100 megákat spórolsz havonta, miközben még a weboldal is hamarabb tölt be. Bár már a gzip jelenleg majdnem mindenhol default, az adatokból láthatjátok, hogy a zstd minőségi ugrást fog hozni a jövőben. Legyen így – és köszönjük, Facebook!

 

Btrfs, azaz better vagy b-tree filesystem. Ezt ugyan az Oracle kezdte el fejleszteni 2007-ben, de ők már kiszálltak belőle, és ma már szinte egyedül a Facebook viszi a hátán a projectet – erre szeretnének áttérni a közeljövőben, vagy legalább ezt is munkára fogni.

  • Tud snapshot-okat gyártani a filerendszer vagy egy mappa aktuális állapotáról (ez lényegében olyasmi, mint az Apple time machine-ja), ezt a COW, azaz copy-on-write metódussal éri el.
  • Tud transzparensen tömöríteni zlib-bel, ami gyakorlatilag a zip, lzo-val, és – marhára meglepő módon – zstd-vel is. Ez lassú háttértáraknál kimondottan jól jön, mert gyorsítja a rendszerpartíción való elérést, akár 1.5-2-szeres sebességre.
  • Tud subvolume-ket, ami gyakorlatilag partíció a partícióban – nem kell a partícionálással bohóckodni, sőt: mivel dinamikus a helygfoglalása, nem kell előre rögzítenünk a partíciók méretét. Nem kell töprengeni, hogy mekkora rendszerpartíció legyen és mekkora legyen a home, vagy a torrent partíció; minden mehet egybe, és a subvolume-k mérete egymás mellett hízik dinamikusan, amíg a lemezen fizikailag van hely.
  • Magától tud raid 0/1/10/5/6-ot is, és ezt nem blokkszinten, mint a kernel, vagy egy hardware raid kártya, hanem jóval hatékonyabban a filesystem fölött, kevesebb cpu és memória felhasználásával.
  • Deduplication, magyarul deduplikáció. Még magyarabbul: megkeresi azokat a blokkokat a filerendszeren, amik megegyeznek, és ezekből egyet csinál, és a többit csak hozzálinkeli. Tehát ha letöltesz -véletlenül- egy filmet többször, az csak 1szer foglal helyet, mert az okos fs egybevonogatja az azonos tartalmakat. Ugyanez grafikusoknak is jó, akik a sokszázmegás képeikből megtartanak 20-30 fázist, miközben a kép nagyrésze ugyanaz marad, de mégis gigákat foglal a lemezen.
  • Természetesen ez is ópenszósz, free, vigye aki tudja; sőt: már a Linux kernel része jópár éve. A hasonló tudású riválisa a ZFS, de az sajnabajna a szigorú licenc megkötések miatt nem lehet a gpl-es Linux kernel része. Azonkívül sokkal több erőforrást zabál, mint a btrfs. És ismét: köszönjük, Facebook!

 

PHP 7.0 – Micsoda? Dehát a php-t nem is a Facebook fejleszti! Tényleg nem, ők a HHVM-et fejlesztették. Fogták az 5-ös php-t, leforkolták, és elkezdték kidobálni a felesleges részeket, írtak hozzá saját virtual machine-t, 64 bitesítették, és úgy sebességben is, mint memóriahasználatban 2-szeresen rávertek a php seggére. A megrökönyödött -hátulgombolós- php fejlesztők alig kaptak levegőt, hogy a 20 éve reszelgetett kódjukon valaki tudott dobni 200%-ot, miközben még kevesebb memóriát is használ. De mivel a facebook jóságos, és nyílt forrású a hhvm project, ezért a nagyját be is építették már az új 7.0-ás verziójú php-ba. Megjegyezném, hogy a Holdkomp is wordpress-en fut, ami php-t használ, így itt minden olvasó és szerkesztő élvezheti a Facebook munkáját, amit eddig egy nagy cég sem mert bevállalni, hogy gatyába rázza a fostalicska php-t. Beszéljenek a színes grafikonok!


És egy részlet a PHP 7.0 changelog-jából:

  • Improved performance: PHP 7 is up to twice as fast as PHP 5.6
  • Significantly reduced memory usage
  • Consistent 64-bit support

Igen, igen, ezt mind a Facebook-nak köszönhetjük! Mondjunk hát egy nagy vivátot Facebook tesónak, megérdemli! Nélküle a Holdkomp.hu kétszer lassabb lenne!

 

Redex – aszondja magáról, hogy ő egy “bytecode optimizer for Android apps”. Ha hiszünk neki – és márpedig hihetünk -, akkor ez annyit takar, hogy a már lefordított android-os app-ra ráeresztve a redex-et egy méretben kisebb, de fürgeségében gyorsabb appot kapunk.

Nem véletlen, hogy az appok jelentős része már ezt használja. Akár 15-30%os méretcsökkenést, és 5-20%-os sebességnövekedést eredményez. Érted: kevesebbet eszik a mobilnetből, amikor letöltöd, kevesebb helyet foglal a telódon; és ha elindítod, nemcsak fürgébb, de ugyanennyivel az akksidat is kevésbé eszi. Hát mi ez, ha nem szívjóság, és mindez BSD licensszel? Nagy pacsi, Facebook!

 

Remélem, azért tudtam valakinek újat is mondani, hogy miket csinál manapság a Facebook. Ez bőven nem a teljes lista, hiszen a github-on összesen 175 opensource project-jük van jelenleg: https://github.com/facebook , itt pedig még egy pár: https://code.facebook.com/ . Válogassatok hát Facebook tesó gyümölcskosarából kedvetekre!

You May Have Missed

HOLDKOMP