Модуль работающий через cron?

[costas]

Собственно разыскивается сабж (любая версия магазина), смысл следующий, sitemap встроенный в ocStore v0.2.2 работает медленно, имеем магазин на слабом хостинге, нуменклатура в 1тыс (будет 18тыс), сейчас модуль кое как работает, но по факту это кое как умрёт на 3тыс+, переписали модуль, вернее навояли другой который делает всё быстро и складывает сразу sitemap в корень.

Идея запустить это дело через cron.

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

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

[freelancer]

сейчас не вижу сложности..

либо вызывать wget с адресом к модулю,

либо cli скрипт

[costas]

сейчас не вижу сложности..

либо вызывать wget с адресом к модулю,

либо cli скрипт

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

[freelancer]

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

под доп протоколом http подразумевается?

cli: php -f имя файла

[rb2]

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

А крон - не доп. внешний сервис? :)

Действительно непонятно, что именно смущает. Wget/curl/php из крона - вполне обычные способы. Более того - по-моему, единственные. Если, конечно, не эмулировать крон в index.php и зависеть при этом от посетителей.

[costas]

А крон - не доп. внешний сервис? :)

Действительно непонятно, что именно смущает. Wget/curl/php из крона - вполне обычные способы. Более того - по-моему, единственные. Если, конечно, не эмулировать крон в index.php и зависеть при этом от посетителей.

стандартно

cd $HOME/папка_сайта.ru/docs/tools/ && /opt/php/bin/php -c $HOME/etc/php.ini $HOME/папка_сайта.ru/docs/tools/имя_скрипта.php

как раз для этого нужен скрипт в составе движка т.е. в виде модуля.

wget, curl - это решения зависящие от работы web-сервера со всеми вытекающими, соответственно скрипт (модуль) должен работать как обчный модуль но не через web.

Написать костыль в виде скрипта который самостоятельно лезет в базу без использования классов/библиотек/etc. и настроек магазина не проблема, но это и будет костыль, а костыль как раз не нужен.

[rb2]

На это freelancer ответил в #2: тогда CLI. Без внешнего допиливания не получится - не планировалось в опенкарт работать с модулями и всей остальнй кухни мимо index.php. Поэтому переписывайте, подключайте все необходимые для работы потроха опенкарта, чтобы можно было использовать скрипт из CLI, если предусмотренный реализованный путь не устраивает. Wget/curl - просто способы сделать это быстро (вызвать нужную функцию, находясь поверх всего фундамента). Не устраивают - надо писать CLI обвязку рядом с index.php. В этом нет ничего сложного, просто желание про "т.е. в виде модуля" изначально неправильно поставлено. Хотите модуль - пользуйтесь wget/curl. Хотите без них - ваяйте достаточный фундамент опенкарт в своём скрипте, если понадобится.

[afwollis]

везде, где надо было делать нечто подобное, вставлял базовые необходимые классы в свой скрипт, который потом запускался через cron МИМО движка (cli).

работает, есть не просит, багов не выдает.

если у вас нечто лежит в web-root директории и вызывается через wget/curl, то вы рискуете получить незапланированный вызов - в случае, если кто-нибудь узнает, что и где у вас лежит.

поэтому такие скрипты обычно располагаются в директориях, не доступных по http.

[costas]

везде, где надо было делать нечто подобное, вставлял базовые необходимые классы в свой скрипт, который потом запускался через cron МИМО движка (cli).

работает, есть не просит, багов не выдает.

если у вас нечто лежит в web-root директории и вызывается через wget/curl, то вы рискуете получить незапланированный вызов - в случае, если кто-нибудь узнает, что и где у вас лежит.

поэтому такие скрипты обычно располагаются в директориях, не доступных по http.

Поздновато ответили ну и на том спасибо, уже сделал обвязку, работает через cli, берёт все настройки с магазина, осталось тока прикрутить сам модуль... :rolleyes:

[freelancer]

если у вас нечто лежит в web-root директории и вызывается через wget/curl, то вы рискуете получить незапланированный вызов - в случае, если кто-нибудь узнает, что и где у вас лежит.

поэтому такие скрипты обычно располагаются в директориях, не доступных по http.

да, безусловно защиту сделать стоит.

мне кажется автор сам не знает чего хочет.

"пойди туда не знаю куда, принеси то не знаю что"

[costas]

да, безусловно защиту сделать стоит.

мне кажется автор сам не знает чего хочет.

"пойди туда не знаю куда, принеси то не знаю что"

Всё мы знаем, уже всё разгребли, просто думал что есть готовые решения, пришлось поковырять движку магазина.

На счёт защиты да, вынос скрипта за пределы web-root предусмотрели, вроде всё работает...

[freelancer]

Всё мы знаем, уже всё разгребли, просто думал что есть готовые решения, пришлось поковырять движку магазина.

На счёт защиты да, вынос скрипта за пределы web-root предусмотрели, вроде всё работает...

так поделитесь решением

[costas]

так поделитесь решением

В sitemap-cli.php вот это поменять на свой путь до root-магазина

define('OPENCART_ROOT_DIR', '/home/user/www/Ваш_Сайт/docs/');

работает через cli и http/https.

З.Ы отдельно ещё можно прикрутить через админку приоритеты, выборку на генерацию, частоту обновления... но как то не потребовалось

sitemap_cli.tar.gz

[Yesvik]

А по какой причине сдыхает на 3тыс+ ?

И какое максимальное время генерации считаеш приемлемым?

[costas]

А по какой причине сдыхает на 3тыс+ ?

И какое максимальное время генерации считаеш приемлемым?

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

[rb2]

costas, а можно какие-то конкретные цифры озвучить? Может ограничения памяти у хостера известны на этом тарифе или потребление памяти и время исполнения скрипта измерялось. Я ничего не имею против решения отдавать статику, но количество товаров в 1-3 тысячи не кажутся серьёзной нагрузкой. Если эта проблема действительно существует, а не только проблемы вашего хостера, хотелось бы узнать о ней заранее (и сравнить со своими цифрами, когда ближе к 1 тысяче товаров подберемся; ну или нагенерировать у себя эти 1-3 тысячи).

[costas]

costas, а можно какие-то конкретные цифры озвучить? Может ограничения памяти у хостера известны на этом тарифе или потребление памяти и время исполнения скрипта измерялось. Я ничего не имею против решения отдавать статику, но количество товаров в 1-3 тысячи не кажутся серьёзной нагрузкой. Если эта проблема действительно существует, а не только проблемы вашего хостера, хотелось бы узнать о ней заранее (и сравнить со своими цифрами, когда ближе к 1 тысяче товаров подберемся; ну или нагенерировать у себя эти 1-3 тысячи).

Хостинг на nic, не знаю что там в качестве виртуализации используется (судя по конфе jail), сервер, на котором магазин, работаете на пределе, ночью казалось бы когда рунет спит свободной памяти в районе 500мб, загрузка проц 10-15%, и LA 2.5 в среднем, ну а кил форка apacha за недостатком памяти это вообще нормальное явление, на 1к пока вывозит, ну а дальше будем искать хостинг...

З.Ы. тарифы там обычные, как на шаред-хостинг, гарантированных RAM/CPU и вообще каких либо limits нет.

Изначально стоял opencart v1.5.0.5, вообще не ворочилось, мигрировли на ocStore 0.2.2.

[Yesvik]

З.Ы. тарифы там обычные, как на шаред-хостинг, гарантированных RAM/CPU и вообще каких либо limits нет.

Изначально стоял opencart v1.5.0.5, вообще не ворочилось, мигрировли на ocStore 0.2.2.

Лимиты там как раз есть... по крайней мере по памяти режут как дети в школу...

Но ты так и не озвучил цифры...

Сколько категорий, сколько уровней, сколько товаров...

Небольшой разбор полётов:

Про штатный генератор я вообще молчу... но и тот что ты используеш не фонтан...

Вот это полное безобразие

    	private function getCategoryPath($category_id = 0, $path = '') {
            	$query = $this->db->query("SELECT c.parent_id FROM " . DB_PREFIX . "category c WHERE c.category_id = '" . (int) $category_id . "'");
            	if ($query->rows) {
                    	foreach ($query->rows as $category) {
                            	if ($category['parent_id'] != 0) {
                                    	$path = $this->getCategoryPath($category['parent_id'], $path);
                            	} else {
                                    	return $category_id;
                            	}
                    	}
            	}
            	return $path . '_' . $category_id;
    	}

Давай считать...

Если у тебя 18000 товаров равномерно распределены примерно по 100 товаров в категории - тогда у тебя должно быть порядка 180 категорий.

Не будем рассматривать кошмарные сценарии с каталогами в 10-15 уровней и будем считать что у тебя категории построены в три уровня и равномерно распределены примерно так:

Первый уровень 5 категорий, каждая категория первого уровня содержит 5 категорий второго уровня и аналогично категории второго уровня содержат по 5 категорий третьего уровня...

Получается 5 + 5*5 + 5*5*5 = 155 категорий... это меньше 180 но так считать проще.

Алгоритм который я привёл из твоего генератора сделает 5 запросов на первом уровне, 50 на втором уровне и 375 на третьем уровне... Итого: 430 запросов - и это на трёх уровнях. У меня на 1000 категорий до 12 уровней этот алгоритм дал около 8500 запросов

Всё тоже самое можно сделать одним запросом...

На тестовой базе в 1000 категорий, 12 уровней, 10 000 товаров - алгоритмы из твоего генератора на шаред хостинге не смогли вывести даже категории.

Переписал формирование категорий и товаров, изменил таблицу с алиасами и сайтмэп начал сносно генерится.

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

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

[costas]

Лимиты там как раз есть... по крайней мере по памяти режут как дети в школу...

Но ты так и не озвучил цифры...

Сколько категорий, сколько уровней, сколько товаров...

Небольшой разбор полётов:

Про штатный генератор я вообще молчу... но и тот что ты используеш не фонтан...

Вот это полное безобразие

    	private function getCategoryPath($category_id = 0, $path = '') {
            	$query = $this->db->query("SELECT c.parent_id FROM " . DB_PREFIX . "category c WHERE c.category_id = '" . (int) $category_id . "'");
            	if ($query->rows) {
                    	foreach ($query->rows as $category) {
                            	if ($category['parent_id'] != 0) {
                                    	$path = $this->getCategoryPath($category['parent_id'], $path);
                            	} else {
                                    	return $category_id;
                            	}
                    	}
            	}
            	return $path . '_' . $category_id;
    	}

Давай считать...

Если у тебя 18000 товаров равномерно распределены примерно по 100 товаров в категории - тогда у тебя должно быть порядка 180 категорий.

Не будем рассматривать кошмарные сценарии с каталогами в 10-15 уровней и будем считать что у тебя категории построены в три уровня и равномерно распределены примерно так:

Первый уровень 5 категорий, каждая категория первого уровня содержит 5 категорий второго уровня и аналогично категории второго уровня содержат по 5 категорий третьего уровня...

Получается 5 + 5*5 + 5*5*5 = 155 категорий... это меньше 180 но так считать проще.

Алгоритм который я привёл из твоего генератора сделает 5 запросов на первом уровне, 50 на втором уровне и 375 на третьем уровне... Итого: 430 запросов - и это на трёх уровнях. У меня на 1000 категорий до 12 уровней этот алгоритм дал около 8500 запросов

Всё тоже самое можно сделать одним запросом...

На тестовой базе в 1000 категорий, 12 уровней, 10 000 товаров - алгоритмы из твоего генератора на шаред хостинге не смогли вывести даже категории.

Переписал формирование категорий и товаров, изменил таблицу с алиасами и сайтмэп начал сносно генерится.

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

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

Про рекурсии нет вопросов, это и так понятно, изменять код самого магазина относится к кастомизации без возможности дальнейшего клонирования, это вот к этому:

Переписал формирование категорий и товаров, изменил таблицу с алиасами

, думаем пока.

Относительно формирования товаров - используется seo_tool из поставки магазина, очивидно, что правка кода отвечающего ЧПУ не приведёт к правке sitemap, остальные модели смысла нет использовать, потому, что там везде запросы вида "SELECT * FROM" в то время когда требуется всего одно поле в результирующем наборе (очевидное зло и всё те же клещи).

Заглянул в контроллер и модель категорий - там решение то же самое, та же самая рекурсия, предполагаю что на 180 категориях и 18 тыс товаров может быть всё не очень хорошо. Про решение никто не говорил и почему оно не попало в релиз об этом история умалчивает.

При текущей структуре таблицы единственный верный вариант это хранимая процедура с той же рекурсией, но она себя то же в конечном счёте не оправдает.

Сейчас 1000 позиций и 22 категории, ничего сверх естественного нет, будет рост до 18тыс, тогда уже будем смотреть.

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

Речь в конечном итоге идёт о модуле, а не о частной кастомизации (к которой придётся в конечном итоге прийти путём изменения структуры БД и кода или сменой движка)...

[rb2]

Про рекурсии нет вопросов, это и так понятно, изменять код самого магазина относится к кастомизации без возможности дальнейшего клонирования

...

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

Речь в конечном итоге идёт о модуле, а не о частной кастомизации (к которой придётся в конечном итоге прийти путём изменения структуры БД и кода или сменой движка)...

Ну вообще-то не факт. Отдавайте свои решения и мелкие правки "SELECT *" в гуглокод SVN blueyon-у и qphoria, и они попадут в Опенкарт на радость всем. В т.ч. желающим менее болезненно обновляться.

[costas]

Ну вообще-то не факт. Отдавайте свои решения и мелкие правки "SELECT *" в гуглокод SVN blueyon-у и qphoria, и они попадут в Опенкарт на радость всем. В т.ч. желающим менее болезненно обновляться.

Не совсем понял, что Вы хотели этим сказать, в чём смысл тогда ocStore если коммиты делать в оригинальную версию, просто из всего диалога этой темы складывается впечатление, что "не надо ничего писать ибо код плохой, мы знаем как луче но никому не скажем, а если хотите счастья идите на ... opencart.com"... бессмысленно, печально.

[rb2]

То ли я не понимаю, как у людей мыслительный аппарат работает, то ли как писать по-русски понятно.

Я сказал, что не надо полезные правки в себе держать - отдавайте их не в воздух (на форуме с сотней активных пользователей), а прицельно - сразу авторам Опенкарт. Желательно оригинального, потому что изменения в ocStrore всё равно потом оттуда берутся. Так пусть исправленные рекурсии и лишние выборки в селектах сразу попадают в оригинал, чтобы потом их не сопровождать в своих локальных версиях и сборках, а с меньшим количеством проблем обновляться.

Несовершенство Опенкарта - преимущество для разработчиков и сообщества вокруг движка, имеющих возможность продавать свои улучшения. Если они раздаются бесплатно и от их включения в ядро движка все только облегченно взохнут, то я не вижу смысла их не отдавать Даниэлю и Qphoria (автору vqmod), которые коммитят в опенкарт на гуглокоде. Патчи и исправления они принимают. Так что вам их отдавать туда мешает лень или гордость. Не знаю. Технически всё довольно просто.

[Yesvik]

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

Ерунда полная. Большинство дополнений не улучшает код, а расширяют функционал... при этом эти расширения функционала сами требуют улучшений кода...

Патчи и исправления они принимают. Так что вам их отдавать туда мешает лень или гордость. Не знаю. Технически всё довольно просто.

Похоже ты не отдавал код... и не наблюдал как у них межу собой идёт срач... один включает, другой удаляет...

И на этом форуме и на opencart.com периодически появляются интересные решения, возьми какое-то решение и попробуй продавить его в SVN.

Когда сделаеш это - будеш писать про гордость и о том что это просто...

[rb2]

Отдавал несколько раз мелкие исправления. 1-2 отклонили, остальное молча включили.

[costas]

Ерунда полная. Большинство дополнений не улучшает код, а расширяют функционал... при этом эти расширения функционала сами требуют улучшений кода...

Похоже ты не отдавал код... и не наблюдал как у них межу собой идёт срач... один включает, другой удаляет...

И на этом форуме и на opencart.com периодически появляются интересные решения, возьми какое-то решение и попробуй продавить его в SVN.

Когда сделаеш это - будеш писать про гордость и о том что это просто...

+1

с коммитами на оффе всё печально, да это и по коду заметно...