>Какой смысл тестировать вещи не предназначенные для этого?
Потому что они хорошо подходят для этого. А что ты предлагаешь вместо? :)
xcache ещё в тест включу (APC и eaccelerator в последние годы глючат, так что не буду), но это не альтернатива, xcache и пара миллионов записей на несколько гигабайт - это нонсенс ;)
>Ну как подходят, если по твоим же тестам сливают в производительности?
А кто быстрее? memcache? Так он, во-первых, начинает терять данные на высокой нагрузке, во-вторых, не предназначен для хранения больших объёмов данных. А меня интересует именно такой вариант и приведённый тест служит только для начального отбора к следующему. О чём в описании теста и написано :)
Кроме того, при многопоточной работе скорость memcache стремительно падает почти до уровня redis.
Так он, во-первых, начинает терять данные на высокой нагрузке
Я писал php memcache бэкенд на старой работе. Нагрузка была около 200-300 rps и иногда всё упиралась в 100Mbitный канал до memcache сервера. Проблемы с потерей данных или невозможностью подключиться не встречал.
https://github.com/mailru/tarantool
А то они его тут так пиарили на YAPC, даже обещали подумать над открытием плагина графов, а я что-то смысла в нем так и не увидел.
Тарантул - это memcachedb кустарного производства, унылое, как и все майлрушные поделки.
Редис очень хорош в продакшене (используется в нашем проекте), только он однопоточный, к сожалению.
Очень хочется видеть сравнительный тест MySQL Handler Socket
Ты потерял нить. Пойнт был в том, что для клиента абсолютно по-барабану насколько сложна реализация кеш-бэкенда, интерфейс которого достаточно примитивен, чтобы допустить утечку абстракций.
я стал в питоне для этого использовать
dbm
это кеу-value файлик
по мне так быстрее всего
если есть нечто похожее в php
было б здорово включить это в тест
потому как шарить по многим файлам за раз оно конечно накладно
а если данные подготовить
и сохранить в один файл где искать по ключу - должно быть быстрее всего
>есть нечто похожее в php было б здорово включить это в тест
dbm есть, и я даже когда-то (в Perl'е) с ним работал. Он насквозь однопоточный и блокируемый. Как дело до многопоточной работы доходит — всё колом встаёт. Можно, конечно, партицировать на N файлов, это улучшит ситуацию, но это уже костыли в данном случае, ИМХО :)
на счет однопоточности тоже думал
не знаю какой он в питоне
но я запускал тест типа
httperf --hog --num-conns 100 --num-calls 100
и пока он работал
перестраивал не прерывно этот dbm
ошибок не было
так же
зашел в питон
открыл файл на чтение
а в броузере открывал страницу
там тоже только на чтение
нет проблем
более того
открыл на чтение в одной сессии
а в другой добавил данные
он их в первой не видит пока не закроешь и не откроешь сначала
но ОШИБОК ДОСТУПА нет
а такая он-лайн передача данных мне не нужна