Hlavní navigace

Technický pohled na aukce s platbou za příhoz

Eduard Hlava 14. 12. 2009

V minulosti se nejen zde na Lupě řešil rozmáhající se fenomén aukcí s platbou za příhoz. Myslím, že jedním z prvních článků na toto téma byl ten od Patricka Zandla. V něm je popsán jak princip těchto systémů, tak také nějaké příklady. Od doby vzniku článku se vyrojily na českém internetu snad desítky dalších podobných webů. I mne jeden takový neminul.

Eduard Hlava - karikatura

Ilustrace: Nenad Vitas

Nechci zde spekulovat o právní či morální rovině těchto aukcí. Ale protože jsem nakoukl do kuchyně vývoje jednoho takového systému, podělím se o některé své poznatky. Ti, kteří nyní očekávají návod, jak vyhrát, však zklamu hned v úvodu. Mým cílem není podrobně technicky rozebírat systém fungování. Spíše bych rád maličko poodhalil některé technické záležitosti a pohlédl na tento typ webové aplikace z jiného úhlu, než se běžně stává. A třeba i přinesl okruhy problémů, které bude muset vyřešit každý, kdo se do výroby něčeho takového bude chtít také pustit.

Jak to začalo? Pamatuji si to jako dnes. Poprvé jsem se o těchto typech aukcí dozvěděl na začátku léta na obědě, kdy jeden náš tehdejší kolega přišel s tím, že našel nějakou podivnou aukci, kde se platí za příhoz a výsledná cena předmětu je dost nízká. Třeba plasma televize za „pade“. Výsledkem naší diskuse bylo to, že to je „tedy fakt husťárna“. Říkal jsem si, že do toho bych jako dražitel opravdu nešel. Rozfofrovat peníze umím i jinak. I když přiznávám, že určitou míru vzrušení zde vnímám a chápu, že to spoustu lidí velmi láká.

Uběhlo několik měsíců a přišel za námi klient, který chtěl takovýto systém vyrobit. Jak jinak, než v šibeničním termínu. To bylo ještě více vzrušení než ze samotné hry. Tím jsme se také okamžitě ocitli na druhé straně barikády. A začali jsme řešit, jak to celé technicky uchopit, aby to fungovalo tak, jak má.

Ten princip aukce je docela jednoduchý a byl nejen zde na Lupě mnohokrát popsaný. Příhoz zvýší cenu o nějaké haléře a prodlouží čas do konce aukce o vteřiny. Technicky už to taková sranda však není, protože zejména co do zatížení serveru zde platí trochu jiná pravidla než u běžného informačního webu. U webové stránky je jedno, kolik lidí na stránky zrovna kouká (čte si), ale je podstatné, kolik lidí v nějakém krátkém okamžiku klikne na odkaz a tím vygeneruje požadavek na server. Takto může mít webovou stránku otevřeno třeba milion lidí, ale pokud nikdo na nic neklikne, server zívá a neví, do čeho píchnout.

U aukcí s platbou za příhoz je to ale maličko jinak. Jsou tu samozřejmě také důležité samotné kliky na tlačítko „Přihodit“, ale zároveň je podstatné, kolik lidí se právě dívá na hlavní stránku s běžícími aukcemi nebo na jednotlivé aukce. Vtip a problém zároveň je v tom, že se hraje v reálném čase a prakticky každá vteřina je důležitá. Na stránce odpočítává čas javascript, tedy na straně webového prohlížeče. Jenže aby to celé fungovalo, musí každý klient (webový prohlížeč) jednou za čas poslat požadavek na server a „zeptat“ se, jestli se něco v aukcích nezměnilo – tj. zda někdo jiný někde nepřihodil, nebo jestli nějaká aukce už neskončila. Přičemž perioda dotazování se počítá maximálně v jednotkách vteřin.

Když tedy uživatel klikne na „Přihodit“, odešle se požadavek serveru, ten to nějak zpracuje, vyhodnotí a uloží do databáze. A co dál? Nyní se musí informace o přihození prakticky okamžitě dostat k ostatním uživatelům, kteří zrovna pozorují odpočítávání času u aukce, která je zajímá. Nelze spoléhat na to, že si uživatel bude obnovovat stránku. Proto musí každý prohlížeč, který zobrazuje stránku s aukcí, odesílat pravidelně dotazy na server. Ten pak vrací zpátky aktuální stav. Bystřejším již došlo, že čím více uživatelů má otevřenou stránku s aukcemi v jednom okamžiku, tím více dotazů se sype směrem k serveru. Dovedu si představit, že uživatel přijde ráno do práce, pustí prohlížeč, nahodí si do jednoho panelu stránku s aukcemi a pak celý den dělá něco jiného. V pozadí mu však běží stránka s aukcemi. Když toto udělá třeba 100 lidí, mohou vygenerovat během vteřiny 100 dotazů na server. To není zrovna málo. Za hodinu to máme od stovky pasivně přihlížejících lidí přes 350 tisíc požadavků.

Z toho plyne, že na free web hostingu se tento typ aplikace provozovat rozhodně nedá. Kdybych si měl rýpnout, tak vlastně ani na žádném mně známém placeném web hostingu. K zahlcení serveru by v tom případě došlo už při několika desítkách civějících uživatelů.

Posuňme se ale dále. Nyní víme, že když se na aukce dívá alespoň jeden uživatel, jeho prohlížeč vlastně pravidelně posílá žádosti o vyhodnocování aukcí. Co ale když se zrovna nikdo nedívá? Neběží tedy javascripty vysílající požadavky na server, leč aukce musí běžet dál.

Nastupují tedy automatické úlohy na serveru. Tyto úlohy, zjednodušeně řečeno, nahrazují prohlížeče uživatelů a aktualizují stav aukcí. Aukce prostě musí běžet nezávisle na tom, jestli ji někdo pozoruje nebo ne. Zde bych rád uvedl, že tyto úlohy neslouží pro robotické umělé přihazování od virtuálních uživatelů provozovatele. Není k tomu důvod, uživatelé si podle všeho vystačí sami. A to i ve vymýšlení šílených přezdívek typu lentilka18, big_durasel apod.

Ale k čemu je třeba sledovat aukce a aktualizovat je, i když se nikdo nedívá a tedy ani nikdo momentálně nepřihazuje? Nestačilo by aukce zaktualizovat s příchodem prvního návštěvníka na stránku s aukcemi? Nestačilo. Důvod je prostý. Každý uživatel si může vytvořit tzv. automatického přihazovače. Tyto automaty jsou běžné i v normálních online aukcích, jen fungují trochu jinak.

Princip automatického přihazovače u aukce s platbou za příhoz je takový, že si uživatel zvolí, od jaké ceny předmětu chce, aby se robot spustil, jaká je maximální částka a … teď pozor … zvolí si maximální počet příhozů (bidů, čipů, …), které chce vyčerpat. Tímto způsobem si může uživatel určit maximální cenu, za kterou chce předmět získat.

Důvod toho, že si server musí sám sobě „posílat“ požadavky o aktualizaci aukcí, je tedy jednak nutnost vyhodnocování končících aukcí a hlavně právě automatičtí přihazovači. Tyto roboty jsou pak příčinou toho, že u aukcí těsně před koncem najednou přihodí franta222 a po něm big_lolitka a pak zase franta222. Po dvacáté páté iteraci nakonec ale vyhraje třeba prdelinka, která doteď nic nepřihodila. Ano, franta222 a další na tom prodělali a nakonec se směje ten (ta) třetí. Proč? Protože prdelinka měla lépe nastaveného svého robota. Vzhledem k tomu, že uživatelé vzájemně netuší, jak mají ostatní nastaveného přihazovače, tak tím do celého klání vstupuje i faktor správného úsudku, odhadu chování soupeřů a samozřejmě i trochu štěstí. Ale to už jsme v maličko jiné rovině.

Aby aukce běžely opravdu svižně, je třeba je vyhodnocovat téměř v reálném čase. Za třicet vteřin už může být pozdě. To klade nároky na dobrou optimalizaci celého procesu. Jednou z možností optimalizace je to, že každý uživatelův prohlížeč posílá dotaz na vyhodnocení všech aktuálních aukcí najednou, nikoliv pro každou zvlášť (což asi nikoho nepřekvapí). Zpátky od serveru dostane opět stav všech aukcí. Další možností je kešování aktuálního stavu aukcí na serveru, čímž se výrazně odlehčuje databázi (méně již aplikačnímu serveru). Má-li server třeba každou vteřinu „vyplivnout“ stav všech běžících aukcí, vyhodnotí je jen jednou v daném okamžiku, ale distribuce tohoto výsledku již probíhá asynchronně. Česky a zjednodušeně řečeno – výsledek v podobě datového souboru se uloží někam na disk serveru a tento soubor si sosají jednotlivé prohlížeče.

Možností technického řešení i optimalizačních metod je samozřejmě více. Stejně jako problémů, na které lze při vývoji či provozování narazit. Výše zmíněný vzorek je asi tím nejdůležitějším, co musí při vývoji každý dříve či později (vy)řešit. Všechno ostatní, jako je například zajištění plateb, zobrazování aukcí, objednávky, správa uživatelů a další funkce jsou už spíše rutinní záležitosti, které vývojářův mozek příliš nezatíží.

Na rozdíl od mozkových závitů účastníka aukce, který se musí snažit najít vhodnou strategii a taktiku, jak přihazovat nebo jak nastavit svého robota, aby rozebral své konkurenty na atomy a získal vysněný iPhone. A pokud možno při tom neprodělal kalhoty nebo kapesné od rodičů.

Našli jste v článku chybu?

14. 12. 2009 11:00

Stahovač. (neregistrovaný)
Tento typ aukcí, pokud nejsou rovnou podvodem, v podstatě představuje jistý druh gamblingu. Hráč chce přihodit na cenu kupovaného zboží, ale musí za to zaplatit poplatek (=hodit žeton do automatu), přičemž čím vicekrát přihodí, tím roste jeho šance, že dané zboží koupí. Mnohokrát neuspěje, ale jednou za čas ano. Když konečně uspěje, musí ještě zaplatit cenu "vyhraného" zboží, a pokud to má provozovatel dobře nastavené, tak v konečném důsledku ten člověk ztratí víc, než získá. Tj. má to…

14. 12. 2009 8:44

ondra.novacisko.cz (neregistrovaný)
Překvapuje mne, že někdo je překvapen jak takový systém může fungovat. Přitom mi navržené řešení přijde jako by to někdo psal pro fungování na webhostingu typu pipni.cz. Mám-li k dispozici vlastní serverovnu, tak už mám přece víc možností ne?

Jednak tu mám možnost to rozdělit na backend a frontend. Frontend je prostě jen zobrazovač, který se ptá backendu na data, které má zobrazovat. Backend je pak ta vlastní hra, ten celý systém. Tam to všechno běží, i když se nikdo nedívá. Tam to člověk může …

Vitalia.cz: Chtějí si léčit kvasinky. Lék je jen v Německu

Chtějí si léčit kvasinky. Lék je jen v Německu

Vitalia.cz: Potvrzeno: Pobyt v lese je skvělý na imunitu

Potvrzeno: Pobyt v lese je skvělý na imunitu

Měšec.cz: U levneELEKTRO.cz už reklamaci nevyřídíte

U levneELEKTRO.cz už reklamaci nevyřídíte

Podnikatel.cz: Přehledná titulka, průvodci, responzivita

Přehledná titulka, průvodci, responzivita

Měšec.cz: Vklad na cizí účet je draze zpoplatněn (přehled)

Vklad na cizí účet je draze zpoplatněn (přehled)

Vitalia.cz: Dáte si jahody s plísní?

Dáte si jahody s plísní?

Lupa.cz: Google měl výpadek, nejel Gmail ani YouTube

Google měl výpadek, nejel Gmail ani YouTube

Měšec.cz: Kdy vám stát dá na stěhování 50 000 Kč?

Kdy vám stát dá na stěhování 50 000 Kč?

Root.cz: Vypadl Google a rozbilo se toho hodně

Vypadl Google a rozbilo se toho hodně

Vitalia.cz: Spor o mortadelu: podle Lidlu falšovaná nebyla

Spor o mortadelu: podle Lidlu falšovaná nebyla

Podnikatel.cz: 3, 2, 1..EET startuje. Na co nezapomenout?

3, 2, 1..EET startuje. Na co nezapomenout?

Vitalia.cz: Mondelez stahuje rizikovou čokoládu Milka

Mondelez stahuje rizikovou čokoládu Milka

Podnikatel.cz: Víme první výsledky doby odezvy #EET

Víme první výsledky doby odezvy #EET

Měšec.cz: Finančním poradcům hrozí vracení provizí

Finančním poradcům hrozí vracení provizí

Root.cz: Telegram spustil anonymní blog Telegraph

Telegram spustil anonymní blog Telegraph

Měšec.cz: Golfové pojištění: kde si jej můžete sjednat?

Golfové pojištění: kde si jej můžete sjednat?

DigiZone.cz: Další dva kanály nabídnou HbbTV

Další dva kanály nabídnou HbbTV

Podnikatel.cz: Berňák kvůli EET prodlužuje otevírací dobu

Berňák kvůli EET prodlužuje otevírací dobu

Podnikatel.cz: Dárky v podnikání. Jak je uplatnit v daních?

Dárky v podnikání. Jak je uplatnit v daních?

Vitalia.cz: Naučí vás péct kváskový chléb bez lepku i s lepkem

Naučí vás péct kváskový chléb bez lepku i s lepkem