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

J36i41ř27í 65U67r90b63a69n 3368623643873

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

0/0
11.3.2013 7:14

P29a28v91e82l 88N46o31v53á52k 6381426269281

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

J20a72n 67Š83l62é50g18l 8702810988503

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

M66a49r85t19i65n 81P12e79c78i72n44a 4451153

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

M32a93r94t40i26n53a 24M38a64r38t42í64n74k42o65v66á 5827805894578

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

J52i26ř66í 46F77r19a56n71k37l 9863511750370

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

J62i61n68d54ř76i53c37h 83Š22k12o20p53e53k 4905491460225

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

V94í90t 53B87r61z15o37b58o62h16a96t52ý 7110762863661

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

M37a22r79t95i22n 15V37o61j72á40č24e55k 9922338288177

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í25t 90B59r31z48o10b56o41h94a24t46ý 7400412213341

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

K33a85m26i77l 68K49r10b89á63l90e25k 6314892805653

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

V87á88c26l84a85v 37S45ý87k21o32r64a 6262900897310

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

0/0
9.3.2013 19:24
Foto

P29a89v31e16l 17Č49e47r84n25í11k 1948395330770

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

V65á59c39l84a58v 50S24ý35k47o95r50a 6372660457840

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

M82a97r73t69i83n 12P10e58c59i31n47a 4511413

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

+2/0
9.3.2013 23:52

I69v83o 41H15u64b43á66l14e86k 1158400804260

ž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

M92i51r35o64s79l82a11v 98O41r12t 2302685498744

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

0/0
9.3.2013 16:43

L65u11d79ě63k 21M97u81s64e63l63í44k 3726329

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

+1/0
9.3.2013 16:36

V78i80k95t92o42r 88Š67e18d57i33v93ý 8516631490426

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

V38í81t 21B46r24z67o10b12o16h50a29t81ý 7430382873701

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

P29a16v60e31l 28P45o18k86o79r80n65ý 2186764840222

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

0/0
9.3.2013 17:21

J56a57n 49P36a80v52e97l57k63a 3787771884511

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

0/0
9.3.2013 18:58

V23í16t 34B79r68z61o74b44o13h28a24t92ý 7720332653431

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

P11a90v34e31l 38Č72e33r92n12í16k 1278305580950

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

K52a49m55i66l 73D72o56l85e48z25e20l 6762526394352

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

P42a18v29e42l 24Č61e86r52n67í23k 1498825400770

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

T62o44m53á84š 17V75a73n47č16u58r91a 4858255520198

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

V20i61k29t92o67r 68Š96e97d87i44v43ý 8646961860526

Neboli neschopný dodavatel.

0/0
9.3.2013 19:33
Foto

P33a89v25e17l 84Č80e66r90n45í63k 1608945120690

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

Z50d37e46n44a 42H56v60o30z88d72e18n64s45k64á 6503727207766

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

P59a62v35e11l 70Č17e66r38n53í69k 1838385160720

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

J94a38n 47Š17l96é30g63l 8392910138103

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

T52o97m30á44š 11V50a71n53č83u45r49a 4438485660388

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

T76o13m13á89š 45V60a65n45č68u17r27a 4438755880238

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

M29i70c31h11a27l 19C46h93a51l29u22p84a 6328370559933

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

P98a50v68e52l 59Č36e11r67n49í85k 1628605370830

"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

V17í94t 63B69r25z77o22b47o48h29a40t19ý 7610702333741

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

J43i18ř23í 22U27h92e17r45e62k 2928688637608

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

0/0
9.3.2013 16:10

H41o55n84z65a 66F22á26t31o61r 2219765814600

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

0/0
9.3.2013 16:13





Najdete na iDNES.cz