1

While researching the possibilities that the second level cache in nhibernate provides I tested some implementations. Currently the outcome is quite unexpected and I'am questioning if my expectations are wrong.

  1. Scenario (Read-Heavy)

At first 4 * 20000 simple objects with one string property are inserted into the database then four threads are getting them by the object-id (session.Get<SimpleObj>(id)). Each thread only accesses the ids it did create. The access-pattern is random and gets 1000 objects and then recreates the session.

while (true)
{
    using (var session = sf.OpenSession())
    using (var tx = session.BeginTransaction())
    {
        for (int i3 = 0; i3 < 1000; i3++)
        {
            long id = (long)ids[rnd.Next(19999)];
            var t = session.Get<SimpleObject>(id);

            var no = t.StringProperty;
        }

        Interlocked.Add(ref ops, 1000);

        tx.Commit();
    }
}

Results

  1. Redis 5000 reads per second
  2. MemCached 8000 reads per second (EnyimMemcached)
  3. No Caching 15000 reads per second (Same machine, TCP-IP)
  4. No Caching 25000 reads per second (Same machine, shared memory)
  5. SysCache2 200000 reads per second
  6. HashtableCacheProvider 380000 reads per second

Versions used

Is the different performance between those providers and the SysCache2 implementation to be expected?

Update 1

As Frederic pointed out the testing scenario does not make too much sense as two different classes of caching architectures with two different uses cases are compared. The first class (5 & 6) can not be scaled horizontally while 1 and 2 can. Currently the SQL-Server is running on the same machine so shared-memory as an IPC-Mechanism is used, therefore i disabled all IPC Connection possibilities an configured it to use TCP/IP to connect to the database. As result the performance of the no-cache-scenario drops about 10000 op/s which brings the fastest distributed caching provider into a reasonable distance.

With the comparison of the caching providers I want to test if these providers can be used in a session-per-request setup to cache reference data like countries, currencies or balance-sheet structures. As the performance of the best performing distributed cache is still only half the op/s of the plain NHibernate version I am not sure if this is the way to go.

hessenmob82
  • 175
  • 12
  • I have updated my answer to address your update. Note that this is not the preferred way on Stack Overflow. Usually, you should ask a new question, pointing this one for reference. – Frédéric Apr 04 '16 at 09:14

2 Answers2

1

This is no surprise to have SysCache(2) (or RtMemoryCache if you try this other one too) to perform highly better than Redis or MemCached. The formers are in-process memory caches, their use does not incur any network IO nor any inter-process communication. The laters are distributed caches, they implies at-least inter-process communications and in most cases network IO, which incurs quite higher use cost.

There is not really any point comparing distributed caches performances to non-distributed caches performances. You should use distributed caches only if you need sharing your cache among many processes. You would not be able to use non-distributed caches if you have that requirement.

What is surprising is to have the "no cache" scenario (so, SQL queries) to perform highly better than distributed caches.

One key point is missing in your test description in my opinion: what drives the performance cost of SQL queries in your scenario? If the db server is hosted on the same physical host than the web server, this cost is fairly low compared to what it is in more usual setups. Some db solution like SQL server may even skip any network IO and go for inter-process in memory communications (through named pipes) when they are hosted on the same host than the web server.

Side note: if you do not consider configuring SysCache2 for getting invalidated through SQL Server data change notifications, you should test SysCache instead, which is lighter. (This will probably not really change results in your test scenario though.)

Addressing Update 1:

The very first point is to be sure you actually need your cache to be distributed. Each process can safely have its own cache if:

  1. The cached data is read-only (or eventually, if having some processes serving stale cached data does not cause trouble in your application case).
  2. This does not cause to much memory consumption. (Cached data is not heavy, duplicating it among many processes would not be an issue.)

Of course, data cache warm-up will be slower with non distributed caches, but if distributed cache performs too poorly, this is not a point.

If you need it to be distributed, you should then evaluate if your SQL Server is a bottleneck under load or not. If under load, your SQL Server can be a bottleneck to your application, then distributed cache will help offloading it. Otherwise, better not use them if, in your setup, distributed caches are consistently performing worse than your db server.

Side note: If only the condition (2.) is met, you may also give a try to non-distributed cache with invalidation from SQL Server notification, allowing you to avoid stale data. See here for how to configure SysCache2 for being notified by SQL Server.

Community
  • 1
  • 1
Frédéric
  • 9,364
  • 3
  • 62
  • 112
1

Frederic already wrote that you tested two completely different types of cached, so I am not going to repeat that again. But I will add some info on how NH caches work and answer Frederic's comment:

What is surprising is to have the "no cache" scenario (so, SQL queries) to perform highly better than distributed caches.

Actually, there is no surprise :) You need to remember that:

  1. NHibernate tries to play safe with caches and emulates "transactions" on each cached entity. Depending on its implementation a distributed (NHibernate) cache can send two additional requests to the cache server (lock and release entity) that results into serious performance drop
  2. different caches use different serializers. For example, Redis cache uses built-in .NET XML serializer that is not famous of its speed ;)
  3. depending on configured expiration policy you may also have additional performance drop if you use distributed caches
  4. some cache servers (like, Redis) can cause serious performance issues by removing cached entries due to resource pressure on their side (in this case NH will got to cache server, get cache miss and only then try to retrieve entity from database => 2x network calls)

Also I must say that your tests are not very representative. Before running those performance tests you need to

  • check how many entities will be stored in cache
  • how many "puts" versus "gets" you have for those entities
  • how many linked collections you have in cached entities
  • how many items are stored in linked collections on average
  • what kind of entities do you have (readonly, mainly immutable or all of them are updatable?)
  • etc

And, of course, run tests on your data not on dummy data set ;)

Volodymyr Usarskyy
  • 883
  • 8
  • 17