Кэш замедляет выдачу при проверке в PageSpeed Insights

[rb2]

7 hours ago, chukcha said:

Э... то вы батенька давно не смотрели в 2.3
Зачатки уже есть

Зачатки адаптеров я заметил только для кеша: сейчас можно выбирать между file, memcache и apc.

Языки не при делах. В `system/library/language.php` всё по-старому. Смотрел как в 2303rc (master), так и в 3.0 (dev).

 

Но идея переноса языковых ресурсов в базу у меня восторга не вызывает.

Я бы и OCMOD-ы из базы в файлы вынес :)

[chukcha]

design/translation

design/menu

 

Не видел?

[chukcha]

48 минут назад, rb2 сказал:

Я бы и OCMOD-ы из базы в файлы вынес

А смысл?
Из базы легче управлять, отключать, можно даже порядок устанавливать

А вот в config прописать путь к файлам ocmod...

 

50 минут назад, rb2 сказал:

Но идея переноса языковых ресурсов в базу у меня восторга не вызывает.

А почему бы и нет
В принципе, не разницы откуда

 

Но зато удобно добавлять свои языковые, чем рыскать по файлам и перевод проще сделать

В крайнем случае - сбрасывать в языковый кеш

 

[Dotrox]

Посмотрел я на эти файлы в админке и возникло плохое предчувствие, что оно будет грузить из языковых файлов в базу (именно тот идиотизм, из-за которого я не перевариваю мультиязычность в Drupal и WP).

 

[rb2]

9 minutes ago, chukcha said:

design/translation

design/menu

 

Не видел?

Увидел.

design/menu - не вижу, но думаю, речь про design/theme. Надеюсь, они не забудут прикрутить тот же самый редактор и на доступ к коду окмод-ов.

24 minutes ago, chukcha said:

А смысл?
Из базы легче управлять, отключать, можно даже порядок устанавливать

 

Я из своей практики исхожу. Мне жутко неудобно. Очень часто при работе нужен доступ к коду одного или нескольких окмодов. Если не устанавливать каждому клиенту редактор окмод-ов (по совместительству показывающий и конфликты между ними, а также каким модом сделано изменение) - то работа по разрешению конфликтов между модулями превращается в ад. Установка на предварительно не снесённый окмод - пыбыдыщ! ошибка! 5-10 кликов и возни с прицеливанием на переход в другую менюшку, там поиск (иногда на нескольких страницах) и удаление (отмотай найди мод, отметь, отмотай вверх, нажми на кнопку), вернись опять на установку, выбор файла и т.п.....

Там UX интерфейс менять и менять - да, вполне юзабельно можно сделать. А ещё инсталлятор сделать более нормальным, а ещё деинсталлятор предусмотреть. И редактор, и экспорт текстов окмодов из базы в файлы. Для тах, ком у сними работать, а не смотреть на них. Но то, что сейчас - мне очень неудобно. Приходится дополнительные инструменты использовать, когда изменения не единичные и быстропонятные.

 

А иногда бывает на некторых задачах, что доступ в админку нужен только чтоб нажать кнопку перегенерации окмодов. Русскоязычным магазинщикам в 99.999% случаев эта вся ваша секюрити и разграничение доступа - пустой звук. Люди доверяют всем, кто назвался программистом, и спокойно дают доступ в кишки с секретами. Но ничего удобного в том, что приходится просить доступ в админку только ради этой кнопки, я не вижу.

 

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

53 minutes ago, chukcha said:

1 hour ago, rb2 said:

Но идея переноса языковых ресурсов в базу у меня восторга не вызывает.

А почему бы и нет
В принципе, не разницы откуда

Ну, опять же - из опыта. Сталкивался. Престашоп, например, крепко запомнился.

Помню смутно и проекты родом из детства, где люди уносили в базу ресурсы, которым там не место. Понимали не сразу, почему не стоило.

 

Но это неважно. Речь на самом деле не о том, где. А о том, кто и как реализует. И что-то мне подсказывает, что гениальный архитектор выберет какое-то очень нестандартное и непременно странное решение. И потом забудет поставить индекс на поле в базе. (шёпотом) Или на каждую локализованную фразу в OC4 появится запрос в базу... И будет их не по 100 и не по 400 на страницу, а по 800... Или в OC3 уже появился?

 

Сейчас мне в языковых ресурсах не нравится то, что много дубликатов, причём сделано сознательно.. Но решается это и на файлах легко и просто.

Плюс дурдом с перекладыванием строчек из одного массива в другой в каждом контроллере. Ради экономии пары килобайт PHP-памяти?

В общем, я просто не вижу преимуществ в перекладывании. При том, что база в опенкарте - слабое звено.

[rb2]

54 minutes ago, Dotrox said:

Посмотрел я на эти файлы в админке и возникло плохое предчувствие, что оно будет грузить из языковых файлов в базу (именно тот идиотизм, из-за которого я не перевариваю мультиязычность в Drupal и WP).

 

По-моему, останется как прежде, но добавился механизм перезаписи: по роуту нашли переопределённые строки и заменили ими дефолтные.

См. https://isenselabs.com/posts/opencart-3

[Dotrox]

6 минут назад, rb2 сказал:

Плюс дурдом с перекладыванием строчек из одного массива в другой в каждом контроллере. Ради экономии пары килобайт PHP-памяти?

Дэниэль уже писал где-то почему так: без лапши в контроллерах (школоте) будет непонятно, как оно работает. (в скобках примечание переводчика )

 

 

16 минут назад, rb2 сказал:

Или на каждую локализованную фразу в OC4 появится запрос в базу...

В текущем коде оно тянется пачками на основе роута.

class ModelDesignTranslation extends Model {
	public function getTranslations($route) {
		$query = $this->db->query("SELECT * FROM " . DB_PREFIX . "translation WHERE store_id = '" . (int)$this->config->get('config_store_id') . "' AND language_id = '" . (int)$this->config->get('config_language_id') . "' AND route = '" . $this->db->escape($route) . "'");
		return $query->rows;
	}
}

Правда, это пока в любом случае не используется. И бросается в глаза отсутствие фолбека на случай отсутствия для роута локализации на текущем языке. Разве что ключами будут уже не названия переменных, а сами фразы на дефолтном языке.

[chukcha]

Меня вполне устраивает http://www.opencart-templates.co.uk/modification-manager

и редактор, и даунлооад и лог, какие файлы и кем изменены, и поиск

 

 

Я скорей склоняюсь к кешированию языковых переменных, особенно когда тебе нужно свою пременную

А то действительно тяжко писать в окмод на нескольких языках, а так реально и достаточно просто прямо в инсталле - addL(lang_code,route,text);

Нажал на кнопочку компиляции и получил готовый результат

 

Появление инсталятора большой шаг - по крайней мере  не надо рассказывать как подключаться по фтп,

а раз есть инсталятор, то за деинсталятром будущее, Кстати я уже видел что-то подобное.

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

 

Не все еще потеряно...

 

Ну и лапшу можно "отключать"

или merge - если языковый файл нужен в других модулях

или

$data = $this->load->language($route); - годится для себя

 

 

Тю.. ресурсы

Не помню какой там modx - там даже шаблоны лежали в базе

 

Наличие/отсутствие индексов.

Все достаточно объяснимо нишей OC - начальный/средний уровень, но не крупный бизнес
Но!!! Как только это становится крупным бизнесом, то  найдутся деньги на оптимизацию. И плакаться в этом не надо.
иначе имея 100500 позиций  и 2-3 заказ в день - смех сквозь слезы.

 

 

 

 

[Dotrox]

1 час назад, chukcha сказал:

Появление инсталятора большой шаг - по крайней мере  не надо рассказывать как подключаться по фтп

А надо только рассказать как заставить ОК работать с FTP.

 

1 час назад, chukcha сказал:

Ну и лапшу можно "отключать"

или merge - если языковый файл нужен в других модулях

или

$data = $this->load->language($route); - годится для себя

В мастере на Гитхабе есть кое-что получше (внимание на второй параметр):

public function load($filename, &$data = array()) {

		...

		$data = array_merge($data, $this->data);
		return $this->data;
	}

Но в дев ветке 3.0 предпоследней строки нет (как и в 2.3, хотя параметр есть начиная с 2.2). Так что оно может и потеряться.

 

А на счёт лапши в целом, так она ж не только из-за языковых переменных, контроллеры - это вообще сплошная лапша. Особенно радует переменная $url, которая по 10 раз формируется полотнищами кода. Вместо этих полотнищ можно было бы просто профильтровать содержимое get на случай чего-то лишнего и склеить имплоудом.

 

 

1 час назад, chukcha сказал:

Наличие/отсутствие индексов.

Все достаточно объяснимо нишей OC - начальный/средний уровень, но не крупный бизнес

Я из собственного опыта могу сказать, что после трёх тысяч товаров магазин уже еле открывается, если не вешать индексы (речь про 1.5). А такое количество товаров даже на средний бизнес ещё не тянет абсолютно. Ну, и тормоза ж не резко выпрыгивают на каком-то числе товаров, а плавно нарастают.

А крупному бизнесу ОК вообще не подойдёт, ибо нет транзакций.

[chukcha]

7 часов назад, Dotrox сказал:

ибо нет транзакций.

Упс, а это зачем при SELECT
Не надумывай.

Знаешь, по поводу размеров бизнеса.

Скажи, в винде какое количество компов в сети считается малой группой? При каком количестве уже рекомендуется ставить доменный сервер (чтобы ты не искал, а поверил - от 5-6)

 

Языковое.

Ну да,
 

Простыня проще, минус простыни - ее количество.

 

Не имеет значения на самом деле фильтровать из простыни, или делать исключения, в любом случае нужно знать что фильтровать

 

 

 

[rb2]

7 hours ago, Dotrox said:

А надо только рассказать как заставить ОК работать с FTP.

По моим клиентам по установке - из 100 человек это правильно настроено в 2-3 случаях. Ещё у нескольких человек бывает установлен localCopy ocmod. И бывает, встречаются 1-2 чудесатых ситуации, когда ошибки валятся и при правильных настройках FTP, и при локалкопи - и у меня тоже не получается разобраться, проще и быстрее установить модуль вручную, проделав за инсталлятор доп. действия кроме копирования, если они нужны.

 

То есть по самым оптимистичным оценкам - 90-97% понятия не имеют, как этот FTP в настройках настраивать и зачем он нужен. Всё решается переделкой UX и документацией, но этого нет.

7 hours ago, Dotrox said:

контроллеры - это вообще сплошная лапша. Особенно радует переменная $url, которая по 10 раз формируется полотнищами кода.

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

 

9 hours ago, chukcha said:

Наличие/отсутствие индексов.

Все достаточно объяснимо нишей OC - начальный/средний уровень, но не крупный бизнес

Ой, та не смешите. Гениальный архитектор утверждает, что всё должно быть нормально, просто потому, потому что у него есть клиенты на опенкарте с миллионом товаров на дедике. Вот двухнедельной давности очередное такое утверждение: https://github.com/opencart/opencart/issues/5287

 

Не надо иллюзий. Он просто не понимает, что у него не так в базе и что у него не так с производительностью.

 

Я не говорю, что это плохо в целом - это даёт мне, Йоде, Снастику и другим наверное тоже, возможность зарабатывать на оптимизации магазинов у тех, кто дорос до этого. Да, у меня был случай, когда нам дали магазин с зашкалом 154тыс CP попугаев нагрузки на базу (при лимите максимум 5000CP) и мы смогли оптимизировать нагрузку со средних 100к до 541. 100тыс разделить на 500 - это в 200 раз снизить нагрузку на базу.

Да, это было непросто, небыстро и интересно. И мы там ещё оптимизацией фронт-энда принципиально не занимались, разделили.

Если в мире опенкарт это уже воспринимается как норма - мне очень жаль. На самом деле это просто говнокод и отсутствие профессионализма. Движок легко может быть ГОРАЗДО оптимальней.

 

8 hours ago, Dotrox said:

А крупному бизнесу ОК вообще не подойдёт, ибо нет транзакций.

Плюсую. Жаль, что ещё никто крупно не подзалетел на отсутствии целостности данных.

[chukcha]

Зачем транзакции? На какой стадии?

Целостность данных - на какой момент?

 

 

Почитал ветку

И что? Но ведь он не сказал, что на голом OC
 

Ну, ХК - это было для меня самым первым откровением.
А пагинация без шаблона - вторым

 

Я уже озвучивал еще раз не поленюсь

 

единый шаблон index.

 

$header
-- $language
-- $currency
-- $menu
-- $search
$center

---- $left
------ $module
---- $top
------ $module

 

-- $content -

 

---- $bootom
------ $module
---- $right
------ $module
$footer

 

 

 

[Dotrox]

2 часа назад, chukcha сказал:

Упс, а это зачем при SELECT
Не надумывай.

Так я ж как раз не про SELECT.

Например, формирование заказа, там достаточно инсертов. И держится оно на mysqli_insert_id, который вернёт id после последнего инстерта/апдейта и есть у меня сомнения, что привязано к текущему экземпляру класса mysqli (то есть, вернёт не просто последний вставленный  id, а вставленный именно здесь).

 

Но если тут ещё вопрос (ибо точно не знаю, как оно сработает), то есть же просто множество мест, где идут последовательные запросы. Даже, опять же, формирование заказа: там куча последовательных запросов, например, тоталы, каждый из которых вставляется отдельным запросом. А вдруг какой-то сбой, половина тоталов не вставится? Ну, или сбой будет ещё на запросах записи товаров - заказ есть, а товаров в нём нет. Ну, тут ещё можно увидеть (если товаров совсем нет, а не часть потерялась), но может товар записаться, а выбранные опции - нет. И такого полно.

 

 

2 часа назад, chukcha сказал:

на самом деле фильтровать из простыни, или делать исключения, в любом случае нужно знать что фильтровать

$url = http_build_query(array_intersect_key($this->request->get, ['sort', 'order', 'limit', ...]));

И вынести хотя бы в хелпер, где будут прописаны шаблоны параметров для каждого типа ссылок, чтоб можно было так сделать:

$url = $this->helper->buildUrl($this->request->get, 'sort_params');

 

1 час назад, rb2 сказал:

А однотипный код в шаблонах (те же хлебные крошки - один и тот же код в десятках файлов), который так и просится в отдельный файл, подключаемый include-ом.

Он не только в шаблоне просится в отдельный файл, он и в контроллере просится в отдельный метод, общий для всех контроллеров.

 

 

[chukcha]

10 минут назад, Dotrox сказал:

есть у меня сомнения, что привязано к текущему экземпляру класса mysqli

Ок, "допустим"
Если это "большой" проект - конвертируй  order в innodb

Но при 20 заказах в день - стоит ли так париться?

 

[Dotrox]

3 часа назад, chukcha сказал:

Ок, "допустим"
Если это "большой" проект - конвертируй  order в innodb

Но при 20 заказах в день - стоит ли так париться?

 

Ну, так я ж и не говорил про 20 заказов в день - я говорил про крупный бизнес (а если там 20 заказов в день, то какой же он крупный?).

 

Ну, и просто конвертировать в innodb мало, транзакции от этого не возникнут магически из ниоткуда. И заказы это просто самое критичное, но проблема эта есть во всех методах моделей со вставкой/обновлением/удалением записей. Если при добавлении товара к нему, например, опции не пропишутся - в этом тоже ничего приятного нет.

Представь, если б у Розетки периодически из заказов часть данных терялась.

 

То есть, зачем брать движок, который наполовину надо переписать, чтоб он смог работать с действительно крупным проектом?

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

 

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

 

В результате получается: нужна какая-то мелочь, которая есть в любом фреймворке и, например, в том же Мадженто одной строчкой выдёргивалась бы из Зенда - впиливай самостоятельно.

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

Змінено 30 березня 2017 користувачем Dotrox

[chukcha]

Я тебя не понимаю

Ну давай тогда говорить о тригерах, о процедурах и функциях, на бесплатном движке..

И что.. там в магенте запись опций и атрибутов согласованы?

Как ты не поймешь, что универсальность, масштабирование - не есть задача OC
Еще раз - ОС - ниша малого, малосреденго торгового бизнеса.

 

[Dotrox]

6 минут назад, chukcha сказал:

Еще раз - ОС - ниша малого, малосреденго торгового бизнеса.

Так а я о чём?

Мы же как раз с этого и начали: я сказал, что он не подходит для крупного бизнеса - ты не согласился.

[AMF]

Камрады, большое спасибо!

 

Сделал кэши в один файл. Количество файлов в папке сократилось до 13  Время ответа существенно упало

 

Ещё вопрос - может кого-то не затруднит индексы базы глянуть? Делали их когда-то по вот этому образцу

 

В 21.07.2011 в 22:18, UncleAndy сказал:

По результатам оптимизации alexxxus своей большой базы были добавлены следующие индексы:

oc_product:

KEY `model` (`model`),

KEY `stock_status_id` (`stock_status_id`),

KEY `quantity` (`quantity`,`date_available`),

KEY `tax_class_id` (`tax_class_id`,`weight_class_id`,`length_class_id`),

KEY `sort_order` (`sort_order`)

oc_product_option_description:

KEY `product_id` (`product_id`)

oc_product_option_value:

KEY `product_option_id` (`product_option_id`),

KEY `product_id` (`product_id`)

oc_url_alias:

UNIQUE KEY `query` (`query`),

KEY `keyword` (`keyword`)

oc_zone:

KEY `country_id` (`country_id`)

 

[AMF]

И да, какое время жизни кэша оптимальное по вашему мнению?

[chukcha]

50 минут назад, AMF сказал:

oc_product_option_description:

KEY `product_id` (`product_id`)

бессмысленность индекса, для этого есть составной product_id language_id

 

Остальные нужно смотреть в связке

[chukcha]

54 минуты назад, Dotrox сказал:

что он не подходит для крупного бизнеса - ты не согласился.

Я сказал, что средний и выше требует уже наличия постоянной поддержки (или выделения бюджета под это).

[rb2]

1 hour ago, AMF said:

И да, какое время жизни кэша оптимальное по вашему мнению?

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

 

1 hour ago, AMF said:

Ещё вопрос - может кого-то не затруднит индексы базы глянуть? Делали их когда-то по вот этому образцу

Бросьте мне в личку адрес сайта и досуп к FTP. Посмотрю.

 

Если есть возможность (спросите хостера или админа) - включите лог медленных запросов или в конфиге MySQL - лог запросов, не использующих индексы. Это золотое дно и готовые ответы для оптимизации запросов.

Змінено 30 березня 2017 користувачем rb2

[rb2]

7 hours ago, Dotrox said:

Он не только в шаблоне просится в отдельный файл, он и в контроллере просится в отдельный метод, общий для всех контроллеров.

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

Змінено 30 березня 2017 користувачем rb2

[rb2]

2 hours ago, chukcha said:

Как ты не поймешь, что универсальность, масштабирование - не есть задача OC
Еще раз - ОС - ниша малого, малосреденго торгового бизнеса.

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

Змінено 30 березня 2017 користувачем rb2

[chukcha]

Причем здесь второй сорт?

 

Надежность?

Сколько стоит промышленный комп? с повышенной надежностью, с резервированием?

 

Какая разница межу IDE шиной и SCSI
 

нужен ли скази на домашнем компе? на компе бухгалтера?
В конце концов
Нужна ли про версия винды бухгалтеру?

 

Что такое нормальная нагрузка на базу?
Кто  и что создает нагрузку?

 

Если нагрузка создана - то  нужна  "оптимизировать" в процессе работы - решать проблемы по мере поступления.

 

Вот только не надо... Давайте сразу расставим нужные индексы, почитаем книШки, и расставим.

 

Так не бывает!!!