FSF konferencia 2018

Iden eloadokent vettem reszt az esemenyen, es a time series adatbazisokrol (a TICK stack-et is megemlitve) tartottam eloadast, ill. mutattam peldakat, hogy mi mindenre lehet egy ilyet hasznalni.

Altalaban szeretem a video felveteleket, de iden nem lesz, ami talan most jobb is, mert reggel eleg keves idom volt, es valasztanom kellett, hogy indulas elott meg TRX-ezek egyet vagy megborotovalkozom. Hat az elobbi lett :-), de egy gyors tusolas meg belefert ;-)

Kadlecsik Jozsef igyekezett osszezavarni Linux tuzfal ugyben. A lenyeg az, hogy a jovo nincs kobe vesve, de jol teszed, ha barakozol az nftables nevu cuccal.

Utana Tomka Gergely megosztott par sztorit hadoop klaszterekrol, meg tulkepzett security csapatokrol, ill. arrol, hogy legyen mentesed!

Aztan jott egy eloadas, amiben kivaltottuk a microsoft SBS-et Uninvention corporate szervererrel + kopano-val (ami egy zarafa fork). Tetszik benne, hogy van hozza egy store, amibol osszelegozhatja az ember, hogy mi kell neki. Bar az ilyen cuccok kapcsan mindig van egy olyan felsz bennem, hogy akkor mit csinal az egyszeri rendszergazda, ha olyan dologra van szuksege, amit a gui (vagy meg a cli sem) nem tud: pl. email archivalas beallitasa.

Vegul jott atya az adatbazisok teljesitmenyhangolasaval kapcsolatban. Sajnos nem ert a mondanivaloja vegere, de kivancsian varom a slide-jait, mert erdekel a vege is :-) Azzal viszont vitatkoznek, hogy az optimalizaciot [lehetoleg] a kod modositasa nelkul kelljen megoldani. Szerintem leginkabb az ugyetlen alkalmazasok (es itt most nem a posgresql-re gondolok, hanem arra a kodra, ami azt [is] hasznalja) fixalasaval lehet a legnagyobb sebessegjavulast elerni.

Volt egy sztorim egy hazai, bizonyos mobiltelefon tartozekokat arulo webshoprol:
- Birni fogja a vm a fekete penteket?
- Azt en honnan tudjam?
- Hat, aggodunk, hogy nem fogja
- [itt adtam par altalanos tippet, miket kene megnezni a php-s cuccban, sql, indexek, cache-eles, egy kis teszteles, etc, mert hogy ha mar mindezeken tul vannak, akkor van ertelme hw-t boviteni]
- Hmm-hmm, akkor kerunk meg ennyi memoriat es cpu-t...

Ebben az ertelemben atya mondanivalojat huztak ala, miszerint a fejleszto (ideje) draga, foglalkozzon massal. De szerintem meg ez a kicsi, magyar rogvalosag, ahol az atlagbela webshop tulaj 1x fizet php pistinek, aki kepessegei szerinti megoldast szallit, aztan soha tobbe nem foglalkozik vele (ami ebbol a szempontbol zsak a foltjat, ha nem kap zset a support-ert).

Itt meg nem volt vege, csak nekem mennem kellett, mert eleg huzos volt az utobbi par nap. Btw. amilyen eros volt a mezony, jo esellyel nem en lettem a legjobb eloado. Pedig igyekeztem nem hadarni :-)

Ja, a vegen kaptam par kerdest (amiket meg elo tudok hivni), amikre az alabbi valaszt adom (most, hogy van idom egy kicsit gondolkozni is :-)):

- az influxdb egy celszerszam, altalanos sql kivaltasara nem jo. Ha ossze kell kotni az abban ill. egy sql szerverben tarolt adatokat, akkor ehhez a logikat leginkabb magunknak kell osszerakni, hiszen mi tudjuk, hogy mit akarunk :-)

- a TICK es az ELK nem pont ugyanazt tudjak, mert egyreszt az ELK-ba jobbara logokat kuld az ember (es nem metrikakat), mig a Telegraf gyakorlatilag barmilyen metrikat kepes influxdb-be (vagy eppen elasticsearch-be, stb. tolni). Azonkivul a Kibana GUI-ja sem ugyanazt tudja, mint a Chronograf (vagy epp a Grafana). Szoval a TICK es az ELK mas feladatra lonek.

- az rrdtool-rol azert nem volt szo a benchmark reszben, mert egyreszt ilyen eredmenyeket nem talaltam, masreszt (szigoruan szubjektiv maganvelemenyem) elavultnak tartom azt ezt hasznalo eszkozoket, pl. mrtg, cacti, munin, etc. Nem azt mondom, hogy ezek rosszak, de a TICK (vagy epp a TIG) stack-hez kepest dinoszauruszok, ill. az RRD nem tamogat semmilyen muveletet, transzformaciot az adatokon, ami szukseges lehet egy uzleti dontes megtamogatasahoz. Bar magad is megirhatod a szukseges fuggvenyeket, de sokkal egyszerubbnek tartom egy kesz megoldas hasznalatat, ami mindezt beepitve tudja. Vegul a Grafana megjelenitesi kepessegei is joval felulmuljak az RRD-re epulo gui-s cuccoket.

- zabbix-ban nem trivialis osszerakni egy olyan alertet, ami egy komplex feltetel teljesulese eseten szol. Bevallom nem probalkoztam ilyennel a kapacitor hasznalatakor.

- ha a telegraf nem tudja (pl. halozati gubanc miatt) elkuldeni az adatokat, akkor probalkozik parszor ujra, de (imho) nem fogja bufferelni huzamosabb ideig az adatokat, hogy kesobb egy nagyobb batch-et elkuldjon. Ha van lokalisan kafka, es oda ir a telegraf, ugy esetleg megoldhato, hogy onnan a kozponti influxdb (vagy valami mas) megkapja az adatokat. Bar, ha ilyen esetre kell felkeszulni, akkor inkabb egy file-ba iratnam az adatokat a telegraf-fal, es egy periodikusan futo cucc tolna a tavoli influxdb-be az adatokat

- a nyilt forrasu valtozat nem tamogat influxdb klasztereket, az a fizetos verzioban van csak

- MIT licenszet hasznal az influxdb

Vegeztul par szo a catering-rol: nekem bejott a svedasztalos megoldas (tortilla, salatak, hidegtalak, whatever). A 3 fele retes kozul az almas volt a legjobb.

Majd a kovetokiadvanyba beleirom a kimaradt twitteres bitcoin sztorit is, ugyhogy rettegjetek :-)

Hozzászólások

- [itt adtam par altalanos tippet, miket kene megnezni a php-s cuccban, sql, indexek, cache-eles, egy kis teszteles, etc, mert hogy ha mar mindezeken tul vannak, akkor van ertelme hw-t boviteni]

Azt az apróságot ne feledjük el, hogy egy "PHP-s cucc" egy-két nagyságrenddel lassabb, mint egy normális architektúrán megírt alkalmazás (pl. Java, Scala, C#)

Így ezen résszel teljesen egyetértek veled sj:
Azzal viszont vitatkoznek, hogy az optimalizaciot [lehetoleg] a kod modositasa nelkul kelljen megoldani.

--
Ickenham template engine

Azt az apróságot ne feledjük el, hogy egy "PHP-s cucc" egy-két nagyságrenddel lassabb, mint egy normális architektúrán megírt alkalmazás (pl. Java, Scala, C#)

az meglehet, de a mondanivalom lenyege az, hogy amig az alkalmazasod (es a java, etc. sem ved meg sajat magadtol, hogy rossz kodot irj) nem 100-as, addig nem a hw a szuk keresztmetszet, ezert inkabb a kodot kell(ene) reszelni.

--
"dolgozni mar reg nem akarok" - HZ 'iddqd' zoli berserk mode-ba kapcsol

"Azzal viszont vitatkoznek, hogy az optimalizaciot [lehetoleg] a kod modositasa nelkul kelljen megoldani."

Úgy néz ki, ezt nem sikerült jól megfogalmaznom. A tapasztalatom szerint már a környezet megfelelő javításával hatalmas javulást lehet elérni. Nagyon sokszor a fejlesztők azt sem tudják, hogy mi az a slow query log, performance schema, EXPLAIN ANALIZE. Nyilván a kód módosítása hozza a legnagyobb eredményt, de átütő javulást lehet elérni külső cache-ek, megfelelő(bb) indexek létrehozásával. Valójában a PM-ek és a dev-ek is örülnek, ha a funkcionális teszten átmegy egy featúra, a biztonság, a hatékonyság nem szempont.

Stílszerűen: Az előadás hosszát nem sikerült optimalizálni :S Az előadásomban felépítettem egy gondolati ívet, melynek a 70%-ánál leesett az óra. Mivel ez az előadás is, mint minden előadásom, egyedi darab és a valós hosszát nem volt időm letesztelni. Plusz elkövettem egy hibát. vim-mel írtam a slide-okat (reveal-md rulez), így 30x egyszerűbb volt, mint LO-ban, így szórtam a slide-okat és utána nem volt időm visszavágni az oldalszámot. Slapic felvetette, hogy leadhatnánk a teljes előadást (a végével együtt :D) a Devops Akadémián. Megfontolom az ötletet.

A slide-okat hamarosan még egyszer átnézem és utána kilinkelem a konf oldalra. Vagy lesz videó és utána.

A Kopano-nak van sajat archiver megoldasa, azt tudod hasznalni archivalasra.
Vagy olyan messzire neked nem kell menni, mert ott a Piler :)