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

J71i15ř55í 89U57r62b87a16n 3188143693173

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

0/0
11.3.2013 7:14

P66a57v88e52l 70N55o79v85á65k 6351986329641

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

J16a47n 92Š40l34é36g65l 8732340898553

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

M84a59r20t42i50n 28P90e52c53i42n35a 4111233

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

M95a75r26t35i84n70a 41M80a29r33t82í38n97k60o32v54á 5597745264398

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

J97i10ř26í 23F53r83a52n39k33l 9153381310760

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

J61i59n15d13ř81i45c36h 38Š32k39o10p45e25k 4205301900355

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

V40í87t 51B58r83z72o69b87o14h17a18t80ý 7740252503471

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

M11a68r37t91i54n 23V58o15j19á17č73e85k 9342128358677

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

V65í62t 27B34r23z68o80b84o88h61a44t43ý 7670112393841

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

K85a86m20i11l 23K26r49b15á85l26e89k 6274202525633

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

V89á48c37l95a85v 62S15ý13k43o66r97a 6172670367480

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

0/0
9.3.2013 19:24
Foto

P14a95v89e33l 79Č48e85r44n49í55k 1198635430740

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

V41á84c98l35a55v 41S98ý10k13o32r27a 6592480157140

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

M32a92r68t66i98n 80P50e71c10i88n29a 4251163

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

+2/0
9.3.2013 23:52

I52v96o 59H17u73b13á43l63e74k 1888170864420

ž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

M98i72r96o63s23l48a14v 92O77r54t 2302435288674

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

0/0
9.3.2013 16:43

L88u86d48ě28k 81M37u65s45e37l43í19k 3716159

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

+1/0
9.3.2013 16:36

V15i40k35t38o54r 27Š94e86d71i26v78ý 8546111560276

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

V64í57t 40B34r46z47o97b36o41h78a44t81ý 7360682463671

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

P18a95v53e26l 31P60o75k74o41r70n50ý 2346394170922

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

0/0
9.3.2013 17:21

J45a89n 66P18a95v63e74l89k77a 3467921664291

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

0/0
9.3.2013 18:58

V58í73t 77B65r21z50o14b23o39h16a92t34ý 7490472883551

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

P79a88v39e76l 14Č54e13r89n74í79k 1488595310740

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

K59a20m20i70l 61D11o64l56e98z88e69l 6142886194762

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

P77a28v59e30l 86Č87e71r23n28í68k 1368985270550

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

T10o78m51á21š 74V58a92n45č79u43r10a 4468135210218

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

V27i83k66t25o27r 60Š61e78d32i32v56ý 8146191400296

Neboli neschopný dodavatel.

0/0
9.3.2013 19:33
Foto

P50a36v16e62l 62Č19e36r13n52í15k 1658665100750

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

Z62d70e69n21a 61H48v46o14z52d23e46n69s59k11á 6843687947406

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

P36a52v39e57l 40Č47e53r20n51í30k 1958555160970

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

J22a42n 27Š79l42é66g48l 8802280658673

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

T21o32m36á65š 96V55a21n67č21u55r58a 4548665250628

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

T22o49m16á28š 34V19a56n96č87u41r45a 4268575710138

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

M70i55c82h45a71l 35C96h60a95l63u79p91a 6938580169233

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

P92a69v84e69l 60Č49e81r48n20í48k 1298655190240

"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

V20í49t 42B23r93z61o90b86o32h68a62t42ý 7910352643331

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

J86i46ř48í 58U96h16e18r52e47k 2608418717958

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

0/0
9.3.2013 16:10

H39o21n13z98a 15F76á56t33o40r 2259235874380

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.