Это не модуль, это такой наколеночный скрипт на перле (а не на php).

Очень сложно посчитать правильно.

Реально я начал фтыкать, смотреть модули для переезда, смотреть все эти видео про Migrate - второго января.
"Постановка задачи" - исчисление URL, разделов и все такое - было третьего.

6-го вечером у меня один из блогов (twitter.lexa.ru) уже работал на новом движке в бою, 7-го вечером - второй.

Но это все - далеко не полные дни. Реально я на все тратил часа 4 вечером и урывками утром-днем, каникулы, у няни тоже каникулы, надо детей пасти...

Но порядок величины именно такой - 4-5 дней.

У меня да, только что попробовал.

Не говоря о ругани
Вы используете маркер [catpath], у которого есть парный -raw маркер [catpath-raw]. Для шаблонов Автосинонима следует использовать -raw версии маркеров, если вы не полностью уверены в том, что делаете

Но если бы работало - я бы ругань перетерпел

Ну так раскройте секрет, как настроить то?

Потому что патч может меняться, апдейтить его в куче мест - у меня нет сил

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

Stalker-g2 wrote:

и ещё раз - никаких проблем с производительностью записи _нет_и_не_будет_ для вёб-проектов именно в силу их специфики.

Ага-ага, шардинг придумали т.к. заняться было нечем. Идите, расскажите это Мамбе.

<a href="mailto:andypost@drupal.org">andypost@drupal.org</a> wrote:

А я вот особой разницы не вижу - чем простой запрос 1й записи из базы по индексу хуже такого же в memcache?

Есть наилучший случай, обычный и наихудший. Наилучший - query cache, разница только в том, что запрос надо попарсить ну и библиотеки клиентские потяжелее.

<a href="mailto:andypost@drupal.org">andypost@drupal.org</a> wrote:

<a href="mailto:andypost@drupal.org">andypost@drupal.org</a> wrote:

Илья, специально для того, чтобы кеш не сбрасывался при каждом посте, коих может быть много и часто - есть настройка "Минимальное время жизни кеша" ставишь пол часа и все твои очистки обламываются - гугл и яша получают как и анонимы из кеша!

<a href="mailto:andypost@drupal.org">andypost@drupal.org</a> wrote:

Версионность данных в кеше - считаю излишней, хотя для версионности узлов может быть полезна.
Логика такая сделана умышленно - для скорости! Приоритет за удалением, те если я сотру запись после того, как другой процесс обновит\запишет ничего страшного, ибо следующее обращение запишет или добавит!

Знаешь анекдот про то, что неровное висение - неаккуратненько.

Ilya1st wrote:

flock() никто не отменял. да и расширение PHP для блокировок если припрет пишется за пару дней. я в своих решениях flock() пока отбиваюсь.

Блокировка на файлах - это 19-й век. В 21-м есть atomic cmp and set, 7 ассемблерных инструкций без контекст-свитча

<a href="mailto:andypost@drupal.org">andypost@drupal.org</a> wrote:

По поводу flush_prefix - просто не представляю, как его хакать и как эти изменения потом включить в поставку.

Ну, народ его как-то улучшает и результат сабмитит, в nginx-ru такие тусуются.
А хакать просто - там же где-то обязан быть индекс, вот по нему пробежаться и удавить все,

Ilya1st wrote:

я обхожусь самописом на файлах
еще. с друпалом 200-500 select на страницу- норма. и логику промежуточного кеширования продумать - почти невозможно. там есть нюансы - ты не всегда знаешь четко, ЧТО надо из хранилища сбросить... увы.

<a href="mailto:andypost@drupal.org">andypost@drupal.org</a> wrote:

Основная проблема это чистка кеша по маске - очень остро стоит в мемкеш, посему приходится ставить вариант shared=false (делать flush для всего кеша, и под каждую таблицу кеша свой инстанс)

ps: по кешроутеру вообще стоит поднять отдельно тему, похоже мэйнтейнер приостановил работы над всеми своими проектами.

Stalker-g2 wrote:

учитывая, что кэш восстановится после следующего чтения. да я и вообще не понимаю, о чём тут спорить. mysql всяко быстрее с query cache. любой тест покажет. и вы сами с этим соглашались

Да в тестах - конечно быстрее, где вы видели нормальный read-write тест.

<a href="mailto:andypost@drupal.org">andypost@drupal.org</a> wrote:

А разве возможна универсальная система кеширования?
[module=cache_router] всего лишь обертка для перенаправления запросов к кешу в нужные разработчику бэки

Stalker-g2 wrote:

неа. совершенно неверно. отрисовка ЧАСТИ любой другой страницы будет не из кэша. так что драматизировать ситуацию не надо. комментарии хранятся в отдельной таблице. кроме того, вы постоянно упускаете про число запросов на чтение - 80%. Это значит, что на 1 ваш комментарий, который приводит к перегенерации ЧАСТИ страницы, приходится, вообще говоря, 4 чтения этой страницы, 2-3 которых отлично берутся из кэша. это весомо.

Stalker-g2 wrote:

однако в случае, когда запросов на чтение 70-85% это самое выше выбивание кэша опять-таки большого значения не имеет-слишком много чисто чтения потом.

Pilat wrote:

Alex Tutubalin wrote:

А транзакции - ну можно привинтить в обработке постингов (вроде больше нигде не надо), но неужто часто целостность нарушается?

Quote:

нет, сам автор честно заметил, что на чтении работает медленнее. а для вёб-проектов запросы на чтение(по крайней мере у меня на серверах) составляют 70-85%

Конкретный watchdog можно легко полечить, дописав туда ::varchar(16) в запрос, вставляющий в таблицу в нужное место.

Pilat wrote:

Было бы возможно использовать транзакции - перейти смысл был бы. А так - есть ли смысл переходить на Postgres, ведь Drupal не заморачивается с транзакциями, а без них mysql быстрее и распространённее. Вообще интересно, чем вызвано желание перейти?

axel wrote:

Мейби некоторая популяризация постгреса в друпаловской среде заставит разработчиков тестировать модули под постгрес также.

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