rb2

Это, кстати, к вопросу о том, что кто-то не видит смысла в транзакциях и целостности связанных данных.

Бывает. И пряморукие программисты бывают. И принимающие дельные пуллреквесты в опенсорс проекты бывают.

Да при чём тут высокомерие, когда речь идёт о призыве потратить моё личное время в виде вызова в стиле "на слабо", аргументированном только смайликами? Всё гораздо проще. Время и желание. Оценка рисков и перспектив. Ресурсов и баланса. Мне неинтересно было реагировать и рассказывать. Извините, если это показалось грубым. Если бы меня интересовало получить известную собеседнику информацию - я бы приложил к этому какие-то усилия, пропорциональные моему желанию.

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

Ну да. В общем, SOLID по всему коду опенкарту плачет.

А как часто хранящееся в кеше у вас обновляется? Если вы шпарите контент, переиначиваете категории, меняете ЧПУ - раз в день или раз в час кажется разумным. Но если вы не меняете ЧПУ направо и налево, а остатки и названия товаров (или что там в кеше хранится) и структура категорий меняется раз в году - то месяц или того реже тоже вполне ок Но там же ж не будет уже катастрофических задержек, так что какую-то золотую середину типа 24 часов или 7 суток себе придумайте и забудьте. Бросьте мне в личку адрес сайта и досуп к FTP. Посмотрю. Если есть возможность (спросите хостера или админа) - включите лог медленных запросов или в конфиге MySQL - лог запросов, не использующих индексы. Это золотое дно и готовые ответы для оптимизации запросов.

По моим клиентам по установке - из 100 человек это правильно настроено в 2-3 случаях. Ещё у нескольких человек бывает установлен localCopy ocmod. И бывает, встречаются 1-2 чудесатых ситуации, когда ошибки валятся и при правильных настройках FTP, и при локалкопи - и у меня тоже не получается разобраться, проще и быстрее установить модуль вручную, проделав за инсталлятор доп. действия кроме копирования, если они нужны. То есть по самым оптимистичным оценкам - 90-97% понятия не имеют, как этот FTP в настройках настраивать и зачем он нужен. Всё решается переделкой UX и документацией, но этого нет. О, да! А подключение темплейтов из текущей или дефолтной темы? А однотипный код в шаблонах (те же хлебные крошки - один и тот же код в десятках файлов), который так и просится в отдельный файл, подключаемый include-ом. Ой, та не смешите. Гениальный архитектор утверждает, что всё должно быть нормально, просто потому, потому что у него есть клиенты на опенкарте с миллионом товаров на дедике. Вот двухнедельной давности очередное такое утверждение: https://github.com/opencart/opencart/issues/5287 Не надо иллюзий. Он просто не понимает, что у него не так в базе и что у него не так с производительностью. Я не говорю, что это плохо в целом - это даёт мне, Йоде, Снастику и другим наверное тоже, возможность зарабатывать на оптимизации магазинов у тех, кто дорос до этого. Да, у меня был случай, когда нам дали магазин с зашкалом 154тыс CP попугаев нагрузки на базу (при лимите максимум 5000CP) и мы смогли оптимизировать нагрузку со средних 100к до 541. 100тыс разделить на 500 - это в 200 раз снизить нагрузку на базу. Да, это было непросто, небыстро и интересно. И мы там ещё оптимизацией фронт-энда принципиально не занимались, разделили. Если в мире опенкарт это уже воспринимается как норма - мне очень жаль. На самом деле это просто говнокод и отсутствие профессионализма. Движок легко может быть ГОРАЗДО оптимальней. Плюсую. Жаль, что ещё никто крупно не подзалетел на отсутствии целостности данных.

Любым из этих 2 способов: $_['button_login'] = 'S\'identifier'; или $_['button_login'] = "S'identifier";

По-моему, останется как прежде, но добавился механизм перезаписи: по роуту нашли переопределённые строки и заменили ими дефолтные. См. https://isenselabs.com/posts/opencart-3

Увидел. design/menu - не вижу, но думаю, речь про design/theme. Надеюсь, они не забудут прикрутить тот же самый редактор и на доступ к коду окмод-ов. Я из своей практики исхожу. Мне жутко неудобно. Очень часто при работе нужен доступ к коду одного или нескольких окмодов. Если не устанавливать каждому клиенту редактор окмод-ов (по совместительству показывающий и конфликты между ними, а также каким модом сделано изменение) - то работа по разрешению конфликтов между модулями превращается в ад. Установка на предварительно не снесённый окмод - пыбыдыщ! ошибка! 5-10 кликов и возни с прицеливанием на переход в другую менюшку, там поиск (иногда на нескольких страницах) и удаление (отмотай найди мод, отметь, отмотай вверх, нажми на кнопку), вернись опять на установку, выбор файла и т.п..... Там UX интерфейс менять и менять - да, вполне юзабельно можно сделать. А ещё инсталлятор сделать более нормальным, а ещё деинсталлятор предусмотреть. И редактор, и экспорт текстов окмодов из базы в файлы. Для тах, ком у сними работать, а не смотреть на них. Но то, что сейчас - мне очень неудобно. Приходится дополнительные инструменты использовать, когда изменения не единичные и быстропонятные. А иногда бывает на некторых задачах, что доступ в админку нужен только чтоб нажать кнопку перегенерации окмодов. Русскоязычным магазинщикам в 99.999% случаев эта вся ваша секюрити и разграничение доступа - пустой звук. Люди доверяют всем, кто назвался программистом, и спокойно дают доступ в кишки с секретами. Но ничего удобного в том, что приходится просить доступ в админку только ради этой кнопки, я не вижу. При работе со своими магазинами и проектами я испытываю пусть и неполный, но в принципе тот же самый набор неудобств. Просто на нескольких клиентах в день / в неделю это заметней. А почему бы и нет В принципе, не разницы откуда Ну, опять же - из опыта. Сталкивался. Престашоп, например, крепко запомнился. Помню смутно и проекты родом из детства, где люди уносили в базу ресурсы, которым там не место. Понимали не сразу, почему не стоило. Но это неважно. Речь на самом деле не о том, где. А о том, кто и как реализует. И что-то мне подсказывает, что гениальный архитектор выберет какое-то очень нестандартное и непременно странное решение. И потом забудет поставить индекс на поле в базе. (шёпотом) Или на каждую локализованную фразу в OC4 появится запрос в базу... И будет их не по 100 и не по 400 на страницу, а по 800... Или в OC3 уже появился? Сейчас мне в языковых ресурсах не нравится то, что много дубликатов, причём сделано сознательно.. Но решается это и на файлах легко и просто. Плюс дурдом с перекладыванием строчек из одного массива в другой в каждом контроллере. Ради экономии пары килобайт PHP-памяти? В общем, я просто не вижу преимуществ в перекладывании. При том, что база в опенкарте - слабое звено.

Зачатки адаптеров я заметил только для кеша: сейчас можно выбирать между file, memcache и apc. Языки не при делах. В `system/library/language.php` всё по-старому. Смотрел как в 2303rc (master), так и в 3.0 (dev). Но идея переноса языковых ресурсов в базу у меня восторга не вызывает. Я бы и OCMOD-ы из базы в файлы вынес :)

Обескуражен. Ждать готовых ответов - это по-детски. Гуглить, изучать вопрос, предоставить хоть какие-то результы и сказать "а вот тут у меня затык, помогите-подскажите" - это по взрослому. Разве не так? Трудно найти сравнивалки и выбиралки лицензий, предыдущие обсуждения или продукты с другой лицензией даже среди нескольких широкоизвестных, погуглить, как у них дела обстоят с ионкубом и юристами? Это элементарщина. 10-30-минутная. Если это обижает даже адекватных вроде людей - да ну и пох уже. Чесслово.

Это у них вежливая форма отказа. При обычной форме - при любом дельном предложении автора тикета называют идиотом или улучшение "not required". Хотя когда начинаешь возиться и понимаешь, что в базе нет такой элементарщины, как 90% необходимых индексов, а DK в тикетах по производительности людям говорит, что всё решается более мощным сервером - понимание, кто идиот, приходит за несколько итераций. С другой стороны, это хорошо, т.к. даёт обширное поле для зарабатывания вокруг неидеального движка. Надо только пересилить и терпеть работу по колено в говнах. Точнее, движок сам по себе вполне, но идиот-мантейнер - это горе. У меня надежда появилась только с приходом ещё одной команды в разработку (с опенкарт 2), а когда он был один - это было самым мощным тормозом развития движка. Я только сейчас понял, что вышеприведённый код по очистке от устаревших файлов кеша исполняется при каждом запросе к index.php. Заметно поможет даже введение тайм-аута в час, например, чтобы скан нескольких тысяч файлов и очистка выполнялись намного реже. 1000 : 0.480421 5000 : 1.990968 10000 : 3.808470 Это простое сканирование glob-ом, даже с GLOB_NOSORT. Без NOSORT ещё дольше, но ненамного. Но заметно. Цифры на SSD и на сервере могут, конечно, в разы, а то и на порядок, отличаться, но всё равно - зачем такое бесполезное счастье при каждом запросе? Чота ржу. Извините. Не могу удержаться. Успокаивать, переубеждать или волноваться не надо, умоляю.

1. гугл 2. "администрация этого форума" (с) @Vladzimir Давайте по-взрослому: зачем мне это? Даже если я знаю какие-то ответы частично или полностью. Я уже напомогался и наэкспериментировался и какие-то выводы для себя сделал.

Не знаю, о какой проблеме темы вы говорите, но если запрос `SELECT * FROM ts_event` выполняется 787 мс, тут к доктору не ходи - надо в первую очередь валить с этого хостинга. Или как минимум менять шаред с буйными соседями на впс. Тутанхамона ещё откопайте и полечите лазерной коррекцией или физиотерапией. Вдруг случится чудо.

Когда заполнится кэш и станет тормознее - смотрите на кол-во файлов в system/cache. Если их там десятки тысяч - время сканировани glob-ом линейно и заметно растёт с ростом кол-ва файлов. Поможет переписать ф-ции кеширования на работу с папками (изменить структуру хранения кеша с плоской на 1-2 уровня папок)

@ZeroHero именно. На это не раз указывалось. В том числе Даниэлю Керру. GPL - худший из вариантов для подобной модели (для продажи дополнений). Лиценция для Опенкарт выбрана через самизнаетечто. Впрочем, как и многое в Опенкарт сделано. Черезжопно.

https://www.gnu.org/licenses/gpl-faq.ru.html#NonfreeDriverKernelLinux Является ли нарушением GPL распространение несвободного драйвера, предназначенного для компоновки с ядром Linux? (#NonfreeDriverKernelLinux) Linux (ядро операционной системы GNU/Linux) распространяется по GNU GPL версии 2. Является ли нарушением GPL распространение несвободного драйвера, предназначенного для компоновки с Linux? Да, это нарушение, потому что это фактически создает более крупную комбинированную работу. Тот факт, что предполагается, что пользователь будет складывать эти части друг с другом, в действительности ничего не меняет. Каждый соразработчик Linux, который является правообладателем существенной части программ, может требовать соблюдения GPL, и мы призываем каждого из них к действиям против тех, кто распространяет несвободные драйверы Linux.

Не знаю, как насчёт среднего (и зачем оно? мы же затыки ищем), а вот $ grep -i "время выполнения" sql_time.log | awk '{print $3}' | sort -g > time-sorted.tmp.txt показывает в конце такие аж такие значения (далёкие от высмотренных Вами 170 мс): 703.6мс 705.09мс 709.22мс 713.09мс 724.74мс 727.87мс 727.99мс 729.25мс 737.93мс 741.62мс 742.19мс 767.25мс 769.19мс 774.01мс 779.33мс 786.56мс 787.4мс 810.1мс 817.88мс 827.49мс 829.15мс 891.84мс 893.03мс 912.86мс 922.07мс 929.08мс 929.15мс 933.62мс 938.23мс 943.44мс 947.08мс 965.9мс 966.22мс 971.79мс 973.63мс 1009.99мс 1022.32мс 1025.94мс 1038.27мс 1038.92мс 1054.12мс 1059.91мс 1128.06мс 1133.33мс 1141.62мс 1163.49мс 1172.04мс 1193.05мс 1267.18мс 1365мс 1368.8мс 1377.11мс 1381.46мс 1418.84мс 1549.67мс 1558.83мс 1770.66мс 1773.94мс 1858.77мс 2164.99мс 2367.32мс 2378.93мс 2445.68мс 2528.36мс И кратко пробежимся по кол-ву запросов со временем запроса 200-300мс: 4493 шт в логе 300-400мс: 314 шт 400-500мс: 113 запросов 500-600: 24 600-700: 26 700-800: 18 800-1000: 19 1000-2000мс: 25 2164.99-2528.36мс: 6

Мощно: Страница:/ Источник:/var/www/u0941353/data/www/tservice23.ru/system/library/openbay.php Время выполнения: 1770.66мс SELECT * FROM ts_extension WHERE `type` = 'openbay' ---------------------- Страница:/ Источник:/var/www/u0941353/data/www/tservice23.ru/index.php Время выполнения: 787.4мс SELECT * FROM ts_event Сдаётся мне, у вас даже просто индексы в базе расставить кому-то пряморукому - и всё взлетит. Даже без какой-либо оптимизации запросов. Я может прослушал в этом топике - а сколько в базе товаров, атрибутов, категорий?

Можно, универсальными конфигами. Google: opencart универсальный конфиг. И заодно в .htaccess можно универсально правило редиректа "с www / без www" написать, чтобы и там адрес сайта не фигурировал. А вам зачем? Ежедневно будете домен у сайта менять? Мне несложно две строчки 1-2 раза в жизни подправить, не заморачиваюсь. https://opencartforum.com/topic/4956-kak-pereimenovat-put-v-adminku/?do=findComment&comment=32069 https://opencartforum.com/topic/44104-universalnyy-config/

В конфигах опенкарта смените адрес сайта. config.php admin/config.php

mysqldump, tar, gzip, ssh / rsync, cron, bash. Там реально пара строчек там, пара строчек здесь. Даже не знаю, что там описывать. На серверах делаю ежедневные копии, там же ротация (оставляю последние 3-5 копий), домашний комп тоже по крону регулярно забирает бекапы и аналогично оставляет только последние 5-7 архивов. С дропбоксами, гуглодисками, яндексдисками и т.п. не связывался, хватает копирования на домашние компы. Оттуда уже несложно в папку, синхронизируемую с облаком, переложить, если очень надо, чтобы и туда улетало.

2.2? Это вообще не версия, а мертворожденный выкидыш. Метнитесь от него как можно быстрее и как можно дальше.

Краткий ответ: doctype, находящийся не в первой строке, иногда может мешать. Редко, но может. Особенно если речь идёт не об HTML, а всяких XML документах (типа сайтмапов и RSS-фидов). По стандартам - https://www.w3.org/TR/html-markup/documents.html#conformant-documents HTML может содержать комментарии и символы-пробелы до строки с DOCTYPE. XML-форматы - нет. См. также выдачу гугла по запросу "doctype not on first line" https://www.google.com.ua/search?q=doctype+not+on+first+line