Starší komentáře ke článku: Práce se sdílenou pamětí v PHP - rozbor možností
Zpět na článek | Úvodní stránka Interval.cz
Datum vložení: 18.1.2005 14:01:31
Myslim ze po precteni tohoto clanku nikdo tuto technologii nepouzije protoze neni popsano pro co se hodi. Tahle to vypada, ze autor suse prepsal manual, kterej kazdy jiste pouziva :-)
Tyto prostredky je vhodne pouzit jeste jako nadstavbu session pro promenne ktere jsou sdileny v ramci jednoho webu. Napr. pokud z DB generujeme menu, muzem si ho sem ulozit, pak ho muzem generovat jen jednou pri jeho zmene a ne pro kazdyho pri prvnim pristupu.
Veta "... zajistit komunikaci například mezi skriptem PHP a aplikací vytvořenou v C#..." je usmevna, kdyz vezmeme v potaz ze technologie sdilene pameti funguje jen v Linuxu, coz autor jaksi zapomel sdelit :-)
Michal
Datum vložení: 18.1.2005 14:51:51
Za prvé, článek je úvodem seriálu, tedy se věnuje "suchému" popisu pricipů a metod. Nebo byste čekal, že autor rovnou začne s nějakou komplikovanou implementací, kterou nikdo nepochopí, a teprve následně bude vysvětlovat základy?
A za druhé, doporučoval bych Vám článek nejprve přečíst, než začnete kritizovat, protože sdílenou paměť lze se správnou skupinou funkcí použít i na Windows. Nemluvě už o tom, že C# není jazyk na Windows závislý...
Datum vložení: 19.1.2005 11:37:16
Chjo,
no ja si predstavuju ze na zacatku serialu se napise pripadova studie, k cemu je to dobry a k cemu ne. Kdyz na zacatku vybafnes pouziti dle manualu tak to lidi odradi :-)
jj jde to pouzit ve windows, ale jen za urcitych pripadu a jiste to neni uplne standardni reseni, protoze se o to musi starat primo PHP modul a neni to reseno Win systemem :-) Jj nemas co rict kdyz se tu tahas o slovo (C#). Clovek by rekl ze tu budou clanky co ti neco daj, ale resit diskuzni forum pres sdilenou pamet je prasarna.
Jinak treba zajimava vec je, ze kdyz by ten hypoteticky chat mel bezet na vice serverech je ti sdilena pamet k prdu pac se vaze na jeden system, takze to opet musis prerubat na spolupraci pres DB, ci soubory. Mozna by bylo lepsi psat clanek o ObjectCache ktera lze vyuzit i z PHP a i z vice stroju naraz ;-)
Datum vložení: 19.1.2005 15:21:33
Vycházet při vysvětlování principů libovolné funkce z případové studie samozřejmě lze. Tento postup se však hodí spíše do monografií, které pojednávají dané téma uceleně. V případě seriálů v magazínech (papírových i elektronických) se tato metoda neosvědčila - většina čtenářů prostě nerada čte o něčem, čemu nerozumí a o čem si nemůže doplnit informace "přeskočením" několika kapitol.
Co se týče ObjectCache, máte volné pole působnosti, stačí napsat e-mail do redakce. Iniciativě a dobrovolnosti meze neklademe (viz <a href='http://interval.cz/__redirect/redirect.asp?what=interval_discussion&url=http://interval.cz/clanek.asp?article=3738' target='_blank'>http://interval.cz/clanek.asp?article=3738</a> ;-)
Datum vložení: 19.1.2005 8:35:34
no nevim nevim, me by to moc pomohlo, neb presne tohle hledam. Ukladat informace v PHP do "promene", ktera je pristupna na kazdem skriptu, na kazdem pozadavku, aniz bych ji musel porad plnit. Jenze ja hledam reseni pro windows.
Co se tyce C#, tak si o nem napred neco zjistete. C# je nezavisly na OS. Konkretne jsem ho videl na Linuxu a na freeBSD taky jde.
Datum vložení: 19.1.2005 8:49:19
Funkce SHMOP jsou dostupne i na systemech WIndows, hned v prvnim odstavci je to ajsne uvedeno. Bohuzel vsak tyto fce umoznuji pracovat pouze s promennou typu string. Pokud by jste potreboval toto omezeni obejit, je mozne pouzit fci serialize(), ktera prevede jakoukoliv promennou vcetne typu array do stringu.
Datum vložení: 6.2.2006 17:59:54
Funkce SHMOP mi na systémech Windows XP nefunguje. Tak mě neštvěte.
Datum vložení: 19.1.2005 15:40:38
> Tyto prostredky je vhodne pouzit jeste jako nadstavbu session pro
> promenne ktere jsou sdileny v ramci jednoho webu. Napr. pokud z DB
> generujeme menu, muzem si ho sem ulozit, pak ho muzem
> generovat jen jednou pri jeho zmene a ne pro kazdyho pri prvnim
> pristupu.
no, to tak to je naprosto maximalni vyuzitelnost tohoto nastroje, to je atomovka na vrabce jak vysita, imho to autor vystihl zcela presne, kdy velmi zajimave a podstatne (skoro bych rekl primarni) je uplatneni pro komunikaci s jinymi aplikacemi, ktere mohou byt napsane v jinem (vysim jazyce). Pouzit to pro "menu" jak vy rikate povazuji za vicemene kontraproduktivni a nevidim jediny duvod, proc ho nenacachovat do souboru, ale jak pisete do pameti. Skoro bych se dozadoval alespon jednoho rozumneho duvodu - a prosim nic lacineho jakoze include souboru je pomalejsi nez natazeni z pameti, v pripade "menu" to totiz rozhodne nebude relevantni zalezitost.
Datum vložení: 5.1.2007 15:17:15
toto reseni je naprosto idealni tam, kde cache soubor je prilis veliky, rekneme 2Mb, pritom jeho vytazeni z DB neni trivialni a je proto dobre to NEKAM kesovat, a neni potreba, aby to bezelo v ramci uzivatelske session, ale staci, kdyz to bezi v ramci aplikace celeho webserveru, tak jako to byvalo u ASP - Application promenne a Session promenne. Prave resim takovyto problem a bez SHM by se to asi ani vyresit nedalo. Nacitani dat z DB zabira nekolik vterin, cache soubor je 2,5Mb velky a proto jeho pouziti je skoro stejne dlouhe jako select do databaze, pritom pomoci SHM se podarilo celou stranku dostat na 0.45 vteriny a predpokladam, ze na zaklade pouziti informaci z toho clanku, zejmena o IPC, ktere NEVYZADUJE serializaci, ktera v mem pripade zabira celych 0.32 vteriny, tedy velkou cast behu stranky, ale umoznuje prime vkladani pole do pameti, se to jeste vyrazne zkrati. Dekuji timto i s odstupem casu autorovi za clanek a zdravim vsechny ustove brzdare, kteri tady toho sice hodne nakecaji, ale o realite nemaji ani tuseni !
Datum vložení: 18.1.2005 14:06:37
k cemu se to da vyuzit v praxi?
Datum vložení: 18.1.2005 14:25:01
myslim, ze jedno pouzitie sa nacrta uz v samotnej podstate shared memory a to napr: moznost komunikovat medzi dvomi scriptami. jeden v cykle caka na stav "true" v shared memmory a druhy ho setuje.
Datum vložení: 18.1.2005 14:58:19
Myslim, ze tohle lze v praxi stezi pouzit a stezi to prinese vyhody. Predevsim se pamet musi nacist a bez nejakeho preruseni to je skoro na nic. Podle me se vetsinou komunikace resi na urovni databaze, implementacne je to take nejsnadnejsi vzit MySQL a dat modul do Perlu, Pythonu, PHP, C++ a vsichni muzou komunikovat. Rychle a snadno. MySQL se da take zkopirovat s podporou Temporary tables, takze se vse ulozi do RAM a vyjde to takrka na stejno.
Krom toho, ze vyuziti databaze prinasi neskutecne mnozstvi vyhod. Pri pouziti PostgreSQL lze navic pouzivat i triggery
Datum vložení: 18.1.2005 15:26:58
Ano, temporary tables jsou take moznost, nicmene nejak jste opomenul, ze prave tyto tabulky vyuzivaji fci shared memory (i kdyz s vlastni obsluhou). Ve zde uvedenem clanku pristupujete k pameti primo, kdezto i mysql apd dochazi k ruznym zdrzeni typu overeni uzivatele, vytvoreni samotneho spojeni, nemluve pak o tom, jaké odezvy ma pak taková databáze při využití dané aplikaci několika stovkami, tisíci uživateli. Zde by jste zřejmě dospěl k velice nepříjemným zjištěním.
A take druha vec. O uzitecnosti a vyhodach teto technologie rovnez hovori, ze se pouziva v podbne forme na vysokozatezovych aplikaci typu xchat.cz. Sice pravdou je, ze xchat bezi jako modul apache, ovsem na zpusobu ukladani dat se nic nemeni.
Datum vložení: 19.1.2005 9:00:55
Podle mě kdo programuje zátěžovou aplikaci v PHP je skoro blázen. Podle mých měření výkonu je PHP asi 10x pomalejší než Perl/Python a na zátěž snad není nic horšího. Konkrétně hodně specifické části se zpravidla programují v něčem jiném než v PHP a to zrovna chat je. I když přiznávám, xchat je starý, takže věřím že tam obcházeli možnosti PHP jak to jen šlo.
Datum vložení: 19.1.2005 9:08:01
Bohuzel jste encetl muj prispevek pozorne.
Predne jsem nepsal nic o vysokozatezovych aplikaci ala PHP, ale o vyuziti ukladani dat do Shared Memory vs Mysql - TemporaryTable, kde jsem chtel pouzkazat nato, ze primy pristup k pameti je rychlejsi nezli k MySQL. (i kdyz na ukor komfortu). Toto tvrzeni jsem potvrzoval tim, jak to maji udelane na vysokozatezovych apliakci typu xchat.cz.
Xchat.cz neni tvoreno v PHP. Jeho jadrem je Ckovsky modul "modchat", ktery zajistuje evskere stezejni funkce. V PHP jsou tvoreny pouze diskuzni fora a dalsi doplnkove "futury", nikoliv chat samotny. Ovsem to uz sem nepatri.
Datum vložení: 20.1.2005 13:28:08
to je taky dobra fama :-)
protoze pres temporary table se nemuzou dorozumivat dve aplikace ze :-) takze pak vam staci pro tu jednu klidne neco uplne jinyho.
Temporary table je drzena v pameti jen do uzavreni spojeni a navic je dostupna jen z tohoto spojeni!
Myslim si ze uplne nejlepsi reseni nez nejaky temporary table ci sdilenou pamet je lepsi pouzivat sdileny soubor, protoze se to chova stejne jako sdilena pamet. navic kdyz k nemu bude casty pristup - coz by mel, jinak vlastne bude takovyhle sdileni dat jen aby se nereklo :-) - tak si ho bude system drzet v pameti sam - pristup bude vicemene stejne rychly.
Datum vložení: 20.1.2005 13:37:53
Výměna dat mezi různými aplikacemi prostřednictvím sdíleného souboru je absolutní nesmysl, protože nedokážete ošetřit kolizní situace, kdy jedna aplikace bude zapisovat data a druhá bude "rozepsaný" soubor číst. Musel byste pro takovou věc použít specializovaný souborový server...
Datum vložení: 20.1.2005 20:15:48
Podle mě by to šlo řešit na úrovni souborů, ale byla by to Sisifofská práce založená na zamykání, uzavírání a otevírání souborů. Což je zbytečně přehnané, takže souhlasím s Vámi - sdílena pamět se jeví jako ideální.
Datum vložení: 21.1.2005 14:09:53
a nechova se sdilena pamet jako soubor? nastavuje se opravneni, mod pristupu, tak v cem je to jiny????
Michal
Datum vložení: 21.1.2005 14:16:57
V clanku je to ale napsane. Konkretne druha sada fci SystemuV pouziva tzv semafor, ktery v pripade, ze je s udaji v pameti pod danym ID pracovano, znemozni ostatnim praci, dokud predesla neskonci. A prave tohoto pomoci beznych souboru standardne nedosahnete.
Datum vložení: 21.1.2005 15:54:16
A system V semafory nelze použít pro řízení přístupu k souboru? Nemám s tím zkušenosti, ale zdá se mi že se dají použít k řízení přístupu k čemukoliv - nebo ne?
Datum vložení: 21.1.2005 23:23:23
samozrejme ze se da. navic v PHP jsou i jine semafory. Proste sdilena pamet nema zadne vyhody oproti sdilenemu souboru.
Datum vložení: 22.1.2005 0:15:27
Stále je zde zásadní rychlost. Je to asi skoro stejne, jako kdyz by jste rekl, ze swapovaci soubor/oddil a pamet jsou vykonostne na tom stejne. Uz z principu je to nesmysl.
Datum vložení: 23.1.2005 19:32:28
Takze podle vas jsou dnesni operacni systemy tak blby, ze kdyz se k souboru pristupuje nekolikrat do minuty tak si ho neda cely do operacni pameti? To si asi nemyslite ze :-)
Datum vložení: 23.1.2005 20:15:24
Hospodaření se soubory je i v moderních operačních systémech velice neefektivní a problematické. Proto se například souborová cache používá jen tam, kde se soubory čtou mnohokrát, ale generují se pouze jednou za delší čas. Jakmile se pokusíte použít soubor jako sdílenou paměť mezi dvěma či více programy (což může být třeba jen opakovaně volaný PHP skript), narazíte na množství problémů s řízením přístupu, čtením a ukládáním z operační paměti na disk. Možná že vám taková aplikace bude njaký čas fungovat na málo vytížených stránkách, ale třeba na Intervalu už je něco takového naprosto nepoužitelné...
Datum vložení: 24.1.2005 10:30:11
myslim ze vse co jste ted napsal plati i pro sdilenou pamet
Datum vložení: 24.1.2005 12:41:46
To bohuzel myslite spatne. Veskere mozne operace trvaji pri praci se sdilenou pameti priblizne stejne. U souboru velice zalezi na tom, jake operace provadite. Ano, pokud byste potreboval data akorat cist, pak je to jedno, ovsem pri rezimu cteni/zapis soubor sdilenou pmaet proste nemuze plne nahradit.
Datum vložení: 24.1.2005 20:51:15
a co kdyz mame dva servery v clusteru, tak nam je sdilena pamet naprd, ale pres soubor to pujde :-)
Datum vložení: 24.1.2005 22:04:24
Když máme dva servery v klastru, vůči aplikaci se hovají jako server jeden, takže je to jedno ;-)
Datum vložení: 8.6.2006 17:22:50
Poslyšte, a co mmap() na sdílený soubor? Je vám známo, že protějškem SysV SHM v BSD je právě mmap() call? Jestli on fakt, že je to zhruba stejně rychlé, nebude mít něco společného s vyrovnávacími paměťmi... Swapovací oddíl je fyzická oblast disku. Naproti tomu, když OS manipuluje se souborem, většinu toho času manipuluje s vyrovnávací pamětí a po jejím zaplnění přesouvá bloky na disk pomocí blokových operací. Nějak nechápu tu analogii.
Datum vložení: 1.2.2006 13:26:04
Měl bych dotaz, jake jine semafory mate namysly? Potřebuju to právě pro přístup do souboru. Já sem našel akorát Tyhle pro sdílenou pamět.... pak mě ještě napadlo použít jen shmod (má přepínač, který v případě existence ID hazy chybu- jako by zamceno) : zamykani shmop_open ,odemykani shmop_delete . Myslíte že by to bylo korektní řešení? Tedy spíš, je shmop_open atomicka? Nebo tedy jake jine semafory jsou v php?
Datum vložení: 8.6.2006 17:13:58
Zajímavé je, že přesně takhle funguje MS Access, databázový server Firebird v Classic provedení...zámky, zámky, zámky... ;-)
Datum vložení: 24.1.2005 13:05:10
zavisi takrka vyhradne na schpnostech programatora/analytika. Napriklad ulozeni rozsahle struktury do shm je mozne, AFAIK, jen v serializovanem tvaru - nasledna deserializace ma take svou rezii. Ocividne se to da "out of box" pouzit pouze tak, ze pres output buffering zachytite cely, slozite generovany, vystup skryptu do promenne a tu pak ulozite do shm a pri pristich totoznych pozadavcich pouze odeslete na vystup tuto promennou.
Inteligentnejsi vyuziti tohoto prostredku musi predchazet poradna analyza a hlavne sladeni s celym systemem.
Ja sam pouzivam 2 urovnoveho cacheovani(priserne slovo!) - casto generovana data menim v PHP kod ulozeny do souboru, ktery je nasledne zaclenovan do skriptu(include), na serveru mame nainstalovanu turck mmcache(vyuziva shm) - ta se postara o kompilaci do mezikodu a vysledek je az do zneplatneni udrzovan ve sdilene pameti. Tento pristup, mimochodem, vyzaduje uplne oddeleni formy od obsahu - dosazeno je to pouzitim sablon. A jeste k nasemu webu - poskytujeme tematicky zamereny obsah(magazin, novinky), mame v prumeru 150 - 200 tis. stazenych stran denne na dual PIII 1GHz s PHP a mysql. Vytizeni db je dlouhodobe 350 query/sec.
Datum vložení: 1.2.2006 13:40:03
Potřebuju zapisovat do souboru z vice skriptu proto potřebuju nejaky semafor(vim že je lepší databáze ale teď bych potřeboval vyřešit toto) Měl bych dotazy: 1) Existují v PHP i jine semafory? 2) Šlo by boužít jako semafor shmop? U shmop_open je přepínač "n" a příkaz skončí chybou jestliže už dane ID existuje. zamykani shmop_open (v připade chyby je zamčeno a čeka se) odemykani shmop_delete. Je to korektni řešení? nebo spíš : Jsou instrukce shmop atomicke?
Datum vložení: 11.9.2007 0:21:51
Zamyslam sa nad vyuzitim shm v php pre zrychlenie autorizacie prihlasenych uzivatelov. terz to riesim databazou. Potrebujem vsak s kazdym requestom urobit nejake zapisy do db a tu vznikne problem s uzkym hrdlom i/o disk a locking(myisam). Uvazujem udrziavat v shm jedno velke multidimenzionalne pole $users_online['uid'] = array('remoteIP', 'last_access_TS', .. a pod). Kazdy request by nacital toto pole a cez uid by zapisal potrebne data bez nutnosti iteracie celeho objektu. Vlastne by to fungovalo podobne ako session, ale bolo by to jednoduchsie pre pristup serverovym skriptom, ktore budu manipulovat s tym velkym polom na zaklade aktualnych hodnot. Mate s tym niekto skusenosti ? Alebo to nie je moc dobry napad ?