Will Lagom be able to handle few thousands PersistentEntities?

[Joo Lee]

Hello all,

I am wondering how well Lagom would operate when holding few thousands PersistentEntities in memory.

In our business domain, we are likely to create few hundreds to few thousands PersistentEntity instances with their own states being managed by commands and events.

If I am right, they are all being stored and managed within the memory while the service is running. Am I right? 

Have we done any performance load testing on Lagom? I am actually only concerned about how many persistent entities Lagom can handle simultaneously.

Thanks,

Joo

[Lutz Hühnken]

> If I am right, they are all being stored and managed within the memory while the service is running. Am I right? 

Generally, yes. In more detail

a) It is clustered. Lagom uses Akka Cluster Sharding underneath, so the entities will be distributed over the nodes that form the cluster. It can surely deal with way more than a few thousand entities.

b) Entities are not necessarily kept in memory all the time. Snippet from the configuration:

  # A persistent entity is passivated automatically if it does not receive 

  # any messages during this timeout. Passivation is performed to reduce

  # memory consumption. Objects referenced by the entity can be garbage

  # collected after passivation. Next message will activate the entity

  # again, which will recover its state from persistent storage.  

  passivate-after-idle-timeout = 120s

> Have we done any performance load testing on Lagom? I am actually only concerned about how many persistent entities Lagom can handle simultaneously.

I don't have one to share, but I'd like to point out that if you designed a test to show how many entities a Lagom cluster can handle, you can go up to millions, just make the entities small and only send them tiny messages every once in a while. That won't tell you anything about your actual application, though. Actual resource consumption will depend on entity memory usage as well of number and size of messages, and on everything else you do in your application. And you have to scale Cassandra along with the Lagom cluster. I'm afraid you'll have to do load testing on your actual application. But again, a few thousands, that really shouldn't be a problem. I'm tempted to say you can run that on a single node, but for resilience, that wouldn't be great advice.

[Joo Lee]

Thanks Luts!

[James Roper]

Hi Joo,

Everything Lutz said is right, holding a few thousand persistent entities in memory should be no problem - the main caveat is that your entities aren't ridiculously large.  You can estimate the size of your entities by serializing them to JSON and seeing how many bytes that is - that's only a very rough approximation, but it's the right ballpark.  So, let's say each entity is 2kb of JSON, then a few thousand entities is going to be less than 10mb to hold all the entities, plus each entity has a small amount of memory overhead for the actor that runs it, but it's less than 1kb.  So, from a memory perspective, you will have no problems.

To answer your question on performance testing, we have done some rudimentary performance testing, and plan to create some automated nightly load tests to do more.  What we've done so far is ensure that Lagom doesn't have any gaping performance issues, and this includes persistent entities.  But we haven't done a lot of performance tuning yet, this will happen over time.

Regards,

James

--
You received this message because you are subscribed to the Google Groups "Lagom Framework Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lagom-framework+unsubscribe@googlegroups.com.
To post to this group, send email to lagom-framework@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lagom-framework/28b7e16b-a5ef-4570-bc28-69bb11585f36%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

James Roper
Software Engineer

Lightbend – Build reactive apps!
Twitter: @jroper