[PHP] gegevens uitwisseling tussen scripts met shmop

[Consequator]

Ik probeer iets op te zetten zodat ik makkelijk (zonder database) een array met data kan uitwisselen tussen verschillende lopende scripts.
Na wat speurwerk kwam ik uit bij de 'shmop' functies van php, als experiment heb ik hiervoor de onderstaande functie gemaakt.
Het probleem waar ik echter tegenaan loop is dat de oude data niet wordt verwijderd.
Zoals hier onder al te zien is heb ik al een aantal dingen lopen proberen, waaronder even wachten na het verwijderen en om in elk block een spatie te schrijven, maar om voor mij nog onduidelijke redenen blijft hij oude data bewaren dat in dit geheugen blok staat.
Iemand enig idee wat ik fout doe, of een andere suggestie om data uit te wisselen tussen verschillende scripts ?

code:

function DoShmop() {
       global $shmid;
       shmop_delete($shmid);
       shmop_close($shmid);
       usleep(500);
       $shmid = shmop_open(100,"n",0644,102400);
       $erase = 0;
       $count = 0;
       while($erase !== FALSE) {
               $erase = @shmop_write($shmid," ",$count);
               $count++;
       }
       $size = shmop_write($shmid,serialize($GLOBALS),0);
}

om het weer uit te lezen:

code:

<?php
        $shmid = shmop_open(100,"a",0666,20480);
        print_r(unserialize(shmop_read($shmid,0,shmop_size($shmid))));
        shmop_close($shmid);
?>

Het resultaat:

code:

Array
(
    [GLOBALS] => Array
        (
            [GLOBALS] => Array
                (
                    [GLOBALS] => 
etc etc...
}

[Cartman!]

Waarom wil je perse geen database gebruiken? Het gebruik van shared memory komt over als een houtje-touwtje oplossing en is alles behalve betrouwbaar.

[smesjz]

A helpful hint, although when using shmop on windows (yes you can use shmop on windows in IIS or Apache when used as isapi/module) you can delete a segment and later open a new segment with the SAME KEY in the same script no problem, YOU CANNOT IN LINUX/UNIX - the segment will still exist - it's not immediately deleted - but will be marked for deletion and you'll get errors when trying to create the new one - just a reminder.

Commentaar uit 2004 op php.net. Welke waarde heeft $shmid op het moment dat je DoShmop() aanroept? Ook 100?

In dat geval is het commentaar hierboven van toepassing zo te zien.

[naam]

Kan je niet de data serializen en dan naar een bestand wegschrijven?

[Janoz]

marabunta2048 schreef op woensdag 07 april 2010 @ 12:32:
Kan je niet de data serializen en dan naar een bestand wegschrijven?

Daarmee worden de raceproblemen alleen maar groter.

[Verwijderd]

Is SQlite geen oplossing?

[Consequator]

Omdat ik hem vrij vaak wil updaten had ik gehoopt hem in RAM te houden zodat hij niet constant in de mysql database loopt te schrijven, scheelt weer disk io. En aangezien het toch vluchtige data is.

De $shmid is alleen de identifier, die staat eigenlijk altijd op 0.

Met naar een bestand schrijven krijg je alleen het probleem dat hij nog net aan het schrijven is terwijl je probeert te lezen.

Ik krijg geen fouten met het opnieuw aanmaken van een segment, ik zou steeds een andere key kunnen pakken maar dan zit ik weer met 'hoe krijg ik die key bekend in het andere script zonder ergens iets op disk te schrijven.'

[HuHu]

Is het niet verstandiger dit soort optimalisaties gewoon aan MySQL zelf over te laten? Zo'n database is er voor gemaakt om veel dingen te lezen/schrijven.

[Icekiller2k6]

Ik snap hem wel, ik heb zelf een 3GB grote db in het geheugen zitten, ik gebruik wel MSSQL..

Dus puur in het geheugen gooien gaat hoor incombinatie met mssql/mysql..
ook al is het vluchtig, je wilt voor welke reden dan ook kunnen opslaan en dan later verder gaan, of als je later satellieten gaat toevoegen dit kunnen doorgeven

[Consequator]

Volgens mij gaat het inderdaad anders ook niet werken...
MySQL heeft wel een 'heap' table maar die kan geen text opslaan, tenminste, niet genoeg.

Dan toch maar een extra tabel er bij.

[HuHu]

Kun je trouwens niet iets als APC gebruiken om alles in het geheugen te bewaren?

[kwaakvaak_v2]

Consequator schreef op woensdag 07 april 2010 @ 13:13:
Omdat ik hem vrij vaak wil updaten had ik gehoopt hem in RAM te houden zodat hij niet constant in de mysql database loopt te schrijven, scheelt weer disk io. En aangezien het toch vluchtige data is.

Zelfs daar heeft mysql aan gedacht voor jou de MEMORY storage engine doet precies wat je verwacht, het schrijft data in het gegeugen. Maar dan wel shared

Ik heb het een hele poos gebruikt/getest op een middel groot forum voor de sessie tabel, en werkt prima. Data blijft in het geheugen zolang mysqld loopt, stop je de server is de data weg. En ja, mysql kan verschillende storage engines per table gebruiken in 1 database.

[Consequator]

kwaakvaak_v2 schreef op donderdag 08 april 2010 @ 09:13:
[...]


Zelfs daar heeft mysql aan gedacht voor jou de MEMORY storage engine doet precies wat je verwacht, het schrijft data in het gegeugen. Maar dan wel shared

Ik heb het een hele poos gebruikt/getest op een middel groot forum voor de sessie tabel, en werkt prima. Data blijft in het geheugen zolang mysqld loopt, stop je de server is de data weg. En ja, mysql kan verschillende storage engines per table gebruiken in 1 database.

Die kwam ik ook tegen, maar daar stond dat hij dan geen TEXT en BLOB velden ondersteund.
Stiekem toch wel dan ? Of had je er alleen maar integers in ?

[Icekiller2k6]

Consequator schreef op donderdag 08 april 2010 @ 14:50:
[...]


Die kwam ik ook tegen, maar daar stond dat hij dan geen TEXT en BLOB velden ondersteund.
Stiekem toch wel dan ? Of had je er alleen maar integers in ?

als ik kwaak juist begrijp, maakt het niet uit.. 'tis het geheugen wat "wordt opgeslagen" en deze terug kunt zetten en zo weer aanspreken

[Cartman!]

HuHu schreef op donderdag 08 april 2010 @ 08:41:
Kun je trouwens niet iets als APC gebruiken om alles in het geheugen te bewaren?

Inderdaad, daar is t redelijk voor bedoeld. Of Memcached, komt ongeveer op t zelfde neer maar dan wat schaalbaarder.

[Janoz]

Hmm, ik ben wel erg benieuwd welke data je eigenlijk op wilt gaan slaan wanneer je het liefst TEXT en/of BLOB in memory wilt houden.

[kwaakvaak_v2]

Consequator schreef op donderdag 08 april 2010 @ 14:50:
[...]


Die kwam ik ook tegen, maar daar stond dat hij dan geen TEXT en BLOB velden ondersteund.
Stiekem toch wel dan ? Of had je er alleen maar integers in ?

Varchar (255) zijn voor mij groot zat, meeste zijn toch int met referenties naar andere tabellen