модуль DBCache. beta version. FAQ.

. Согласен, что модуль сырой, и что многое можно еще сделать
+1

Сергей Тарасов, ну ты немного строг, некоторые из аппонентов довольно-таки опытные товарищи (кого я знаю лично), хотя флейма развели значительно больше, чем требовалось. мне всегда казалось, что форум нужен, чтоб находить решения, обсуждать проблемы... Есть люди на Форуме, чьему мнению я всегда прислушиваюсь и чье мнение для меня важно. Эти люди, очевидно пока отдыхают и в обсуждении не участвуют. Ну что поделаешь, любят некоторые повыступать. Такова сущность человека, смотри на жизнь проще ;)
бог простит их, ведь сегодня Рождество! :)

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

суть того что пофиксил: вывод данных производится в темповый файл, после закрытия - он переименовывается. А ранее - он переименовывается сразу :( , а вывод производится в "рабочий файл".
был вариант - использовать блокировки, но так вернее,
во первых, нет ожидания на считывание - запись - дело длинное, запрос может исполняться долго,
во вторых, когда переименовывается файл, его переименование фактически происходит, когда освобождаются все эффективные ссылки на дискриптор файла, т.е. накладок не будет и целостность данных не нарушится.
 
флейма было бы куда меньше, если бы ты не сопротивлялся необходимости реализации инвалидации по событию отличному от таймаута.
 
Автор оригинала: zerkms
http://dev.mysql.com/doc/refman/5.0/en/query-cache-in-select.html

до сих пор так и не было аргументов - зачем было писать когда есть нативное кеширование? ;)
При любом изменении данных в таблице кеш сбрасывается. А это может быть не всегда желательно. Об этом ведь уже говорили.
 
Мня вот что смущает. Даже если отбросить очень узкую специализацию неуправляемого кеша, не ясно, почему же экстеншн? Онные хорошо когда мы или делаем интерфейс в чужое сишное API или есть скорость работы такого экстеншена дают значительный прирост производительности (по тестам реальных приложений, а не абстрактного действия). Платим за это, ясно дело, всем тем, что отличает интерпретируемый язык от компилируемого.
Так вот... что дает нам экстеншн такого кеширования, чего не мог бы дать PHP-шный класс?
 
При любом изменении данных в таблице кеш сбрасывается. А это может быть не всегда желательно. Об этом ведь уже говорили.
аргументы о "топ10 модеров" ? ;) я предложил там решение, вы на него не ответили, это во-первых ;)
во-вторых: как часто будут запрашиваться эти данные и насколько процесс получения этих данных ресурсоёмок? а может не нужно кеширование вообще?

-~{}~ 07.01.08 22:02:

Так вот... что дает нам экстеншн такого кеширования, чего не мог бы дать PHP-шный класс?
сейчас тебе аргументом будет приведена "скорость". и в качестве примера - будут приведены относительная разница времени выполнения пхп vs ext (которая, вероятно, будет составлять 1-2 порядка). в то время, как абсолютная разница - незначительна ;) (но это не наш метод, угу ;))))))) )

-~{}~ 07.01.08 22:16:

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

сейчас тебе аргументом будет приведена "скорость". и в качестве примера - будут приведены относительная разница времени выполнения пхп vs ext (которая, вероятно, будет составлять 1-2 порядка). в то время, как абсолютная разница - незначительна ;) (но это не наш метод, угу ;))))))) )
Не очень понятно, о чем ты?.. :)

Автор оригинала: zerkms
кстати вспомнилось вот
аналогичный функционал можно реализовать и с помощью mysql proxy
Как я понимаю, суть модуля - сверхбыстрый, очень простой и компактный модуль для решения очень конкретной и довольно несложной задачи "малой кровью".

-~{}~ 07.01.08 15:28:

Alexandre

Честно говоря не понял, зачем в коде появились такие функции, как

int str_creplace(char* in , char * out, char* old, char * new, int new_len );
int str_replace(char* in , char * out, char* old, int old_len, char * new );

Последние 2 года я писал только на C++, поэтому код кажется куцым :)

То, что ты сделал работоспособные ext - это очень круто. Я честно, сказать, уже давно собирался, но все никак не решался... Теперь есть, с кем посоветоваться :))
 
Не очень понятно, о чем ты?..
как раз о том, что:
Как я понимаю, суть модуля - сверхбыстрый, очень простой и компактный модуль для решения очень конкретной и довольно несложной задачи "малой кровью".
ты можешь привести разницу производительности между реализацией на пхп и ext? :)
 
Автор оригинала: MiksIr
zerkms, ну, кстати, интересно даже и сферического коня в вакууме померять, ибо есть подозрение, что не будет там даже одного порядка, не то что двух.
С чего ты решил???

Вот я, например, имею сравнительные цифры C++ vs PHP 4. С++ собран с -O3. 2-3 порядка на простейших задачах. PHP с тех пор еще подрос, я имею в виду интерпретатор, да еще и добавились классы, причем опять-таки не компилируемые.

А вот цифры с модулем - интересно бы увидеть.
 
Вот я, например, имею сравнительные цифры C++ vs PHP 4. С++ собран с -O3. 2-3 порядка на простейших задачах. PHP с тех пор еще подрос, я имею в виду интерпретатор, да еще и добавились классы, причем опять-таки не компилируемые.
о чём, собственно, я и говорил. относительные величины ;)
очень напоминает вот это вот (там правда относительные величины, но смысл тот же - демонстрация псевдо-огромной разницы):
http://www.leadtek.com.tw/eng/3d_graphic/image/winfast_px9900_gt_1.jpg
(с) http://phorror.livejournal.com/49473.html#cutid1
 
Автор оригинала: zerkms
как раз о том, что:

ты можешь привести разницу производительности между реализацией на пхп и ext? :)
Есть такой DBAL ADOdb. Он есть в PHP варианте и в ext варианте. Замена PHP расширением дает выигрыш в скорости до 100%. Никаких двух порядков там нет.
Хотя, конечно, цифры относительны и для кеша запросов они могут быть другими.
 
FractalizeR
заметь, кстати, что adodb будет куда посложнее сабжа. по крайней мере мне так кажется ;)
 
zerkms

Ммм.... соотношение скорости PHP class/ext будет ОЧЕНЬ сильно зависеть не от "сложности модуля" :) а от внутренней начинки. Как все понимают, вызов функции через C-API в ext, например mysql_connect() и тот же самый вызов через PHP-функцию примерно соизмерим по скорости, поскольку тут просто классический враппер. Но вот если мы переносим в методы много логики, например, циклы, работу со строками, условия и т.п. - тогда уж извините, собранное с оптимизацией, это всяк побыстрее будет работать, чем в виде PHP-кода.

Кстати, что-то мы отвлеклись от темы.
 
Ммм.... соотношение скорости PHP class/ext будет ОЧЕНЬ сильно зависеть не от "сложности модуля" а от внутренней начинки. Как все понимают, вызов функции через C-API в ext, например mysql_connect() и тот же самый вызов через PHP-функцию примерно соизмерим по скорости, поскольку тут просто классический враппер. Но вот если мы переносим в методы много логики, например, циклы, работу со строками, условия и т.п. - тогда уж извините, собранное с оптимизацией, это всяк побыстрее будет работать, чем в виде PHP-кода.
и? алгоритмическая сложность?
я сказал что-то другое? ;)
 
int str_creplace(char* in , char * out, char* old, char * new, int new_len );
int str_replace(char* in , char * out, char* old, int old_len, char * new );
да, можно было и одной функцией... просто одну я взял из своего другого проекта... а дорабатывать - оказалось проще написать вторую. покурю в сторону кода.

я не хочу много флеймить на тему "обоснованности экстеншена". Просто приведу аналогию: фишеровский блитц. zerkms, как ты думаешь, зачем он, довольно таки тривиальное решение, которое на пхп пишется максимум 4 часа - собрал в ввиде экстеншена?

что касается функционала - у меня в апи забит метод FetchAll(). его использование действительно даст прирост в скорости, так как, показывает профилирование, много ресурсов теряется на вызов внутреннего АПИ, т.е. если это сделать внутренним циклом, то действительно выииграем.

второе предложение, которое выдвинул fixxxer, - это сделать метод skip() или нечто подобное( fetchFrame( $top, $limit ) ).
у меня были мысли на этот счет, в другом проекте именно так и сделано.

Применение: мы делаем выборкуу по некоторой группе товаров, вывод которой не укладывается на одной странице. В этом случае - кеширование данной выборки и отдача кеша по частям довольно-таки съэкономит нам на обращениях к БД. Правда, если файл не мегабайтный будет ;)

Ну и наверно, чтоб не было споров об инвалидации данных кеша, сделаю метод - clear(), который будет чистить кеш.
 
Просто приведу аналогию: фишеровский блитц. zerkms, как ты думаешь, зачем он, довольно таки тривиальное решение, которое на пхп пишется максимум 4 часа - собрал в ввиде экстеншена?
ты совершенно серьёзно сравниваешь свою кешировалку и блитз??? (* поперхнулся) 4 часа?? (* в шоке)

ps: ну да ладно, удаляюсь ;)))
 
Сверху