Klávesové zkratky na tomto webu - základní­
Přeskočit hlavičku portálu


Diskuse k článku

Nový registr řidičů se odkládá, neprošel zátěžovými testy

Ministerstvo dopravy odložilo spuštění nové verze registru řidičů. Při zátěžových testech se ukázalo, že úředníci museli čekat na reakci téměř minutu, což je neúnosně dlouhá doba pro ostrý provoz. Pokud se nedostatky podaří odstranit, mohl by se nový systém rozjet na konci příštího týdne.

Upozornění

Litujeme, ale tato diskuse byla uzavřena a již do ní nelze vkládat nové příspěvky.
Děkujeme za pochopení.

Zobrazit příspěvky: Všechny podle vláken Všechny podle času

J38i76ř95í 68U49r44b75a86n 3458353933603

za co tahle povedená koalice vezme, to jen vzkvétá;-D

0/0
11.3.2013 7:14

P50a14v22e60l 23N88o85v85á60k 6461936819291

Bude se někdy někdo z politiků za tenhle bordel zodpovídat .............. je jasné že za těmito registry stojí IT firmy Drábek a spol ........... takže jsme zaplatili o stovky milionů více za nefunkční paskvil .......... děkujeme hrůzovládě rozpočtových rozkrádaček Rv

+2/0
10.3.2013 6:20

J92a65n 87Š13l22é68g38l 8642330168123

Já bych to spíš osobně viděl, že při tom zápisu probíhá kontrola s jinými systémy a ti experti netuší nic o tom, že by to mohli zpracovávat paralelně. Minule to bylo u toho dopravního registru. Neprošla validace s jedním serverem a celý proces se ukončil.

+1/−1
10.3.2013 0:09

M33a27r95t47i51n 43P60e46c15i72n81a 4511713

V tom případě mi přijde rychlejší udělat najednou třeba 400 dotazů, vytisknout a pak s nimi poslat na ústředí nějakého kurýra... Bude zpět rychleji než dotaz zadaný přes ten vypečený program;-D

+3/0
9.3.2013 23:50

M98a41r12t43i68n30a 98M22a72r61t46í20n58k90o96v83á 5597985144978

Pročpak mě to ani trochu neudivuje?8-o IT zakázky pro stát dělají firmy, které o tom nemají ani "šajn" a podle toho to vypadá;-€;-€ Doufám, že to bude stát ministerské či náměstkovo křeslo!!!!

+7/0
9.3.2013 20:34

J48i77ř71í 26F86r54a57n12k34l 9613291790920

Sice o IT nemají ani páru,ale jak sepsat nevypověditelnou smlouvu,jsou machři.Že se raději nevěnují advokacii.

+4/0
9.3.2013 21:28

J35i66n11d20ř47i66c48h 55Š12k29o28p56e69k 4795271730905

Nedávno se v tisku objevil článek, kolik si hackeři berou za pád nějakého serveru. Napadlo mě, že schození registru řidičů díky jeho stabilitě musí být brnkačka a budou ho dávat jako bonus zdarma při větší objednávce

+3/0
9.3.2013 20:14

V56í69t 57B89r52z28o48b76o76h67a20t60ý 7540332153431

Je vidět jak tomu rozumíte. On je rozdíl zahltit veřejný server dostupný z miliard přístupných míst dotazy a tím jej znedostupnit, tak jak se to dělo se spousty webových serverů tento týden a mezi neveřejným systémem, který funguje pouze mezi několika ověřenými a přesně danými pobočkami. V prvním případě se proti takovému útoku dopředu nejde nějak efektivně bránit, v druhém případě se jedná o uzavřený výměnný systém, který jde zabezpečit daleko lehčeji a efektivně.

0/0
10.3.2013 13:14

M90a40r43t37i14n 42V35o22j51á77č30e81k 9732688158807

noo to vypadá slibně ,výměna řidičáku a přihlášení auta je při nových registrech na týdenní dovolenouR^ jen tak dál ještě zapojit katastr a třeba sociální ať ten měsíc dovolené lidi trochu vyžijou

+4/0
9.3.2013 19:44

V35í66t 50B67r34z68o30b32o19h79a14t38ý 7440232763161

U řidičáků kvůli tomu start odložili - viz. článek. Na registru vozidel jsem byl několikrát na konci minulého roku - žádný problém jsem neměl, Vy ano, nebo jen tak plácáte?

0/0
10.3.2013 13:18

K76a77m49i96l 53K15r85b74á44l89e48k 6834922795563

a bude si moci teď člověk vyřídit řidičák kdekoliv i mimo okres trvalého bydliště? to by byl pokrok

+1/0
9.3.2013 18:01

V53á57c40l56a25v 87S91ý66k84o62r64a 6872160887300

O tom hodně pochybuji. Třeba u pasu to nejde.

0/0
9.3.2013 19:24
Foto

P36a75v43e39l 43Č88e74r35n34í81k 1188205210190

Nevidím důvod proč by to nemělo jít. Tedy - samozřejmě že to nepůjde ale objektivní důvody už jsou mimo. Celostátní databáze čehokoliv můžou být centrální a tisíckrát rychlejší než lokální kartotéky, které mnoho úřadů používá. představa že kdokoliv může vydat doklad je však pro mnoho úředníků tak nepředstavitelná, že to nemůže projít.

+2/0
9.3.2013 19:42

V79á37c65l34a26v 48S50ý38k34o55r79a 6102430197630

Jasně že technicky by to šlo, ale musel by někdo chtít změnit zákon. Třeba u živností to už funguje.

+1/0
9.3.2013 21:29

M63a39r60t50i62n 80P37e72c83i98n28a 4871323

No jasně, že to nikdy nemůže projít. Ztratili by totiž práci...:-P

+2/0
9.3.2013 23:52

I23v18o 74H59u66b21á14l62e30k 1778510354890

že to nefunguje mě tak dalece nepřekvapuje, mě děsí jiná věc s tímto související - docela rád bych viděl ty smlouvy...sem tam se šustne něco v tom smyslu, že smlouvu stejně nejde vypovědět, že smlouva je napsaná nevýhodně pro odběratele ( stát ), že nám opět hrozí arbitráž za neplnění smlouvy a zpravidla taky, že smlouva je tajná a nejde bez souhlasu obou stran zveřejnit, protože by to ohrozilo know-how....tak z těchto zpráviček já šílím, motá se kolem toho bůhvíkolik právníků ministerstev, právních poradců, externích právních firem a nevím kolik ještě přísavek a parazitů a potom se člověk dozví tyhle hovadiny a krade se vesele dále - to mi prostě hlava nebere

+2/0
9.3.2013 17:54
Foto

M75i35r80o57s15l26a90v 35O16r92t 2852955128434

To je taky pěkná drábkovina...

0/0
9.3.2013 16:43

L30u70d54ě29k 63M27u72s85e98l64í13k 3746629

Laický dotaz: ten původní registr opravdu nešel propojit s ostatními registry?

+1/0
9.3.2013 16:36

V60i58k47t48o34r 43Š68e94d40i69v49ý 8786561430126

Ježišmarjá, to jste fakt tak naivní, že si myslíte, že "elektronizace veřejné správy" se dělá proto, aby se ušetřilo nebo aby to bylo pro někoho efektivnější? ;-D

+4/0
9.3.2013 17:18

V59í90t 12B72r67z55o11b86o67h26a92t86ý 7510502903221

Podívejte, je sice vcelku jasné, že si někdo na tomto mastí kapsu, ale zároveň je vidět, že systémy přináší již první ovoce. Za posledních 5let se skutečně výměna dat mezi úřady zlepšila. A dokonce se zlepšuje i komunikace mezi člověkem a úřady. Tedy spoustu věcí už člověk nemusí na úřad nosit, stačí zaslat elektronicky a dokonce při některých změnách si člověk nemusí vystát frontu na každém úřadu zvlášť, ale stačí ji podat jen na jednom. Já osobně nevidím problém v elektronizaci jako takové, jen v přefinancování této jistě dobré myšlenky.

0/0
10.3.2013 13:31
Foto

P62a73v55e50l 56P58o59k82o46r21n41ý 2576124970282

Jde třeba o to, že byl pod systémem, který již prodejce nepodporuje.

0/0
9.3.2013 17:21

J75a58n 55P92a21v23e61l83k49a 3977831904961

Spíš se spouští pod systémem, který prodejce podpoří.

0/0
9.3.2013 18:58

V77í84t 18B21r93z58o17b31o54h44a83t82ý 7410552783561

Obávám se, že ne, ono třeba u registru vozidel byl problém, že spousta pracovišť používala systém "jinak" tzn. doplňkové informace psala do databáze jinak, do některých políček psala jiné údaje a při spojení se tyto údaje "bily". Proto se pak až třetina všech zápisů musela do cílové databáze importovat ručně. V přímém propojení o kterém mluvíte by se navzájem spousta informací přepsala, ztratila a nebo nebyla kompletní. Centrální systém má právě tyto chyby eliminovat. U registru aut se spousta věcí povedla - jen se o tom moc nemluví - například se zjistilo, že úředníci dokážou na jedno VIN registrovat více aut a legalizovat tak krádená vozidla.

0/0
10.3.2013 13:24
Foto

P42a48v13e27l 27Č18e94r54n72í16k 1138505780960

wtf? minutu? minutu trvá v mysql několikanásobný select s vnořeným poddotazem na víc než jednu tabulku o velikosti stovek tisíc řádků... co doprčic dělá tahle aplikace, že to musí trvat tak dlouho?

+3/−1
9.3.2013 16:16

K42a35m13i25l 98D62o79l85e77z54e65l 6792726404372

ono takovych dotazu zrejme prislo napr 5000 zaroven. Aby neco takoveho dobre fungovalo, to se musi umet, jak z hlediska psani samotneho SQL spravne navrhnout a nadimenzovat cluster na kterem to bezi. pri spatne optimalizaci se obvykle SQL uvari na pozadavcich na disk

+2/−1
9.3.2013 16:28
Foto

P83a25v68e88l 76Č46e57r14n93í63k 1528805920220

5000 zároveň jich přijít nemůže protože počet obcí s rozšířenou působností je kolem 200. V každé obci není na 100% víc než 5 souběžně fungujících přepážek.

A představa že všech 1000 přepážek naráz odešle request nějakého složitého dotazu na DB je nulová. A i kdyby ta nula nastala, (klasicky pripad kdy null == true) je tu přeci cachování (jak na úrovni DB, tak na úrovni webového serveru ... Prostě a jednoduše - jsem programátor. Něco málo o databázích vím. A i přes všechny znalosti nevidím jediný důvod, proč by měla odezva systému trvat minutu. Nedovedu si představit jediný smysluplný úkon, který by dokázal běžný komerční server zahltit tak, aby to trvalo minutu.

+2/0
9.3.2013 18:28

T41o78m31á52š 98V77a13n20č10u27r94a 4418735580358

Jediný důvod? Blbej programátor. Stačí špatně navržený datový model, SQL dotaz nebo ignorovat indexy a klidně může jediný dotaz trvat i více než minutu. V jiném případě to může být i špatně navržený server. Jednou jsme měnili u klienta server a aplikace rázem jela několikanásobně rychle.

+1/0
9.3.2013 19:09

V80i69k14t10o89r 30Š35e20d37i47v27ý 8216811140466

Neboli neschopný dodavatel.

0/0
9.3.2013 19:33
Foto

P95a51v78e67l 82Č23e91r30n47í59k 1678785240770

základní úkol úředníků bude: 1) zadávání nových informací (insert = zlomek sekundy) . 2) zpravování stávajících informací (update konkrétního řádku = zlomek sekundy pokud má tabulka definovaný primární klíč) 3) vyhledávání (select = v rámci běžných formulářů jde o běžný select, nikoliv o select s pod-dotazy, které by mohly zvýšit zátěž)

4) mazání údajů (delete = zlomek sekundy pokud je definovaný primární klíč)

to co popisujete není "blbej programátor". to je naprosté zanedbání základních principů databáze. Tady prostě není žádná výmluva. řidičáky nepotřebují nějaké šílené query. To je prostě jen registr - úložiště dat. Vkládáte, upravujete a v nejhorším případě hledáte v rámci určité skupiny.

Shodou okolností jsem dělal v PHP (ano, domácí bastl) skript na zpracování RUIANu. Můj hosting za necelých 500 kč za rok včetně dvou CZ domén zvládl stáhnout. zpracovat a uložit do DB všechny adresní místa celé republiky (řádově dva a půl milionu adresních míst) za necelých 24 hodin (pomocí CRONu volaného každých 10 minut) vzhledem k omezení 90 sec na jeden skript to znamená 216 minut čistého výpočetního času. Kdybych nebyl línej a napsal to v C# (a měl odpovídající hosting) bude to zlomek této doby.

řidičáky budou na přibližně stejné úrovni a vzhledem k tomu že hledání adresy v mé DB (která vznikla z výše uvedeného skriptu) je naprosto realtime (např hledání ulic v rámci města nezabere víc než zlomek sekundy) pak nechápu, proč by mělo zpracování řidičáků trvat tak dlouho.

Je mi jasné že důvod se nikdy nedozvíme. Oni si přeci musí chránit své know-how. Problém je v tom, že neexistuje rozumný důvod, proč by to mělo být tak pomalé.

+1/0
9.3.2013 20:03

Z67d51e35n29a 66H76v52o69z75d56e26n89s98k63á 6693857857816

Vzpominam si, ze pri spousteni toho nesmyslu v prosinci se pomalost omlouvala tim, ze ten kram se ted musi ptat jeste nejake databaze, kterou spravuju policajti, tedy vnitro. A snad ta vnitracka mela byt pod jinym systemem, nebo co. Dokonce se snad naznacovalo, ze policie dostatecne nespolupracuje...

Takze uz to sjednotili, nebo zas jako obvykle?

0/0
9.3.2013 20:21
Foto

P72a50v59e25l 26Č94e90r83n54í49k 1478335470590

to je něco jiného. registr řidičských průkazů je novinka. Tamto mělo sloužit k registraci aut a poznávacích značek.

0/0
9.3.2013 20:29

J58a63n 21Š57l28é56g21l 8272590238783

Tady zapomínáte na ten argument, že nevíte jak je napsaný ten web. Pokud ti chytrolíni třeba blbě použili AJAX, tak nemusí být prodleva mezi databází a web server, ale klientem a serverem. Osobně jsem tohle zažil. Najmou experta na databázi a pak webař tam udělá, že při AJAXu si pošle prakticky pro všechny data, která nepotřebuje. Zbastlit se dá všehcno.

0/0
10.3.2013 0:07

T38o17m67á96š 95V39a62n14č27u41r89a 4408175910718

Jste mě pořád nepochopil. Pokud je aplikace špatně napsaná, tak existuje rozumný důvod, proč to může trvat tak dlouho. Jednou se mi klidně stalo, že si klient stěžoval na neúnosné načítání stránky (asi tak 30 sekund), a to byl naprosto obyčejný select. Později se zjistilo, že u jednoho sloupce chyběl index. Jakmile se to nastavilo, stránka se načetla okamžitě.

Dobře provedena aplikace samozřejmě bude fungovat rychle. O tom žádná. Nic ale není růžové. Chyby se vždycky stávají. Pokud jste jen domácí bastl, nepracujete, časem to pochopíte.

A pokud i přesto na tomto existuje neúnosná prodleva, pak je problém někde jinde než v databázi - blbý skript, pomalý server, příšerná odezva mezi klientem a serverem, externí napojení apod. Všechno není jen o databázi.

0/0
10.3.2013 10:03

T18o19m57á94š 58V57a95n12č20u70r55a 4128885890518

Navíc byste už měl vědět, a je všeobecně známo, že státní zakázky vždycky byly takové zmetky. Nejčastěji to bývá tím, že zakázky dostává někdo blízký s průměrnými programátory, kteří mají malé znalosti, a ne nějaká renomovaná firma.

0/0
10.3.2013 10:09

M19i45c41h82a36l 64C82h90a82l41u38p75a 6518110109663

tak psát enterprise aplikace pro souběžnou práci více klientů je něco jiného než doma bastit něco v PHP a MySQL. MySQL není ani databáze, ta dost věcí neumí, takže to může dělat rychle.

+1/−3
9.3.2013 16:52
Foto

P18a46v57e10l 18Č38e69r71n68í91k 1748835690410

"bastlím" databáze pro herní server ke kterému se připojuje řádově tisícovka klientů v jednu chvíli. Každý klient vygeneruje průměrně aspoň jeden db request za sekundu. To vše se musí zpracovat, seskupit (nemá smysl podávat stejné requesty dvakrát za sebou) provést a rozeslat herním klientům.

Prosím - řekněte mi jediný obhajitelný důvod, proč by odezva serveru měla být 1 minuta. Jaký požadavek může něco takového způsobit?

+2/0
9.3.2013 18:32

V56í71t 85B13r24z91o14b98o71h10a94t49ý 7290362403511

Třeba dotaz do dalších databází z kterých to má načítat a porovnávat data? On asi nebude problém v té jedné databází ale opět, jako u registru vozidel, v propojení a synchronizaci s těmi dalšími.

0/0
10.3.2013 13:04

J77i80ř28í 28U58h94e46r25e55k 2798878747758

Těším se,až někdy něco spustí a ono to pojede bez problémů!

0/0
9.3.2013 16:10

H97o78n41z65a 75F55á60t80o40r 2779945784290

To máte fajn. Můžete se tak těšit do smrti.

0/0
9.3.2013 16:13





Najdete na iDNES.cz



mobilní verze
© 1999–2017 MAFRA, a. s., a dodavatelé Profimedia, Reuters, ČTK, AP. Jakékoliv užití obsahu včetně převzetí, šíření či dalšího zpřístupňování článků a fotografií je bez souhlasu MAFRA, a. s., zakázáno. Provozovatelem serveru iDNES.cz je MAFRA, a. s., se sídlem
Karla Engliše 519/11, 150 00 Praha 5, IČ: 45313351, zapsaná v obchodním rejstříku vedeném Městským soudem v Praze, oddíl B, vložka 1328. Vydavatelství MAFRA, a. s., je členem koncernu AGROFERT.