<div dir="ltr">On Wed, May 24, 2017 at 3:02 PM Oliver Korpilla <<a href="mailto:Oliver.Korpilla@gmx.de">Oliver.Korpilla@gmx.de</a>> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br>
* Are there mechanisms internal to BEAM impacting this? Or is it purely a property of the CPU architecture?<br></blockquote><div><br></div><div>If you experience latencies in the millisecond range, I don't think you are looking at a CPU caching problem. A DRAM hit is 300ns or 0.3us. So you'd need about 3000 of those to hit 1ms run time. The napkin math doesn't really pan out too well.<br><br></div><div>Do you run the ERTS in embedded mode[0]? I'd look at code loading. Or perhaps ASN.1 loading initially if it compiles stuff the first time around.<br><br></div><div>As for the two DB writes to the same row in short order: Mnesia uses an optimistic locking strategy. If two transactions write to the same row at the same time, both will aborted, wait a bit and try again. If you're unlucky, those two writes will keep interfering with each other and you will get lag. A good way around this is a design which serializes such writes. Or perhaps you can make the write dirty (this can actually be safe in some situations, depending on your setup).<br></div><div><br>[0] <a href="http://erlang.org/doc/system_principles/system_principles.html#code_loading">http://erlang.org/doc/system_principles/system_principles.html#code_loading</a><br></div></div></div>