abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
    včera 20:22 | Nová verze

    Byla vydána (𝕏) květnová aktualizace aneb nová verze 1.101 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a videi v poznámkách k vydání. Ve verzi 1.101 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.

    Ladislav Hagara | Komentářů: 0
    včera 10:00 | Komunita

    V Brně na FIT VUT probíhá třídenní open source komunitní konference DevConf.CZ 2025. Vstup je zdarma, nutná je ale registrace. Na programu je celá řada zajímavých přednášek, lightning talků, meetupů a workshopů. Přednášky lze sledovat i online na YouTube kanálu konference. Aktuální dění lze sledovat na Matrixu, 𝕏 nebo Mastodonu.

    Ladislav Hagara | Komentářů: 0
    včera 09:44 | IT novinky

    Vyloučení technologií, které by mohly představovat bezpečnostní riziko pro stát, má umožnit zákon o kybernetické bezpečnosti, který včera Senát schválil spolu s novelami navazujících právních předpisů. Norma, kterou nyní dostane k podpisu prezident, počítá rovněž s prověřováním dodavatelů technologií pro stát. Normy mají nabýt účinnosti od třetího měsíce po jejich vyhlášení ve Sbírce zákonů.

    Ladislav Hagara | Komentářů: 4
    včera 01:11 | Nová verze

    Open source platforma Home Assistant (Demo, GitHub, Wikipedie) pro monitorování a řízení inteligentní domácnosti byla vydána v nové verzi 2025.6.

    Ladislav Hagara | Komentářů: 0
    včera 00:55 | Nová verze

    Po Red Hat Enterprise Linuxu a AlmaLinuxu byl v nové stabilní verzi 10.0 vydán také Rocky Linux. Přehled novinek v poznámkách k vydání.

    Ladislav Hagara | Komentářů: 0
    11.6. 22:55 | Nová verze

    Bylo vydáno Eclipse IDE 2025-06 aneb Eclipse 4.36. Představení novinek tohoto integrovaného vývojového prostředí také na YouTube.

    Ladislav Hagara | Komentářů: 0
    11.6. 22:33 | IT novinky

    Americká filmová studia Walt Disney a Universal Pictures podala žalobu na provozovatele populárního generátoru obrázků pomocí umělé inteligence (AI) Midjourney. Zdůvodňují to údajným porušováním autorských práv. V žalobě podané u federálního soudu v Los Angeles označují firmu za „bezednou jámu plagiátorství“, neboť podle nich bez povolení bezostyšně kopíruje a šíří postavy z filmů jako Star Wars, Ledové království nebo Já, padouch, aniž by do nich investovala jediný cent.

    Ladislav Hagara | Komentářů: 1
    11.6. 18:33 | IT novinky

    Ultra Ethernet Consortium (UEC), jehož cílem je optimalizace a další vývoj Ethernetu s důrazem na rostoucí síťové požadavky AI a HPC, vydalo specifikaci Ultra Ethernet 1.0 (pdf, YouTube).

    Ladislav Hagara | Komentářů: 0
    11.6. 13:00 | IT novinky

    Francouzský prezident Emmanuel Macron chce zakázat přístup na sociální sítě pro děti do 15 let. Francie podle něj tento krok udělá sama do několika měsíců, i pokud se na něm neshodnou další státy Evropské unie. Reaguje tak na úterní vraždu vychovatelky, kterou ve východofrancouzském městě Nogent pobodal 14letý mladík. Jednotlivé sociální sítě podle něj mají možnost věk ověřit a vymáhat zákaz pomocí systémů na rozpoznávání tváří.

    Ladislav Hagara | Komentářů: 12
    11.6. 05:11 | IT novinky

    Byl aktualizován seznam 500 nejvýkonnějších superpočítačů na světě TOP500. Nejvýkonnějším superpočítačem zůstává El Capitan od HPE (Cray) s výkonem 1,742 exaFLOPS. Druhý Frontier má výkon 1,353 exaFLOPS. Třetí Aurora má výkon 1,012 exaFLOPS. Nejvýkonnější český počítač C24 klesl na 165 místo. Karolina, GPU partition klesla na 195. místo a Karolina, CPU partition na 421. místo. Další přehledy a statistiky na stránkách projektu.

    Ladislav Hagara | Komentářů: 0
    Jaký je váš oblíbený skriptovací jazyk?
     (55%)
     (31%)
     (7%)
     (2%)
     (0%)
     (1%)
     (3%)
    Celkem 255 hlasů
     Komentářů: 16, poslední 8.6. 21:05
    Rozcestník

    Dotaz: 1Gbps LAN versus Terminal server a přístup k .DBF souborům

    4.7.2012 09:47 Dramon
    1Gbps LAN versus Terminal server a přístup k .DBF souborům
    Přečteno: 415×

    Našel by se tu odborník, který by byl schopen mi vysvětlit, jaký je rozdíl když přistupuji z 10 stanic po 1Gbps síti k datům v cca 150 .DBF souborech na Samba Serveru a nebo pokud použiji 10 terminálů na Windows serveru, na kterém budou zmiňovaná data fyzicky uložena?

    Jde o to, že nejmenovaná společnost se svým SW doporučuje od cca 3-5ti stanic začít používat TS. Zatím jede na Sambě po síti, ale jsem tlačen do nového Windows serveru s terminálovými licencemi :(

    Nejde mi do hlavy, jaké výhody má lokální přístup na TS? Po síti tahám rychlostí cca 100 MB/s na stanici a 200 MB/s na serveru (bonding), z RAID vytáhnu 200 MB/s, ale nejvíce času stejně trávím čekáním na zámky ostatních uživatelů, což bude v obou případech stejné. Nebo ne??
    Navíc při práci po síti mi data zpracovává 10 moderních CPU, v serveru je jedno na vše.

    Děkuji předem za objasnění problematiky :)


    Řešení dotazu:


    Odpovědi

    4.7.2012 10:17 ji
    Rozbalit Rozbalit vše Re: 1Gbps LAN versus Terminal server a přístup k .DBF souborům
    nemenovana spolocnost chce proviziu. nech donesu nieco na vyskusanie
    4.7.2012 12:32 mobi
    Rozbalit Rozbalit vše Re: 1Gbps LAN versus Terminal server a přístup k .DBF souborům
    Jde o to, že zamykání .dbf souborů (oplocks) může být pěkný průšvih jak co do výkonu, tak co do konzistence dat. Nepomůže seberychlejší diskové pole, a GB síť s Intel NIC. Sám jsem se na tom dost spálil. Společnosti, co pak nepoužívají SQL engine, ale zápis do sdílených souborů se pak vymlouvají na kde co. Obvykle pak padne na řadu první prefabrikované řešení - MS Terminal Server, kdy se sdílí nad lokálem a zamykání souborů se řeší lokálně.

    Jeden čas (2 roky) jsem používal workaround, kdy jsem na serveru s přebytkem výkonu se Sambou zvirtualizoval X winXP a zřídil na ně TS přístup a ty jely nad lokální Sambou přes virtuální GB síť. Pak se hodně problémů s rychlostí (zamykání soborů) vyřešilo.

    Ale nakonec bylo stejně zmigrováno na TS, protože jakákoli závada na DB šla na vrub toho, že to je nestandartní nevyzkoušené řešení.
    4.7.2012 13:04 Dramon
    Rozbalit Rozbalit vše Re: 1Gbps LAN versus Terminal server a přístup k .DBF souborům

    Oplocky chápu tak, že slouží k řízení síťové cache na straně klienta a osobně jsem nikdy na problém s konzistencí nenarazil. Co se týká výkonu, není mi jasné, v čem se liší rychlost lokálního zamykání od síťového. Jasně že lokálně/TS budu mít data v RAM, takže mi je to servíruje rychleji než síť nebo samotný disk/RAID, ale všechny soubory na lokál přenesu za cca 20s, ale reporty trvají mnohem déle a vytížení serveru, ale hlavně sítě nebo klienta není 100% ani u jednoho.

    A pak mi tvůrci SW tvrdí, že TS vyřeší mé problémy :)

    vandrovnik avatar 4.7.2012 15:22 vandrovnik | skóre: 21
    Rozbalit Rozbalit vše Re: 1Gbps LAN versus Terminal server a přístup k .DBF souborům
    Kdyby to bylo aspoň trochu možné, doporučil bych přechod na software, který používá SQL databázi a ne xxx .dbf tabulek. Jak mají třeba ošetřeno, aby některý uživatel omylem část .dbf souborů nesmazal?
    rADOn avatar 4.7.2012 16:16 rADOn | skóre: 44 | blog: bloK | Praha
    Rozbalit Rozbalit vše Re: 1Gbps LAN versus Terminal server a přístup k .DBF souborům
    Oplocky chápu tak, že slouží k řízení síťové cache na straně klienta
    Ne, oplocky označí část souboru na serveru cedulkou "tady se pracuje" aby nedocházelo k souběhům když více klientů oblejzá stejné bajty. Což se zrovna u .dbf souborů děje neustále a souběh by mohl poškodit data takže je to dost kritické.

    O rychlost nejde. IMO největší problém oplocků po síti nastane když klient něco zamkne a pak zdechne. Na lokále filesystém může zjistit že proces držící zámek neexistuje a zámek pustit. Na síti se to řeší různými obezličkami ale 100% spolehlivé řešení neexistuje.

    Obecně simulovat klient-server architekturu takhle hovadským způsobem dělá jen problémy, takže snaze stáhnout to na jednu mašinu se vůbec nedivím. Kdybych musel nějakou prehistorickou dosovskou aplikaci provozovat, asi bych to tak dělal taky. Ovšem slyšet něco takového od dodavatele _nové_ aplikace tak bych našel nějakou porádně tlustou referenčku SQL a omlátil ji dotyčnému o hlavu.
    "2^24 comments ought to be enough for anyone" -- CmdrTaco
    6.7.2012 07:15 Dramon
    Rozbalit Rozbalit vše Re: 1Gbps LAN versus Terminal server a přístup k .DBF souborům

    Popisovanou funkcionalitu beru jako klasické zamykání, Na základě dokumentu Samby http://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/locking.html#id2615570 jsem opravdu žil a doteď žiju v přesvědčení, že se jedná o rozšíření zámků o kešování na straně klienta.

    Zvláště, když si člověk dá vyhledat něco jako "samba mdb", tak narazí na diskuze a všude píší "vypnout oplocky". Tak snad nevypínají zamykání, ale jen oplock kešování na straně klienta. Tak to aspoň chápu já.

    7.7.2012 10:30 Sandokan
    Rozbalit Rozbalit vše Re: 1Gbps LAN versus Terminal server a přístup k .DBF souborům
    Pokud si pamatuji, tak u aplikací kolem .DBF souborů nebyl ani tak problém se zámky záznamů nebo souborů, to opravdu docela fungovalo, ale největší průšvih bylo udržet trochu pohromadě indexové soubory (takové to .NDX, .IDX, .MDX, .CDX nebo jak se to všechno jmenovalo). Když k té aplikaci přistupovalo asi 50 uživatelů, byla to opravdu velká pakárna. Nevím, jaká skvělá aplikace je to ve Vašem případě, ale důvod může býti toto. Další možnost jsou ty hromady dat, které se v případě klientských aplikací do nich musí ze serveru nasypat. Měli jsme v prehistorické době opravdu úžasnou účetní aplikaci, která mezi spuštěním a úvodní obrazovkou stáhla ze serveru 30MB něčeho. Když u toho bylo 15 účetních, měla toho 100Mbitová síť opravdu plný brejle, takže je možné, že se mysl dodavatelské firmy ubírala tímto směrem.

    Založit nové vláknoNahoru

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.