*How to pre-load your products and their caches:* Initially you could iterate through your products and send a dummy message to all, say a Boolean.TRUE, a dummy and very small message which will allow you to send up to 1m/sec
That way each product will be started before the first query, each product can load its cache, because you have a number of threads operating products don't worry, you won't have more than X loading its cache. *Off JVM? why?* You have sharding which already takes care of redistributing if something goes wrong, you also hava Akka distributed data if you really have a need of distributed sets and maps. HTH, Guido. On Tuesday, December 13, 2016 at 6:31:33 PM UTC, Chris Berry wrote: > > Justin, > > Once again, thank you so very much for your input. > It is much appreciated. > > Now we need to do our homework and build out a strawman > > Thanks again, > -- Chris > > On Tuesday, December 13, 2016 at 7:38:51 AM UTC-6, Justin du coeur wrote: >> >> On Mon, Dec 12, 2016 at 11:57 PM, Chris Berry <chris...@gmail.com> wrote: >> >>> Having an Actor per Product, distributed evenly onto the Shards, makes >>> the most sense to me as well. It is simple and straightforward. >>> Particularly since each Product could cache it's current Rates. >>> In this model, each Actor is caching it's particular Rates info, as >>> opposed to a shared, concurrent HashMap. Correct? >>> >> >> Correct. >> >> >>> Would you create all of these Actors at start-up? (I would assume so) >>> >> >> Not necessarily, but again this gets into latency. In *most* >> applications, I would actually say not -- one of the nice features of >> Cluster Sharding is that it creates Entities on-demand, so you can usually >> leave Actor creation until it is required. In your case, though, that >> might be iffy: it means that the first hit on Product Y is likely to be a >> bit slower, as it loads itself. >> >> >>> Would this make for a really slow start-up? >>> >> >> Could be. It's a trade-off: you either pay all the start-up cost >> upfront, or you pay it in a small latency hit on each Product's first >> access. Do note, though, that creating any given Actor is a pretty fast >> process in and of itself: the cost is usually mostly the I/O. >> >> >>> Would it make sense to use Akka persistence so that restarts are >>> (assumedly) much faster? >>> >> >> I'm quite fond of Akka Persistence, and I find it a very elegant and >> robust architecture, but I honestly don't know the relative performance >> characteristics -- I'd recommend doing some experiments. (Keep in mind >> that I'm just an experienced user, not one of the Akka team, and my >> experience is colored by my own product's needs. I'm mainly operating >> human-scale, so my latency needs aren't so tight.) I suspect that the >> performance depends largely on the underlying DB and having that properly >> tuned, since Akka Persistence is largely an abstraction on top of a >> database -- most often Cassandra, but there are a number of options. >> >> I *suspect* that Akka Persistence does a bit less well with booting >> everything at startup. It's a relatively fine-grained architecture, with >> each Actor's data stream relatively independent AFAIK, so if you tried to >> load millions of those at once I suspect you'd hit bottlenecks. If you >> wanted to load everything at once, I might gravitate towards a more >> conventional RDBMS that could do a single batch load, and then booted the >> sharded Products from that data. (OTOH, that's going to be more work to >> maintain -- again, trade-offs.) >> >> >>> Or are there other more efficient ways to backup the system? >>> >> >> Keep in mind that efficiency and latency are pretty disconnected here. >> Akka Persistence is generally quite *efficient*, and it suits the >> distributed-data architecture extremely well. The only concern I see is >> latency of first hit; you may want to do some experiments and see how it >> does relative to your requirements. (It might well be fine; I'm just >> trying to err on the side of caution, since you emphasized latency as a >> priority.) >> >> >>> If the actual cache was to move off the JVM -- into, say, memcached -- >>> how would you model something like that in this scenario? >>> Would you simply create a child CacheActor that indirectly handles that >>> interaction. >>> >> >> Maybe? That seems like it introduces a little bit of extra latency for >> those interactions, though, and it isn't clear whether it's worth >> subdividing the Product Actor for it. I'd probably do it iff the code >> seemed to warrant it. >> >> Honestly, though, I tend to think of Akka *as* a giant memory cache that >> happens to have the logic embedded in it. My own product is specifically >> designed that way: it's essentially a database where the Actors serve as a >> write-through cache in front of Akka Persistence. I can see some possible >> arguments for using something like memcached in order to reduce GC and the >> like, but I'd recommend trying the more conventional architecture first, >> and treating that as an optimization if needed. >> >> >> To summarize that: the cleanest and easiest architecture is probably >> using relatively conventional Sharding, booting each Product as needed and >> using Akka Persistence to persist its state. I'd probably recommend trying >> some experiments with that, and seeing how it does against your latency >> requirements -- if it suffices, it's likely to result in relatively >> easy-to-maintain code, since it's swimming entirely with the tide of >> conventional Akka and seems to match your *conceptual* requirements quite >> well. If not, then it's time to examine the requirements and trade-offs, >> and how best to get the characteristics you need... >> > -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the FAQ: >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups "Akka User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
