Home > Archive > PERL Beginners > February 2007 > Sharing Threds or in memory database
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Sharing Threds or in memory database
|
|
| Armin ranjbar 2007-02-21, 7:58 am |
| Hi all ;)
im working on high performance dns server using perl , its nearly completed but i had some very urgent and bad looking problem ,
well , im using single hash value to store all queries , for example
$mhash{"kernel.org"}{"MX"} returns cached MX query of kernel.org , the problem is , the data is not cache-able across threads ( threads are making query ).
here is some solution and why i think they are not very usable , please correct me
1 > using IPC::Shareable
very limited , i ran out of space for locks .
2 > using threads::shared
looks like its unable to share second and third level of my %mhash .
3 > in memory databases using DB_file
just like threads::shared its unable to handle second and third level of my mhash .
ideal solution would be some kind of "Unlimiteed Ipc::Shareable" module , any idea please ?
--
You possess a mind not merely twisted, but actually sprained.
| |
| Jeff Pang 2007-02-21, 7:58 am |
|
>
>im working on high performance dns server using perl , its nearly complete=
d but i had some very urgent and bad looking problem ,=20
>well , im using single hash value to store all queries , for example=20
>
>$mhash{"kernel.org"}{"MX"} returns cached MX query of kernel.org , the pro=
blem is , the data is not cache-able across threads ( threads are making qu=
ery ).
>
>here is some solution and why i think they are not very usable , please co=
rrect me=20
>
>1 > using IPC::Shareable=20
>very limited , i ran out of space for locks .
>
>2 > using threads::shared=20
>looks like its unable to share second and third level of my %mhash .=20
>
>3 > in memory databases using DB_file=20
>just like threads::shared its unable to handle second and third level of m=
y mhash .
>
Hello,
You could use memcached to store and share the datas.memcached is better th=
an memory share,though it also use memory to store datas.You may take a loo=
k at:
http://www.danga.com/memcached/
For the DB_File,yes,it can't be used directly to store the hash more than o=
ne level.But for the multi-level hash,you can use MLDBM to store it.I've us=
ed MLDBM for long time,it's stable and ease to use.
Hope this useful.
--
=E7=A5=9D=E6=89=80=E6=9C=89=E4=B8=AD=E5=
8D=8EPerl=E7=94=A8=E6=88=B7=E6=96=
=B0=E6=98=A5=E5=BF=AB=E4=B9=90!
Happy New Year for all Chinese Perl guys!
| |
| Jenda Krynicky 2007-02-21, 6:59 pm |
| From: Armin ranjbar <zoup@zoup.org>
> im working on high performance dns server using perl , its nearly
> completed but i had some very urgent and bad looking problem , well ,
> im using single hash value to store all queries , for example
>
> $mhash{"kernel.org"}{"MX"} returns cached MX query of kernel.org , the
> problem is , the data is not cache-able across threads ( threads are
> making query ).
>
> here is some solution and why i think they are not very usable ,
> please correct me
>
> 1 > using IPC::Shareable
> very limited , i ran out of space for locks .
>
> 2 > using threads::shared
> looks like its unable to share second and third level of my %mhash .
>
> 3 > in memory databases using DB_file
> just like threads::shared its unable to handle second and third level
> of my mhash .
What you could do is to have one thread act as the "bookkeeper", own
and update the hash and all the other threads would ask it. Maybe
using pipes or something.
So the work threads would not access the hash, but instead send a
message to the bookkeeper who'd respond with the data or a message
that the data are not cached. The worker thread would then either
respond to the requestor or do the lookup, respond and send a message
to the bookkeeper to store the mapping.
Do I make sense?
Jenda
===== Jenda@Krynicky.cz === http://Jenda.Krynicky.cz =====
When it comes to wine, women and song, wizards are allowed
to get drunk and croon as much as they like.
-- Terry Pratchett in Sourcery
| |
| Zentara 2007-02-21, 6:59 pm |
| On Wed, 21 Feb 2007 14:19:21 +0330, zoup@zoup.org (Armin ranjbar) wrote:
>here is some solution and why i think they are not very usable , please correct me
>2 > using threads::shared
>looks like its unable to share second and third level of my %mhash .
When you declare a hash as shared, it automatically shares only
it's first level keys. If you want more depth, you need to explicitly
share the deeper levels.
I usually just explicitly list them, but see BrowserUk's improved syntax
in:
http://perlmonks.org?node_id=526204
zentara
--
I'm not really a human, but I play one on earth.
http://zentara.net/japh.html
| |
| Dr.Ruud 2007-02-22, 4:00 am |
| Armin ranjbar schreef:
> im working on high performance dns server using perl , its nearly
> completed but i had some very urgent and bad looking problem ,
> well , im using single hash value to store all queries , for example
>
> $mhash{"kernel.org"}{"MX"} returns cached MX query of kernel.org ,
> the problem is , the data is not cache-able across threads ( threads
> are making query ).
>
> here is some solution and why i think they are not very usable ,
> please correct me
>
> 1 > using IPC::Shareable
> very limited , i ran out of space for locks .
>
> 2 > using threads::shared
> looks like its unable to share second and third level of my %mhash .
>
> 3 > in memory databases using DB_file
> just like threads::shared its unable to handle second and third level
> of my mhash .
>
> ideal solution would be some kind of "Unlimiteed Ipc::Shareable"
> module , any idea please ?
Or use DBD:SQLite?
--
Affijn, Ruud
"Gewoon is een tijger."
|
|
|
|
|