Shared memory between processes

[Ohad]

I have few processes of Node,
What is the best practice of sharing memory between those processes ?

[Vitali Lovich]

Why share memory as opposed to using a tcp socket?

On Aug 11, 2010, at 11:24 PM, Ohad wrote:

> I have few processes of Node,
> What is the best practice of sharing memory between those processes ?
>

> --
> You received this message because you are subscribed to the Google Groups "nodejs" group.
> To post to this group, send email to nod...@googlegroups.com.
> To unsubscribe from this group, send email to nodejs+un...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.
>

[Arnout Kazemier]

memcached?

On Aug 12, 2010, at 8:24 AM, Ohad wrote:

> I have few processes of Node,
> What is the best practice of sharing memory between those processes ?
>

[Olly]

Using a TCP socket is a lot slower in comparison. Consider all the
handshakes and protocol management that needs to take place. inter-
process communication (IPC) is by contrast, most efficiently done
using shared memory therefore.

And i too am interested to know how people are doing this, as i don't
have a clue how it can be done.

[Ben Noordhuis]

On Thu, Aug 12, 2010 at 10:57, Olly <oliver...@kohark.com> wrote:
> And i too am interested to know how people are doing this, as i don't
> have a clue how it can be done.

man 7 svipc

You'll have to write node.js bindings for it, though. And learn to
live with the fact that SysV shared memory segments are of a fixed
size. POSIX IPC is an alternative but it's not as widely supported as
SysV IPC.

[Blaine Cook]

On 12 August 2010 09:57, Olly <oliver...@kohark.com> wrote:
> Using a TCP socket is a lot slower in comparison. Consider all the
> handshakes and protocol management that needs to take place. inter-
> process communication (IPC) is by contrast, most efficiently done
> using shared memory therefore.

Shared memory is better until your system exceeds the capacity of the
machine, or any available machine. You then have two options: use
memcache, or another similar system, or spend lots and lots of money
on a ridiculous machine.

All of the top sites on the web use memcache or memcache-like tools.
They all rely on "slow" TCP connections across many machines. Unless
you're sure that your software will never need to scale beyond a
single machine, do yourself a favour and start with the scalable
option.

b.

[Rasmus Andersson]

On Thu, Aug 12, 2010 at 11:22, Ben Noordhuis <in...@bnoordhuis.nl> wrote:
> On Thu, Aug 12, 2010 at 10:57, Olly <oliver...@kohark.com> wrote:
>> And i too am interested to know how people are doing this, as i don't
>> have a clue how it can be done.
>
> man 7 svipc

Not available on OS X (for instance).

Ohad, may I ask what you are doing (in a greater sense)? If local tcp
sockets are too slow, you might be on the wrong foot to begin with
(using Nodejs). You should be aware that v8 and thus Nodejs is not at
all thread safe, which mean that the memory your processes would share
could never be touched by v8 or Nodejs, thus you would need to copy
any data back and fourth between the shared memory segment and each
process local memory, which in turn is almost as "slow" as talking
over local sockets.

>
> You'll have to write node.js bindings for it, though. And learn to
> live with the fact that SysV shared memory segments are of a fixed
> size. POSIX IPC is an alternative but it's not as widely supported as
> SysV IPC.
>

> --
> You received this message because you are subscribed to the Google Groups "nodejs" group.
> To post to this group, send email to nod...@googlegroups.com.
> To unsubscribe from this group, send email to nodejs+un...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.
>
>

--
Rasmus Andersson

[Ohad]

Thanks for all the answers guy,
I am trying to develop an application server(for now something like
tomcat),

I am adding features like Application and Session scopes.

In case one would like to use more than one CPU core (e.g. using 2
NodeJS processes ) I would like to enable him to share the
Application/Session scope between those two

On Aug 12, 4:18 pm, Rasmus Andersson <ras...@notion.se> wrote:
> On Thu, Aug 12, 2010 at 11:22, Ben Noordhuis <i...@bnoordhuis.nl> wrote:

[Olly]

Ohad,

The easiest way to do it is by using threads. Which allows you to run
code in parrallel without having to create seperate processes. This
will eventually be included natively into V8 with the introduction of
WebWorkers, but until then there are still alternatives:

http://github.com/pgriess/node-webworker

[r...@tinyclouds.org]

On Wed, Aug 11, 2010 at 11:24 PM, Ohad <mro...@gmail.com> wrote:
> I have few processes of Node,
> What is the best practice of sharing memory between those processes ?

By serializing it and using a UNIX socket.

[Marak Squires]

Depending on how much information we are talking about, you could offload your application state to a database and have each process separately communicate with the shared datasource. Obviously this is not ideal for every situation. 

-Marak

[Ohad]

so there are many options

1) memcached
2) "serializing it and using a UNIX socket"
3) DB
4) using node-webworker

Which one is the best for session management?
I rather save everything on the RAM (as much as possible), which makes
#3 problematic
regarding #2 I am not sure about the impl' , one Node holds the "data"
and the other Node talk to it?
regarding #4 I rather develop a solution that can work across
distributed network, so it seems like I need cross-process
memory, but maybe the best thing is to impl' both options in case one
had like to use only one server?
#3 seems like the best/easiest option, yet maybe not the most
efficient?


What do you think?

On Aug 12, 6:27 pm, Marak Squires <marak.squi...@gmail.com> wrote:
> Depending on how much information we are talking about, you could offload
> your application state to a database and have each
> process separately communicate with the shared datasource. Obviously this is
> not ideal for every situation.
>
> -Marak
>
>
>
> On Thu, Aug 12, 2010 at 11:09 AM, <r...@tinyclouds.org> wrote:
> > On Wed, Aug 11, 2010 at 11:24 PM, Ohad <mro...@gmail.com> wrote:
> > > I have few processes of Node,
> > > What is the best practice of sharing memory between those processes ?
>
> > By serializing it and using a UNIX socket.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "nodejs" group.
> > To post to this group, send email to nod...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > nodejs+un...@googlegroups.com<nodejs%2Bunsu...@googlegroups.com>
> > .

[Scott Trudeau]

Did I miss the part where you say why memcached isn't an ideal option? It solves your problem of "saving everything in RAM"  and is easily shared by multiple nodes. If you desire persistence, something like redis might be a good compromise of getting memcached "everything in memory" performance along with the persistence a traditional database would give you.

To unsubscribe from this group, send email to nodejs+un...@googlegroups.com.

[Marak Squires]

In regards to the third option, I would think using something like Redis for session data might be good.

As for efficiency, it really depends how are you intending to use it. Involving any additional I/O will of course decrease your performance, but if done correctly these performance hits should be minimal. 

On Thu, Aug 12, 2010 at 1:04 PM, Ohad <mro...@gmail.com> wrote:

To unsubscribe from this group, send email to nodejs+un...@googlegroups.com.

[Arnout Kazemier]

Same here, I don't see a reason to use persistent storage over something that is designed to be used in memory. 

Arnout Kazemier

in...@3rd-Eden.com

[Ohad]

Excellent, so it seems like I'll go for memcached,
Which NodeJs-Memcached impl' do you suggest? how about
http://github.com/jketterl/memcachejs?

A new question, how do you recommend implementing affinity session?
which mean that the same user will get redirected to the same Node
instance
(btw that will solve the problem above regarding session but not
regarding application scope which is still needed)

> > For more options, visit this group athttp://groups.google.com/group/nodejs?hl=en.

>
> > --
> > You received this message because you are subscribed to the Google Groups "nodejs" group.
> > To post to this group, send email to nod...@googlegroups.com.
> > To unsubscribe from this group, send email to nodejs+un...@googlegroups.com.
> > For more options, visit this group athttp://groups.google.com/group/nodejs?hl=en.
>

> Arnout Kazemier
> i...@3rd-Eden.com

[Ben Noordhuis]

On Thu, Aug 12, 2010 at 19:55, Ohad <mro...@gmail.com> wrote:
> A new question, how do you recommend implementing affinity session?

Don't. It hurts scalability.

[Ben Noordhuis]

On Thu, Aug 12, 2010 at 15:18, Rasmus Andersson <ras...@notion.se> wrote:
>> man 7 svipc
>
> Not available on OS X (for instance).

Sorry, missed this post.

Rasmus, I think you are wrong on this one. An Apache module I wrote
uses SysV IPC[1] and it runs just fine on OS X.

[1] This was before the advent of apr_shm.h

[Rasmus Andersson]

On Thu, Aug 12, 2010 at 21:50, Ben Noordhuis <in...@bnoordhuis.nl> wrote:
> On Thu, Aug 12, 2010 at 15:18, Rasmus Andersson <ras...@notion.se> wrote:
>>> man 7 svipc
>>
>> Not available on OS X (for instance).
>
> Sorry, missed this post.
>
> Rasmus, I think you are wrong on this one. An Apache module I wrote
> uses SysV IPC[1] and it runs just fine on OS X.

Ah. You might be correct. I just did some shallow digging (like
looking up dev manuals). I don't think sharing memory between node
processes is a very good idea in general though.

>
> [1] This was before the advent of apr_shm.h
>

[Ben Noordhuis]

On Thu, Aug 12, 2010 at 22:04, Rasmus Andersson <ras...@notion.se> wrote:
> looking up dev manuals). I don't think sharing memory between node
> processes is a very good idea in general though.

That's another matter and one we agree on. :-)

[Ohad]

> > looking up dev manuals). I don't think sharing memory between node
> > processes is a very good idea in general though.

Why not, what would you do?

[Chris Winberry]

Before settling on memcache/memcached try taking a look at Redis and see if its supported data types are a better fit for session data than plain strings.

On Aug 12, 2010 1:55 PM, "Ohad" <mro...@gmail.com> wrote:
Excellent, so it seems like I'll go for memcached,
Which NodeJs-Memcached impl' do you suggest? how about
http://github.com/jketterl/memcachejs?

A new question, how do you recommend implementing affinity session?
which mean that the same user will get redirected to the same Node
instance
(btw that will solve the problem above regarding session but not
regarding application scope which is still needed)

On Aug 12, 8:30 pm, Arnout Kazemier <i...@3rd-eden.com> wrote:

> Same here, I don't see a reason t...

> > On Thu, Aug 12, 2010 at 1:04 PM, Ohad <mro...@gmail.com> wrote:
> > so there are many options
>

...

> > For more options, visit this group athttp://groups.google.com/group/nodejs?hl=en.

>
> > --
> > You received this message because you are subscribed to the Google Groups "nodejs" grou...

> > For more options, visit this group athttp://groups.google.com/group/nodejs?hl=en.
>
> Arnout Kazemier
> i...@3rd-Eden.com

--
You received this message because you are subscribed to the Google Groups "nodejs" group.

To po...

[Ben Noordhuis]

> Why not

Because it's easy to introduce concurrency bugs, which are awesomely
hard to debug.

> what would you do?

Pick the easiest, most maintainable solution. Probably memcached.

If it's for storing sessions, you could (and probably should) apply
the provider pattern and start out with a simple implementation.

[Don Park]

I could see shared memory being useful with add-ons that pass large
media objects, like images, sounds, or video between processes.

[Vitali Lovich]

The problem is that the quirks & corner cases of shared memory (not to
mention concurrency) mean that it's probably better to implement that
code in C++ & provide node bindings - that's the way I would do it.

On Fri, Aug 27, 2010 at 2:13 PM, Don Park <supe...@gmail.com> wrote:
> I could see shared memory being useful with add-ons that pass large
> media objects, like images, sounds, or video between processes.
>

[Shimon Doodkin]

how about shm?

/dev/shm , memory file based Shared Memory

[Don Park]

Given that the need for shared memory is also likely an add-on
implementation issue, I agree.

BTW, what's the current common practice in portable shared memory? Use
Boost, something else, or just DIY?

[Kevin Swiber]

On Apr 16, 2013, at 6:57 AM, Simon Majou <si...@majou.org> wrote:

Resurrecting this topic ... 

I think there is a real use case for node for shared memory. Because TCP connections are great but will always be slower than direct access to memory.

To avoid any concurrency issue shared memory should be writable only by one process. When using the cluster module, the shared memory should be writable only by the master for example. If you want to write from a worker, just send a message, and the master will do it.

On Thursday, August 12, 2010 8:24:30 AM UTC+2, Ohad wrote:

I have few processes of Node,
What is the best practice of sharing memory between those processes ? 

I'd love to see cross-platform memory mapping in libuv with a JavaScript API in Node… but mostly because I'm hesitant to offer cross-platform native modules at this time.  I still have issues getting the right ducks in a row to do a Windows compilation, so I feel bad asking others to do the same.

Right now, the best memory mapping module I've seen is MappedBuffer[1] (See this PR[2] for v0.10 support).  It delegates async operations to a thread using uv_queue_work (something the node-mmap module does not do).

The module only works on POSIX systems, unfortunately.  It would be great to have cross-platform support, but I'm not sure how easy it is to create a common API over both POSIX and Windows-based systems.

I've been working on an all-JavaScript key-value store named Medea[3].  My initial experiment with memory mapping immutable files for the key-value store was very promising[4].  I'm still hacking on Medea, but the end goal is to use it as Web cache storage for an HTTP reverse proxy (which I am also still hacking on).  This effort won't come close to touching something like Varnish without legit memory mapping, I'm afraid (not that it has to, but it would be pretty cool).

I'm down for spending some cycles on a native module, but I'd likely need some assistance as I have a ton of conflicting priorities at the moment.  :)

[1] https://github.com/kazupon/node-mappedbuffer

[2] https://github.com/kazupon/node-mappedbuffer/pull/1

[3] https://github.com/argo/medea

[4] https://github.com/argo/medea/issues/10

Cheers,

-- 

Kevin Swiber

@kevinswiber

https://github.com/kevinswiber

[Simon Majou]

Thanks for the info ! Medea & medea-clusterify are very interesting.

[Floby]

A fun and efficient way to implement shared memory with minimum consideration for concurrent access would be for it to follow the stream.Duplex API. Like an 'in-memory' stream. That's pretty much how things like Go channels and ØMQ work, and it scales !

[Simon Majou]

Nice ! The locking system can be done directly in JS with messages.

Another solution (which require a little more work) would be to implement the bakery's algorythm. 

For pub/sub, you would need to add for each object a boolean for each process, saying if the process subscribes the object.

On Tuesday, April 23, 2013 11:15:17 AM UTC+2, Jan Supuka wrote:

I wrote a C/C++ binding of shared memory access from nodejs. https://github.com/supipd/node-shm

Still work in progress (but working for me), maybe usefull, if bug or suggestion, inform me.

Exactly like a Simon wrote, already are here real cases for using shared memory from node.js.

And potential concurrency issues (solvable) aren't reason to not use shared memory.

Maybe bigger problem is "eventable" shared memory, something like "inform me, when someting is changed".

In case of one process as central-shared-memory-manager can be there some form of sending very small ((-:

TCP packet "Hey You, signed ChangeOfValue subscriptor, somebody changed Your area of interest in SharedMemoryControlledByMe",

as source of change event, on which COV client read shared memory to accept changes. 

Instead of TCP sending potentially large amount of bytes, this event system simple MUST be (and is) faster.

[Floby]

ØMQ has a shared memory transport. I would use it.

[Deniz Özger]

Can you use ZMQ for shared memory without using IPC or TCP? If not, and the shared memory size is big, that might cause problems.

Looking at https://github.com/JustinTulloss/zeromq.node for Node implementation.

[Alex Kocharin]

 

If shared memory is big, it might be worth it to move it to separate database leaving node.js instances stateless.

 

So, no, you can't. But I don't believe it can cause any real problems, since sharing memory is a bad idea anyway (just look at Java...).

 

 

27.01.2014, 16:18, "Deniz Özger" <deniz...@gmail.com>:

--
--
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines

You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com

To unsubscribe from this group, send email to
nodejs+un...@googlegroups.com

For more options, visit this group at

http://groups.google.com/group/nodejs?hl=en?hl=en
 
---

You received this message because you are subscribed to the Google Groups "nodejs" group.

To unsubscribe from this group and stop receiving emails from it, send an email to nodejs+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.