Yoda

Ну для того зачем я все время напрягаюсь. Чтобы донести какую то культуру отношения к сообществу и немного пересечь потреблядство. Меня аж выворачивает от этого всего. Мы такие умные. Мы тут баг нашли. Как можно. Нам же теперь чтобы наживать. Надо код переписывать. А то что никто из этих персонажей для развития темы пальцем не пошевелил. Так это же пусть лохи парятся. Мы гавномодулей напишем и будет нам покушать.

1 смотрим в гит сюда: https://github.com/opencart/opencart/blob/master/upload/catalog/controller/startup/seo_url.php строка 26. Даниэль Керр знать не знает ни про какие массивы. 2. Следим за руками... // Decode URL if (isset($this->request->get['_route_'])) { $parts = explode('/', $this->request->get['_route_']); //seopro prepare route if($this->config->get('config_seo_pro')){ $parts = $this->seo_pro->prepareRoute($parts); } В контроллер seo_url попадает не параметр $_GET а строка $this->request->get['_route_'], которая в нативном классе превращается в одномерный массив $parts. Который в свою очередь в seo_pro уже обрабатывается методом baseRewrite, в котором для каждого строковой части урла, разбитого на куски через разделитель '/' ищутся соответствия, в базе, которые могут указывать на тот или иной роут, соответствующий урлу. В каком месте туда может попасть массив? 3. С каких пор opencart стал YII и в CodeStyle стало принято передавать post-get данные многомерными массивами? 4. Если вы такие умные-кричащие, где вы уже два года с вашими коммитами на GIT? 5. Даже если вы отошли от принятого CodeStyle - кто мешает вам сделать исключения для ваших поделок в код ? 6. Смотрим в сео про 1.5 public function __construct($registry) { parent::__construct($registry); $this->cache_data = $this->cache->get('seo_pro'); if (!$this->cache_data) { $query = $this->db->query("SELECT LOWER(`keyword`) as 'keyword', `query` FROM " . DB_PREFIX . "url_alias"); $this->cache_data = array(); foreach ($query->rows as $row) { $this->cache_data['keywords'][$row['keyword']] = $row['query']; $this->cache_data['queries'][$row['query']] = $row['keyword']; } $this->cache->set('seo_pro', $this->cache_data); } } Смотрим в 2.3 public function __construct($registry) { parent::__construct($registry); $this->cache_data = $this->cache->get('seo_pro'); if (!$this->cache_data) { $query = $this->db->query("SELECT LOWER(`keyword`) as 'keyword', `query` FROM " . DB_PREFIX . "url_alias ORDER BY url_alias_id"); $this->cache_data = array(); foreach ($query->rows as $row) { if (isset($this->cache_data['keywords'][$row['keyword']])){ $this->cache_data['keywords'][$row['query']] = $this->cache_data['keywords'][$row['keyword']]; continue; } $this->cache_data['keywords'][$row['keyword']] = $row['query']; $this->cache_data['queries'][$row['query']] = $row['keyword']; } $this->cache->set('seo_pro', $this->cache_data); } } Как то вы оба два не очень замечали, что здесь тоже про ваши массивы ни слова. Какая то печаль беда... Вместо того чтобы приносить пользу коммьюнити, только вопли. Стыдно господа должно быть.

Может и не только это.

КЭП. Я же не просил погуглить за меня, как базу сконвертировать. Я спрашивал нет ли готовой-рабочей.

90% да. Все остальное необходимо фиксить. Но в целом, проблем не так много как кажется. В основном более строгая типизация дат. В целом, очень много от pg уже есть в mysql8 как-то JSON поддержка, работа innodb и full-text индксов. Но остаются ништяки которых нет, это объектная модель, физическая а не бинарная репликация, вычисляемые индексы ..... ну и параллелизм. Так как по сути опенкарту никаких кроваво-энтерпрайзных технологий не требутся (да я в курсе, что pg - это opensource), а для сохранения целостности, по большому счету достаточно innodb и регулярного копирования, единственный ништяк, но очень весомый - это способность из коробки выполнять один запрос несколькими ядрами без танцев с бубном. Вот этого mysql не умеет и в ближайшее время научиться не планирует. Поэтому у меня пока что эксперимент - что дороже: воротить какое-то базовое шардирование и поднимать несколько баз, либо же ставить pg и дружить его со структурой запросов OC.

Че, как друзья товарищи, никто не пробовал сделать миграцию? Если вдруг кто делал, поделитесь дампом голой базы, все остальное у меня готово. Предвосхищая холивар - зачем? Отвечу одним словом - параллелизм.

Везде и всегда я все время всем талдычу, бекапы, бекапы, делайте бекапы. Потеря вашего бизнеса стоит намного дороже чем потраченного времени на настройку, проверку, покупку места для хранения и регулярное копирование. Произошла недавно с моим товарищем очень казусная ситуация. В сонном состоянии он удалил несколько сот тысяч товаров из базы, думая, что удаляет дубли, которые неудачно импортирровались в момент последней заливки. Со спокойной душой он пошел спать, зная что резервное копирование у нас настроено, бекап-спейс на хецнере куплен, и даже какие то резервные копии там есть. Когда же он попытался восстановить базу, оказалось, что последняя копия за месяц назад (позже выяснилось, что саппорт пытался выполнить тикет по настройке сервера, позже чем мы это сделали сами и поменял хранилище на свое собственное ограниченное по размеру). В итоге ситуация: есть актуальная база со всеми данными (заказы, категории, статьи) но без товаров, случайно есть живой тестовый сфинкс-индекс на стороннем сервере, в котором есть все актуальные данные о товарах кроме опций и совершенно случайно у меня оказался недокачанный почти актуальный дамп базы, без таблиц oc_product_to_category (видимо при экспорте я встрял в timelimit php или wait_timeout базы или в какое еще ограничение, вобщем большие базы из phpmyadmin экспортить-импортить - зло. Консоль и mysqldump - наше все). Сейчас это звучит спокойно и обнадеживающе. В момент, когда этот триллер происходил - звучало не очень. Перед глазами маячила перспектива обречь моего товарища на полную перезаливку всех его сотен тысяч товаров, что по факту откатывало его стартап на пару месяцев назад в будущее. Как мы вышли из ситуации. 1 - сохранили на всякий случай оставшуюся базу без товаров. 2 - подняли рядом мой недокачанный дамп трехдневной несвежести. 3 - убили все таблицы связанные с товарами из актуальной базы 4 - экспортировали в отдельный sql-файл эти же таблицы из моего дампа (без таблиц product_to_category, product_to_layout и product_to_store). 5 - на сервере, на котором болтался тестовый индекс сфинкса (тут просто повезло потому как таким способом мы тестировали свежеприобретенный сервер нашего товарища) сделали скрипт, который выдрал из сфинкса весь набор связей товаров с категориями, и залил его в рабочую базу. 6 - тупыми запросами создали product_to_layout и product_to_store. Благо у нас один магазин и один айди схемы товаров. И казалось бы можно радоваться все завелось. Но не тут то было. Работало ровно то, что уже было в базе а вот добавить мы не могли ни опцию, ни товар, ни атрибут.... Вопрос знатокам: почему, и как с этим бороться?

Данные пункты напрямую противоречат пункту: 6.2.3.1. Компания предоставляет публичную систему отзывов в рамках Платформы, как средства, через которые Пользователи могут делится своими мнениями публично, и Компания не контролирует и не есть цензором таких мнений. Компания обычно не расследует какие-либо отзывы, которые оставлены Пользователями на предмет их точности или надежности. И в данном случае у вас присутствует две правовых коллизии. Первая - в юридической практике нет такого понятия "по какой-либо причине", так как любая фабула действия подразумевает всегда корректный перечень оснований, для любых действий сторон, которые тем или иным образом описаны в предмете договора. Вторая - нет перечня явных и косвенных признаков, по которым тот или иной отзыв является дискриминирующим и обидным? Или по вашему называть плагиат с пруфами плагиатом, илишелл, который вы не даже сами не смогли найти шеллом - это оскорбительно или обидно? Так что артем, изучите внимательно оферту и не нарушайте обязанности компании по пункту 6.2.3.1

Подскажите, на основании какого пункта правил или публичной оферты вы будете это делать, а также укажите явно, где здесь разборки и переходы на личности?

1 - заэскейпить ввод!

Постучался несколько дней назад один уважаемый форумчанин, с просьбой посмотреть на его подопечного, которого взломали и удалили целиком весь магазин. Устали они восстанавливать все из бекапа. При этом человек, который обратился, достаточно грамотный, для того чтобы закрыть все известные публичные уязвимости, и настроить безопасность окружения. Все равно сносят магазин подчистую. Начали смотреть и обнаружили в корне вот такой интересный, и казалось бы безобидный код: <?php if (isset($_GET['name']) || isset($_POST['name'])) { header('Content-Type: image/jpeg'); header('Content-Disposition: attachment; filename="'.htmlspecialchars($_GET['name']).'"'); header('Cache-Control: no-cache'); header('Content-Transfer-Encoding: chunked'); readfile($_GET['name']); } else { echo 'Access Denied!'; } ?> Причем этот код - это часть функционала сайта, который в карточке товара с подстановкой урла изображения товара, позволял его скачать по клику на ссылку. как то типа... https://site.com/?name=https://site.com/image/some_pic.jpg Ничего казалось бы страшного, если не присмотреться ближе. Вместо some_pic.jpg достаточно было вставить ./config.php и привет пароли к базе. Реально и смех и грех. Этот код был написан лет наверное шесть назад, когда мой товарищ только-только начал заниматься сайтостроением и у него не было ни единой мысли, о том что такое уязвимости или "а что так можно было?"... Но времена меняются, хакеры не спят, и реально я наблюдаю в последнее время просто эпидемию заражений и взломов. Будьте аккуратны при написании подобных скриптов, фильтруйте данные! Всегда фильтруйте данные!

Так. Все равно непонятно. Какое отношение пейсатель сайтов имеет к продажнику, и зачем ему стресс тест по программированию, если он должен продавать?

Я наверное ничего не понимаю. Но предположим, взяли вы на работу @chukcha, а он возьми и окажись и программистом не с помойки и продажником неплохим, но продажником лучше чем программистом, вы я так понимаю собираетесь делать сайты. А сайты у вас делает @n3bo, который волочет но не очень. Вот взял продажник, напродавал так напродавал. А реализовать вы не можете... Я все к чему, зачем вам продажник со скиллом, если у вас нет прогаммиста судя по всему, который не может сформулировать требования к знаниям сейла?

Вы меня извините. Но дружища, у вас в подьезде... В таком тоне - говорите с ними. А если вы не понимаете, что у вас не быстрый магазин, а мифическое решение, которое можно реализовать бесплатно с помощью вот этого модуля: https://github.com/budgetneon/v2pagecache, то мне откровенно вас жалко. К сожалению вот из-за таких фанатов сказок как вы, которые некомпетентно хвалят бесполезные решения, многие и многие владельцы магазинов гробят свой бизнес. И если вы не профи, к чему эти "советы", это как гемморой огурцом лечить посоветовать. Тоже ведь кому-то помогает. И все таки я просил показать хотя бы 20 000 товаров в категории с фильтром - не увидел. На данный момент у нас есть проект в котором 570 000 товаров в одной категории с фильтром с 20 параметрами, с временем генерации без кеша менее полутора секунд. Как вы считаете, я тоже не профи?

Вооот. А я говорил. Сейчас будет рекламная акция волшебной мази. Как обычно сплошное введение в заблуждение. Попробую на пальцах открыть фокусы фокуснкиков: 2-3-4к товаров в категории - это не нагрузка, так как все запросы в таблицы товаров сегментированы по id категории и представляют из себя небольшой набор. Тем более у @SooR для версии 2.3 отличный фильтр который отлично переваривает за счет использования сводных таблиц подобные задачи. Это же так просто тыкнуть носом пользователя. С текстом - делай разделение. Почему то все упускают из виду, что каждый дополнительный уровень вложенности катастрофически уменьшает конверсию и ухудшает навигацию. Но как я выше писал, даже 20к товаров в категории никто не показывает, на общем количестве товаров хотя бы овер 100 к, при том что в таких сегментах, как плитка, обои, сантхеника, люстры нормальная навигация - мастхев. Что касается ддоса. Что же это за такой супер-быстрый магазин, оптимизированный, который ложится просто от нажатия f5 в браузере. Как он может держать како-то разумное минимальное количество посетителей. И самое потрясающее передергивание - это рассказывать про то что летает на "шареде". Как известно у beget под базы данных как раз на шареде стоят отдельные оооооочень мощные сервера, судя по всему с огромным количеством памяти. Это позволяет показывать одномоментные очень быстрые результаты. Но шаред он и в африке шаред. И балансировщики ресурсов не спят. Поэтому ни на одном шареде невозможно построить стабильную быструю нагруженную систему. Вобщем друзья мои, не все то золото, что блестит.

На самом деле, судя по всему, вас так же как и многих ввели в заблуждение волшебными способностями чудо-модулей. Вы показываете не реальную работу магазина, а скорость отдачи сервером готовых html-страниц. Если у вас дай бог, когда нибудь появится 20-30 посетитилей онлайн, у вас все ляжет, так как скорость генерации страниц без кеша у вас далеко не фонтан. Сколько ресурсов вы тратите на прогрев, и есть ли у вас возможность оперативно актуализировать каталог - это тоже открытый вопрос, о котором вы умалчиваете. И к этому ко всему у вас только на четвертом уровне появляются где-то там, очень узенько сегментированные товары. Вместо того чтобы дать возможность покупателям иметь нормальную навигацию в общих категориях (плитка, ламинат), вы заставляете его делать несколько лишних действий и теряете до половины посетителей. Ну и с такой мелкой сегментацией, ваш магазин ни чем не отличается от магазина на 3000 товаров.

Круто летает! Научите меня?

Загляну. 1. От 100к товаров по хорошему нужен дедик. Так как ВПСы не справляются ни с io операциями диска, ни с быстрой обработкой mysql-запросов, которая упирается и в io и в скорость ядер. А тут даже не ВПС а опять же облако с непонятной системой виртуализации, с диким оверселингом с HyperThreadingом и так далее. Вобщем это первая печаль. И не говорите мне, что нет трафика. БОТЫ ВЕЗДЕСУЩИ. 2. 2 гб памяти... Ну ок. Скорее всего там стоит 512мб а то и гиг на поток-php (ведь товары откуда то взялись, их парсили, а парсеры прожорливые до памяти). Даже если 512мб, куда то надо еще деть системные ресурсы. В итоге у нас есть ресурсов на 3 паралельных http-потока для клиентов. А от ботов запросов я думаю больше (см п.1) 3. Ладно, допустим, нет проблем с io, есть ресурс процессора, и есть в достатке память. Скорее всего есть большие категории, овер 10к товаров, в которых getProducts и getProductTotal выполняются 2-3-5 сек каждый. А если еще открыта пагинация для индексирования, то на крайних лимитах, на порядок дольше, так как чем больше лимит с сортировкой, тем больше базе приходится сканить данных из таблицы. И у нас уже даже не 3 потока в секунду может отработать система, а 1. Когда на web-сервер приходит очередь запросов, они в нее стали и выели все реусрсы процессора. А еще у нас же есть всякие update в таблицу product. Продолжать могу бесконечно... Хочется конечно поглумиться, и посоветовать поставить один супер-пупер "авторский" "уникальный" кеширующий модуль, либо же обратиться к специалистам оптимизаторам. В какую нить очень честную студию. Но чет я ни у кого из этих специалистов не видел живого магазина с фильтром, который тащит от 100 к товаров в принципе, не то что в одной категории. Так что если вдруг никто не поможет, стучите, полечим беду.

А что там разбираться то... Посмотрите в htaccess, что происходит здесь? RewriteRule ^([^?]*) index.php?_route_=$1 [L,QSA] По моему ясно же, что весь "хвост" запроса уходит в обработчик php с ключом _route_. Т.е. это внешний набор данных, который пришел "из мира" в котором содержится полная информация о запрашиваемых данных, который потом разбирается на части сео-классом: // Decode URL if (isset($this->request->get['_route_'])) { $parts = explode('/', $this->request->get['_route_']); а "route" - это системный указатель, который определяет какой контроллер системы должен обрабатывать ваш запрос. // Router if (isset($request->get['route'])) { $action = new Action($request->get['route']); } else { $action = new Action('common/home'); } В случае использования ЧПУ, у нас в строке запроса нет явно указанных параметров, какой контоллер должен обрабатывать ту или иную ссылку, а есть только что-то вида site.com/product_url. Для того чтобы движок понял, чему этот product_url соответствует ему надо из _route_ разобрать данные, постучаться в базу получить соответствия, типа product_id = 234234, определить по типу сущности, что это товар, выставить соответствующий системный route = product/poduct и отработать при помощи нужного контроллера ваши данные. Ничего военного и тайного в этом нет. Но все таки я поддержу чукчу, если данный механизм непонятен "как есть", а он достаточно логичен и интуитивен, лучше не лезть, потому что можно нахомутать.

Хм, а чего ж вы самого автора не спросите?

Я сделаю тесты. Покажу. Как раз есть набор данных подходящий.

Это плохое решение для нашей ситуации. Во первых у меня уже получилось быстрее ну и сфинкс по сути своего механизма формирует такой же бинарный индекс и реализация внутренней механики очень похожа. Во вторых - самое главное, то, что у меня целиком и полностью весь каталог крутится в индексе сфинкса. Цены, порядок сортировки, бренды, категории, абсолютно вся выборка на страницы каталога идет из того же самого индекса, в котором хранятся и атрибуты. Кроме этого, не нужно мудрить велосипед, и писать сложную логику для преобразования-извлечения данных. Все на sql, единственное стоит сервер 8 версии, там очень пригодилась поддержка JSON. Опять же не нужно было делать какие то прокладки, я прямо из базы новыми операторами mysql забираю готовую json-коллекцию. И в третьих. Я не знаю есть ли возможность в redis распаралелить индексы и делать обработку в несколько потоков. В нашем случае, при использовании сфинкса, можно полноценно использовать из коробки сразу любое количество ядер процессора а также разные части индекса разместить на любом количестве серверов, и в какой-то момент возможно физическое горизонтальное масштабирование станет единственным оставшимся методом оптимизации. Пока что после всех консультаций, если говорить о программных способах дать пинка этому монстру, я вижу два метода. Это хеширование значений атрибутов и отказ от json-коллекций в пользу mva-аттрибутов. Это потребует формированя дополнительных справочников, но сократит размер обрабатываемых данных раз в 50.

Какие коллизии? На наборе уникальных значений атрибутов в 300 штук, Вы ща серьезно? Опять какой то текст, я не совсем понял к чему. Но уточню суть проблемы. В структуре базы Opencart, самое узкое место - это таблица с атрибутами и поле типа text на значениях. Так как mysql плохо приспособлен для поиска-обработки-группировки по текстовым данным, и это все-таки реляционная база, которая по своей природе предполагает первичную типизацию, реализовать в лоб, какой либо вменяемый механизм невозможно. Есть несколько вариантов решения, но они все требуют денормализации таблиц и влекут за собой проблемы с совместимостью остального функционала. И в любом случае это будет костыль. Даже если использовать выборки match against и full-text индексы, мы все равно упремся в ограничении длины минимального слова в четыре символа, а все остальное заигнорится. Самый трезвый способ использовать для обработки больших текстовых массивов инструменты для этого предназначенные Solr, Elastic, Manticore либо Сфинкс. Так как изначально эти платформы разрабатывались для обработки больших текстовых массивов. Эластик и Солр - мне не нравятся, в силу тех или иных причин - это тема для отдельного поста, мантикора - это сфинкс 2.6 от тех кто убежал от Аксенова. А Sphinx 3.1 показывает прирост по скорости по сравнению с 2.6 и даже 3.0.3 процентов на 30. Очень имеет! MD5-хеш содержит 128 бит, а crc 32 - в четыре раза меньше. Для большого набора, который надо отсортировать в нашем случае, те самые 10M решает.

Я немного повангую. Модуль мультивалюта стоит? В каком режиме работает сервер? Apache, или php-fpm ? Судя по симптомам у вас проблема не в заказах.

В данном случае 20 это минимальный набор. Не забывайте товаров же пол ляма. По ним как-то да надо ориентироваться. А оставить пять атрибутов. Это считайте что фильтра и нет.