Как в ПХП обмениваться данными между процессами?

[Ferox]

Как в ПХП обмениваться данными между процессами?

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

Понятно, что в общем случае, данные можно хранить только в БД или файловой системе (что предпочтительнее т.к. быстрее).

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

Вопрос:
1. Существенно ли быстрее будет хранить данные в памяти чем в файловой системе, при их небольшом объеме (ну до 100 байт). Не приведет ли кэширование файловой системы к тому, что существенного бонуса у памяти не будет?

2. Как в ПХП передать данные в памяти от одного процесса/скрипта к другому?

 

[Finder]

мэмкэш?

 

[Ferox]

нет, IDS

 

[Finder]

а что значит IDS?

 

[Ferox]

Intrusion Detection System

Банить айпишники, которые дают слишком много запросов к некоторым .php скриптам. (конкретно к скрипту поиска)

 

[Finder]

честно говоря не совсем понял как это может повлиять на мэмкэш, но если не хо, можешь сделать его простенький аналог в качестве демона на перле с хранением в памяти

либо можно через mysql/other_db и heap (живущую в памяти) таблицу

... а можно и в сессии, если же только скрипты не через консоль стартуют

 

[Ferox]

Сессии - реально та же файловая система. Данные сессии хранятся в файловой системе. Таблица типа MEMORY - да, вариант.

 

[kott]

как вариант, динамически блочить через .htaccess

 

[Ferox]

Да, через .htaccess, только информацию на основе которой блочить, сначала нужно собрать. Наверное, таки буду в файловой системе информацию собирать.

 

[kott]

если правильно понял, тебе нужно просто количество обращений в секуду/минуту?
имхо, лучше в обычной бд таблице - выборку делать все равно быстрее, чем вручную парсить некий файл статистики.

 

[Ferox]

Вручную парсить можно хитро. Я сейчас пробую два варианта, файловая система и БД с таблицей типа MEMORY... посмотрим...

 

[eyeland]

фс это совершенно излишнее извращение полное головняка связанного с синхронизацией. решай проблему с помощью БД и забудь уже о ней =)

 

[eyeland]

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

вот тут есть букварь по shared memory. говорят это не шибко быстро, но думаю пошустрее чем БД или файл (Я ГАРАНТИРУЮ ЕТО лол)

Посилання видалено

 

[kott]

фс это совершенно излишнее извращение полное головняка связанного с синхронизацией. решай проблему с помощью БД и забудь уже о ней =)

+1

вообще, схоже на экономию на спичках..

 

[Ferox]

Господа, опыта особого измерения быстродействия при работе с файловой системой у меня нет, необходимости не было. Но БД работает реально медленно. Поэтому комментарий eyeland в сообщении №12 несколько не в тему. Кроме того, я боюсь, вы действительно несколько не понимаете, насколько в этой задаче критично быстродействие. Запуск, скажем, 5 процессов с интервалом в 0.02 сек. может существенно снизить быстродействие сервера не самой оптимальной конфигурации. Если, он, скажем, четырехядерный, и каждый процесс имеет возможность занять целиком ядро. Такая конфигурация попадается сплошь да рядом. И у 6го процесса будет очень мало времени, при сниженном быстродействии системы, на то, чтобы модифицировать .htaccess при условии если процессы продолжают запускаться с интервалом 0.02 сек. прежде чем сервер вообще сдохнет.

IDS неслучайно обычно делают на уровне вебсервера а не на прикладном уровне.

 

[Finder]

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

а можно попробовать сделать хитро на файлах:
1. в /tmp создаем папку для будущих файлов
2. необходимые для блокировки IPшники укладываем в эту папку называя также как и аддресс (а-ля /tmp/blocked_ips/127.0.0.1)
3. прикол выйдет в том, что по сути в файлы ничего писать не приёдется...равно как и читать - достаточно просто создавать пустые файлы и затем проверять их наличие.
4. периодически очищать данные cron'ом

 

[kott]

Господа, опыта особого измерения быстродействия при работе с файловой системой у меня нет, необходимости не было. Но БД работает реально медленно. Поэтому комментарий eyeland в сообщении №12 несколько не в тему. Кроме того, я боюсь, вы действительно несколько не понимаете, насколько в этой задаче критично быстродействие. Запуск, скажем, 5 процессов с интервалом в 0.02 сек. может существенно снизить быстродействие сервера не самой оптимальной конфигурации. Если, он, скажем, четырехядерный, и каждый процесс имеет возможность занять целиком ядро. Такая конфигурация попадается сплошь да рядом. И у 6го процесса будет очень мало времени, при сниженном быстродействии системы, на то, чтобы модифицировать .htaccess при условии если процессы продолжают запускаться с интервалом 0.02 сек. прежде чем сервер вообще сдохнет.

IDS неслучайно обычно делают на уровне вебсервера а не на прикладном уровне.

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

для этих целей, можно поковырять/подправить tcpdump

если же делать в связке с вебсервером - слишком много сложностей, которые того не стоят

 

[BFG-9000]

Чет я все равно не понял про быстродействие
С чего бы это запущенному процессу занять ядро целиком? А даже если и занять...
Пробил клиент ТЦП-соединение, сервер форкнул ему процесс (что кстати вовсе не обязательно в случае с ПХП - это как его к серверу прикрутить Далее скрипт посмотрел в базу - даже 10000 записей в MEMORY таблице мускуля извините будут просто летать, чтобы там не говорили. Не факт что даже поиск файла в каталоге будет быстрее - ибо к файлам в каталоге не прилагается индекса имен файлов Ну и сдох скрипт если ему что-то не понравилось.
В чем трабель?
Ессесно это спасет от ДОСа полноценными запросами. Синфлуд или неоконченные соединения решаются другими способами.

 

[Ferox]

Я сделал таблицу MEMORY теперь надо придумать алгоритм, по которому ее TRUNC'ать... кроном не очень хочется... пока сделал кроном, но думаю...

 

[BFG-9000]

А чем тебе крон не мясо? Нормальное решение...