Форум PHP

Лучше JSON использовать вместо сеарелизации, это и короче запись, и быстрее преобразование.

В Вашем случае сериализованный массив.

Если записывать просто сами элементы массива, то больше 100-1000 штук (в зависимости от настроек) Вам вряд ли система позволит добавить. А вот записать строку позволит без проблем.

Т.е., к примеру, получается у Вас есть массив в сериализованном виде. Создаёте сектор в разделяемой памяти (как по ссылкам выше, которые я публиковал).

Получается что-то вроде этого (здесь старый формат со старых версий PHP, но Вы их легко замените на новый):

$MEMSIZE = 1024 * 1024;     // Ключ сектора $SHMKEY = 3; $shm_id = shm_attach($SHMKEY, $MEMSIZE);

Затем вставляете нужный массив. В старом формате это выглядит так:

$var = shm_put_var($shm_id, 0, $arr);

где $arr - сериализованная строка Вашего массива, а 0 - номер ячейки куда добавлять данные (от 0 до n).

Это Вы делаете в подпрограмме, отвечающей за добавление/обновление данных массива.
А в подпрограмме, которая считывает эти данные используете:

$key = shm_get_var($shm_id, 0);

где 0 - номер ячейки с данными (в коде Выше мы добавляли строку в ячейку под этим номером).

А что можно сделть?:
а) закинуть в разделяемую память сериализоанный массив
б) записать туда массив в бинарном виде
в) записать туда фотографию всего скрипта целиком, со значениями переменных, как есть?

Настройки ОС мне доступны (комп. у меня дома)

Я её использую в небольшом стартапе. Пока никаких сбоев и т.п. замечено не было за более 7 месяцев. Да и не должно быть, т.к. это очень простой метод в реализации и очень странно почему мало распространён. В нём, правда, нельзя шибко много данных хранить (128мб по-умолчанию уставновлено в PHP, но надо ещё настраивать настройки в самой ОС, т.к. там скорее всего ограничено 8мб (так было в моём случае)).

Быстрее просто потому, что разделяемая память - это участок в оперативной памяти ПК в то время как таблица в БД (в зависимости от типа БД) - это всёго лишь файлик на жёстком диске. А оперативная память, как Вы понимаете, гораздо быстрее.

Тут попросту неоткуда возникать ошибкам, серъёзно:)

В любом случае дело, конечно, за Вами, как решить Вашу задачу. Я не пиарщик этого метода и мне за это даже не приплачивают;)

Только разделяемая память в десятки раз быстрее и проще

Это и всё остальное, что вы пишете, очень интересно.

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

Я почему-то впервые сталкиваюсь с обсуждением данной темы.
Было бы интересно послушать мнение Хеопса и др. старожилов. Например, классы в РНР широко используются, а ошибок в них ещё много. К счастью, ошибки связанные с объектами быстро показывают себя. А вот с разделяемой памятью может получиться наоборот: при малой нагрузке - работает, а при значительной нагрузке даст сбой.

Вы пробовали стресс-тесты программ с разделяемой памятью делать?

Пробовал и активно использую - очень хорошая штука;)

Вы же из памяти производите только выборки (ну иногда добавляете/обновляете информацию) как я понимаю? В случае выборки одновременный доступ к памяти никак не повливает на данные (не испортит их). Это как из БД (пусть будет MySQL) делять SELECT-запрос - их же могут делать одновременно несколько подпрограмм и ничто не будет испорченно:) Только разделяемая память в десятки раз быстрее и проще:)

Если вы хотите обновить там данные и хотите, чтобы в тот момент никто не мог эти данные получить (чтобы не забрать случайно старые данные до обновления), то пользуйтесь семафорами. А в программе, которая берёт данные из памяти циклически обрабатывайте получение данные. К примеру, если установлен семафор, то попробовать получить данные ещё раз через n миллисекунд.

Надеюсь правильно понял Ваш вопрос.

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

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

>Попробуйте ипользовать разделяемую память. Насколько я понял, она идеально подойдёт

Я прочитал текст по ссылкам, спасибо!
А вы пробовали использовать разделяемую память?
Там ведь пишут, что память не защищена от одновременного обращения к ней.
А как разруливать не пишут. Если назначить какую-то часть памяти на роль семафора, то опять же, к ней возможно одновременное обращение...

>Исходный массив одинаковый, если пользоатели обратились к нему с одинаковыми GET-
>параметрами и не все. Когда обращается последний пользователь(из списка с одинаковыми
>GET параметрами), производятся вычисления и массив изменяется. Сессию задействовать,
>думаю, можно. Только в чём будет преимущество?
Зависит от данных, однако, если в сессии уже есть массив или данные, а это всегда можно проверить, то не потребуется новый запрос к базе данных. Чем дольше сессия - тем больше выгода, таская за собой сессию часами посетитель не делает лишних запросов.

>В чём конкретно состоит разница в объёме усилий? Долго извлекать длинную запись из
>таблицы? Таблица невелика, обращение к ней по первичному ключу...
Чтобы задействовать возможности СУБД в частности по поиску и покрыть накладные расходы, которая СУБД обязательно производит за счет своей сложной организации, вам нужно преобразовывать объекты или сложные массивы в реляционные структуры - это довольно трудоемкий процесс, который довольно сложно автоматизировать. При автоматизации легко построить неэффективную СУБД, которая не позволит задействовать индексацию, кэши и прочие возможности СУБД по ускорению работы. Поэтому, как правило, получается либо мощная база данных, либо мощная объектная модель. Чтобы соединить их, оставив и то и то, нужно проделать титаническую работу по программированию соответствующего интерфейса (что скорости и надежности не добавляет).