Перейти к публикации
Поиск в
  • Дополнительно...
Искать результаты, содержащие...
Искать результаты в...

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


AMF
 Поделиться

Рекомендованные сообщения

7 hours ago, chukcha said:

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

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

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

 

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

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

Ссылка на комментарий
Поделиться на других сайтах


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

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

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

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

 

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

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

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

 

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

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


 

Ссылка на комментарий
Поделиться на других сайтах

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

 

Ссылка на комментарий
Поделиться на других сайтах


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-памяти?

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

Ссылка на комментарий
Поделиться на других сайтах


54 minutes ago, Dotrox said:

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

 

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

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

Ссылка на комментарий
Поделиться на других сайтах


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;
	}
}

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

Ссылка на комментарий
Поделиться на других сайтах


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

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

 

 

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

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

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

 

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

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

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

 

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

 

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

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

или

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

 

 

Тю.. ресурсы

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

 

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

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

 

 

 

 

Ссылка на комментарий
Поделиться на других сайтах

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). А такое количество товаров даже на средний бизнес ещё не тянет абсолютно. Ну, и тормоза ж не резко выпрыгивают на каком-то числе товаров, а плавно нарастают.

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

  • +1 1
Ссылка на комментарий
Поделиться на других сайтах


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

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

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

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

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

 

Языковое.

Ну да,
 

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

 

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

 

 

 

Ссылка на комментарий
Поделиться на других сайтах

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:

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

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

Ссылка на комментарий
Поделиться на других сайтах


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

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

 

 

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

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

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

 

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

 

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

 

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

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

 

-- $content -

 

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

 

 

 

Ссылка на комментарий
Поделиться на других сайтах

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-ом.

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

 

 

  • +1 1
Ссылка на комментарий
Поделиться на других сайтах


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

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

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

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

 

Ссылка на комментарий
Поделиться на других сайтах

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

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

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

 

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

 

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

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

 

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

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

 

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

 

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

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

Изменено пользователем Dotrox
  • +1 1
Ссылка на комментарий
Поделиться на других сайтах


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

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

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

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

 

Ссылка на комментарий
Поделиться на других сайтах

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

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

Так а я о чём? :)

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

Ссылка на комментарий
Поделиться на других сайтах


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

 

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

 

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

 

В 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`)

 

  • +1 1
Ссылка на комментарий
Поделиться на других сайтах


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

oc_product_option_description:

KEY `product_id` (`product_id`)

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

 

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

Ссылка на комментарий
Поделиться на других сайтах

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

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

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

Ссылка на комментарий
Поделиться на других сайтах

1 hour ago, AMF said:

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

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

 

1 hour ago, AMF said:

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

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

 

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

Изменено пользователем rb2
  • +1 1
Ссылка на комментарий
Поделиться на других сайтах


7 hours ago, Dotrox said:

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

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

Изменено пользователем rb2
Ссылка на комментарий
Поделиться на других сайтах


2 hours ago, chukcha said:

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

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

Изменено пользователем rb2
Ссылка на комментарий
Поделиться на других сайтах


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

 

Надежность?

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

 

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

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

 

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

 

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

 

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

 

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

 

 

 

 

 

 

Ссылка на комментарий
Поделиться на других сайтах

Создайте аккаунт или войдите в него для комментирования

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

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Войти

Уже зарегистрированы? Войдите здесь.

Войти сейчас
 Поделиться

  • Сейчас на странице   0 пользователей

    • Нет пользователей, просматривающих эту страницу.
×
×
  • Создать...

Важная информация

На нашем сайте используются файлы cookie и происходит обработка некоторых персональных данных пользователей, чтобы улучшить пользовательский интерфейс. Чтобы узнать для чего и какие персональные данные мы обрабатываем перейдите по ссылке. Если Вы нажмете «Я даю согласие», это означает, что Вы понимаете и принимаете все условия, указанные в этом Уведомлении о Конфиденциальности.