1. Желательно цитировать или как-то указывать ту область статьи, на которую пишется возражение или вопрос. К примеру вот это мне вообще не понятно к какому месту относится: 1. Зачем случайное число и куча рекурсивных проходов вверх по дереву, если пары alias+id (который unique primary key)и проверки по одному полю в таблице с индексом в нужном месте вполне хватило бы закрыть эту проблему. И где этот PK alias+id и где я зачем-то по дереву вверх поднимаюсь? Печально, если нет :) Если бы у меня здесь были проблемы, я бы использовал этот метод. А если проблемы не было, то и париться мне не за чем было. В консоли ограничений на выполнение php точно нет. Не верное утверждение. Где-то нет, а где-то и есть. на том же таймвебе есть и консольные ограничения, и за 5 секунд потребления процессора более чем на 60% приводит к обрыву процесса. 3. Это скорее болезнь самого modx и его системы кеширования. Особо не придумать ничего. Разве то итемы каталога держать не в ресурсах Там полно вариантов что можно придумать, начиная от простой заплатки cacheOptimizer, и заканчивая этим решением. 4. Стандартные решения удобны тем, что просты и понятны. Но на таких объемах я бы подумал о подключении какого-нибудь sphinx или провел бы серьезную денормализацию данных и возможно что-то положил бы в какой-нибудь redis или mongo или что там сейчас можно Всегда надо держать грань между производительностью и простотой (для простоты сопровождения). Если скорость устраивает, то зачем еще усложнять? Усложнение будет задирать планку на специалистов для сопровождения. P.S. этот проект не на миллионы уников, так что сейчас мы не будем привлекать сюда все мощнейшие технологии. Мощнейшие проекты занимают не мало времени и как правило требуют участия группы программистов. А я это сделал за 2 дня. Так что здесь исходим из бюджетов и потребностей.

Спасибо, понял. в php же в функциях область видимости — локальная, и если нужна глобальная видимость переменной, то необходимо использовать global для этой переменной, к примеру global $modx это я знаю, все-таки php не очень далеко в этом от с++ ушел :) Кстати, раз списались… мы говорили по поводу передачи наборов параметров в процессоры. я дописал код в твои функции, в песочнице топик

Пожалуйста! По поводу нотиса: там действительно косяк. В процессорах внутри функций нет переменной $modx. Есть только $this->modx. То есть правильный кот вот такой (сейчас поправлю в топике): public function getMenuItems(){ $items = array();

$startId = $this->getProperty('startId');
$level = $this->getProperty('level');
$cacheable = $this->getProperty('cacheable');
$id = $this->getProperty('id', 'menu');
$cacheKey = $this->modx->context->key."/{$id}/{$startId}";

if($cacheable){
    if($fromCache = $this->modx->cacheManager->get($cacheKey)){
        return $fromCache;
    }
}
    
//else
if($items = $this->getItems($startId, $level)){
    if($cacheable){
        $this->modx->cacheManager->set($cacheKey, $items);
    }
}

return $items;

} Как видишь, переменные $id и $startId тоже внутри этой функции объявляются. Так что смотри, чтобы все переменные были объявлены внутри функции (в php же в функциях область видимости — локальная, и если нужна глобальная видимость переменной, то необходимо использовать global для этой переменной, к примеру global $modx). Спасибо за багрепорт!

  1. Зачем случайное число и куча рекурсивных проходов вверх по дереву, если пары alias+id (который unique primary key)и проверки по одному полю в таблице с индексом в нужном месте вполне хватило бы закрыть эту проблему.
  2. Кроме времени еще важна и память. На клауде можно не боятся, но на хостинге процесс могут затоптать за оверхед по памяти. 5000 тыс конечно не число, но я бы предусмотрел бы какое-нибудь порционное скармливание данных по чуть-чуть. Не знаю наверняка, но скорее всего так оно и есть. Печально, если нет :) Ну и запускать такое нужно не через веб-морду. В консоли ограничений на выполнение php точно нет.
  3. Это скорее болезнь самого modx и его системы кеширования. Особо не придумать ничего. Разве то итемы каталога держать не в ресурсах
  4. Стандартные решения удобны тем, что просты и понятны. Но на таких объемах я бы подумал о подключении какого-нибудь sphinx или провел бы серьезную денормализацию данных и возможно что-то положил бы в какой-нибудь redis или mongo или что там сейчас можно. P.S. Ответы пишу не с пустой головы. Работаю сейчас с проектом, у которого под миллион уников в сутки и отдельные таблицы весят под 10 гб, не считая десятков миллионов записей в nosql-хранилищах. Это все добро конечно же не на modx, но подходы в крупных проектах все равно одни и те же.

Я прошел. smarterer.com/scores/ac422a4465a535581cf757e375a3625a ?

Спасибо за статью! Использовал процессор на сайте, все заработало сразу. Только сегодня почему-то он начал выдавать Notice: Undefined variable: modx in /home/v/v98516/v98516.bget.ru/public_html/core/site/processors/getmenu.class.php on line 58 ругается на конструкцию $cacheKey = $modx->context->key.'/{$id}/{$startId}'; Подскажи пожалуйста, что может быть? Если просто в этом месте вставляю {$modx->context->key.'/{$id}/{$startId}'} то выводит 'web' Если из процессора вывожу print_r($modx->context->key.'/{$id}/{$startId}'), то выводит '/page1/4'

Да, я согласен. Это мне вот нужен просто технический интерфейс для доступа к желаемой информации. А у кого-то совершенно другое восприятие. Ему картинки нужны, привычное расположение блоков и т.п.

Интересная статья, на самом деле, для мобильников грузить все данные как для обычных компьютеров не правильно… Да и переход на полную версию тоже желателен, у меня есть куча друзей которые тот же вк просто не воспринимают в мобильной версии.