Hlavní navigace

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

14. 12. 2009
Doba čtení: 6 minut

Sdílet

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.

BRAND24

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čů.

Byl pro vás článek přínosný?

Autor článku

Autor se zabývá publikačními systémy, eshopy a dalšími užitečnými internetovými. Aplikacemi, e-commerce a marketingem na internetu. Pracuje jako CEO ve společnosti Neternity Group s.r.o.
Upozorníme vás na články, které by vám neměly uniknout (maximálně 2x týdně).