Performance
Threading
Archipelago is built on Akka which provides a number of mechanisms all designed to promote multithreaded non-blocking concurrency. From the diagrams above it should be clear that the amount of processing power available is a factor of the number of threads allocated and the proportion of time spent in the running state. Time spent blocked is potential lost, the greater the time spent blocked, the greater the loss of potential. There are obviously limits to the CPU core allocation associated with process allocation and the total number of cores available, but these limits can be approached by non-blocking multithreaded techniques.
Akka actors are lightweight in terms of their basic memory requirement and very large populations, (even at an entity level), do not impose large overheads in terms of memory allocation and certainly not in terms of inactive CPU consumption when inactive. The message passing mechanisms actors require to communicate is significantly slower than direct method invocation, however this characteristic is substantially reversed by the effects of concurrency and aggregated messaging.
Where long running computations or blocking operations are unavoidable, dedicated threads are allocated, allowing the actor's message delivery and processing threads to run in the optimal short activation, non blocking way.
Akka actors are lightweight in terms of their basic memory requirement and very large populations, (even at an entity level), do not impose large overheads in terms of memory allocation and certainly not in terms of inactive CPU consumption when inactive. The message passing mechanisms actors require to communicate is significantly slower than direct method invocation, however this characteristic is substantially reversed by the effects of concurrency and aggregated messaging.
Where long running computations or blocking operations are unavoidable, dedicated threads are allocated, allowing the actor's message delivery and processing threads to run in the optimal short activation, non blocking way.
Memory
We constantly consider the usage of memory in systems we create both at the design level and actively at runtime. The representation of data, both in terms of their types, the choices of containers and the treatment of non-essential data strongly influence memory consumption. We also are keen to exploit some of the recent optimizations making their way into Spark, such as off heap memory usage and alternate String representations.
The JVM, and in particular, garbage collection strategies are typically significant factors in memory consumption and system performance, we profile, benchmark and tune as a matter of course. Whether our recommendations are applied to systems we contribute to is a matter for discussion.
The JVM, and in particular, garbage collection strategies are typically significant factors in memory consumption and system performance, we profile, benchmark and tune as a matter of course. Whether our recommendations are applied to systems we contribute to is a matter for discussion.
Our choices of paradigms, namely: event driven, streaming, massively concurrent systems focus our minds on 'In-flight' memory volumes, back-pressure and throttling strategies and we dedicate a lot of time to tuning and auto-tuning behaviours to optimize and fairly allocate memory resources.
I/O Performance
What gets sent over the wire and why, how it's represented, how close is the representation to the in-memory entities we work with, how efficient is the serialization, what are the characteristics of the network, what physical choices were made for the network and it's fibre, impedance with endpoint systems, contention, resilience, security, stability, protocols and routing, I/O is a headache, we take it seriously and always try to make good choices. We are helped by those choices when we have a say, which isn't a luxury we take for granted.
Some things we like: NIO, Netty, TCP/IP, UDP, Infiniband, ExaData, Datomic, Cassandra, MongoDB, 10 Gb links, Scala Pickling, locality, cohesive designs, essential travel.