Господа программисты, вопрос по memcached

Объясните толком, что за зверюга?

Вот я так понял, что можно сделать так:
$obj = new StdClass;
$obj->something = 1;

А потом этот объект толкнуть в мемкеш по ключу, так?

Тогда еще вопрос: а что будет если я какой-либо объект MySQL допустим суну туда?

И еще вопрос: в каких ситуациях оно может понадобиться?
Ато мне тут один программист затирает про необходимость это все заюзать, а я не спал сутки уже.
По-простому расскажите?

имеет смысл хранить выборки БД - с целью уменьшить нагрузку
в некоторых случаях - HTML
зачем хранить объекты , тем более SQL - хз

Мемкеш вообще то предназначен для хранения "ключ-значение". Не уверен, что у тебя получится туда полноценно объект запихать. Наверное можно если извратиться, но зачем ?

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

Оборотень: хранить объекты - да, можно

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


технически можно хранить конечно не сам объект трейдера, а только статистику по хитам + задолженность как значение, но с объектом удобнее тк подхватывается сразу все.

PS пример надуманный конечно но смысл думаю ясен.

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

а вообще смысл хранить просто какой-то объект, действительно оч. сильно зависит только от предметной области задачи (например онлайн игра, храним композитный объект перса, где его атрибуты так же могут являться сложными агрегированными объектами, каждый из которых при своём создании, как объекта, чё-то тянет из БД, опрашивает другие сервисы и прочее), вот например объекты такого рода можно таки да, целиком там и хранить, что бы не тратить много времени при следующем инстанциировании объекта (в ущерб памяти под кэш ессно), но в целом, подобные объекты лучше перепроектировать, все инициализации вынести в отдельные методы, не вызываемые во время создания этого объекта (то есть, не конструкторы), а в кэшах хранить только состояния таких объектов, то есть, просто хэши (ассоциативные массивы)посчитанных данных, и восстанавливать его для объекта, после его очередного создания, вытаскивая только сами состояния (разные небольшие по объёму, но долгие выборки, всякие там арифметические вычисления, типа тех, которые упомянул LemonS и т.д.).
А вообще, рекомендую APC вместо memcached

То есть, если я делаю $x = new Stdclass;
потом
$x->xxx=1;

То при десерелизации(при get объекта из мемкеш), я должен создать точно такой же объект, так?

И например сделать сначала
$x = new Stdclass;
потом
$x->xxx=любое число;
потом
$mc = new Memcache;
$mc->get('key',$x,$compression);

Так? То есть, грубо говоря, все поля структуры должны быть.

Тогда закономерный вопрос: а что если у меня одно из полей - строка неизвестной заранее длины?

$x = new stdClass;
$x->aaa = 'aasdasdawe';

Как потом будет происходить десерелизация?

С сериализацией функции класса Memcache прекрасно управляются сами. При десериализации (вот ведь, сцуко, слово ) ничего создавать не надо - класс сам создаётся. В кэше будет храниться копия текущего состояния класса, со значениями переменных на тот момент.

Код: [развернуть]

<pre> <? $memcache = new Memcache; $memcache->connect("localhost", 11211) or die("Can't connect to Memcache"); class someClass {    var $x;    function someClass($x)    {       $this->x = $x;    } } $obj1 = new someClass(12345); var_dump($obj1); $memcache->set("obj", $obj1); $obj2 = $memcache->get("obj"); var_dump($obj2); ?> </pre>

Последний раз редактировалось: alex.raven (17/10/11 в 18:38), всего редактировалось 1 раз

Цитата:

То при десерелизации(при get объекта из мемкеш), я должен создать точно такой же объект, так?

Memcache::get вернёт объект в десериализированном виде, то есть строку вида

Код:

O:8:"stdClass":1:{s:3:"aaa";s:10:"aasdasdawe";}

заетём $x = unserialize($mc->get('key',$x,$compression));
var_dump($x2);

Код:

object(stdClass)#2 (1) {   ["aaa"]=>   string(10) "aasdasdawe" }

Цитата:

Тогда закономерный вопрос: а что если у меня одно из полей - строка неизвестной заранее длины?

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

Оборотень писал:

То при десерелизации(при get объекта из мемкеш), я должен создать точно такой же объект, так?

Нет, не совсем так. Можно запихнуть объект полностью, и тогда при десериализации он воссоздастся из кэша. Для этого у объектов есть магические методы __sleep() и __wakeup()

mr. snatch писал:

Memcache::get вернёт объект в десериализированном виде

Ты хотел сказать в сериализованном?

Точно ) Затупил я что то.
То есть unserialize() - палюбасу впихивать придется... ага.
С другой стороны, какая хуй разница )

То есть, если я правильно понимаю, то что APC что memcached - это такой костыль-способ IPC для php?
Зная ключик, можно получить доступ к данным.

То же самое происходит если пользовать shared mem программируя, к примеру на си или перле. Только так сериализация - на плечах программиста, либо сторонней библиотеки.

Цитата:

То есть unserialize() - палюбасу впихивать придется... ага.

не, сорь, гоню, давно отказался от memcached уже не помню чё оно точно возвращает, глянул в мануале - там строка (то есть в сериализированном виде), но вот щас специально поставил себе memcached, после Memcache::get сам десериализируется, то есть, самому unserialize() делать не надо, почему - CABMIT сказал выше

то есть, с объектом $x после $mc->get('key') работаешь как с обычным объектом, как бы с ним работал до того, как засунул его в кэшь. ничё дополнительно для выделения памяти и т.д. делать ненадо

теперь вкурил. прям волшебная палочка )

у мемкеша только одно преимущество существенное в принципе - то что можно легко разнести на несколько серваков.

Ну так вот потому и волшебная )

в общем, наверно ещё нужно уточнить такой случай, который описывал выше:
есть три файла:

Код:

<?php # test.php class Test {    protected $myConf = array();        public function init(array $my_conf) {       $this->myConf = $my_conf;    } } ?>

Код:

# push.php <?php require_once 'test.php'; $mc = new Memcache; $mc->connect('localhost', 11211) or die ("Could not connect"); $test = new Test(); $mc->set('key2', $test, false, 3000); ?>

и

Код:

<?php #get.php $mc = new Memcache; $mc->connect('localhost', 11211) or die ("Could not connect"); $out = $mc->get('key2'); print_r($out); ?>

то есть, в push.php создаём объект класса Test и пихаем его целиком в кэш, затем, в файле get.php пытаемся его прочитать, и смотрим, что нам возвращается - возвращается так называемый __PHP_Incomplete_Class:

Код:

__PHP_Incomplete_Class Object (     [__PHP_Incomplete_Class_Name] => Test     [myConf:protected] => Array         (         ) )

происходит это потому, что в отличае от stdClass (который является встроенным), ПХП ничего не знает, о кастомном классе Test, и что бы сработала "магия" спец. методов, мы должны явно подключить файл с классном test.php до его неявного десериализирования (представить интерпретатору), то есть, переписать переписать get.php как-то так:

Код:

<?php require_once 'test.php'; $mc = new Memcache; $mc->connect('localhost', 11211) or die ("Could not connect"); $out = $mc->get('key2'); print_r($out); ?>

вот именно поэтому, лучше всего не хранить в кэше целые объекты, а только их состояния, например, массив конфигов класса Test, который потом просто передаём в метод Test::init()

Ну рассказать интерпретатору что-то о классе, с которым ему работать - это как бы логично.

Но за подробный пример спасибо

Последний раз редактировалось: Оборотень (17/10/11 в 19:49), всего редактировалось 1 раз

ну и так же, если начинаешь работать с кэшем, сразу советую использовать некую абстракцию от кэш-бэкенда (например многие cmf имеют такую фитчу, или самому написать), вполне возможно, что в последствии решишь перейти с memcached на APC, как например я, и не портировать весь код, который работает с кэшем.
Кстати, очень рекомендую Kohana (с версии 3.2), как подобную CMF, с которой можно начать разбираться, да в принципе, и оставаться на ней же для средних проектов

Оффтопик: Люблю Кохану, но Yii также весьма неплох

CABMIT писал:

Оффтопик: Люблю Кохану, но Yii также весьма неплох

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