Monthly Archives: március 2011

A fapados/lean startup

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.

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.