Pull to refresh

Comments 46

Спасибо за интересное сравнение. Давольно давно работаю в связке Mongo + memcached, а вот про ramfs, tmpfs. Есть вопрос: имеет ли смысл в эти разделы загонять статический контент сайта, чтобы на фронтенде уменьшить операции с диском?
Нет, после перезагрузки данные будут утеряны!
Эти томы очень хорошо подходят для:
1. если Вы кешируете страницы целиком (скажем на не большей период времени 5-10 сек.)
2. если Вы используете кеширование самим web-сервером, в примере nginx, который позволяет кешировать ответ скрипта на время, в приделах которого он даже не будет обращаться к Вашему прокси или cgi. В этом случаи очень удобно ложить кэш nginx-а в эти тома (ramfs или tmpfs).
Ну я конечно о временном хранении. + кто мешает копировать из физического диска необходимые статические файлы в эти разделы после каждой перезагрузки. Конечно это вызовет проблемы, поэтому лучше использовать именно для кеша nginx. Буду тестировать у себя. Спасибо
В статье перепутаны tmpfs и ramfs — заголовки и команды монтирования. точно не перепутали дальше в графиках? :)
Спасибо, сейчас подправлю.
Нет, на графиках все верно, RamFS просто не пишет данные, поэтому «самый быстрый», а TmpFS все время swap-пится.
По XCache — вы как-то не правильно бутерброд едите. Мой опыт говорит о безпроблемности xcache и о проблемах с APC :)
xcache.var_size — какой размер ставили в php.ini?
Пробовали ставить любые и 2Mb и 200Kb, ставили и 0, что снимает ограничения, все по прежнему, не запускался.
Что касается APC — все очень просто было, быстро и очень просто.
Интересное сравнение, спасибо. Хотя, на мой взгляд стоило бы отдельно сравнивать хранилища с доступом по сети (к примеру, memcache, redis, mongo) и локальные стораджи в памяти ( к примеру, eaccelerator, apc, xcache, ramfs/tmpfs )
Понятно, что у второй группы нет задержек на работу с сетью, зато у первой есть возможность обслуживать к примеру ферму бэкендов. Несколько иные задачи у этих двух групп…
И самое главное забыли — показать код чтения-записи, которым тестировали, объемы выделенные на каждый кеш-механизм, общий объём памяти сервера (может, они дрались кому вывалиться в своп?).
Я в самой статье писал что на компе стояло 2Gb памяти, а запускались все тесты по очереди, Вы ведь знаете, что APC не уживется с MemCache. Были написаны простые шел скрипты которые запускал php скрипт и подсовывал ему нужный php.ini.
UFO just landed and posted this here
UFO just landed and posted this here
Возможно, я не буду утверждать. мы провели тесты, результат нас устроил.
Я не внушаю Вам ничего и не заставляю его использовать, просто рассматриваем варианты кеширования.
Очень радует, что mongodb не сильно сливает простым key-value хранилищам. Я считаю, что это офигенный плюс к mongodb.
Я в ужасе. Не осилить сборку xcache и сказать «ну, он вообще глючный» — это круто

php --version
PHP 5.2.17 (cli) (built: Feb 8 2011 23:21:31)
Copyright © 1997-2010 The PHP Group
Zend Engine v2.2.0, Copyright © 1998-2010 Zend Technologies
with XCache v1.2.2, Copyright © 2005-2007, by mOo

Дальше. Я, когда прочитал на графиках «итераций», подумал, может вы их с параллельными запросами спутали? Похоже что нет, не спутали. И тогда возникает вопрос — а что вы вообще меряли? 1 итерация — да у вас дольше соединение устанавливается. На времени меньше секунды вообще полагаться нельзя — у вас же и один прогон теста был, да?)

Ну и измерение в один поток — очень помогает понять, как себя инструмент ведёт на реальной нагрузке. В общем, очередное исследование ниачом.
Прогон был не один, я это написал.
На счет сборки XCache я привел ссылку, в которой говорится что не одни мы столкнулись с похожей ситуацией и как ее решить не знаем.
На счет времени соединения — да, какраз нас интересовало время, которое тратится на получение данных. Живой пример — Вам нужно получить только одну запись из кэша, что будет лучше MemCache или MongoDb? Это нас и интересовало.

И на будущее Вам, если Вы заключаете фразу в кавычки, как Вы это сделали в первом предложении, это подразумевает цитату, а я такого не писал.
MongoDB — не кешер, а полноценная документо/объекто ориентированная база.
Как БД монго быстра, как кешер не очень. Ежу понятно, что простое ключ-значение хранилище будет быстрее чем монго.
Так в данных тестах Mongo так и использовалось, как ключ — значение.
UFO just landed and posted this here
MemCached — это всего драйвер для PHP, а программа называется MemCache.
С MongoDB сильно не сталкивался, а вот с hbase (из того же поколения nosql) приходилось, нормальные показатели если использовать нативный java протокол, да и не зря же facebook перешёл с memcache на hbase, но там согласен его дополнительно ещё интересовали моменты о скорости работы с холодным кешем + единый для всех серверов, а отнють не локальный.
Чего-чего? На HBase с memcache? Ничего, что первое — база данных, а второе — тупой кэш?
www.slideshare.net/cloudera/h-base-in-production-at-facebook-jonthan-grayfacebookfinal

glennas.wordpress.com/2011/03/09/hbase-in-production-at-facebook-jonathan-gray-at-hadoop-world-2010/

возможно ошибаюсь когда говорю что именно как кешер используют, им больше нужно было для инкрементальных счётчиков + высокая скорость доступа, а у memcache проблемы с атомарностью операций присутвуют.

По поводу базы данных: тут стоит учитывать, что это key-value база данных, поэтому выборка по ключу достаточно быстро происходит, а вот попытки писать всё в стиле реляционных бд вызывают ооочень большие тормоза.
HBase — key-value? С каких пор?

Презентация вообще мутная. В частности, там есть «Note that HBase does not actually replace any of these element of the stack, but rather plays an interesting intermediate role between online transactional and offline batch data processing.»

Я не знаю как на самом деле обстоит дело в Facebook. Но HBase очень долгое время не отличалась низким временем отклика. Возможно, в последних версиях стало значительно лучше, но, думаю, до memcache все равно очень далеко.
основной вопрос заключается в том что:
тестирование в 1 поток не дают никакой информации по поводу того, как всё это всё поведёт себя под большой нагрузкой, не упрётесь ли вы в один момент на неприятную ситуацию когда имеется 1000 запросов на обработку, и каждому надо из кеша по 1 записи:
1. выполняем их последовательно в 1 поток, выигрывает база1, база2 сливает в 2 раза.
2. выполняем их в 10 потоков, база1 сливает в 5 раз, база2 вырывается вперёд.

Так что, как было замечено выше, вы тестировали отнють не поведение системы под нагрузкой. Да я и не могу себе представить какую можно создать нагрузку в 1 поток.

По поводу установки соединения (сам java разработчик): неужели в php нет никакого пулинга соединения, чтобы не проводить эту тяжёлую операцию для каждого запроса?

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

Вы к монге обращаетесь по _id, верно? А _id имеет индекс, B-tree. Если в хранилище 500 обьектов, то высота дерева равна log(2)(500) = 9 (если оно сбалансировано), а это значит, что на каждый запрос, по индексу будет 9 операций.

А если взять среднестатистический кэш в хайлоад проекте? Там миллиарды записей в кэше, для 1 млрд записей, log2(10^9) = 27 (опять же, если оно сбалансировано). Уже операций в 3 раза больше. Сложность выборки из B-tree равна O(logn).

А для memcached, который строит hashtable по сути, потому для него сложность всегда O(1). Вы это отлично почувствуете на больших проектах, когда монга начнет стремительно сдавать с ростом количества записей… И медленным будет даже не чтение, а вставка, так как вставка в B-tree дорогая операция по сравнению с hashtable.

Ах да, еще есть лимиты по памяти… Вы бы посмотрели какой оверхед у монги при использовании памяти… Очень удивились бы. На 2гб рамы, мемкеш будет держать 1 млрд среднестатистических данных в кэше, реальных данных, а не выдуманных с размером в 2мб, а вот монга держать не будет, ей, скорее всего, под 8гб понадобится (тут без цифр, субьективные данные основанные на опыте работы).

Потому по моему мнению, ваши тесты некорректны, они не покажут как себя будет вести монга и мемкэш в реальных условиях.
Вчера только увидели что у Mongo не был отключен журнал. Скорее всего без журнала будет быстрее запись.
Что Вы имеете ввиду?
драйвер пыха устроен таким образом, что ему можно указать опцию, по которой команда ждет ответа от сервера. Без нее скорость записи увеличивается, но нет проверки что данные реально записались
Мы не ждем ответа от сервера о корректной записи кэша, считаем что он его записал корректно.
+ это не особенность драйвера, а дополнительная возможность MongoDB. Если у Вас есть какая-то критическая информация, и Вы должны быть уверенны что данные точно попали в БД, то вы юзаете этот флаг, нам он не нужен.
Мы тестировали те продукты, которыми в данный момент пользуемся.
Хотя на продакшене мы и юзаем XCache, на тестовом сервере установить его не вышло.

Возможно при дальнейших тестах мы попробуем и его.
потестируйте редис и будете приятно удивлены :)
По-моему у автора путаница, зачем-то сравниваются PHP in-process кешеры вроде APC, xCache, c key-value хранилищами вроде Memcache, сюда же приплетены RamFS/TmpFS зачем-то.

У всех этих вещей различные предназначения: если вам нужен кешер оп-кодов и внтрипроцессный локальный кеш для ваших аппсерверов, используйте APC/xCache. В заголовке вы упоминаете, что вам нужен «сетевой кеш», причём здесь RamFS/TmpFS непонятно без описания того как именно вы планируете их использовать — тесты-то на локальной машине.

Из подходящих под определение «сетевого кеша» у вас только Memcache. Поддержу предыдущие коменты — используйте Redis, только вначале разберитесь что же вам всё-таки нужно.
Когда начал читать статью думал, что дальше будут какие-то хитрые решения для APC и xCache с php-демоном, который обрабатывает запросы по сети, а RamFS/TmpFS будут монтироваться по сети…
Сравнение сетевого кеша, базы данных, файловой системы и локального кешера опкода с возможностью хранения данных! WTF?
UFO just landed and posted this here
какая прелесть!
Такие вещи решаются красными надписями 72м шрифтом в документации или даже в выдаче перед запуском кешируемого скрипта, но никак не скрытыми неочевидными дефолтными настройками…
UFO just landed and posted this here
Ничерта не видно цвета на таких тонких линиях, так сложно сделать их потолще, особенно подписи к ним?
>>Также можно и продумать систему таким образом, чтобы был многоуровневый кэш
Именно так и рекомендует Facebook уже много лет.
Кроме того, даже трёхуровневую:
1. php $GLOBALS
2. APC
3. медленное сетевое по вкусу.
www.scribd.com/doc/3871729/Facebook-Performance-Caching
Sign up to leave a comment.

Articles