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 22:00 | Komunita

Portál Stack Overflow po roce opět vyzpovídal své uživatele, jedná se především o vývojáře softwaru, a zveřejnil (podcast) detailní výsledky průzkumu. Průzkumu se letos zúčastnilo více než 64 tisíc vývojářů. Jejich nejmilovanější platformou je linuxový desktop. Ten je také druhou nejpoužívanější platformou vývojářů.

Ladislav Hagara | Komentářů: 0
24.3. 11:55 | Komunita

Vývojový tým OpenSSL ve spolupráci s iniciativou Core Infrastructure konsorcia Linux Foundation spustil proces přelicencování této kryptografické knihovny ze současné licence na licenci Apache Licence v 2.0 (ASLv2). Nová licence usnadní začleňování OpenSSL do dalších svobodných a open source projektů. Všichni dosavadní vývojáři OpenSSL (Authors) obdrží v následujících dnech email s prosbou o souhlas se změnou licence.

Ladislav Hagara | Komentářů: 11
24.3. 01:11 | Komunita

Před třemi týdny Mozilla.cz představila projekt Photon, jehož cílem je návrh a implementace nového vzhledu Firefoxu. Včera zveřejnila první náhled vzhledu Photon. Práce na projektu Photon jsou rozděleny do pěti týmů, které celkem čítají 19 lidí. Zaměřují se na zlepšení prvního spuštění Firefoxu a zaujetí nových uživatelů, celkovou úpravu vzhledu, zlepšení animací, zrychlení odezvy uživatelského rozhraní a také upravení nabídek. Vývoj lze sledovat v Bugzille.

Ladislav Hagara | Komentářů: 38
23.3. 20:00 | Komunita

OneDrive pro firmy je již ve webových prohlížečích na Linuxu stejně rychlý jako na Windows. Microsoft opravil chybu z listopadu loňského roku. OneDrive pro firmy běžel na Linuxu mnohem pomaleji než na Windows. V popisu chyby bylo uvedeno, že stačilo v prohlížeči na Linuxu nastavit v user-agentu Windows a vše se zrychlilo. Odpovědí Microsoftu bylo (Internet Archive: Wayback Machine), že Linux není podporován. Po bouřlivých diskusích na redditu i Hacker News byla chyba nalezena a opravena.

Ladislav Hagara | Komentářů: 6
23.3. 19:00 | Zajímavý projekt

Byla vyhlášena soutěž Hackaday Prize 2017. Soutěž je určena vývojářům open source hardwaru. Pro výherce je připraveno celkově 250 tisíc dolarů. Každý ze 120 finalistů získá tisíc dolarů. Nejlepší pak navíc 50, 30, 20, 15, 10 a 5 tisíc dolarů. Jedná se již o čtvrtý ročník soutěže. V roce 2014 zvítězil projekt globální sítě open source pozemních satelitních stanic SatNOGS. V roce 2015 zvítězil open source systém pro řízení elektrických invalidních vozíků pohybem očí Eyedriveomatic. V roce 2016 zvítězil modulární robot Dtto.

Ladislav Hagara | Komentářů: 0
23.3. 15:00 | Bezpečnostní upozornění

Byla vydána Samba ve verzích 4.6.1, 4.5.7 a 4.4.12. Řešen je bezpečnostní problém CVE-2017-2619. Pomocí symbolických odkazů a souběhu (symlink race) lze "teoreticky" získat přístup k souborům, které nejsou sdíleny. Linuxové distribuce jsou postupně aktualizovány (Debian).

Ladislav Hagara | Komentářů: 0
23.3. 07:43 | Nová verze

Na Steamu se objevil port hry Arma: Cold War Assault (Operation Flashpoint) pro Mac a Linux. … více »

creon | Komentářů: 30
23.3. 05:55 | Nová verze

Po 18 měsících od vydání verze 8.0 byla vydána verze 9.0 open source alternativy GitHubu, tj. softwarového nástroje s webovým rozhraním umožňujícího spolupráci na zdrojových kódech, GitLab. Představení nových vlastností v příspěvku na blogu a na YouTube.

Ladislav Hagara | Komentářů: 0
23.3. 03:33 | Komunita

Platnost posledního patentu souvisejícího s Dolby Digital (AC-3) vypršela. Po MP3 se tak do Fedory oficiálně dostane také kodek AC-3.

Ladislav Hagara | Komentářů: 5
23.3. 00:44 | Komunita

Feral Interactive, společnost zabývající se vydáváním počítačových her pro operační systémy macOS a Linux, nabízí své hry na Steamu vývojářům open source 3D grafické knihovny Mesa zdarma. Podmínkou je minimálně 25 commitů za posledních 5 let. Stejnou nabídku dostali vývojáři knihovny Mesa v roce 2015 od Valve. O rok dříve dostali od Valve tuto nabídku vývojáři Debianu a Ubuntu.

Ladislav Hagara | Komentářů: 0
Jak se stavíte k trendu ztenčování přenosných zařízení (smartphony, notebooky)?
 (14%)
 (2%)
 (71%)
 (3%)
 (10%)
Celkem 935 hlasů
 Komentářů: 72, poslední 1.3. 11:16
    Rozcestník

    Dotaz: Návrh na ušetření výkonu

    6.8.2011 02:20 Jano
    Návrh na ušetření výkonu
    Přečteno: 402×
    Zdravíčko přátelé. Načítám z mysql spoustu dat a ta data jsou pořád stejna. Nešlo by nějak v PHP nebo MYSQL udělat to, že by data zůstala načtena a ušetřila tak spoustu výkonu na stroji?

    Poradil by někdo jak na to?

    Odpovědi

    6.8.2011 03:17 Kit
    Rozbalit Rozbalit vše Re: Návrh na ušetření výkonu
    Otázkou je, kolik je pro tebe "spousta dat" a také zda jich do aplikace nenatahuješ zbytečně mnoho. Typickou chybou je například načtení tabulky do pole, ze kterého se data teprve vybírají a zpracovávají nebo dokonce se podle nich posílají další dotazy do databáze.

    Možná jen hledáš memcached. Občas také pomůže denormalizace databáze. Bez konkretizace účelu jenom hádám.
    6.8.2011 10:53 SPM | skóre: 28
    Rozbalit Rozbalit vše Re: Návrh na ušetření výkonu
    Co se týče samotné MySQL, tak je tam něco query cache size, tedy nějaká velikost cache, do které se schovávají výsledky... tím si samozřejmě neušetříš ten samotný dotaz a transfer dat mezi PHP a MySQL, nicméně pokud je to korektně nastaveno, tak to MySQL alespoň nehledá na disku...
    poky74 avatar 6.8.2011 22:23 poky74 | skóre: 36 | blog: Zápisník | Vrchlabí
    Rozbalit Rozbalit vše Re: Návrh na ušetření výkonu

    Pokud jsou neustále stejná, tak je kravina používat databázi, implementuj to do aplikace.

    Pokud bych to neměl brát tak doslovně, ta ty data načti do session a pracuj už jen s ním.

    Chcete Linuxové samolepky nebo Tuxe na klíče? ->
    6.8.2011 23:12 Kit
    Rozbalit Rozbalit vše Re: Návrh na ušetření výkonu
    Kravina to není. Data mají být oddělena od aplikace a mají být v samostatném souboru nebo v databázi.

    Pokud jsou ta data jen pro čtení, tak velmi zajímavým a rychlým řešením je funkce parse_ini_file(). Na mém Atomu dokáže načíst 120000 řádek souboru (8 MB ve formátu INI, což je běžný textový soubor) za sekundu do dvourozměrného asociativního pole. Dokonce umí i rozbalovat $proměnné v datové části, pokud je to potřeba.
    poky74 avatar 7.8.2011 14:53 poky74 | skóre: 36 | blog: Zápisník | Vrchlabí
    Rozbalit Rozbalit vše Re: Návrh na ušetření výkonu

    Jasně, takže pokud tu máme nějaký konstanty, s kterými musíme pracovat, tak spustíme nějaký databázový server, nejlíp nějaký pořádný moloch, třeba to mysql, do něj nejlíp špatně navrhneme tabulky, nebudeme používat indexy a vykašleme se na cache..

    Nebo ty konstanty nadefinujeme v aplikaci.

     

    Nevím proč, nevidím výhodu databáze...

    Chcete Linuxové samolepky nebo Tuxe na klíče? ->
    7.8.2011 15:05 Kit
    Rozbalit Rozbalit vše Re: Návrh na ušetření výkonu
    Na každý problém je vhodná jiná databáze. Bohužel se velmi často používá MySQL i tam, kde se vůbec nehodí, například na webové prezentace či redakční systémy. Ovšem existují běžně dostupné databáze (součást PHP), které jsou při správném použití rychlejší a úspornější na prostředky, než konstanty nastrkané přímo do PHP.
    poky74 avatar 7.8.2011 15:07 poky74 | skóre: 36 | blog: Zápisník | Vrchlabí
    Rozbalit Rozbalit vše Re: Návrh na ušetření výkonu

    Aj, tak to bude zřejmě mezera ve znalostech, o tom jsem neslyšel, link, info?

    Chcete Linuxové samolepky nebo Tuxe na klíče? ->
    7.8.2011 15:46 Kit
    Rozbalit Rozbalit vše Re: Návrh na ušetření výkonu
    DB4 na mém Atomu zvládá přes 70000 dotazů/s.

    SQLite na stejném stroji 12000 dotazů/s.

    MySQL jen 3000, tedy dvacetinu proti DB4 a čtvrtinu proti SQLite.

    Už jsem se zmínil, že parse_ini_file() na stejném stroji načte 120000 konstant/s (8 MB dat). Je to rychlejší, než parsování PHP.

    Když pak vidím redakční systém, ve kterém se při zobrazení každé stránky parsuje a ukládá do pole několik tisíc chybových hlášek, které se za běžného provozu vůbec nepoužijí a při chybě je potřebná jen jedna, chce se mi zvracet. Přitom by se krásně daly uložit třeba do CDB a v případě potřeby vytáhnout jen tu jednu položku.

    Podobně jsou na tom i některá diskusní fóra, která kvůli zobrazení každého příspěvku vytváří samostatný dotaz do MySQL. Sto příspěvků, sto dotazů. Hrůza.
    poky74 avatar 7.8.2011 15:48 poky74 | skóre: 36 | blog: Zápisník | Vrchlabí
    Rozbalit Rozbalit vše Re: Návrh na ušetření výkonu

    Dobře, beru zpátky, byla to mezera v mých znalostech, samozřejmě máš pravdu.

    Má úcta, díky.

    Chcete Linuxové samolepky nebo Tuxe na klíče? ->
    Josef Kufner avatar 7.8.2011 19:00 Josef Kufner | skóre: 67
    Rozbalit Rozbalit vše Re: Návrh na ušetření výkonu
    Jen tak mimochodem, co to bylo za dotazy?
    Hello world ! Segmentation fault (core dumped)
    7.8.2011 19:28 Kit
    Rozbalit Rozbalit vše Re: Návrh na ušetření výkonu
    Správná otázka. Byly to dotazy typu key->value, nejčastější typy dotazů v běžných internetových prezentacích. Uvědomuji si, že to silně upřednostňuje KVS před SQL. Pro e-shop je samozřejmě vhodnější SQL, ale v běžných prezentacích se vůbec nevyužívá jeho potenciál. Vždy, když vidím SELECT * FROM tabulka; tak si říkám, že je v aplikaci asi něco špatně.

    Proto tvrdím, že pro každou úlohu je potřeba použít vhodný typ databáze. Někdy je správné použití SQL, jindy zase primitivní úložiště KVS. Univerzální databáze neexistuje, každá má jiné přednosti a nedostatky.
    Josef Kufner avatar 7.8.2011 20:15 Josef Kufner | skóre: 67
    Rozbalit Rozbalit vše Re: Návrh na ušetření výkonu
    Ono ale i u jednoduchých webů spousta dotazů obsahuje několik joinů – u článků jméno autora a kategorie ve kterých článek je, v komentářích jména uživatelů, pak taky jsou docela časté různé stromové struktury (menu, hiearchie stránek, komentáře).

    Ftip je v tom, že jednoduché řešení psané na míru konkrétnímu webu je mnohem náročnější na tvorbu, než obecnější, pomalejší, ale zato již hotové řešení, na kterém běží i složitější weby. Proto se všude používá MySQL, i když by to kolikrát nebylo nezbytně nutné.

    A taky... co na tom, že to je 20× pomalejší, když i tak je to 50× rychlejší než je nutné.
    Hello world ! Segmentation fault (core dumped)
    7.8.2011 20:51 Kit
    Rozbalit Rozbalit vše Re: Návrh na ušetření výkonu
    Ve chvíli, kdy aplikace využívá schopnosti jazyka SQL, je jeho použití na místě. Pak už se rozhoduji mezi MySQL, PostgreSQL nebo SQLite podle dalších požadavků a možností. Konkrétně tam, kde se z databáze často čte, bývá SQLite velmi výhodné řešení. Nebo třeba i jen kvůli tomu, že má lepší podporu cizích klíčů než MySQL.

    S tou stromovou strukturou je to však trochu horší. Víme, že SQL se na stromová data moc nehodí. Pokud vím, že ze stromu při každém zobrazení budu potřebovat víc než 50% dat, raději ho uložím jako blob v serializovaném formátu do KVS. Typicky diskusní fórum.

    Reagoval jsem hlavně na připomínku, že konstantním datům je lépe v aplikaci než v databázi. Než přesouvat data kvůli výkonu z SQL DB do aplikace, je lepší je přesunout do KVS.
    7.8.2011 01:34 Sten
    Rozbalit Rozbalit vše Re: Návrh na ušetření výkonu
    Takže chcete implementovat cache? To není úplně triviální, ale je to celkem jednoduché. Stačí vygenerovaný HTML soubor někam uložit a při načítání zjistit, jestli už existuje, a pokud existuje, tak jej odeslat místo dotazování se databáze. Při změně dat v databázi pak stačí ten soubor smazat, takže při příštím zobrazení se znovu vygeneruje.
    MMMMMMMMM avatar 7.8.2011 08:50 MMMMMMMMM | skóre: 41 | blog: unstable | Valašsko :-)
    Rozbalit Rozbalit vše Re: Návrh na ušetření výkonu

    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.