Meetupok, konferenciák

7 Replies

Nekiálltam összeszedni a hazai meetupokat, konferenciákat, és azzal szembesültem, hogy nem nagyon van semmi gyűjtőoldal, ahol össze lenne szedve legalább a tizedük. Tipikus crowdsourcing probléma, gyűjtsük össze közösen! :)

Nyitottam egy Google Calendart a dolognak, illetve be tudtok küldeni ti is újabb elemeket. Maximum 1-2 nap késéssel fognak megjelenni a naptárban a releváns események.

Azokat az eseményeket szeretném összeszedni, melyek hazaiak, vagy itthonról kiutazva is érdekesek lehetnek. Leginkább az IT vonal érdekelne, de jöhet minden más is, így még időben kiderülhetnek az egymásra szervezések.

Objective-C I.

2 Replies

Az iOS fejlesztés tanulása közben az egyik dolog, amivel megismerkedik az ember, az az Objective-C. Részemről a webes, scriptes fejlesztések irányából közelítettem a nyelvhez, s amellett, hogy egy teljesen másik világ, pár ismerős dologgal is lehet találkozni. Két bejegyzést is írok a témáról, de inkább csak a – számomra – érdekesebb, és a “szokásostól eltérő” nyelvi lehetőségeket próbáltom meg összeszedni, és nem egy átfogó képet adni a nyelvről.

Az Objective-C-ről a Wikipédiában is lehet olvasni egy korrekt áttekintést, és a bejegyzés írása közben is találtam egy rövid, tömör összefoglalást: Learn Objective-C, ezeket is érdemes átolvasni, sokkal több infót átadnak, mint én a következőkben. :)

Rövid történet

Az Objective-C 1983-ban jelent meg a NeXT által fejlesztett NeXTSTEP operációs rendszerben (december 20-án volt 15 éve, hogy bejelentette az Apple a NeXT felvásárlását) – Steve Jobs aktívan részt vett a fejlesztésében. A nyelv ugyanúgy a C kiterjesztése, mint a C++, de az előtt jelent meg, és – értelemszerűen – sok ponton különböznek egymástól. Jelentős részén, például az üzeneteken (lásd lejjebb) a Smalltalk jelentős befolyása figyelhető meg, de “szerencsére” inkább a C-s vonal maradt az erősebb. Az iOS eszközökön az Apple által 2006-ban bejelentett Objective-C 2.0 változattal dolgozhatunk, bár például a garbage collection-t pont nem támogatja (még?) az iOS.

Szintakszis

Az Objective-C szintakszisa első ránézésre eléggé szokatlan. Másodikra is. Harmadikra viszont már teljesen okés, és az XCode kódkiegészítése is sokat tud segíteni. Mivel C-s nyelvi elemekből építkezik, a PHP-val vagy JavaScripttel összehasonlítva a szinktakszist nagyon sok a hasonlóság, leginkább a metódusok hívása különbözik. Egyből két dolog is van, egyrészt szögletes zárójelek között, nem ponttal, hanem szóközzel elválasztva hívunk meg egy metódust, másrészt sokkal bőbeszédűbb a nyelv a megszokottakhoz képest. Konkrétan:

[UIView alloc]

Itt az UIView objektum  alloc metódusát hívtuk meg. Más nyelveken ez UIView.alloc() szintakszisú lenne. A paraméterek átadásánál lesz bőbeszédű, ámde nagyon könnyen olvasható a nyelv:

[UIColor colorWithRed:0.16 green:0.33 blue:0.33 alpha:1.0]

Ahogy látható, nem csak a paramétereket soroltuk fel, hanem a paraméterek neveit is, utánuk kettősponttal írva az értékeket. Más nyelveken ez UIColor.colorWithRedGreenBlueAlpha(0.16, 0.33, 0.33, 1.0) lenne, vagy méginkább UIColor.colorRGBA(0.16, 0.33, 0.33, 1.0). Fontos megérteni, hogy a paraméterek nevei szerves részét képezik a metódus nevének, a sorrendjük nem felcserélhető. A gépelésben a kódkiegészítés segít, a kezdőknek végképp.

Szerintem a legnagyobb sokkot ez a szintakszis tudja okozni a nyelvvel ismerkedőknek, miután megszokjuk, utána viszont már teljesen érthető, átlátható.

Bár ezzel a szintakszissal érhetjük el az objektumtulajdonságokat is, az Objective-C 2.0 bevezette a más nyelveknél megszokott ponttal jelölést is, tehát amennyiben az “x” egy property-je az obj-nak, akkor a következő két sor teljesen ekvivalens, mind a kettőt használhatjuk:

[obj x]
obj.x

Üzenetek, protokollok

Az Objective-C a metódushívást alapvetően nem metódushívásnak, hanem üzenetküldésnek hívja. Az objektumoknak üzenetet küldünk (fentebb az “alloc” üzenetet küldtük), amivel az kezd valamit. Az egyik opció az, hogy van egy ilyen nevű metódusa, és azzal fogja lekezelni. Ez a megfogalmazás azonban nem öncélú, az is előfordulhat, hogy az objektum az üzenetet továbbküldi, akár egyszerre több objektumnak is. Ha így gondolkozunk, akkor az gyorsan segít megérteni a protokollokat is.

A protokollok olyan nyelvi elemek, melyek üzeneteket (metódusokat) sorolnak fel, de nem valósítják meg azokat. Nagyon hasonlítanak az osztályok interfészeihez, de csak metódusokból állhatnak. Egy osztály deklarációjakor jelezhetjük, hogy az megvalósít egy konkrét protokollt, vagyis a protokoll által definiált üzenetekre válaszolni tud. Ekkor az osztályunknak ezeket a metódusokat meg kell valósítania (az egyes üzeneteknél a protokoll jelezheti, hogy opcionálisan megvalósítandó egy üzenet lekezelése). A protokollok standardizálják azt, hogy az egyes objektumok hogyan kommunikálhatnak, s milyen üzeneteket küldhetnek egymásnak – s ez a filozófia aztán az egész objektumhierarchiát áthatja, amivel dolgozunk.

Kategóriák

A protokollokhoz hasonlóan érdekes nyelvi lehetőséget kínálnak a kategóriák, melyek segítségével “kész” (pl. amit az operációs rendszer kínál számunkra) osztályokat tudunk kiegészíteni újabb metódusokkal, illetve akár már létező metódusokat is felüldefinálhatunk (ezzel azért óvatosan). Ez nagyon-nagyon hasonlít a JavaScript prototípusainak kiterjeszthetőségéhez, annyira, hogy akár futási időben is kiterjeszthető egy osztály (ez is egyébként a Smalltalk-ból érkezett az Objective-C-be). A kategóriák célja, hogy a kód amit írunk logikusan szervezhető legyen, s ne kelljen alosztályokat létrehoznunk egy kiterjesztéshez.

Folyt. köv.

Rövidesen jön a következő bejegyzés a témáról, melyben pár további egyedi nyelvi megoldásról fogok szót ejteni még.

Tanulni, tanulni, tanulni

5 Replies

Sikerült úgy alakítanom a szabadságaim, hogy szinte teljes decemberben szabadságon leszek. Unatkozni nem fogok, mert hamarosan megszületik második gyermekünk, és már csak emiatt is van itthon segíteni való a születés előtt is, utána pedig pláne (január legelejére vagyunk “kiírva”, de hetekkel előbbre várjuk a kissrácot). Emellett azonban úgy gondoltam, hogy egy komolyabb tanulást is lenyomok decemberben, amennyire időm engedni fogja majd.

 

A folyamatos tanulás egy jó webfejlesztőnél életmód jelleggel működik, a terveim viszont most egy igen intenzív hónapról szólnak. Szeretném elsajátítani az iOS/Mac fejlesztést úgy, hogy komoly programokat is le tudjak tenni az asztalra, és a Symfony 2-től a JavaScripttel kapcsolatos újdonságokig szeretnék további mély ismereteket összeszedni. A célok között szerepel az is, hogy kialakítsak egy olyan felállást, mely biztosítja azt, hogy a jövőben több tanulásra legyen lehetőségem a munka mellett is.

A kérdés, hogy milyen módon lehet a legtöbb tudást összeszedni? Úgy döntöttem, hogy első körben több tucatnyi órányi videóanyag megnézésével, és feldolgozásával fogom kezdeni.

iOS/Mac fejlesztés

Tősgyökeres webfejlesztőként érdekes nézőpontváltást jelent a mobil/desktop vonal felfedezése. A napi szinten is használható tudás elsajátítása melett pont egy ilyen teljesen új nézőpont meglépése is a célom, amitől azt várom, hogy más szemmel fogok tudni utána tekinteni a webfejlesztésre is. Az iOS/Mac fejlesztéshez az Objective C elsajátítása az első lépés, melytől egy kis C-s tudás megszerzését is várom, illetve az OO programozásban egy előrelépést.

Első blikkre az Objective C szintakszisa elég gáz (“szokatlan”), de sikerült felidéznem magamban azt az időszakot, amikor a Mac-kel ismerkedtem, és jópár dolog itt is “stevejobsi” módon idegen volt a Windows/Linux felől érkezve. Ahogyan akkor is pár nap / hét alatt sikerült túllendülni a szokatlanságon, most is így voltam vele, és még csak belekezdtem a tanulásba, de máris kezd tetszeni az egész környezet, és a nyelv lehetőségei.

Úgy látom, hogy a Delphivel szerzett tapasztalataim is segíteni fognak, az Xcode fejlesztés egyáltalán nem áll messze a több, mint tíz éve porosodó desktopos tapasztalataimtól. Abban az időszakban nem igazán sikerült semmi maradandó desktoposat letennem az asztalra, és nem is ezt, hanem a webfejlesztés irányt választottam, így a “komoly programokat is le tudjak tenni” nem kis kihívásnak tűnik.

Ígéretes anyagnak tűnnek az iTunes University-n fellelhetőek, ezek közül is a kiemelkedik a Stanford University-n tanító Paul Hegarty kurzusa, mely jelenleg is zajlik, s folyamatosan kerülnek fel az anyagok. Nagyságrendileg alapból 20-30 órányi megnézendő videóról van szó, amit utána végig is kell gyakorolni, és a házi feladatokat is érdemes lesz végigvinni, hogy elsajátítsam a céloknak megfelelő tudást – szóval nem egy gyorstalpalóról beszélünk. A következő kör további egyetemek előadóitól, illetve az Apple-től származó anyagok feldolgozása lehet. Sokat segít, hogy a gépemen, az iPad-emen és még az első generációs iPod Touchomon is tudom nézni a videókat. Nem utolsó sorban az angolomnak sem árt, ha egy ennyi videót feldolgozok.

Két-három értelmes, de nem egetverően bonyolult alkalmazás ötlet is van, meglátjuk meddig jutok velük.

Egyebek

Az egyéb tanulandókat is szeretném videók, prezentációk feldolgozásával kezdeni. Elég sok olyan konferenciaanyag gyűlt össze, melyek végignézésére a napi teendők mellett egyszerűen nem jutott időm, ezek végignézésére, kipróbálására most sort tudok majd keríteni. Ezeket megpróbálom majd blogbejegyzés keretében is összegyűjteni.

A jövőbeni tanulások biztosításához olyan megoldásokat keresek, melyek az eddig “elvesztegetett” időimet tudják hasznossá tenni, mint például az utazással eltöltöttek. A különböző prezentációk, videók offline, iPod Touch-on, iPad-en elérhetőségét, valamilyen közös nevezőre konvertálás lehetőségeit próbálom majd megcélozni.

A fapados/lean startup

2 Replies

A StartUp Underground konferencia kapcsán ajánlotta figyelmembe Balogh Ákos a “lean startup” fogalmát, mely a lean filozófiáját alkalmazza a startupokra. A gondolat most kezd népszerűvé válni nemzetközi szinten is, persze leginkább az USA-ban. Az érdeklődőknek érdemes lehet végigmenni egy ingyenesen elérhető kurzuson:  How to Build a Better Startup, illetve megtekinteni a Lean Startup prezentációt - ezeket, és saját gondolataimat próbálom meg összefoglalni az alábbiakban.

A lean szó jelentése: vékony, vézna, sovány. A lean filozófia/menedzsment forrása a Toyota módszerként ismertté vált megközelítés, mely a Toyota gyár sikeresen működő megközelítéséből származik. A lean rendszer kiépítéséhez a filozófia 5 pontot fogalmaz meg. A lean startup ezeknek a módszereknek, megközelítésnek a startupokra alkalmazása, melyet a következőkben megpróbálok körüljárni. Ahogy ez lenni szokott, elemeiben nem beszélhetünk hatalmas újdonságról, azonban végigtekintve a hazai startup kínálaton (beleértve a saját dolgaimat is), van tanulnivaló az egyes elemek kapcsán is.

A lean startup ígérete, hogy a startupba fektetett pénz költését hatékonyabbá, a startup indítását és jövedelmezővé válását pedig rizikómentesebbé teszi, alapvetően egyszerű módszerekkel. Az egész filozófia egyébként nagyon közel áll az agilis fejlesztéshez, és a scrumhoz is (hiszen ezek gyökere is a lean környékén keresendő), viszont az üzleti megoldásokra koncentrál. A “lean startup” fogalma Eric Ries-hoz fűzhető, ő írt róla blogbejegyzésében.

A célcsoport felderítése (customer development)

Egy startup egyik kritikus kérdése, hogy van-e megfelelő célcsoportja, lesz-e elegendő felhasználója, s ha olyan az üzleti modellje, akkor megfelelő vevőköre. Elég rizikós, hogy ha rengeteg időt a fejlesztésbe ölve a folyamat végén kiderül, hogy ez mégsincs meg, s rossz esetben az egész projekt kukázható.

Ennek kivédésére igen korai szakaszban érdemes piackutatást végezni, illetve potenciális ügyfeleket találni. Ehhez a fentebb is belinkelt írás a projekt ötlet állapotában demózását, illetve az érdeklődő ügyfelek felől szándéknyilatkozatok beszerzését javasolja.

A termék kialakítása (minimum viable product)

Mivel a legtöbb esetben nagyon költséges annak kiderítése, hogy a piac pontosan mit igényel, és jellemzően a startup indítói és a célcsoport között nincs, vagy nem 100%-os az átfedés, így nehéz meghatározni, hogy mit fognak a felhasználók igényelni, hasznosnak találni. Valószínűleg mindenkinek rengeteg ötlete van, hogy mit lehet belezsúfolni a szolgáltatás feature listájába, de a legjobb, ha egy felesleges sallangoktól mentes, éppen még beindítható, egyszerű megoldást választunk. A korai visszajelzések, a valódi igények mentén aztán lehet alakítani a dolgokat.

Tesztelve fejlesztés (Pivoting)

Egy termékkel sohasem lehetünk készen, indulás után közvetlenül pedig végképp nem. A feladatunk az, hogy megtaláljuk, hogy melyek a célcsoport igényei a továbbfejlesztésre, s hogy jó irányban tegyünk lépéseket. A pivoting jöhet ilyenkor képbe, vagyis az, hogy egyetlen lényegi elem megváltoztatásával felmérjük annak hatását az egészre, s így, lépésenként haladjunk előre. Képbe jöhet az A-B tesztelés, annak mérhetővé tétele, hogy egy változtatásunk milyen hatást hoz.

A projektnek ezt a fázisát hívhatjuk bétának, mely döntésünktől függően lehet zárt, vagy nyitott. Fontos, hogy a visszajelzéseket annak függvényében kezeljük, hogy kik használják a terméket, és a jövőben mire számítunk. Akkor mondhatjuk, hogy egy termék piacképes, “kész”, ha ezen a tesztelési szakaszon túl vagyunk, és kialakítottunk egy működő terméket a piac visszajelzései alapján.

Továbbiak

A fenti összegzésre leginkább egy nagyon durva összefoglalásként lehet tekinteni, mint egy átfogó bemutatóként. A bevezetőben említett kurzus szót ejt az árazásról, s további gondolatokról is, s elérhetünk egy kiváló wikit is a témában.

A StartUp Underground konferencián minden évben kiderül, hogy kiváló ötletekkel és fejlesztőkkel (“technológus” kifejezést használtunk rájuk) vagyunk megáldva, viszont az üzleti szemlélet, a startup résztvevői közül egy üzleti vonatkozásban jártas szereplő a legtöbb esetben hiányzik. Ez a potenciális befektetőkkel való kommunikációt, illetve a startup reális üzleti lehetőségeinek feltérképezését erőteljesen gátolja. A lean startup fogalmával megismerkedés bár nem gondolom, hogy egy jó üzleti vezetőt pótolhat, de mindenképpen a helyes irányba mozdíthat el egy startupot, így csak javasolni tudom.

MyISAM, InnoDB és MongoDB tapasztalatok II.

3 Replies

Pár napja írtam bejegyzést MyISAM, InnoDB és MongoDB adatbázisokkal végzett tesztjeimről, most új mérésekről tudok beszámolni. Egyrészt a kapott visszajelzések mentén végeztem pár konfiguráció változtatást, s ennek kapcsán sikerült elérni jelentős sebességnövekedéseket, másrészt pedig bővítettem a kört, és MariaDB (Aria, MyISAM, XtraDB és PXBT motorokkal), Percona Server (MyISAM és XtraDB motorokkal) felállásokban is végeztem méréseket.

Előző alkalommal egy saját fordítású, de különböző népszerű, finomhangolásokat lehetővé tevő patcheket nem tartalmazó MySQL 5.5.9 community edition, illetve egy gyári beállításokkal indított MongoDB 1.6.5 voltak a tesztalanyok. Most egy Percona Server 5.5.8 (béta), és egy MariaDB 5.2.4 disztribúció bővítette a kört. Ezek a disztribúciók alapvetően bináris kompatibilitást ígérve alapból sokkal jobban hangolt, illetve még jobban hangolható változatát ígérik az eredeti MySQL disztribúciónak. A bináris kompatibilitás azt jelenti, hogy a diszken tárolt adatbázisunk felett konverzió elvégzése nélkül kicserélhetjük az adatbázisszervert. Ezek a gyakorlatban nagyon jól is működtek, az egyes adatbázisszerverek által előállított fájlok egy-az-egyben meg is egyeztek.

Az InnoDB-vel végzett tesztjeim kapcsán kaptam több irányból is visszajelzést, hogy ennél jobbnak kellene lennie az eredményeimnek. Alapvetően gyári beállításokkal futtattam, a konfigurációba nem nyúltam bele, emiatt erre számítottam is, de utánaolvastam a témának, és a végeredmény végül erősen meglepett, az InnoDB hozta a MyISAM sebességét. Ezen kívül a MongoDB kapcsán végeztem még el egy változtatást, miszerint egy extra paraméterrel indítottam, mely csökkentette az I/O-t, és tovább gyorsította az importálás sebességét, még szimpatikusabbá téve a MongoDB szolgáltatásait.

Először álljanak itt a friss eredmények, majd pedig írok arról, hogy pontosan milyen változtatásokat eszközöltem a konfigurációkon. Az adatok és a felállás teljesen megegyezik a korábbi bejegyzésben írottakkal, egy korrekt, más feladatot el nem látó, terhelést nem kapó szerverrel végeztem a méréseket. Az adatfájlok méretét itt nem részletezem, a korábbi bejegyzéshez képest nem változtak. A referencia sebesség, csak az XML feldolgozása továbbra is 2:28 körüli érték.

MySQL Community Server 5.5.9, saját fordítás, extra configure paraméterek nélkül

  • MyISAM tábla, tömörítés nélkül: 5:32
  • MyISAM tábla, PHP oldalon gzdeflate-tel: 6:17
  • InnoDB tábla, tömörítés nélkül: 5:24
  • InnoDB tábla, PHP oldalon gzdeflate-tel: 6:15
  • InnoDB tábla, ROW_FORMAT=COMPRESSED-del: 7:56

Az InnoDB tábláknál a többi MySQL disztribúcióhoz képest a konfiguráción változtatnom kellett, nem engedett akkora logfájl méretet, mint a többi megoldás.

Percona Server 5.5.8, béta változat, bináris 64 bites Linuxos disztribúció

  • MyISAM tábla, tömörítés nélkül: 4:54
  • MyISAM tábla, PHP oldalon gzdeflate-tel: 6:17
  • XtraDB tábla, tömörítés nélkül: 5:14
  • XtraDB tábla, PHP oldalon gzdeflate-tel: 6:29
  • XtraDB tábla, ROW_FORMAT=COMPRESSED-del: 8:03

Az XtraDB engine egy InnoDB fork, olyannyira, hogy a CREATE TABLE során az ENGINE megadásakor így kell rá hivatkozni.

MariaDB 5.2.4, bináris 64 bites Linuxos disztribúció

  • Aria, tömörítés nélkül: 7:54
  • Aria, PHP oldalon gzdeflate-tel: 8:00
  • MyISAM, tömörítés nélkül: 5:31
  • MyISAM, PHP oldalon gzdeflate-tel: 6:12
  • XtraDB, tömörítés nélkül: 6:25
  • XtraDB, PHP oldalon gzdeflate-tel: 6:16
  • PXBT, tömörítés nélkül: 8:23
  • PXBT, PHP oldalon gzdeflate-tel: 8:16

Az Aria engine egy MyISAM fork, komolyabb eltérésekkel, például ACID műveletekkel. A PXBT egy a PrimeBase cég által fejlesztett, szintén ACID megoldás. Az Aria és a PXBT finomhangolásának erőforrások hiányában NEM jártam utána.

MongoDB 1.6.5, bináris 64 bites Linux disztribúció

  • tömörítés nélkül: 3:01
  • PHP oldal gzdeflate-tel: 4:47

MongoDB 1.8.0 RC0, bináris 64 bites Linux disztribúció

  • tömörítés nélkül: 3:02
  • PHP oldal gzdeflate-tel: 4:46

Kipróbáltam a fejlesztői változatot is.

Optimalizációk

A MyISAM tuningolásakor a key_buffer, a key_buffer_size és thread_concurrency értékek voltak, melyek leginkább befolyásolták a sebességet. A végleges beállítások:

key_buffer              = 16M
key_buffer_size         = 384M
max_allowed_packet      = 16M
table_open_cache        = 512
sort_buffer_size        = 2M
read_buffer_size        = 2M
read_rnd_buffer_size    = 8M
myisam_sort_buffer_size = 64M
thread_stack            = 192K
thread_cache_size       = 8
query_cache_limit       = 1M
query_cache_size        = 32M
thread_concurrency      = 8

Az InnoDB/XtraDB esetén a sebességben a legjelentősebb változást az alapértelmezett innodb_buffer_pool_size korrekt, illetve az innodb_log_file_size és innodb_log_buffer_size paraméterek hangolásával sikerült elérni. A rendelkezésre álló memóriához, illetve az adatbázis méretéhez képest nagyobbra állítással értem el a kedvező sebességeket. Végül az alábbi paramétereknél maradtam (az utolsó két megoldás az InnoDB ACID mivoltát torpedózza meg, ezzel sebességnövekedést elérve):

innodb_file_per_table
innodb_file_format      = Barracuda
innodb_buffer_pool_size = 8G
innodb_additional_mem_pool_size = 20M
innodb_log_file_size    = 2G
innodb_log_buffer_size  = 512M
innodb_flush_log_at_trx_commit = 0
innodb_flush_method     = O_DIRECT

A MongoDB esetében egyetlen változtatást eszközöltem, parancssorban a –syncdelay 1000 átadásával. Ez a bufferek kiírási gyakoriságát csökkentette 1000 másodpercre, mely több volt, mint az írások futási ideje.

Összefoglalás

Mint látható, a korábbi méréseimhez képest sikerült az InnoDB sebességét a MyISAM motoréhoz hasonló sebességűre hoznom, sőt, volt olyan felállás is, ahol az InnoDB-ből jobb eredményt tudtam kihozni, mint a MyISAM-ból. A Percona Server bizonyult a legjobban optimalizáltnak, hiszen ugyanazon szerverbeállításokkal a MyISAM táblákból jelentősen jobb, az InnoDB (XtraDB) táblákból pedig a többi adatbázis disztribúcióhoz képest megegyező sebességet tudott kihozni. A MongoDB-t tovább sikerült gyorsítanom, ezzel is megmutatva, hogy az egyik leggyorsabb adatbázismotorok között van, jelentősen lepipálva a MySQL szerverek lehetőségeit. A MongoDB-nél mindenképp, de a többi esetben is elmondható, hogy a sebesség eredményeket a PHP oldali adatfeldolgozás, kitömörítés nagymértékben befolyásolta, sokkal gyorsabb eredmények születtek volna, ha a betöltendő adat egyből rendelkezésre áll.

A méréseim visszahozták a bizalmam az InnoDB táblákba, illetve rámutattak arra, hogy a Percona Server disztribúcióra érdemes lehet átállnom. Ez utóbbiról más forrásokból is pozitívumokat hallottam csak, így ezt várhatóan meglépem. A mérések nem kis időmet vitték el, de az írási sebességek mellett mindenképp szeretnék még egy olvasási tesztet is elvégezni, valamennyire modellezve a végső felállást is, így úgy tűnik, hogy lesz egy harmadik rész is, mely erről fog szólni.

MyISAM, InnoDB és MongoDB tapasztalatok

16 Replies

A napokban egy viszonylag speciális szemszögből azt vizsgáltam meg, hogy milyen adatbázis lehetőségeim vannak nagy mennyiségű adattárolásra. Azt mértem, hogy a Wikipédia magyar és angol változatának XML-ből adatbázisba áttöltése mennyi ideig tart, és mekkora a tárhelyigénye az így létrejövő adatbázisnak. A mérésben a MySQL 5.5 MyISAM és InnoDB táblaformátumai, illetve a MongoDB vettek részt. Eredmények, tapasztalatok. Update: az InnoDB sebességét más my.cnf beállításokkal is leteszteltem, s jóval kedvezőbb sebességet sikerült kihozni, illetve Percona Server 5.5.8 és MariaDB 5.2.4 szerverekkel is végeztem méréseket. Az eredményeket egy másik bejegyzésben hamarosan közzéteszem.

A célom annak eldöntése volt, hogy mely az az adattárolási eszköz, melyet kiválaszthatok nagyon-nagy mennyiségű adattárolásához. A legfontosabb szempont számomra az, hogy az adatokat minél gyorsabban letárolhassam, mivel folyamatosan fogok komoly mennyiségű változást átvezetni az adatbázison.

Az adatbázisszerver egy saját fordítású, MySQL 5.5.9-es community edition volt, a MongoDB pedig egy 1.6.5-ös, 64 bites bináris Linuxos verzió. A teszteket Ubuntu Linux alatt végeztem. A MySQL beállításai alapvetően a gyári “huge” alapján voltak belőve, a MongoDB-t nem konfiguráltam. A MySQL konfig releváns sorai:

  key_buffer               = 16M
  key_buffer_size          = 384M
  max_allowed_packet       = 16M
  table_open_cache         = 512
  sort_buffer_size         = 2M
  read_buffer_size         = 2M
  read_rnd_buffer_size     = 8M
  myisam_sort_buffer_size  = 64M
  thread_stack             = 192K
  thread_cache_size        = 8
  query_cache_limit        = 1M
  query_cache_size         = 32M
  thread_concurrency       = 8
  innodb_file_per_table
  innodb_file_format       = Barracuda
  innodb_additional_mem_pool_size = 20M
  innodb_log_buffer_size   = 8M
  innodb_flush_log_at_trx_commit = 1
  innodb_lock_wait_timeout = 50

A teszteléshez a Wikipédia adatbázisát választottam, mind a magyar, mind az angol változat dumpjaival végeztem méréseket, de az angol akkora adatmennyiségnek bizonyult, hogy végülis nem futtattam le mindegyik mérést ezekkel az adatokkal. A magyar Wikipédia dump 336,707,547 byte-nyi bzippel tömörített XML fájl volt 415,111 szócikkel, amit egy rövid PHP kóddal dolgoztam fel, on-the-fly kitömörítéssel, és az adatok egyből történő letárolásával.

Több felállást is vizsgáltam, kipróbáltam az InnoDB transzparens tömörítési lehetőségét (ROW_FORMAT=COMPRESSED), illetve olyan felállást is, amikor a PHP oldalán tömörítettem be a Wikipédia cikkeket, a gzdeflate paranccsal. Az adatbázis id, language és content oszlopokat tartalmazott, ahol az id a cikk címe, a language a nyelve (‘hu’), míg a content a cikk tartalma volt. Egyetlen összetett index volt a táblákon, mely az id és language oszlopokat tartalmazta. A méréseket egy mást egyáltalán nem végző szerveren folytattam le, bőségesen elég memóriával, 7200 rpm-es SATA2 diszkekkel, négymagos Intel Xeon processzorokkal.

A következő mérési eredményeim voltak (táblatípus, tömörítés, időtartam perc:másodperc formában, az adatok helyfoglalása):

  • MyISAM tábla, tömörítés nélkül: 5:14, 1,159,562K táblaméret
  • MyISAM tábla, PHP oldalon gzdeflate-tel: 6:24, 531,764,518 byte táblaméret
  • InnoDB tábla, tömörítés nélkül: 27:58, 2,138,120K táblaméret
  • InnoDB tábla, PHP oldalon gzdeflate-tel: 18:14, 1,019,912K táblaméret
  • InnoDB tábla, ROW_FORMAT=COMPRESSED-del: 22:42, 978,952K táblaméret
  • MongoDB, tömörítés nélkül: 3:31, 4,144,128K táblaméret
  • MongoDB, PHP oldalon gzdeflate-tel: 4:25, 2,048,000K táblaméret
  • adattárolás nélkül: 2:28

MyISAM esetén az MYI, MYD és FRM fájlokat, InnoDB esetén az IBD és FRM fájlok, míg MongoDB esetén az adatbázishoz köthető .0, .1, .2… fájlok együttes méretét értem táblaméret alatt. Ez utóbbi méret csalóka lehet, mert a MongoDB nagyobb blokkokban foglalja le a tárhelyet az adatbázishoz.

Bármely megoldást is választottam, látszik, hogy az egyben bzippel tömörített, eredeti XML fájl mérete a legkisebb, ez várható is volt. Az InnoDB tárhelyigényét furcsállom, érdekes, hogy a tömörítés nélküli MyISAM volt akkora kb., mint a tömörített InnoDB. Az InnoDB beépített tömörítési lehetősége ami a sebességet illeti eléggé leszerepelt (de méretben sem sokkal jobb egy kliens oldali megoldásnál), továbbra is úgy tűnik, hogy kliens oldalon érdemesebb a tömörítést megoldani. Az InnoDB-nél látszik, hogy a sebesség erősen függ attól, hogy mekkora lesz a végleges táblaméret, a MyISAM tábláknál nem volt ilyen erős az összefüggés, sőt, amikor nem volt tömörítés, a több adatot gyorsabban ki tudta írni a MyISAM, itt már látszott, hogy a tömörítés fogta a sebességet, nem pedig az I/O műveletek.

A MongoDB verte mindegyik másik megoldás sebességben, a tárhely foglalása viszont láthatóan nem olyan optimális, mint egy MyISAM táblának, még talán úgy sem, hogy a lefoglalt blokk nagy része valószínűleg üres volt.

A sebessége miatt az InnoDB-t egyértelműen elvetettem. Míg MyISAM-mal 3-4 óra alatt betölthető volt az angol Wikipédia tartalom, addig az InnoDB-s táblába majd 1 napig tartott a betöltés. Az igen jelentős sebességkülönbség a fenti számokon is látszik. Azt gondolom, hogy a sebességen biztosan lehetne javítani pár konfig beállítás átállításával, de valószínűleg így is csak megközelítené, de nem érné be a MyISAM sebességét. A MongoDB megoldása továbbra is nagyon szimpatikusnak tűnik, a MongoDB vs. MyISAM kapcsán célszerű lenne egy random olvasási tesztet is elvégeznem, hogy korrekten tudjak dönteni.

A mérések csak az írási sebességet vizsgálták, és az írás 1 szálon zajlott, a forrás és a cél adatbázis ugyanazon a diszken volt, bár mind a kettő együttesen is belefért a memóriába, így valószínűleg az operációs rendszer cache-elte a forrást. Mivel ezek viszonylagosan speciálisnak mondhatóak, így mondjuk egy átlagos weblap esetén a működéssel valószínűleg nem összehasonlíthatók.

Viszlát Origo, hello Arkon!

16 Replies

Twitteren már decemberben megírtam, a blogomra most sikerült összehoznom csak ezt a bejegyzést: január elejétől az Arkon Zrt-nél, közismertebb nevén az ingatlan.com-nál dolgozom. Időközben magánéletemben is jelentőségteljes változások történtek: december 16-án megszületett Nóra Anna névre hallgató kislányom.

Az Origos, konkrétabban iWiW Developer Supportos munkát tavaly 2008. decemberében kezdtem meg, így bő egy évet töltöttem ezen a poszton, s úgy érzem hogy a feladatomat több-kevesebb sikerrel, rengeteg energiát beletéve sikerült jól végeznem. Az iWiW-ben még rengeteg lehetőség van, s bízom benne, hogy az új (Origo) vezetőséggel ezeket még hatékonyabban is kihasználja majd a társaság. A poszt otthagyása nem saját döntésem volt, de tekintettel arra, hogy a kezdeti újdonságdömping, illetve kommunikálandó lehetőségek száma az idő során csökkent, logikus lépésnek gondolom az Origo részéről az együttműködés lezárását.

Az Arkonnál egy igen érdekes munkakörbe, egy jó társaságba, és a válság ellenére is prosperáló, hazánk egyik legjobban működő, kizárólag magyar tulajdonú vállalkozásába csöppentem bele pár hete. A munkám nagyrészt az IT osztályon zajlik, de ezen felül több érdekes feladattal és lehetőséggel is kiegészül. Az egyik ilyen, hogy jobban láthatóvá tehetem az Arkont a hazai fejlesztői közösség számára (a dinamikus növekedés, számos új projektterv további fejlesztők csatlakozását igényli – most is éppen keresünk programozókat, rendszergazdákat), de heti szintű szakmai előadások tartásával, beszélgetésekkel a belső oktatás is új lendületet kapott. A cég már érkezésem előtt bevezette a fejlesztésben a “scrum” metodológiát, melybe én is belerázódhattam pár nap alatt (egész hatékonynak tűnik). Hazánkban eddig más cégnél általam még nem látott, a Google által ismertté vált 80-20%-os munkabeosztásra is lehetőségem van, vagyis 20%-át egy hétnek a saját projektjeimre fordíthatom. Az ingatlan.com csoport részét képezi a linkcenter.hu, utcakereso.hu, telepuleskereso.hu, koponyeg.hu, alaprajz.com és a blogol.hu is, s a Miner is kicsit közeledni fog jellemzően leginkább apróságokkal (a linkcenter.hu keresőjét például pár hónapja már a Miner keresőmotorja szolgálja ki), így bőven van mivel ismerkedni egy ideig.

HipHop, avagy gyors PHP a Facebooktól

3 Replies

A napokban be lett harangozva (bár még nem jelent meg a cég nyílt forrású projektjei között, de dolgoznak rajta), hogy a Facebooktól egy a PHP sebességét megsokszorozó fejlesztést fogunk kapni. A HipHop for PHP nevű projektnek bár vannak viszonylagosan komoly kötöttségei, de egyrészt ezzel együtt is nagyon hasznosnak tűnik, márészt a PHP-nak bármilyen jellegű frissítés, új vérvonal csak jót tehet.

hiphop-php

A HipHop for PHP a gyakorlatban egy C++ fordító, illetve webszerver funkciót lát el. A Facebook azért fejlesztette ki, mert sem a PHP memóriafoglalásával, sebességével, sem a kódok más nyelvi környezetben felhasználhatóságával, s a kiterjesztések programozhatóságával nem voltak túl elégedettek, másfelől viszont már van egy hatalmas PHP-ben írt kódbázisuk, és a tanulhatósága is jó a nyelvnek.

Érdemes megnézni a prezentációjukat:

Illetve én is megpróbáltam összeszedni, hogy milyen gyakorlati különbségek vannak a HipHop és az eddig megszokott, Zend Engine-es PHP között:

C++-ra fordít

A HipHop a PHP forráskódot egy optimalizált C++ kódra írja át, melyet aztán a G++ fordítóval lehet futtatható kóddá alakítani. A nyelvi elemek, a teljes PHP-ben a programozó számára elérhető kódkörnyezet egy jól optimalizált C++ kódban testesül meg az átírás végére, melynek a PHP kódjához ezután nem sok köze van. Néhány – általában ritkán használt – funkció (legfőképpen a PHP kódból dinamikusan új kód előállítását megcélzóak): eval(), create_function(), a preg_replace “e” kapcsolója be lett áldozva a teljesítmény oltárán, mindazonáltal pár dolog, mint a call_user_func(), dinamikus változók, extract() megmaradtak. A hiányzó függvények miatt pár népszerű framework (konkrétan a Symfony felől hallottam ilyen véleményeket) várhatóan nem fog működni HipHoppal. Kérdés, hogy ki alkalmazkodik majd kihez, mennyit jelent majd a gyakorlatban a HipHop sebességnövekedése, s mennyire lesz kényelmesen használható – ezek majd a kód közzététele, és a lehetőségek pontos megismerése után derülnek ki.

Ami a sebesség növekedést illeti, a Facebook webes forgalmánál 50%-kal kevesebb processzor használatot tapasztaltak ugyanakkora, az API-nál 30%-kal kevesebb processzor használatot dupla forgalom mellett. Ezek nem feltétlenül tűnnek hatalmas számoknak, de ha belegondolunk, hogy több, mint 30.000 szerverük van (2009 októberi adat), akkor mindjárt komoly spórolásról beszélhetünk.

Fejlesztőkörnyezet

A fordítás a kód méretétől függően várhatóan nem tizedmásodperces, másodperces sebességű lesz, így leginkább egy deploy folyamatba lesz beilleszthető. Ez így nehézkes lenne fejlesztés közben, így elkészült egy HPHPi névre hallgató interpreter is, ahol kimarad a fordítgatás, így a fejlesztés könnyebbé válik. Ez a megoldás eval() függvényt is megvalósítja, de a HipHophoz közel áll.

Deployment

A deployment során nem PHP kódot kell a szerverekre eljuttatni, hanem egy darab lefordított, “hatalmas” bináris fájlt. Egy HipHop szerver egy processzként, threadek segítségével fog futni, leállás nélkül lehet új verzióra átállni vele.

PHP kiterjesztések

A Facebook programozók saját bevallásuk szerint jópár PHP kiterjesztést használnak. Nem túl tiszta számomra, hogy pontosan mely kiterjesztések lesznek a HipHoppal is használhatóak, de a fenti prezentációban 100.000 sornyi kiterjesztés függvényről beszélnek, mely a HipHop részét képezi – ezzel gondolom jópár kiterjesztés le van fedve.

Beépített webszerver

A HipHop saját webszerverrel rendelkezik, ami az én meglátásomban hatalmas előnyként jelentkezik, mindazonáltal a hoszting cégek dolgát ezzel sem könnyíti meg. Gondolom a webszerver a statikus fájlok kiszolgálására nincsen felkészítve, illetve nem feltétlenül támogatja a rewrite rule-okat, és más hasonló tipikus általános webszerver funkciókat sem, így várhatóan egy nginx/lighttpd felhúzása proxyként a HipHop elé lehet a legcélszerűbb felállás.

Roadmap

A HipHop PHP jelenleg az 5.2-es PHP verzióval kompatibilis, de szeretnék az 5.3-as verziót mielőbb beérni. További cél az Apache támogatása is.

Kinek jó, kinek nem?

Aki néhány nyílt forrású programot futtat egy hoszting cég szerverén, az várhatóan semmit sem fog profitálni a HipHop megjelenésével, sem a hoszting cégek, sem a nyílt forráskódú projekteket fejlesztők várhatóan nem fognak rövid távon átállni rá. A célcsoport sokkal inkább azok a saját nagyobb projekteket kivitelező fejlesztők, melyek jópár szerverre dolgoznak, API-t fejlesztenek, ahol a PHP kódokra jelentős terhelés jut. Ezekből adódóan a HipHop célja nem a Zend Engine lecserélése, ez egy párhuzamos vonal lesz.

Még több olvasnivaló

Ha valaki egy jó kis tech olvasnivalóra vágyik, akkor ajánlom neki Terry Chay írását, jó sok részletről lehet nála olvasni egy hosszú-hosszú blogbejegyzés keretében.

jQuery 1.4 újdonságok

3 Replies

Megjelent a jQuery 1.4, számos újdonsággal, mely miatt érdemes áttérni az új változatra. A legtöbb dologban visszafele kompatibilis az 1.4-es verzió, a potenciális problémák listáját azonban érdemes átnéznie annak, aki régi kódot frissít.

jquery-14

Az újdonságokat egy prezentációban szedtem össze ezentúl, de inkább csak azokat, melyeket érdekesebbnek, izgalmasabbnak találtam:

jQuery 1.4 újdonságok

További olvasnivalók: