This project is read-only.


State saving performance


The process state saving is the most frequent operation on the directory. It makes the most of the directory's load therefore moving the function out of the directory is crucial to enhance scalability. With a lot of processors with tens of thousands simultaneously running processes the state saving will become a bottleneck.

The key thing is that not all of the states should be saved in the directory. The directory is to share the data between the Flower components, but most of the states are never shared. Moreover, in most of the cases only the last (current) state of a process is important.

The idea is to save the states not to the directory directly, but to a special state service. The service will hold the states persistently and propagate to the directory only those states which potentially may need to be shared - the key states.

The following states should be considered the key states:
  • The initial state (because the client will save it to the directory to make it available for a processor).
  • The final state (because it allows administrators to check the result of a process).
  • The error states i. e. the states right before an exception (because administrators may need to analyse the state to diagnose the error).
  • The last state before a processor shutdown (because the shutdown may mean server decommission, so the processes will need to be moved to another processor).
Another important thing is to allow state services to be deployed on the same hosts as the processors i.e. on commodity hardware. Therefore, the following should be taken into account:
  • No additional software like proprietary database engine should be required.
  • The disk of a host should be considered unreliable i.e. reliability should be achieved through replication.
Closed Nov 3, 2013 at 11:28 AM by dbratus


dbratus wrote Aug 13, 2013 at 3:20 PM

Resolved with state services.