StackExchange.Redis в Azure выбрасывает тайм-аут при выполнении операции get и исключений для подключения нет.

Недавно я переключил приложение MVC, которое обслуживает потоки данных и динамически генерируемые изображения (пропускная способность 6k об / мин), с клиента ServiceStack.Redis v3.9.67 на последний клиент StackExchange.Redis (v1.0.450), и я наблюдаю некоторую более медленную производительность и некоторые новые исключения.

Наш экземпляр Redis имеет уровень S4 (13 ГБ), процессор показывает довольно постоянные 45% или около того, а пропускная способность сети выглядит довольно низкой. Я не совсем уверен, как интерпретировать график получения / набора на нашем портале Azure, но он показывает, что мы получаем около 1 млн. Наборов и 100 тыс. Наборов (кажется, что это может быть с шагом 5 минут).

Переключение клиентской библиотеки было простым, и мы все еще используем сериализатор JSON ServiceStack v3.9, так что клиентская библиотека была единственным изменением.

Наш внешний мониторинг с помощью New Relic ясно показывает, что наше среднее время отклика увеличивается с примерно 200 мс до примерно 280 мс между библиотеками ServiceStack и StackExchange (StackExchange медленнее) без каких-либо других изменений.

Мы записали ряд исключений с сообщениями в виде:

Тайм-аут выполнения каналов канала GET:ag177kxj_egeo-_nek0cew, inst: 12, mgr: неактивно, очередь: 30, qu=0, qs=30, qc=0, wr=0/0, in=0/0

Я понимаю, что это означает, что в очереди есть ряд команд, которые были отправлены, но ответа от Redis нет, и это может быть вызвано длительными командами, которые превышают время ожидания. Эти ошибки возникали в течение периода, когда наша база данных sql, стоящая за одной из наших служб данных, создавала резервные копии, поэтому, возможно, в этом была причина? После масштабирования этой базы данных, чтобы уменьшить нагрузку, мы не увидели больше этой ошибки, но запрос к БД должен происходить в.Net, и я не вижу, как это задержит команду или соединение redis.

Мы также записали большое количество ошибок сегодня утром за короткий промежуток времени (пару минут) с такими сообщениями:

Нет соединения для обслуживания этой операции: каналы подачи SETEX:vleggqikrugmxeprwhwc2a: последняя попытка

Мы привыкли к временным ошибкам соединения с библиотекой ServiceStack, и эти сообщения об исключениях обычно выглядят так:

Невозможно подключиться: порт: 63980

У меня сложилось впечатление, что SE.Redis должен повторять попытки соединений и команд в фоновом режиме для меня. Нужно ли мне оборачивать наши звонки через SE.Redis в мою собственную политику повторов? Возможно, другие значения тайм-аута были бы более подходящими (хотя я не уверен, какие значения использовать)?

Наша строка подключения redis устанавливает следующие параметры: abortConnect=false,syncTimeout=2000,ssl=true, Мы используем единственный экземпляр ConnectionMultiplexer и временные случаи IDatabase,

Подавляющее большинство нашего использования Redis проходит через класс Cache, и важные моменты реализации приведены ниже, на случай, если мы делаем что-то глупое, что вызывает у нас проблемы.

Наши ключи обычно состоят из 10-30 строк символов. Значения - это, в основном, скалярные или достаточно малые сериализованные наборы объектов (обычно от сотен байтов до нескольких кБ), хотя мы также сохраняем изображения jpg в кэше, поэтому большой объем данных составляет от пары сотен кБ до пары МБ.

Возможно, мне следует использовать разные мультиплексоры для малых и больших значений, возможно, с более длительными таймаутами для больших значений? Или пара / несколько мультиплексоров, если один из них остановлен?

public class Cache : ICache
{
    private readonly IDatabase _redis;

    public Cache(IDatabase redis)
    {
        _redis = redis;
    }

    // storing this placeholder value allows us to distinguish between a stored null and a non-existent key
    // while only making a single call to redis. see Exists method.
    static readonly string NULL_PLACEHOLDER = "$NULL_VALUE$";

    // this is a dictionary of https://github.com/StephenCleary/AsyncEx/wiki/AsyncLock
    private static readonly ILockCache _locks = new LockCache();

    public T GetOrSet<T>(string key, TimeSpan cacheDuration, Func<T> refresh) {
        T val;
        if (!Exists(key, out val)) {
            using (_locks[key].Lock()) {
                if (!Exists(key, out val)) {
                    val = refresh();
                    Set(key, val, cacheDuration);
                }
            }
        }
        return val;
    }

    private bool Exists<T>(string key, out T value) {
        value = default(T);
        var redisValue = _redis.StringGet(key);

        if (redisValue.IsNull)
            return false;

        if (redisValue == NULL_PLACEHOLDER)
            return true;

        value = typeof(T) == typeof(byte[])
            ? (T)(object)(byte[])redisValue
            : JsonSerializer.DeserializeFromString<T>(redisValue);

        return true;
    }

    public void Set<T>(string key, T value, TimeSpan cacheDuration)
    {
        if (value.IsDefaultForType())
            _redis.StringSet(key, NULL_PLACEHOLDER, cacheDuration);
        else if (typeof (T) == typeof (byte[]))
            _redis.StringSet(key, (byte[])(object)value, cacheDuration);
        else
            _redis.StringSet(key, JsonSerializer.SerializeToString(value), cacheDuration);
    }


    public async Task<T> GetOrSetAsync<T>(string key, Func<T, TimeSpan> getSoftExpire, TimeSpan additionalHardExpire, TimeSpan retryInterval, Func<Task<T>> refreshAsync) {
        var softExpireKey = key + ":soft-expire";
        var lastRetryKey = key + ":last-retry";

        T val;
        if (ShouldReturnNow(key, softExpireKey, lastRetryKey, retryInterval, out val)) 
            return val;

        using (await _locks[key].LockAsync()) {
            if (ShouldReturnNow(key, softExpireKey, lastRetryKey, retryInterval, out val))
                return val;

            Set(lastRetryKey, DateTime.UtcNow, additionalHardExpire);

            try {
                var newVal = await refreshAsync();
                var softExpire = getSoftExpire(newVal);
                var hardExpire = softExpire + additionalHardExpire;

                if (softExpire > TimeSpan.Zero) {
                    Set(key, newVal, hardExpire);
                    Set(softExpireKey, DateTime.UtcNow + softExpire, hardExpire);
                }
                val = newVal;
            }
            catch (Exception ex) {
                if (val == null)
                    throw;
            }
        }

        return val;
    }

    private bool ShouldReturnNow<T>(string valKey, string softExpireKey, string lastRetryKey, TimeSpan retryInterval, out T val) {
        if (!Exists(valKey, out val))
            return false;

        var softExpireDate = Get<DateTime?>(softExpireKey);
        if (softExpireDate == null)
            return true;

        // value is in the cache and not yet soft-expired
        if (softExpireDate.Value >= DateTime.UtcNow)
            return true;

        var lastRetryDate = Get<DateTime?>(lastRetryKey);

        // value is in the cache, it has soft-expired, but it's too soon to try again
        if (lastRetryDate != null && DateTime.UtcNow - lastRetryDate.Value < retryInterval) {
            return true;
        }

        return false;
    }
}

1 ответ

Несколько рекомендаций. - Вы можете использовать разные мультиплексоры с разными значениями времени ожидания для разных типов ключей / значений. http://azure.microsoft.com/en-us/documentation/articles/cache-faq/- Убедитесь, что вы не связаны сетью на клиенте. и сервер. если вы находитесь на сервере, то переходите на более высокий SKU с большей пропускной способностью. Пожалуйста, прочитайте этот пост для получения дополнительной информации http://azure.microsoft.com/blog/2015/02/10/investigating-timeout-exceptions-in-stackexchange-redis-for-azure-redis-cache/

Другие вопросы по тегам