MODx и 500 000 ресурсов
Как можно проследить из моих вопросов, с разбором и записью ресурсов я разобрался :)
Распарсиваю данные, пишу их в MODx (MODx на VPS, 128 памяти выделено), получается примерно в пол миллиона результатов, которые пишутся как подресурсы в свои подрубрики, в рубриках. То есть максимум по 200 ресурсов в конечных контейнерах.
Я вписал что вопрос связан с pdoTools, но это не баг, конечно, я понимаю. Просто использую только его для вывода.
На тестовых запусках с 1-5к ресурсов была проблема, что ресурсы создавались, но как будто не прописывались в MODx, то есть в админке они как ресурсы появлялись но на фронте не выводились, а в админке у контекстного меню не появлялось пункта «просмотреть»,
Что бы решить эту проблему, дописал в конец скрипта добавления $modx->cacheManager->refresh(); и так всё заработало.
Но при полноценном запуске, когда создаются все 400-500к ресурсов, похоже что обновление кэша вешается совсем.
В серверном логе ошибок ничего нет, что к MODx бы относилось, в логе MODx 150mb вот такого:
Информация по настроке и версии PHP тут starsagram.ru/ph.php
Переписать всё на чистом php и со своими таблицами вариант крайний и не хотелось бы его касаться.
В общем прошу помощи, надеюсь подскажите направление действий.
upd. Выложу ещё как зписываются ресурсы:
Распарсиваю данные, пишу их в MODx (MODx на VPS, 128 памяти выделено), получается примерно в пол миллиона результатов, которые пишутся как подресурсы в свои подрубрики, в рубриках. То есть максимум по 200 ресурсов в конечных контейнерах.
Я вписал что вопрос связан с pdoTools, но это не баг, конечно, я понимаю. Просто использую только его для вывода.
На тестовых запусках с 1-5к ресурсов была проблема, что ресурсы создавались, но как будто не прописывались в MODx, то есть в админке они как ресурсы появлялись но на фронте не выводились, а в админке у контекстного меню не появлялось пункта «просмотреть»,
Что бы решить эту проблему, дописал в конец скрипта добавления $modx->cacheManager->refresh(); и так всё заработало.
Но при полноценном запуске, когда создаются все 400-500к ресурсов, похоже что обновление кэша вешается совсем.
В серверном логе ошибок ничего нет, что к MODx бы относилось, в логе MODx 150mb вот такого:
[2016-12-11 06:21:06] (ERROR @ /var/www/www-root/data/www/starsagram.ru/core/model/modx/modcachemanager.class.php : 100) Resource URI aktyoryi/inostrannyie-aktyoryi/camerondallas/bnxvdv9g0ym-new-video-ask-cam-link-in-bio.html already exists for resource id = 100299; skipping duplicate resource URI for resource id = 100399
[2016-12-11 06:21:06] (ERROR @ /var/www/www-root/data/www/starsagram.ru/core/model/modx/modcachemanager.class.php : 100) Resource URI aktyoryi/inostrannyie-aktyoryi/camerondallas/bnuolscgiem-happy-birthday-beautiful-ginabina77.html already exists for resource id = 100300; skipping duplicate resource URI for resource id = 100400
[2016-12-11 06:21:06] (ERROR @ /var/www/www-root/data/www/starsagram.ru/core/model/modx/modcachemanager.class.php : 100) Resource URI aktyoryi/inostrannyie-aktyoryi/camerondallas/bnr8ibuafbq-twitter-camerondallas.html already exists for resource id = 100301; skipping duplicate resource URI for resource id = 100401
[2016-12-11 06:21:06] (ERROR @ /var/www/www-root/data/www/starsagram.ru/core/model/modx/modcachemanager.class.php : 100) Resource URI aktyoryi/inostrannyie-aktyoryi/camerondallas/bnqdxagglvs-coming-soon-netflix.html already exists for resource id = 100302; skipping duplicate resource URI for resource id = 100402
[2016-12-11 06:21:06] (ERROR @ /var/www/www-root/data/www/starsagram.ru/core/model/modx/modcachemanager.class.php : 100) Resource URI aktyoryi/inostrannyie-aktyoryi/camerondallas/bnjgw91gjom-smile-(.html already exists for resource id = 100303; skipping duplicate resource URI for resource id = 100403Это же выдаёт консоль при попытке обновления кэша из админки. Информация по настроке и версии PHP тут starsagram.ru/ph.php
Переписать всё на чистом php и со своими таблицами вариант крайний и не хотелось бы его касаться.
В общем прошу помощи, надеюсь подскажите направление действий.
upd. Выложу ещё как зписываются ресурсы:
$finally = function($new_medias)use(&$insta_user,&$account){
$insta_user->saveState();
State::getInstance()->users_checked++;
State::getInstance()->save();
if(empty($new_medias))
return;
global $has_new_media;
$has_new_media = true;
global $modx;
$resource2 = $modx->getObject('modResource', ['pagetitle'=>$account['resource_name']]);
if(!$resource2){
$parent = $modx->getObject('modResource', ['id'=>$account['mainresource_id']]);
if($parent){
$resource2 = $modx->newObject('modDocument');
$resource2->set('parent',$parent->get('id'));
$resource2->set('pagetitle',$account['resource_name']);
$resource2->set('longtitle','');
$resource2->set('alias',$account['username']);
$resource2->set('description',$account['mainresource_descr']);
$resource2->set('template', Settings::$template2);
$resource2->set('published','1');
$resource2->set('isfolder','1');
$resource2->setContent('');
$resource2->save();
$resource2->setTVValue('akaunt', $account['username']);
}
}
if($resource2){
$resource2->setTVValue('avatar', $new_medias[0]->avatar);
foreach($new_medias as $new_media){
$resource3 = $modx->newObject('modDocument');
$resource3->set('parent',$resource2->get('id'));
$caption = '';
if($new_media->caption){
$caption = Utils::removeEmoji(trim($caption));
}
if(!$caption)
$caption = 'Запись от '.date('Y-m-d');
if(mb_strlen($caption, 'utf8mb4')>100)
$caption = mb_substr ($caption, 0, 100);
if(preg_match('#/([^/]+)/?$#sui',$new_media->link,$matches)){
$resource3->set('alias',$matches[1]."-".$caption);
}
$resource3->set('pagetitle',$caption);
$resource3->set('longtitle','');
$resource3->set('description','');
$resource3->set('template', Settings::$template3);
$resource3->set('published','1');
$resource3->setContent($content);
$resource3->save();
$resource3->setTVValue('akaunt', $account['username']);
$resource3->setTVValue('avatar', $new_medias[0]->avatar);
}
}
};
ну и после отработки всех циклов записи
$modx->cacheManager->refresh(); Комментарии: 30
Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.
Кстати на каком моменте они дублируются, я так и не нашёл. Но это вообще не должно мешать обновлению кеша, он видимо не обновляется из за общего количества ресурсов.
Скажите, стандартные механизмы MODx в принципе не рассчитаны на такую нагрузку и надо делать свою таблицу, свои выборки т.п. или дело в чём то другом?
Но про свой компонент я понял… но не скоро осилю видимо.
Или локально? Конфигурация ПО совпадает?
Отключаю дружественные урл, наполняю бд и оно работает. Иду, включаю д.урл и всё, админка падает, ошибки такие:
Получается что механизм кеширования не может прожевать такое количество ресурсов?
Что делать, отказаться от д.урл? Может я в скрипте как то не так новые ресурсы создаю?
Fi1osofНо если включить чпу то всё упадёт, выключить уже не получится. Скажите пожалуйста, ваш модифицированный код в методе modContext_mysql::getResourceCacheMapStmt() из примра, может решить эту проблему?
И что ещё можно сделать с оптимизацией этого всего, что бы так не грузить сильно сервер?
Fi1osofFi1osofРазница в том, что ресурсы нужны для разделов сайта, служебных страниц и всего такого. Если же сайт продаёт полмиллиона товаров или содержит объявления — нужно это выносить в отдельные таблицы, с нужными колонками и индексами.
Например, вот я делал vrmedia.tv. Ресурсов в дереве там меньше 50, а фоторепортажей и картинок многие тысячи. Всё летает, лайкается, добавляется в избранное — и хранится в отдельных таблицах.
В таком направлении и нужно двигаться, используя MODX как удобную обёртку для своих данных.
У меня на 200 000+ ресурсах такая же проблема была. Пришлось разбить на несколько (у меня 7) таблиц по разделам. По сути поля могут в точности повторять поле из таблицы modx_site_content.
Создай столько таблиц, сколько у тебя крупных разделов (например modx_site_content_1 и т.д.). И расфасовывай уже страницы по этим таблицам в зависимости от раздела.
Дальше можешь воспользоваться компонентом VirtualPage, чтобы создать в этих разделах отдельные адреса страниц. Выборку можешь сделать по конкретно взятой таблице категории через простой PHP, например:
Если же нужна пагинация и все дела, то сделай на основе этих таблиц с помощью UICMPGenerator модели и подключай свой класс таблицы в pdoPage.
И при таком раскладе Василий правду сказал — у тебя в админке останутся только ресурсы категорий (по ним сможешь делать менюшки на pdoMenu и т.д.
Также скорее всего прийдётся создать несколько отдельных страниц с XML-картами этих разделов и скормить их robots.txt и Яндексу.
А в своей таблице могут быть и миллионы записей — тут уже ограничения могут быть только у MySQL, а не сайта.
Разные таблицы нужны только для разных сущностей. Например, фоторепортажи и лайки для них — 2 разные таблицы, а распихивать 200 000 фоторепортажей по 7 таблицам бессмысленно.
Мне кажется оба варианта имеют право на жизнь и оба решают основную проблему — разгрузку основной таблицы modx_site_content…
P.S. Правда и таблицы у меня были с огромным количеством полей и информации (намного больше чем у родной таблицы) — это тоже могло повлиять на вес таблицы и на тормоза при выборке.
У меня прямо сейчас есть внутренний сайт организации с миллионами строк в таблицах — и всё хорошо работает.
Правильная организация базы данных — целая наука, этому годами учатся. Но, это уже лирика, я просто высказался против нескольких одинаковых таблиц.
Возьму их на вооружение на будущее!