From what I have seen in the source, the vaults will write each chunk to its own file on disk. (When the code exits it would clean up the disk though.)
MockVault however, writes to a single file. This makes IO performance absolutely dismal, and the testing utility for it when storing anything above a couple of thousand stored values, diminishes.
Would it be possible to redesign the MockVault implementation, to be closer to the actual implementation, so that chunks are written to individual files? It wouldn’t be very complicated or invasive it seems to me, and the change would be rather well contained, with few implications if any.
I know there is also in-memory storage, not sure how I would enable that through the C# libs though?
Furthermore, I would actually want a persistence mechanism that is as closely resembling the actual implementation as possible, to increase the value of the tests.
I could device it myself of course, but as I would be circumventing the entire safe_app lib by doing that, it seems to me it would be making the value of such testing dubious.
You have a couple of different options for enabling in-memory storage, see here. We run all of our tests internally with in-memory storage enabled because it is so much faster. Let me know if you have any questions.
We would like to make these configuration options more discoverable, since I assume you weren’t able to find that page easily, so if you have any ideas we’re all ears. Maybe adding a section about configuration below Features in the readme?
Sounds like a great idea to me. It makes sense to improve the performance of the default configuration, and at the same time to increase the accuracy with respect to simulating vaults. Do you mind writing an Issue so we can track this?
Edit: The advantage of the single MockVault file is that it can be easily shared between machines, but I’m thinking the individual files can all be stored in a folder which can easily be zipped up.
Ah, I did actually see the example config file in the repo, and I tried to add one to the output folder of the binaries (with no effect, but I see now that should be because I didn’t name the file correctly), and so then I figured it needed to be modified/included when compiling the rust source.
It’s true I hadn’t seen that page. There’s also been some post here on how to setup the config files, which I did get more or less right some time ago when doing a local network, but I must admit it has been a little bit confusing to me, which config file is used when, what entries are valid in which one of them (I think I haven’t been sure which information is up to date), and where it is placed. So, I guess in that regard a section there, as you suggest, would be helpful.
EDIT: I still didn’t get it right it seems. Have SAFE.DataStore.Tests.safe_core.config in the SAFE.DataStore.Tests\bin\Debug\netcoreapp2.2 folder (as I’m trying to debug the tests). I wonder if the problem is that the output file is a .dll instead of an .exe …?
The file naming should be in <executable name>.<library name>.config format.
You can get the executable name using Session.GetExeFileStemAsync() API. For .NET core it returns dotnet so the final name will be dotnet.safe_core.config.
Use Session.SetAdditionalSearchPathAsync(string path) API to add the path in configuration file search path list, where the path is the location for your config files.
agh, premature cheering.
I looked at the speed of which data was added, and though that I was now inmem, but what had happened was that the MockVault file (that was at 50Mb by then) had been overwritten when I did the above.
Hmm… to be continued
EDIT: Or maybe not exactly caused by the above, but it happened just then. For a moment I wondered if explicitly setting "mock_vault_path" : null would overwrite the file, but it didn’t. So not sure why the old file was overwritten
Yes, indeed unexpected. I have no idea what could have happened, if there was some kind of filesystem crash (since the file got so big) or what happened. One minute it was there, the next, after I did those changes above, I started debugging, saw that every add was at a few ms each and thought “Yay, in memory storage!”, then saw every add get slower and slower, and got suspicious, tabbed back to the folder and saw a new MockVault file…
Unfortunately have not got the loading of config file working yet. But I have not been home today, so I will get back to this. But I don’t know right now what I might change. First of all I think I will try with .NET Framework instead of dotnetcore, just to check if there might be something about that.
I don’t have any direct reason to believe so, but no indication of something else either. I’ve run maybe a couple of hundred times with MockVault, and have never seen that happen before. But it was the first time I had a file of 50Mb size (I had let it insert all night and day). As I have looked at the code I haven’t seen anything that could cause it. But I could try again and build a big file and see if I might trigger it to happen again.
Couldn’t get it working that way either The SAFE_MOCK_UNLIMITED_MUTATIONS was already there, but adding SAFE_MOCK_IN_MEMORY_STORAGE with value true made no difference. I wonder what that might be about.
About the config file, it seems that it doesn’t even load the file.
And the environment variable seems to have no effect. I have no idea what it’s about.
I’m on Win10. The variables are there, not sure how more to confirm them: doesn’t seem to be any trailing white space or anything like that.
A thought: Wouldn’t it be much easier if the API just took a config object (and naturally not require it, whereby default values used), and any users of the API can handle the config in anyway they need to.
Seems that there would be less strange things in the API, simplifying what it needs to do under the hood (looking for ExeFileStem, dealing with environment variables, setting search paths and trying to find the config etc.).
I think it is a little bit odd way to handle the config. Most API:s I use regularly just take some stuff as a ctor parameter, or use some fluent API with a builder (if they want to be fancy).
Can you please try one more thing: please print out the contents of the configPath file in the code you posted above:
to make sure that what your application sees it is actually the same as what’s on the filesystem.
And for the environment variables, I’m suspecting the variables are not accessible to the application for some reason (due to some quirk with Windows or .NET, I haven’t worked with these in a while but i remember that env vars are not commonly used for configuration in this ecosystem). Can you try printing out the values of the env vars from within your application? Reference
I agree. We use config files throughout the backend – Crust and Routing both use them, allowing changing settings without recompiling. But it’s certainly possible to also support passing a config object to the SAFE App API – app_unregistered already accepts a crust config object as an optional parameter, and we could extend this to the safe_core config.
I believe that doing so would make things cleaner and would allow us to deprecate the environment variables. I was part of the design and implementation of the env vars but I have to admit that they are technically lacking: any app can change them and thus change the behavior of other apps. We also run into possible issues with multithreading: one thread can write to a var while another reads it – there is no concurrency guard on env vars, which is they are known to be a bad solution in these cases. We actually ran into this problem while writing tests because cargo test runs each test in a separate thread, so using env vars to test for certain things was tricky and we (well, I) ended up putting some dirty hacks in place.
Of course, we only use the config for the mock network, so the security points are moot. But passing the config in through the API would just be better, easier, and allow us to remove the hacks we use for testing.