LINUX.ORG.RU

Какой самый быстрый способ считать значение из общего кеша ?

 , ,


0

1

Привет

Потребовался максимально быстрый кеш на чтение. Замеры показали, что самый быстрый обычный пофайловый, который в django FileBasedCache.

Вопрос в том, можно ли ещё быстрее ? Пробовал атрибуты файла ФС, setxattr, но оно сказало

OSError: [Errno 95] Operation not supported

Хотя из консоли работает setfattr утилитой

Redis как оказалось на чтение намного медленней файлового, то же diskcache.DjangoCache

Есть ли ещё варианты быстро вычитать значение ?

★★★
Ответ на: комментарий от anonymous

LocMemCache процессозависим, то есть каждый процесс uwsgi django имеет свой кеш

Иначе бы использовал его

ism ★★★
() автор топика
Последнее исправление: ism (всего исправлений: 2)
Ответ на: комментарий от ism

Я так понимаю memcached тоже оказался медленным? Тут видимо надо пытаться найти узкие места тех решений что есть, нежели искать другие решения. Поэтому сложно вам что-то посоветовать, вы же видимо всерьез не задавались метриками, и статистики дать не можете, где, почему и как происходит просадка производительности при выборе из кеша. В общем как и сказано ранее, наверное стоит эту метрику подбить и станет ясно что делать чтобы стало быстрее. Так вот просто типа, перейди с системы N на систему M, эту задачу не решить.

anonymous
()
Ответ на: комментарий от anonymous

На самом деле тут вопрос проще, самое примитивное самое быстрое.

Получается что файл вычитывается из кеша ФС linux, это очень быстро. Но возможно есть чтото ещё более эффективное. Пока такого не нашел

ism ★★★
() автор топика
Ответ на: комментарий от ism

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

Но in-memory это уже заход на терриротию кастомных кэшей, а это значит что придется что-то писать в отличии от готовых решений в пределах django.

anonymous
()
Ответ на: комментарий от ism

Так ты memcached пробовал? Скорость должна быть стабильнее чем с файлами. Пока файл в кеше будет конечно норм, но контролировать это ты не можешь.

pi11 ★★★★★
()
Ответ на: комментарий от eternal_sorrow

у него редис получается медленнее, но мне кажется это проблемы настройки и связующего кода в пределах django

anonymous
()
Ответ на: комментарий от rikimaru

Спасибо

Кажется то, что нужно, правда оно только в 3.8 питоне, но это решаемо. Оно очень напоминает memcached только без обвеса

Интересно, какие подводные камни ?

ism ★★★
() автор топика

Как вариант, можно на уровне Nginx кешировать, тогда, по идее, будет ещё быстрее. Вопрос только в том, как его инвалидировать.

dimuska139 ★★
()
Ответ на: комментарий от pi11

Пока файл в кеше будет конечно норм, но контролировать это ты не можешь.

Можно примонтировать RAM диск или писать в /dev/shm.

xpahos ★★★★★
()
Ответ на: комментарий от xpahos

Ещё вопрос сколько наносекунд он сэкономит на 100к запросов vs memcached, у которого стандартный и удобный интерфейс.

pi11 ★★★★★
()
Ответ на: комментарий от xpahos

Можно, но все равно много лишнего. Например FileBasedCache пересчитывает количество файлов при вставке, что накладно даже для рам диска. Что касается чтения, то скорость с tmpfs и с обычной почти одинакова ибо кеш ФС

В общем shared memory хорошо, но на будущее, слишком много переделывать

Поэтому накатал изврат. Подсчет файлов в кеше редиса или подобного, это позволило убрать тормоза, но сохранить свойства FileBasedCache. Он ценен ещё тем, что не падает при многопоточных запросах. diskcache.DjangoCache много раз падал

import random
from django.core import cache
from django.core.cache.backends.base import DEFAULT_TIMEOUT
from django.core.cache.backends.filebased import FileBasedCache


class MyFileBasedCache(FileBasedCache):

    def __init__(self, dir, params):

        """
        Кеш совмещает надёжность файлового кеша, скорость чтения, и не ограничен в размерах как FileBasedCache
        FileBasedCache тормозил при большом количестве файлов, ибо считал их заново
        Здесь же подсчёт перенесен на быстрый кеш

        """

        super().__init__(dir, params)

        self.default_cache = cache.caches['default']

        self.cache_key = '981a50825cf542d9bafbdbabeb840410'

        self.count_cache()

    def _cull(self):

        num_entries = self.default_cache.get(self.cache_key, 0)

        if num_entries < self._max_entries:
            return

        if self._cull_frequency == 0:
            return self.clear()

        # Delete a random selection of entries
        filelist = self._list_cache_files()

        filelist = random.sample(filelist, int(num_entries / self._cull_frequency))

        for fname in filelist:
            self._delete(fname)

        self.count_cache()

    def set(self, key, value, timeout=DEFAULT_TIMEOUT, version=None):

        super().set(key, value, timeout, version)

        res = self.default_cache.get(self.cache_key)

        if not res:
            self.count_cache()

        self.default_cache.incr(self.cache_key)

    def count_cache(self):

        filelist = self._list_cache_files()
        self.default_cache.set(self.cache_key, len(filelist), None)

ism ★★★
() автор топика
Последнее исправление: ism (всего исправлений: 3)
Ответ на: комментарий от pi11

Ещё вопрос сколько наносекунд он сэкономит на 100к запросов vs memcached, у которого стандартный и удобный интерфейс.

Вопрос же был в контроле кэша. Он есть. Ну и у vfs тоже стандартный интерфейс ;)

xpahos ★★★★★
()
Ответ на: комментарий от ism

Я не очень понимаю про что этот код. Смотрел бы встрону какого-нибудь хипа, там вставка log n

xpahos ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.