Ja se taky bavim:-) Dane uz v CR 5 let neplatim.
Ale samozrejme, at si min.obrany kupuje cokoliv a jakkoliv drahy, kdyz si to zaplati ze svyho.
Obecne by to tak melo byt - kdyz nejakej statni urad o necem rozhodne, meli by to zaplatit ze svyho. Tim myslim bud z penez strany toho, kdo rozhodnul to koupit, nebo rovnou z hotovosti toho cloveka, kterej to rozhodnul (pokud se za nej strana nepostavi a neda mu na to penize).
No a kdyz se ukaze, ze je vsechno OK a vsechno funguje dobre, neprokaze se nejaky pochybeni pri vyberovym rizeni, tak to muze stat zaplatit. No a kdyz se prokaze nejakej bordel, tak je to problem strany nebo toho jedince, jak si to zaplati, pripade jenom skutecny naklady. To by se pak hned vsichni snazili, aby to bylo v poradku a za rozumnou cenu, kdyby slo o jejich penize a hrozilo by jim, ze ty prachy daji ze svyho.
Je to skandální, již 3.7. na MD věděli, že 800 tisíc záznamů v DB má problém a vypsali za 27M další zakázku!!! "V návaznosti na zpracovanou analýzu dat bylo zjištěno, že cca 800 000 záznamů není možné převést do databáze nového systému CRV. Stávající registr vozidel je veden obecními úřady obcí na lokálních úložištích dat a na jednom centrálním úložišti dat. Po spojení dat uložených na obou úložištích se ukázalo, že existují neočekávaně velké rozdíly v datech." zdroj: http://www.isvzus.cz/cs/Form/Display/343682
Dokonce to věděli dřív, 3.7. to vyšlo v tom Věstníku. A formulář ještě odtajňuje, že se počítá s 65 % zakázky udělanými subdodavatelsky.
Oni si neumí ani pořádně nastavit DNS, proto to některým úředníkům nešlo, to už není ani k smíchu, ani k pláči http://list.hw.cz/pipermail/hw-list/2012-July/419621.html
MD už 3.7.2012 vědělo, že 800 tisíc záznamů má problém! A tak za 27M udělali další zakázku pro ATS telcom. http://www.isvzus.cz/cs/Form/Display/343682 " Jelikož se neuskutečnil předpokládaný převod 5 pracovníků z MV na MD by zůstala oblast podpory provozu nového CRV bez personálního zajištění. Ad b) V návaznosti na zpracovanou analýzu dat bylo zjištěno, že cca 800 000 záznamů není možné převést do databáze nového systému CRV. Stávající registr vozidel je veden obecními úřady obcí na lokálních úložištích dat a na jednom centrálním úložišti dat. Po spojení dat uložených na obou úložištích se ukázalo, že existují neočekávaně velké rozdíly v datech. Dokud nedošlo ke spojení dat na jedno úložiště, nebylo možné tuto velmi vysokou chybovost dat objektivně zjistit. Nový IS bude pracovat pouze s jedním úložištěm dat, a proto bylo nutné stávající data před jejich převedením do nového registru opravit, stávající stav byl překážkou provozu nového registru. "
Bavíme se tady akademicky, protože ty kódy ani komunikační protokol nevidíme. Vůbec první otázkou je, zda je použita WS, nebo nějaký HTTP požadavek či něco úplně jiného (sokety, ...). Dále, já si nemyslím, že by bylo třeba 100x ověřovat VIN:
Aplikace se zřejmě zasekne, dokud odpověď od serveru PČR nedorazí. A ani nejde o to, že by se ta data kešovala, ona je asi ani napoprvé nezíská a tak to zkouší pořád dokola. Nebo provádí reload stránky v prohlížeči ten úředník a generuje nové dotazy. Silně pochybuji, že to tam řešili asynchronně...
No a pokud má server PČR nastavený throttling, tak možná nadbytek dotazů zařezával a vznikl problém.
Dobre, ale to prece znamena ze:
1. server co zpracovava to VIN by mel mit vhodne nastaveny throttling/concurrency tech dotazu.
2. aplikace registru by kvuli tomu nemela prestat pracovat, protoze ten dotaz by mel byt (i v uzivatelskem rozhrani) zpracovan asynchronne. Zvlaste kdyz jde o volani externiho systemu.
Jestli ze je to typicka web service, tak nedava smysl pro kazdy novy request vytvaret dalsi connection. Vzdyt to umi HTTP uz davno. Nevim jak se ty VIN kody casto meni, ale nebyl by asi problem na strane volajiciho (tedy aplikace registru co se pta na VIN) ty data nejaky cas cachovat a neptat se 100x zbytecne znova na totez.
Tím se potvrzuje moje úvaha, že ten systém neposílá požadavky dávkově, ale pro každé VIN to posílá zvlášť a zřejmě to při absenci odpovědi do nějakého limitu opakuje.
Když si vezmete, že je to 130x jedno VIN, tak tam docházelo k opakování dotazu (např. co 2s), dejme tomu 400 uživatelů souběžně, tak to opravdu nemusel ten server ustát. A čím méně % odpovědí posílal, tím více opakovaných dotazů bylo generováno...
Předpokládám, že tam ani nemají náhodný čas do opakování a exponential backoff, takže se jim ty požadavky pěkně zasynchronizovaly...
A pokud ke každému dotazu zvlášť zakládají TCP spojení a byl tam 1 server...
Uff. Jestli jsem to dobře pochopil tak Centrální registr vozidel provedl takový DoS útok na server Policejního prezidia ČR -
„V některých případech jsme zaznamenali až 135 dotazů u jednoho VIN kódu od jednoho uživatele, čímž došlo k zahlcení a přetížení systému, který na to nebyl připraven,“ uvedl Pavel Osvald. http://www.mdcr.cz/cs/Media/Tiskove_zpravy/Problemy_registru_vozidel_s_pristupem_do+aplikaci_Policejniho_prezidia_CR_nebyly_zpusobeny_Ministers.htm
A tak hlavně že se to bude opravovat, opravovat a opravovat ...... :)
Za naše samozřejmě. Hned mě hřeje u srdce, že to půjde na něco dobrého. Možná .... jednou .... ,ale nenasytnost je nenasytná, to třeba zprovozní.
Třeba to bude s HW stejný, něco se nasadí, zjistí se že je to na c*uja, tak se to bude postupně opravovat(měnit), až se přijde na to, že jsou nakonec všechny HW komponenty od jiné firmy a z původní zakázky zůstane jen tunel a suprdupr smlouva. ;)