代码改变世界

并发环境下的缓存容器性能优化(下):性能测试

2009-11-16 00:29 by Jeffrey Zhao, ... 阅读, ... 评论, 收藏, 编辑

上一篇文章里,我谈到对于某些场景中的缓存容器,其写操作非常少,到了程序后期甚至为零,而对它的读操作却几乎是密集连续且无穷无尽的。对于这样的容器,如果使用ReaderWriterLockSlim去进行保护每个“读”操作,这开销是在有些多余。因此我提出了“不可变”的哈希表,目的是在保持读操作的时间复杂度为O(1)的情况下,尽可能避免多余的开销。现在我们便将它和其他几种时间进行一个性能的对比。

需要强调一点的是,我们这里讨论的仅仅是符合我提出的特定场景的缓存容器,而不是一个“线程安全的字典”。或者说,其实我这里更强调的是“并发环境下”的“读”性能,而不涉及IDictionary<TKey, TValue>的其他操作(如Count),更不会关心如CopyTo、Remove这类功能的性能。

上一篇文章结束时,我给出了两个缓存容器的基类,可用于此类容器的实现。其中ReadWriteCache类基于ReaderWriterLockSlim,而ReadFreeCache类则基于不可变的字典。不过这两种做法不太适合进行性能测试,因此我这里的实验使用了这样的接口:

public interface IConcurrentCache<TKey, TValue>
{
    TValue Get(TKey key);
    void Set(TKey key, TValue value);
}

我为这个接口提供了几种最基本实现,无论是“读”还是“写”,都是最直接的,并不对任何特殊的情况(如key缺失,key重复)进行处理。例如ImmutableMapCache:

public class ImmutableMapCache<TKey, TValue> : IConcurrentCache<TKey, TValue>
{
    private object m_writeLock = new object();
    private FSharpMap<TKey, TValue> m_map = FSharpMap<TKey, TValue>.Empty;

    public TValue Get(TKey key)
    {
        return this.m_map[key];
    }

    public void Set(TKey key, TValue value)
    {
        lock (this.m_writeLock)
        {
            this.m_map = this.m_map.Add(key, value);
        }
    }
}

ImmutableMapCache是基于F#中的Map而实现的读写操作。由于是Immutable的集合,因此对它的读操作不需要任何并发方面的保护——而写操作理论上也是线程安全的,但是我这里还是使用了lock。这是因为如果没有lock的话,在实际并发的场景中容易出现“摇摆”的情况出现。试想,同时有2个线程正在添加元素,它们同时读取了集合的当前状态,但是在写回的时候只后一个线程的操作生效,先写回的线程的修改丢失了。当并发程度高的情况下,“摇摆”会更加严重。因此,无论是ImmutableMapCache,还是基于Immutable Dictionary的实现,在Set操作中都使用lock进行保护。

测试代码如下:

static void CacheBenchmark<TCache>()
    where TCache : IConcurrentCache<int, int>, new()
{
    var typeName = typeof(TCache).Name;
    var index = typeName.IndexOf('`');
    var cacheName = typeName.Substring(0, index);

    // warm up
    TCache cache = new TCache();
    cache.Set(1, 1);
    cache.Get(1);

    for (int n = 100; n <= 1000; n += 100)
    {
        cache = new TCache();

        CodeTimer.Time(cacheName + " (Set " + n + " elements)", 100, () =>
        {
            for (var i = 0; i < n; i++)
            {
                cache.Set(i, i);
            }
        });

        CodeTimer.Time(cacheName + " (Get from " + n + " elements)", 1, () =>
        {
            var key = 0;
            for (int i = 0; i < 1000 * 1000 * 5; i++)
            {
                cache.Get(key);
                key = (key + 1) % n;
            }
        });
    }
}

请注意,这里的测试都是在单线程环境下的。严格来说,这并不表示每种容器在多线程环境下的表现。事实上,即便是多线程环境下,不同实现随并发程度的高低也会有所变化。因此,除了进行实验和观察结果之外,也必须结合实际情况进行思考,而不能简单的“采纳”这次实验的结果。在这里我们总共测试5种不同的实现:

CacheBenchmark<RwLockSlimDictionaryCache<int, int>>();
CacheBenchmark<RwLockDictionaryCache<int, int>>();
CacheBenchmark<ImmutableMapCache<int, int>>();
CacheBenchmark<ImmutableDictionaryCache<int, int>>();
CacheBenchmark<ConcurrentDictionaryCache<int, int>>();

它们分别是:

  1. RwLockSlimDictionary:基于Dictionary,使用ReaderWriterLockSlim进行保护的缓存容器。
  2. RwLockDictionary:基于Dictionary,使用ReaderWriterLock进行保护的缓存容器。
  3. Immutable Map:基于F#中Map实现的缓存容器。
  4. Immutable Dictionary:基于不可变的哈希表实现的缓存容器。
  5. Concurrent Dictionary:基于.NET 4.0中提供的Concurrent Dictionary实现的缓存容器。

运行环境是.NET 4.0 Beta 2,实验进行三次。我们首先关注“写”操作的结果,如下:

取平均值作为最后结果,并绘制成图表:

在这结果里我并没有包含基于Immutable Dictionary的实现,因为它的结果实在太惨,如果一并放入的话,其他实现方式就几乎看不出来了。我们在来看一下我们的测试代码,它是统计向一个空容器内添加n个元素所花的时间(n等于100、200、...、1000)。对于基于字典的实现来说,添加1个元素的时间复杂度是O(1),因此添加n个元素的时间复杂度是O(n)。而基于Immutable Map的实现,其添加1个元素的时间复杂度是O(log(n)),于是添加n个元素的时间复杂度是O(n * log(n))。这两种时间复杂度都可以从图表中表现出来——当然,这个表现形式是“趋势”也就是“形状”,同样的时间复杂度的常数还是不一样的。

那么Immutable Dictionary又是什么样的呢?我们为其单独进行一番实验,减小实验粒度,希望可以得到更清晰的结果:

for (int n = 100; n <= 10000; n += 100)
{
    CodeTimer.Time(String.Format("add {0} elements", n), 1, () =>
    {
        var cache = new ImmutableDictionaryCache<int, int>();
        for (int i = 0; i < n; i++)
        {
            cache.Set(i, i);
        }
    });
}

将其结果绘制成图表:

向Immutable Dictionary中添加1个元素的时间复杂度是O(n),于是添加n个元素的时间复杂度则是O(n2),从图表上看,这趋势也是相当明显的。而且,与基于Dictionary的实现方式不同,由于Immutable Dictionary每次都要重新复制元素,它对于GC的压力也是非常可观的,如下:

从图中可以看到一个有趣的结果,那就是GC的频率在n为8000到9000的某一个时刻的收集频率突然开始加快了,莫非这就是传说中GC的自我调节能力吗?不过这并非是本次实验的关键,我们只需要发现说,Immutable Dictionary与Dictionary相比,前者对GC的消耗较大,而后者则几乎没有GC方面的压力。

在写方面,Immutable Dictionary的表现可谓残不忍睹,但如果是“读”的话,一切就都不一样了:

将结果绘制成图表:

与“写”操作的测试方式不同,“读”操作测试的是“从包含n个元素的容器中读取元素”所需要的时间。除了Immutable Map是O(logN)的时间复杂度外,其余4种容器都是基于Get操作时间复杂度为O(1)的哈希表。换句话说,基于Immutable Map的容器会随着元素数量而耗时增加,而其他4种容器,它们“读”操作的耗时和其中有多少元素并没有关系。

从结果上我们可以得出一些有趣的结论。首先,ReaderWriterLockSlim似乎会进行“自我调节”,一开始它的Write Lock开销较大,但是随着实验的进行,它的开销变小了很多。其次,基于Immutable Dictionary的实现自然因为其“Read Free”而表现最好,但是.NET中Concurrent Dictionary的表现也相当出色,可谓遥遥领先于基于ReaderWriterLockSlim的实现。而在“写”操作测试时,它的表现也可圈可点,仅次于RwLockSlimDictionary。我并不清楚Concurrent Dictionary的实现方式,有人说是Lock Free,也有人说是小粒度的锁。这点可以通过阅读代码来得知,在这里就不多作展开了。

相关文章

使用Live Messenger联系我