<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><span style="font-family:Arial,Helvetica,sans-serif">On Thu, Apr 8, 2021 at 9:51 PM <a href="mailto:valentin@micic.co.za">valentin@micic.co.za</a> <<a href="mailto:valentin@pixie.co.za">valentin@pixie.co.za</a>> wrote:</span><br></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div><br></div><div>Presuming that by micro-batching” you mean more than one message being delivered at the same time, I don’t think that would be the only way to accomplish rates of 100k messages per second.</div><div>In fact, in one of our project we have accomplished rates of above 200k UDP messages per second per Erlang node (using Erlang’s gen_udp module).</div><div><br></div></div></blockquote><div><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">It just means that you avoid processing messages one-by-one, but set up a short interval (5ms say) and process in batches in that short interval. In practice, this will "feel" instant in the system, but amortizes some back-n-forth overhead over multiple messages, reducing it. In a certain sense, the kernel buffer on an UDP connection is already doing micro batching when it delivers messages up to the VM. The actual amount of messages you can process is somewhat dependent on the hardware configuration as well, and probably also kernel tuning at these rates.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div><br></div><div>I am not sure what <span style="font-family:"Courier New"">process_flag( message_queue_data, off_heap )</span> actually does. I mean, I do understand that a particular process queue is allocated from some "private space", but not sure how such memory is managed.</div><div><br></div><div>It would be great if anyone can shed some light on this.</div><div><br></div></div></blockquote><div><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">In normal operation, the message queue is part of the process heap[0]. So when it's time to do a GC run, all of the messages on the heap are also scanned. This takes time proportional to the size of the message queue, especially if the message queue is large and the rest of the heap is small. But note that a message arriving in the queue can't point to other data in the heap. This leads to the idea of storing the messages off-heap, in their own private space. This then improves GC times because we don't have to traverse data in the queue anymore, and it's safe because the lifetime analysis is that messages in the queue can't keep heap data alive.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">On the flip side though, is that when you have messages off_heap, sending messages to the process is slightly slower. This has to do with the optimizations and locking pertaining to message passing. The normal way is that you allocate temporary space for the messages from the sending process and then hook these small allocations into the message queue of the receiving process. They are "temporary" private off-heap spaces, which doesn't require locking for a long time, and doesn't require a lock on the memory area of the receiving process heap at all. Messages are then "internalized" to the process and the next garbage collection will move the messages into the main heap, so we can free up all the smaller memory spaces. With off-heap, we need to manage the off-heap area, and this requires some extra locking, which can potentially conflict more, slowing down message delivery.</div></div><div><br></div>-- <br><div dir="ltr" class="gmail_signature">J.</div></div>