Kockázati tőke

(Külföldön, nyugaton) főleg úgy szoktak cégeket alapítani vagy komoly növekedési szakaszba lendíteni, hogy kockázati tőkét vonnak be. Megmutatom, hogy néhány ismert webvideós szereplő "mennyiből indult". Forintban írom oda, mert jófej vagyok:

• Brightcove: 9.6 milliárd
  
• Veoh: 6.4 milliárd
  
• Tudou (kínában ők a piacvezetők): 13.6 milliárd
  
• YouTube: a fejlesztés kezdéséhez 560 millió, a növekedés kezdetén plusz 1.3 milliárd, amikor ismertté és piacvezetővé vált megvette a Google 264 milliárdért.

Becslésem szerint (meg láttam a háttérben ezt-azt) a hazai videómegosztók egyikének elindítása sem került többe 30 milánál, de jellemzően 15 alatt maradt.

Nagyon fontos megjegyezni az okát: egyik sem akkora, még a mai piacvezető IndaVideo sem, hogy a fentiekhez hasonló, több száz szerverből álló komoly szerverhátteret igényelne vagy valamilyen trükkös CDN-t. Kicsi a magyar piac, így most maximum 10 szerverrel elvannak. Nudli.

Nagyobb volumennél a fejlesztési költségek exponenciálisan nőnek, több mindenre kell odafigyelni, ha a szerverek száma akár óránként is dinamikusan változik és egy "óriásfarmba kell beleprogramozni". Egész más szaktudást igényel.

Látogatottság

A látogatottságot általában látogatás per napban szoktuk nézni, azaz nem azt, hogy hány oldalt néztek meg, hanem hogy kb. hányszor látogattak az oldalunkra. Egy látogatás alatt ugye több oldalt szokott megnézni az ember. Az oldalak a publikus adatokat látogatás per hóban adják meg, mert így a hétvégék nem torzítanak, hanem benne vannak:

• YouTube: 65 millió (havonta 3-4-5 millióval nő!)
  
• Brightcove: 2 millió
• Veoh: 6 millió
• Facebook: 30 millió
• Flickr: 30 millió
• MySpace: 70 millió
  

A hazai értékek szerint a piacvezető IndaVideo majdnem 1 milliót csinált. A YouTube értékéhez a magyarok 1.5 millióval járulnak hozzá.

Sávszél

Webvideós körökben a legdrágább a sávszélesség, ez a havi üzemeltetési költségek nagy részét elviszi. Magyarországon kevésbé probléma, néhány gigabites hálókártyán és a BIX-en átfér simán a forgalom, de nemzetközi (nyugati) szinten óriási ügy. A CDN-ek árazásáról már szó esett.

A mágikus szám, sweet point a 0.1 USD/GB. Ennél lehet úgy összeegyeztetni a reklámbevételt, hogy rendes profitunk és növekedési potenciálunk legyen.

A YouTube 25 millió GB-ot forgalmaz havonta, de mivel ők a legnagyobbak, biztosan kevesebbet fizetnek 0.1 USD-nél. Becslések szerint 1.5 millió USD a sávszélköltségük. A külföldi nagy videós oldalak költsége a százezer dolláros nagyságrendben van. Havonta!

Technológiamániásoknak: a YouTube videói 10 gigás hálókártyákon szaladnak ki, 80Gbps-re van szükség minden másodpercben.

Reklámok

A jelenleg legelterjedtebb videós reklámozási forma a CPM, ami egyenlő ezer reklámmegjelenítéssel. Gyengébb oldalakon 10 USD-t (1600 Ft-ot) kell fizetned azért, hogy ezerszer megjelenjen a reklámod, drágább/jobb helyeken ez felmehet akár 100 USD-re is. Az átlag 25 USD.

Kérdés, hogy mikor térnek át ők is kattintási modellre. Szerintem addig nem, amíg nincs kialakult videóreklám beágyazási és mérési forma, amiről már írtam részletesebben.

Alapszabály

Ha összeveted a fenti sávszél és egyéb költségekkel a dolgot, akkor jön az ki, hogy videómegtekintésenként átlagosan másfél dollárcentet (0.015 USD), azaz 2.4 Forintot kell megtermelni, úgy jössz ki nullára.

Hazai szinten az olcsóbb fejlesztési és üzemeltetési költségek miatt ez kevesebb is lehet, de ez engem kevésbé érdekel.

Szerverek

Végül jöjjön a tech fejeknek legérdekesebb téma, hány szerverük van, milyenek? (Ha nem vagy fejlesztő, akkor innentől szép lassan el fogod veszíteni a fonalat, előre bocs.)

Adatbázis szerverek (mind MySQL 5.x!)

• Flickr: 166
• Facebook: 1800 (900 master és 900 slave, replikációban tolják)

Webszerverek

• Flickr: 244
• Facebook: 10000 (tíz! ezer!)

Cache szerverek (mind Memcached)

• Flickr: 14
• Facebook: 805
  

Általában és nagyságrendileg az ismert külföldi szolgáltatások több száz szervert üzemeltetnek. Látszik, hogy a Facebook-nál a cache-elésre rettenetesen ráfeküdtek, különben borzasztó kevés lenne 1 MySQL szerver 5 webszerverre. A legnépszerűbb adatbázis megoldás a MySQL replication, a MySQL cluster megoldás a memórialimit miatt nem rúghat labdába.

Ökölszabály, hogyha jól van megírva a webalkalmazásod és a szerver is rendben van, akkor átlagosan:

• egy oldal kiszolgálása 0.01 sec;
• az alkalmazás (pl. PHP) rész 0.005 alatt lefut;
• az adatbázis (pl. MySQL) hívások viszik el messze a legtöbb időt (ugye tudod, hogy miazaz XDebug például?);
• cache nélkül (pl. fejlesztési időszak) legfeljebb 30 lekérdezést nyomsz le egy futáson belül;
• cache-el legfeljebb 3-5-öt, de ha lehet egyet sem!
  

7 hozzászólás

1. idézem 2008.05.19. 14:24
   • lipilee
   honat szedted az infót? mit túrtam én ezek után a net egy pár évvel ezelőtt...
   a facebook park elég érdekes, kicsit úgy érzem túllőtték.
   érdekes perspektívába helyezi továbbá ez a magyar csodafarmot, az iwiwet (meg még pár másikat, amiről kevésbé hallani, de hasonlóan bloated). van adat, hogy most épp mennyi vassal tolják?
2. idézem 2008.05.19. 17:51
   • Hodicska Gergely
   Van azért ilyen irányú kezdeményezés is: yume dot com (sajnos rendesen kiírva smapnek vette).
   
   Üdv,
   Felhő
3. idézem 2008.05.19. 23:24
   • Gábor
   @lipilee Követek jópár oldalt RSS-ben és mindig felírtam, ha érdekes számokat láttam. Így jött össze ez a nagy halom, amit aztán összefoglaltam.
   
   
   @felhő Üdv a blogomon! :-)
   
   A Yume érdekes, köszi. Jól látom, hogy boldog-boldogtalan azért nem illesztheti be a lejátszójába? Nem látok sehol fejlesztőknek szóló finom ActionScript-tel megszórt doksit.
4. idézem 2008.05.20. 07:35
   • Hodicska Gergely
   "Üdv a blogomon! :-)"
   Köszi :), találtam sok érdekeset, épp most fogunk szerintem mi is egy subprojekthez EC2-t használni, bár az pl. még nem tiszta, hogy hogyan lehet ott egy tuti load balance-t összehozni, mármint maga a loadbalancer hogyan lehet redundáns.
   
   Yume: gondolom előbb szerződni kell velük, de ebben kapásból nem vagyok biztos. Viszont azt hallottam, a flashesektől, hogy néha nem a legjobb minőségű cuccok ezek, meg ami bosszantó, hogy rengeteg trace van bennük, ezért a saját üzeneteinekt nem is látjuk. Hasonló can pl. a ClearSpringgel is.
   
   Üdv,
   Felhő
5. idézem 2008.05.20. 08:04
   • Gábor
   A load balancer-hez DNS round robint kell használnod. Aztán az EC2-n prímán elvan a HAProxy (állítólag most az a legjobb).
   
   Reklámügyben: éppen ezért puffogtam a másik postban, hogy nincs még standard megoldás, amit ripsz-ropsz lehet használni mindenféle extra (szerződéskötés) nélkül.
6. idézem 2008.05.20. 15:02
   • Hodicska Gergely
   Hát igen, nekem is úgy tűnt, hogy ott nem lehet jobbat kihozni, csak igazából nem a legszimpibb ez a felállás. DNS nem mindig ad egyenletes terhelést (bár általában elvileg elég jó), kérdés, hogy egy kiesett IP-vel mit lehet az EC2-nél kezdeni.
   
   Üdv,
   Felhő
7. idézem 2008.05.20. 22:26
   • Gábor
   Elastic IP address a barátod, read here.
   
   Fogalmam sincs, hogy mennyi a terhelésetek, de egy nagyobb instance-on futó HAProxy-val állítólag 10e kérést is le lehet kezelni 1 sec alatt. Fontos a nagyobb instance, mert azok szinte teljes dedikált I/O-t kapnak, a kicsik pl. hálókártya szinten 250mbps-re vannak limitálva.

Legutolsó hozzászólások

DJ PLAYER Blue Edition: Gábor: Ja, és természetesen megy iPad-en is, hiszen _minden_ iOS app megy iPad-en.

DJ PLAYER Blue Edition: Gábor: Bug report-okat itt fogadunk: http://djplayer.net/page/bug_report_fixes

DJ PLAYER Blue Edition: hohand: Hello!A dj player mukodik iPad-on is?Tegnap feltettem, wifi-n athuztam ra zeneket,de amikor ranyomtam egy zeneszamra,error-t dobott es valami is!...

Uzsidoboz LED!: zo via Google Reader: vicces dolog, csak nem értem mire való

Uzsidoboz LED!: Gábor: @Benjamin Minek forogjanak? Egy falszínezőnek olyat nem kell tudnia, így is épp elég hatásosak.