[erlang-questions] messages manipulatio

[sasa]

Thanks! I'll take a look.


On Sat, Feb 16, 2013 at 7:14 AM, Mahesh Paolini-Subramanya
<mahesh@REDACTED>wrote:

> Its pretty much a classic Active Queue Management <http://en.wikipedia.org/wiki/Active_queue_management>issue,
> i.e., its not the quantity of the traffic, but the "burst-y" nature of the
> traffic that can confound you.
>
> There has been any amount of work done on this in the Networking field
> (just google any combination of RED, CoDel, AQM, and Van Jacobsen), but its
> only recently that some of the lessons have started making their way into
> the software/"cloud" field. (I gave a preso' about this at TechMesh last
> year<http://www.slideshare.net/dieswaytoofast/can-your-service-survive-a-cold-start-sadly-probably-not>
> …)
>
> For an erlang-baed implementation, take a look at Jesper Anderson's *
> safety* <https://github.com/jlouis/safetyvalve>valve<https://github.com/jlouis/safetyvalve>.
> It may not be distributed, but its certainly rigorously tested…
>
> Cheers
> *
> Mahesh Paolini-Subramanya<http://www.gravatar.com/avatar/204a87f81a0d9764c1f3364f53e8facf.png>
> *
> That Tall Bald Indian Guy...
> Google+ <https://plus.google.com/u/0/108074935470209044442/posts>  | Blog<http://dieswaytoofast.blogspot.com/>
>    | Twitter <https://twitter.com/dieswaytoofast>  | LinkedIn<http://www.linkedin.com/in/dieswaytoofast>
>
> On Feb 15, 2013, at 9:17 PM, sasa <sasa555@REDACTED> wrote:
>
> Hello,
>
> A while ago I encountered the following situation:
>
> I had the gen_server base process P which would receive messages, and
> handle them by sending some data over the network. The messages were coming
> faster than they were being sent. I established the reason for this was the
> "randomness" of my network conditions. I also established that sending more
> messages at once was almost as fast as sending one message, i.e. the
> network push time wasn't highly dependent on the message size.
>
> To tackle this in a generic way, I devised an approach which has served me
> well in multiple places. I was repeatedly googling whether some similar
> solution exists, but I couldn't find it. Now, I'm not sure if I have
> reinvented a wheel, or the approach is not optimal, so I'm asking if you
> are aware of similar approaches, and are there any faults in this one?
>
> The approach I took is following:
>
> I split the server in two processes: the "facade" and the worker. The
> facade acceptes requests from clients, and stores them internally. While
> the worker is doing its work, new messages are stored in the facade. When
> the worker is available, it will take all accumulated messages from the
> facade and process them.
>
> These are the steps:
> 1. The facade receives messages, stores data in its list, and notifies the
> worker (without sending actual data), that some work is ready.
> 2. Upon receiving the notification, the worker first flushes its message
> queue by doing repeated receive ... after 0 as long as there are messages
> in the queue.
> 3. Then the worker pulls all messages from the facade. This is a
> gen_server:call to the facade which will return all messages, and at the
> same time remove them from its state.
> 4. Finally, the worker processes all messages.
>
>
> I found this approach useful because the delay on the worker adapts to the
> incoming message rate.
> If the worker can handle messages at the incoming rate, everything works
> without delay.
> If messages can't be handled at the incoming rate, the worker's delay will
> increase to accomodate the higher load. In other words, the worker will try
> to compensate the load by bulk processing messages. Obviously, this is
> useful only when process_time(N messages) < N * process_time(1 message).
>
> Another benefit I found is that I can vary the implementation of the
> facade i.e. I can store messages using different algorithms. In the first
> implementation, I stored messages in a list. In one variation, I used hash
> which allowed me to eliminate duplicate messages. Another variant was
> truncation of the list, which allowed me to discard old messages if the
> queue was getting too large.
>
> As I said, this has served me well in the production for more than a year,
> and I have finally found the time to make a generic library out of it.
> Before putting it public, I'd like to check if there are similar solutions,
> or alternative approaches?
>
> Thanks, and best regards,
> Sasa
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20130216/f04281f6/attachment.htm>