1) Where does it cache data? In memory on server side or client side? If I am using such code
var session = getCachedSession();
session.BeginRead();
var data = GetData();
session.Commit();
return data;
then next GetData() always opens objects from server disk (even with CacheEnum.Yes).
If the code just like that:
var session = getCachedSession(); //long read transaction
return GetData();
then GetData() immediately gets data from client memory. I don't want to store data in client's memory. How can I cache data only in the memory of the server till first update of related pages? What about caching of system databases (schema, locations etc)?
2) What is proper usage of ServerClientSession in multiple threads (in one process)? I see, the class itself is not thread-safe, and creation of an instance is expensive. Is there any way to make its singleton instance thread-safe (without lock(session) )? In the moment I am manually maintaining a pool of several initialized ServerClientSession using ConcurrentStack; each thread pops (creates if needed) and pushes back own instance with separate transaction block (BeginRead/Update - Commit block). Maybe is there better approach that we could use?
We have the issues with slow usage of ServerClientSession in local network. Version of VelocityDb is 3.13.1. Toggled TcpClient.NoDelay does not help.
First of all, let me to show some benchmarks made by Database Benchmark 2.0.3 . I've just added benchmark for ClientServerSession leading to localhost (same PC with client) and second one leading to remote host (in same network as client).
Write speed
Read speed
Secondary read speed
As you can see, result of ServerClientSession connecting to remote host is very slow. Do you have any benchmark results for ServerClientSession?
There is the source code of an example, the usage of session and classes in it are similar to my models in web application. The program also runs very slow on the network (especially for read of 10 objects on wire). There are the profiler results. You can see that the huge bottleneck occurs in network code (like Socket.Receive). Elapsed time in hundreds milliseconds is not so acceptable.
What can you suggest? Or maybe is there some bottleneck in requests loop in VelocityDbServer or something like that?