Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upGitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
[WIP] [DRAFT] Microsoft Faster Integration Sample #5618
Conversation
|
I will leave others to comment on the Orleans side of the integration for now, but from the point of view of how FASTER is being used, I think this is a good starting point. As background, the basic FASTER model is based on a set of threads, each of which can start a session with FASTER, perform a sequence of operations, and later stop the session. Operations consist of bursts of activity, with periodic invocations of a Refresh() call to FASTER in between. It would not be okay for a thread/session to go to sleep (i.e., stop calling Refresh) without stopping its session. This pattern matches well with the fixed-threads version of your samples. However, this does raise questions on resource sharing with Orleans grains threads. For scale out, I assume the idea is to have a FASTER grain for each (coarse-grained) hash bucket range of the hash space. Then, Orleans may schedule these "state" grains across the cluster as it wishes. Key requests would then need to be routed by Orleans to the appropriate grains in order to be served. The ad-hoc session example you have created is interesting as well because it interacts better with the async/await thread pool model, but I am unsure of the performance effect of short lived sessions. Perhaps this will not be a problem if the bottlenecks are elsewhere. Related, but not blocking this PR, I am starting an effort to discuss native async/await support in FASTER, at microsoft/FASTER#130. FASTER supports a periodic checkpointing/commit mechanism, that would be interesting to parameterize and expose. In other words, users may ask us to persist every e.g., 1 or 10 seconds, and this would correspond to a Checkpoint operation (across all threads) every 1 or 10 seconds, giving users (incremental) state persistence until that point. Read more about the incremental commit mechanism used in FASTER here. Finally, would it make sense to consider the storage provider notion of Orleans, i.e., create a FASTER storage provider, in addition to these grain-level approaches? It's not clear if this makes sense, based on the documentation. For example, with the storage provider model, who would be responsible for moving keys to the new silo when a grain migrates? |
Deprecated FasterDedicatedGrain.
|
@JorgeCandeias Are you still working on this? |
|
@sergeybykov It's still on my list, just swamped to my eyeballs at the moment. I see @badrishc has been busy committing to microsoft/FASTER#130 but I haven't had a chance to review those changes. |
|
@JorgeCandeias Sounds good. We'll keep open then. Thanks. |
|
@JorgeCandeias @ReubenBond We now have full async support in FASTER KV, merged to master (microsoft/FASTER#130). The need for periodically calling Refresh has also been eliminated. Would love to hear your comments on using the same. |
|
Many thanks for this @badrishc and apologies for the late reply. We're going to field test this work of art and I'll come back to this issue to update the sample. |
|
@JorgeCandeias Were you able to get back to this? |
|
@sergeybykov We ended up not using Faster at the time, in favour of a more applicable approach for the client's use case. Faster has its merits regardless in Orleans. Let me come back to this on the weekend. |
|
FASTER has evolved a lot since this first effort. At this point, it behaves exactly like any other standard C# library with respect to threading, making the integration sample much simpler than what we had to do in here. For example, Refresh is no longer needed. Also full async support has been added as well. We think an Orleans sample at this point will be much easier and behave naturally as well. We support both local SSD and Azure Storage as data backends. Look forward to hearing what u think! Get it from the new Nuget feed at https://www.nuget.org/packages/Microsoft.FASTER.Core/ or sources from https://github.com/Microsoft/FASTER. |
…o feature/microsoft-faster-sample
|
@badrishc I've now gone through the Faster repository. Indeed it has come a long way, in fact this old sample format can no longer do it justice. I'll do one from scratch to highlight the different scenarios, and will likely bin the current code in the process. @sergeybykov please leave this PR open for a while longer. |
…re/microsoft-faster-sample
This new sample demonstrates rudimentary integration with Microsoft Faster within the context of a grain, for the purpose of automatic partitioning of massive lookups. The idea is to use Orleans grains to provide state sharding across a cluster, while using Faster to provide the disk spilling lookup.
This sample is a work-in-progress. Integration is proving challenging due to the conflicting designs between Orleans' and Faster's thread concurrency models, which work well on their own but will compete for resources when brought together.
The sample contains two approaches at the moment:
I'm yet to try a shared GrainService or to take the Faster logic out of the silo altogether as that defeats the objective of automatic partitioning.
I've asked @badrishc from the Faster project to help review this and see if there are opportunities for improving things.