ArtemPitov Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 Артем подскажите пожалуйста как это можно сделать. Количество товара отключено, а вот с категориями не могу разобраться. Настройки магазина -> Количество товаров в подкатегории: нет Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... ArtemPitov Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 Да чего мелочиться - давайте кешировать готовые страницы. :-) Это кусок из модифицированного мной кеша, там все раскладывается по папочкам, и совершенно не напрягает. К тому же все единообразно: на входе метода модели проверили кеш, далее запросили, на выходе сохранили. Кешыть не всегда нужно и всегда хорошо Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... sharman35 Опубликовано: 30 ноября 2016 Автор Поделиться Опубликовано: 30 ноября 2016 Настройки магазина -> Количество товаров в подкатегории: нет именно так и стоит. по другому не было. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... chukcha Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 Цитата DISTINCT преобразовывается к GROUP BY для всех столбцов, для DISTINCT в сочетании с ORDER BY, помимо этого, во многих случаях также требуется временная таблица. Вот-вот. А это дополнительные расходы для ОДНОЙ записи. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... ArtemPitov Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 именно так и стоит. по другому не было. тут уже нужно смотреть сколько товаров и что тормозит систему Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... chukcha Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 db_log в поощь Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... sharman35 Опубликовано: 30 ноября 2016 Автор Поделиться Опубликовано: 30 ноября 2016 тут уже нужно смотреть сколько товаров и что тормозит систему пока что 36к, будет около 630к. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Otvet Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 Да чего мелочиться - давайте кешировать готовые страницы. :-) Это кусок из модифицированного мной кеша, там все раскладывается по папочкам, и совершенно не напрягает. К тому же все единообразно: на входе метода модели проверили кеш, далее запросили, на выходе сохранили. как раз таки кешировать страницы это та же степь в модели плодить кеши getCategory, потом каждый раз дергать сотню файлов при построении дерева это глупость а закешировать одно дерево (module/category или header) в 1 файл это оптимизация Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... chukcha Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 Да чего мелочиться - давайте кешировать готовые страницы. Не совсем Можно, полностью закешировать некоторые модули, например рекомендуемые, слайдеры, которые не требуют динамических данных Можно закешировать футер, если в него не попадают, какие-нибудь динамические данные header кешировать нельзя, из-за наличия динамических данных стилей, скриптов Т.е. подход к кешированию, должен быть обдуманный OFFTOP Но, для правильной организации кеша, нужно предусмотреть другой механизм генерации 1. Генерация контента 2. Генерация position 3. Генерация footer 4. Генерация header И это все в разных потоках п.2 можно исключить, потому что он принадлежит потоку Т.е. в output попадает не сгенерированный контент А элементы массива $output['header'] $output['content'] array( 'column_left', 'content' 'column_right' ) $output['footer'] Но эти рассуждения НИ О ЧЕМ... Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 как раз таки кешировать страницы это та же степь в модели плодить кеши getCategory, потом каждый раз дергать сотню файлов при построении дерева это глупость а закешировать одно дерево (module/category или header) в 1 файл это оптимизация Вы не путайте getCategory и getCategories. При построении меню используется второе. Соответственно: если будут только корневые директории - прочитаем 1 файл корневые + поддиректории - прочитаем, условно, 10 файлов корневые + поддиректории + подподдиректории - прочитаем, условно, 100 файлов (здесь да, имеет смысл сохранять готовое дерево) Правильно кеширование делать именно в моделях, т.к. неизвестно из какого контроллера прийдет туда запрос. Это основа, и она всегда должна работать быстро. Ну, если и этого не хватает - тогда добавляйте дополнительный кеш уже на уровне контроллера, целого модуля, блока или вообще целой страницы. Например, вот такая "матрешка" для высоконагруженного проекта: - кеш mysql - кеш на уровне моделей (файловый, мемкеш) - кеш на уровне контроллеров (особо тяжелые куски) - кеш модуля - кеш всей страницы Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... chukcha Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 public function getCategory($category_id) { $category_info = $this->cache->get((int)$this->config->get('config_language_id') . '.' . (int)$this->config->get('config_store_id') . '.' . (int)$category_id); if (FALSE === $category_info) { $query = $this->db->query("SELECT DISTINCT * FROM " . DB_PREFIX . "category c LEFT JOIN " . DB_PREFIX . "category_description cd ON (c.category_id = cd.category_id) LEFT JOIN " . DB_PREFIX . "category_to_store c2s ON (c.category_id = c2s.category_id) WHERE c.category_id = '" . (int)$category_id . "' AND cd.language_id = '" . (int)$this->config->get('config_language_id') . "' AND c2s.store_id = '" . (int)$this->config->get('config_store_id') . "' AND c.status = '1'"); $category_info = $query->row; $this->cache->set((int)$this->config->get('config_language_id') . '.' . (int)$this->config->get('config_store_id') . '.' . (int)$category_id, $category_info); } return $category_info; } @druzhkov, кто предложил этот код? Вы не путайте getCategory и getCategories. Кто и что путает? Вы уж определитесь. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 Кто и что путает? Вы уж определитесь. Вот запрос топикстартера: SELECT * FROM oc_category c LEFT JOIN oc_category_description cd ON (c.category_id = cd.category_id) LEFT JOIN oc_category_to_store c2s ON (c.category_id = c2s.category_id) WHERE c.parent_id = '503' AND cd.language_id = '1' AND c2s.store_id = '0' AND c.status = '1' ORDER BY c.sort_order, LCASE(cd.name) Вот мой код из getCategories: SELECT * FROM " . DB_PREFIX . "category c LEFT JOIN " . DB_PREFIX . "category_description cd ON (c.category_id = cd.category_id) LEFT JOIN " . DB_PREFIX . "category_to_store c2s ON (c.category_id = c2s.category_id) WHERE c.parent_id = '" . (int)$parent_id . "' AND cd.language_id = '" . (int)$this->config->get('config_language_id') . "' AND c2s.store_id = '" . (int)$this->config->get('config_store_id') . "' AND c.status = '1' ORDER BY c.sort_order, LCASE(cd.name) Совпадают? Я не понимаю, чего вы привязались к getCategory. Если не нравится, можно туда не смотреть. Это попутно скопировались из редактора. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... chukcha Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 Что скопировалось? Это $category_info = $this->cache->get((int)$this->config->get('config_language_id') . '.' . (int)$this->config->get('config_store_id') . '.' . (int)$category_id); что-то я не вижу разницы в запросе Один скомпилированный, второй - в модели. Кто предложил кешировать этот запрос? (привел пример) Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 что-то я не вижу разницы в запросе Один скомпилированный, второй - в модели. Кто предложил кешировать этот запрос? (привел пример) Разницы и не должно быть. ТС привел лог и сказал, что тормозит магазин. Логично заключить, что это медленные запросы. Я привел вариант, как их можно закешировать. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... chukcha Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 Вам здесь пытаются объяснить, что кешировать getCategory - бессмысленно Кроме того, также показана неверная конструкция SELECT c использованием DISTINCT Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 Кроме того, также показана неверная конструкция SELECT c использованием DISTINCT Если вас не устраивает, сделайте пулл реквест на гитхаб опенкарта. Данная конструкция стоит как в 1.5, так и в 2.0. Вам здесь пытаются объяснить, что кешировать getCategory - бессмысленно Еще раз напишите обоснование бесмысленности. Не понимаю вашу мысль. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... chukcha Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 Повторять две страницы? Увольте. Те кто заинтересовался - прочтет и поймет. Там 1. Вопрос для понимания 2. Тесты 3. Рассуждения о бессмысленности кеширования одной строки в выборке Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Вы, коллега, полагаю, с высоконагруженными проектами не работали? В любом случае, нужно пояснить: - mysql не резиновый, и при высокой посещаемости всякая мелочь, которой очень много, начинает реально тормозить - а бывает, что сервер базы вообще выносят отдельно, и любые запросы к нему - это дополнительные затраты времени - а еще бывает, что в команде разработчиков кто-то начал делать запросы к незакешированному методу (бывает и в цикле), а тимлид не уследил, потому что он не тысячерукий бог Шива, и снова пошла нагрузка - и т.д. и т.п. Так что это нормальная практика. 100 файлов кеша от getcategory на мелком сайте погоды не делают, а на большом могут сэкономить нервные клетки разработчиков. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Вы, коллега, полагаю, с высоконагруженными проектами не работали? В любом случае, нужно пояснить: - mysql не резиновый, и при высокой посещаемости всякая мелочь, которой очень много, начинает реально тормозить - а бывает, что сервер базы вообще выносят отдельно, и любые запросы к нему - это дополнительные затраты времени - а еще бывает, что в команде разработчиков кто-то начал делать запросы к незакешированному методу (бывает и в цикле), а тимлид не уследил, потому что он не тысячерукий бог Шива, и снова пошла нагрузка - и т.д. и т.п. Так что это нормальная практика. 100 файлов кеша от getcategory на мелком сайте погоды не делают, а на большом могут сэкономить нервные клетки разработчиков. Я работал. И однозначно могу сказать что вы пишите бред! Mysql - резиновый и упирается только в ресурсы сервера. Большое количество товаров - это большое количество постоянных изменений данных, поэтому кеш здесь не то что не панацея - а совсем не вариант. А бывает что не только базы выносят на сервер, а под сегменты таблиц ставят отдельную редиску, которая обслуживает к прмеру клиентов, у которых имя начинается на A, а потом еще одну, у которых на B и так 33 штуки до Z. 630 000 - это не мало и не много. MySql кушает и не кашляет. Но вот некоторые реализации требуют напильника. Умные матюки про teamlead - оставьте молоденьким девчонкам. 100 файлов кеша на getCategory это в 100 раз хуже, чем один кеш на все дерево. И в 10 000 раз хуже, чем один запрос на все дерево и формирование дерева через узлы массива. Вобщем крайне рекомендую, прежде чем писать такие комментарии всерьех подумать, есть ли у вас для них квалификация. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Большое количество товаров - это большое количество постоянных изменений данных, поэтому кеш здесь не то что не панацея - а совсем не вариант. Такое ощущение, что у вас товары меняются ежесекундно. :-) Кеш очень даже неплох. Прикидываете среднее время изменения одного товара - это будет время жизни его кеша. Товар поменялся, почистили его кеш и связанные с ним кеши (категорий, модулей и т.д.), остальные кеши не трогаете. В чем проблема? 100 файлов кеша на getCategory это в 100 раз хуже, чем один кеш на все дерево. И в 10 000 раз хуже, чем один запрос на все дерево и формирование дерева через узлы массива. А вы выше читали мой коммент про многоуровневые кеши (номер 35 в теме)? Или чисто забежали в тему, чтобы отписаться? Если вам достаточно кешировать все дерево, и вы абсолютно уверены, что никто не дергает методы моделей без кеширования - ну, я только порадуюсь за вас. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Вы не за меня радуйтесь - а за себя грустите. Потому как тот механизм который предлагаете вы, база отрабатывает быстрее чем кеш! И в нем смысла нет.Еще раз повторяю. Заканчивайте вредные советы! Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Такое ощущение, что у вас товары меняются ежесекундно. :-) Кеш очень даже неплох. Прикидываете среднее время изменения одного товара - это будет время жизни его кеша. Товар поменялся, почистили его кеш и связанные с ним кеши (категорий, модулей и т.д.), остальные кеши не трогаете. В чем проблема? А вы выше читали мой коммент про многоуровневые кеши (номер 35 в теме)? Или чисто забежали в тему, чтобы отписаться? Если вам достаточно кешировать все дерево, и вы абсолютно уверены, что никто не дергает методы моделей без кеширования - ну, я только порадуюсь за вас. Все придумано и реализовано до вас в модуле Turbo. 1 Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Otvet Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 @druzhkov, ок, я малость смешал в кучу придется расписать... 1. getCategory очень легкий запрос, и вызывается единицы раз на страницу. Mysql работает значительно быстрее нежели засоренная ФС через glob 2. getCategories чуть тяжелее, вызывается множественно только во всяких меню. Не имеет смысла кешировать детали паззла если можно собранный P/S Создавая кучу файлов, пускай даже прямого влияния на сам кешированный запрос и не будет, зато замедлит работу кеша в целом, например сео_про. И мифическая оптимизация приведет к общему минусу Не стоит сравнивать mysql с ФС, как минимум до тех пор пока: это не SSD физически полностью не выделен, что позволяет задействовать аппаратные технологии ускорения ФС (а когда на одном устройстве сотня клиентов этого не будет) используется glob Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Потому как тот механизм который предлагаете вы, база отрабатывает быстрее чем кеш! Вот тест: public function test() { $this->load->model('catalog/category'); $mtime = explode(" ", microtime()); $start_time = $mtime[1] + $mtime[0]; for ($j = 0; $j < 100000; $j++) { $category_info = $this->model_catalog_category->getCategory(209); } $mtime = explode(" ", microtime()); printf ("page generated %f sec", $mtime[1] + $mtime[0] - $start_time); } Из базы 8.771922 sec , из кеша 3.218499 sec. Замечания, наблюдения? Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Вот тест: public function test() { $this->load->model('catalog/category'); $mtime = explode(" ", microtime()); $start_time = $mtime[1] + $mtime[0]; for ($j = 0; $j < 100000; $j++) { $category_info = $this->model_catalog_category->getCategory(209); } $mtime = explode(" ", microtime()); printf ("page generated %f sec", $mtime[1] + $mtime[0] - $start_time); } Из базы 8.771922 sec , из кеша 3.218499 sec. Замечания, наблюдения? Параметры базы, параметры сервера, структура таблиц, индексы на таблицах, количество файлов в папке с кешем, очередь чтения c диска в боевом режиме, внутренний механизм кеширования mysql - не, не слышал? Если на reg.ru на шареде за две копейки - разница будет раз в 100 отличаться. Только разница между вашими теоретическими выкладками и моими тезисами в том, что вы знаете слово teamlead и живете в синтетических тестах, а я сутки на пролет занимаюсь построением больших систем и оптимизацией средних. Поэтому все о чем вы сейчас пытаетесь с пеной у рта рассказать, пройдено в третьем классе так сказать. Я долго не мог понять, кто эти специалисты, после которых люди приходят ко мне со словами "пятеро уже работали, а тормозит как тормозило". И еще конкретно этот пример оптимизируется совершенно иным методом. Если речь идет о методе из 2.x, если внимательно посмотреть в запрос в нем идет выборка SELECT * из нескольких таблиц c последующей сортировкой по lcase(name). Если включить немного мозг и изучить матчасть по mysql. То логичным будет делать выборку SELECT category_id с составным индексом по полям status и parent_id. В этом случае скорость работы запроса увеличвается в несколько сот раз на больших магазинах. И после этого к результирующему набору дособрать необходимые данные (name, title, descr etc...) и уже средствами php по минимальному набору данных осуществить сортировку по названию. Ни один кеш стандартного метода и рядом стоять не будет, я уже молчу про глобальное снижение нагрузки на всю систему. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Назад 1 2 3 Вперёд Страница 2 из 3 Создайте аккаунт или войдите в него для комментирования Вы должны быть пользователем, чтобы оставить комментарий Создать аккаунт Зарегистрируйтесь для получения аккаунта. Это просто! Зарегистрировать аккаунт Войти Уже зарегистрированы? Войдите здесь. Войти сейчас Поделиться Больше способов поделиться... Подписчики 0 Перейти к списку тем Сейчас на странице 0 пользователей Нет пользователей, просматривающих эту страницу. Последние темы Последние дополнения Последние новости Вся активность Главная Поддержка и ответы на вопросы Отчёты об ошибках Помогите разобраться с логом Mysql Покупцям Оплата розширень фізичними особами Оплата розширень юридичними особами Політика повернень Розробникам Регламент розміщення розширень Регламент продажу та підтримки розширень Віртуальний обліковий запис автора Політика просування оголошень API каталогу розширень Вирішення спорів щодо авторських прав Корисна інформація Публічна оферта Політика повернень Політика конфіденційності Платіжна політика Політика передачі особистих даних Політика прозорості Останні розширення Deals – адаптивный универсальный шаблон Автор: octemplates Динамичесткая инфострока в шапке + позиция в макете для opencart\ocstore 2x, 3x Автор: Lito911 Единицы Измерения Товара Автор: RoS Opencart Product Search by Image Автор: slavoglo Простой массовый редактор цен. Fast Price Edit Автор: Sha × Уже зарегистрированы? Войти Регистрация Раздел покупок Назад Приобретенные дополнения Ваши счета Список желаний Альтернативные контакты Форум Новости ocStore Назад Официальный сайт Демо ocStore 3.0.3.2 Демо ocStore 2.3.0.2.4 Скачать ocStore Документация История версий ocStore Блоги Модули Шаблоны Назад Бесплатные шаблоны Платные шаблоны Где покупать модули? Услуги FAQ OpenCart.Pro Назад Демо Купить Сравнение × Создать... Важная информация На нашем сайте используются файлы cookie и происходит обработка некоторых персональных данных пользователей, чтобы улучшить пользовательский интерфейс. Чтобы узнать для чего и какие персональные данные мы обрабатываем перейдите по ссылке. Если Вы нажмете «Я даю согласие», это означает, что Вы понимаете и принимаете все условия, указанные в этом Уведомлении о Конфиденциальности. Я принимаю
ArtemPitov Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 Да чего мелочиться - давайте кешировать готовые страницы. :-) Это кусок из модифицированного мной кеша, там все раскладывается по папочкам, и совершенно не напрягает. К тому же все единообразно: на входе метода модели проверили кеш, далее запросили, на выходе сохранили. Кешыть не всегда нужно и всегда хорошо Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... sharman35 Опубликовано: 30 ноября 2016 Автор Поделиться Опубликовано: 30 ноября 2016 Настройки магазина -> Количество товаров в подкатегории: нет именно так и стоит. по другому не было. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... chukcha Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 Цитата DISTINCT преобразовывается к GROUP BY для всех столбцов, для DISTINCT в сочетании с ORDER BY, помимо этого, во многих случаях также требуется временная таблица. Вот-вот. А это дополнительные расходы для ОДНОЙ записи. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... ArtemPitov Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 именно так и стоит. по другому не было. тут уже нужно смотреть сколько товаров и что тормозит систему Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... chukcha Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 db_log в поощь Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... sharman35 Опубликовано: 30 ноября 2016 Автор Поделиться Опубликовано: 30 ноября 2016 тут уже нужно смотреть сколько товаров и что тормозит систему пока что 36к, будет около 630к. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Otvet Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 Да чего мелочиться - давайте кешировать готовые страницы. :-) Это кусок из модифицированного мной кеша, там все раскладывается по папочкам, и совершенно не напрягает. К тому же все единообразно: на входе метода модели проверили кеш, далее запросили, на выходе сохранили. как раз таки кешировать страницы это та же степь в модели плодить кеши getCategory, потом каждый раз дергать сотню файлов при построении дерева это глупость а закешировать одно дерево (module/category или header) в 1 файл это оптимизация Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... chukcha Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 Да чего мелочиться - давайте кешировать готовые страницы. Не совсем Можно, полностью закешировать некоторые модули, например рекомендуемые, слайдеры, которые не требуют динамических данных Можно закешировать футер, если в него не попадают, какие-нибудь динамические данные header кешировать нельзя, из-за наличия динамических данных стилей, скриптов Т.е. подход к кешированию, должен быть обдуманный OFFTOP Но, для правильной организации кеша, нужно предусмотреть другой механизм генерации 1. Генерация контента 2. Генерация position 3. Генерация footer 4. Генерация header И это все в разных потоках п.2 можно исключить, потому что он принадлежит потоку Т.е. в output попадает не сгенерированный контент А элементы массива $output['header'] $output['content'] array( 'column_left', 'content' 'column_right' ) $output['footer'] Но эти рассуждения НИ О ЧЕМ... Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 как раз таки кешировать страницы это та же степь в модели плодить кеши getCategory, потом каждый раз дергать сотню файлов при построении дерева это глупость а закешировать одно дерево (module/category или header) в 1 файл это оптимизация Вы не путайте getCategory и getCategories. При построении меню используется второе. Соответственно: если будут только корневые директории - прочитаем 1 файл корневые + поддиректории - прочитаем, условно, 10 файлов корневые + поддиректории + подподдиректории - прочитаем, условно, 100 файлов (здесь да, имеет смысл сохранять готовое дерево) Правильно кеширование делать именно в моделях, т.к. неизвестно из какого контроллера прийдет туда запрос. Это основа, и она всегда должна работать быстро. Ну, если и этого не хватает - тогда добавляйте дополнительный кеш уже на уровне контроллера, целого модуля, блока или вообще целой страницы. Например, вот такая "матрешка" для высоконагруженного проекта: - кеш mysql - кеш на уровне моделей (файловый, мемкеш) - кеш на уровне контроллеров (особо тяжелые куски) - кеш модуля - кеш всей страницы Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... chukcha Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 public function getCategory($category_id) { $category_info = $this->cache->get((int)$this->config->get('config_language_id') . '.' . (int)$this->config->get('config_store_id') . '.' . (int)$category_id); if (FALSE === $category_info) { $query = $this->db->query("SELECT DISTINCT * FROM " . DB_PREFIX . "category c LEFT JOIN " . DB_PREFIX . "category_description cd ON (c.category_id = cd.category_id) LEFT JOIN " . DB_PREFIX . "category_to_store c2s ON (c.category_id = c2s.category_id) WHERE c.category_id = '" . (int)$category_id . "' AND cd.language_id = '" . (int)$this->config->get('config_language_id') . "' AND c2s.store_id = '" . (int)$this->config->get('config_store_id') . "' AND c.status = '1'"); $category_info = $query->row; $this->cache->set((int)$this->config->get('config_language_id') . '.' . (int)$this->config->get('config_store_id') . '.' . (int)$category_id, $category_info); } return $category_info; } @druzhkov, кто предложил этот код? Вы не путайте getCategory и getCategories. Кто и что путает? Вы уж определитесь. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 Кто и что путает? Вы уж определитесь. Вот запрос топикстартера: SELECT * FROM oc_category c LEFT JOIN oc_category_description cd ON (c.category_id = cd.category_id) LEFT JOIN oc_category_to_store c2s ON (c.category_id = c2s.category_id) WHERE c.parent_id = '503' AND cd.language_id = '1' AND c2s.store_id = '0' AND c.status = '1' ORDER BY c.sort_order, LCASE(cd.name) Вот мой код из getCategories: SELECT * FROM " . DB_PREFIX . "category c LEFT JOIN " . DB_PREFIX . "category_description cd ON (c.category_id = cd.category_id) LEFT JOIN " . DB_PREFIX . "category_to_store c2s ON (c.category_id = c2s.category_id) WHERE c.parent_id = '" . (int)$parent_id . "' AND cd.language_id = '" . (int)$this->config->get('config_language_id') . "' AND c2s.store_id = '" . (int)$this->config->get('config_store_id') . "' AND c.status = '1' ORDER BY c.sort_order, LCASE(cd.name) Совпадают? Я не понимаю, чего вы привязались к getCategory. Если не нравится, можно туда не смотреть. Это попутно скопировались из редактора. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... chukcha Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 Что скопировалось? Это $category_info = $this->cache->get((int)$this->config->get('config_language_id') . '.' . (int)$this->config->get('config_store_id') . '.' . (int)$category_id); что-то я не вижу разницы в запросе Один скомпилированный, второй - в модели. Кто предложил кешировать этот запрос? (привел пример) Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 что-то я не вижу разницы в запросе Один скомпилированный, второй - в модели. Кто предложил кешировать этот запрос? (привел пример) Разницы и не должно быть. ТС привел лог и сказал, что тормозит магазин. Логично заключить, что это медленные запросы. Я привел вариант, как их можно закешировать. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... chukcha Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 Вам здесь пытаются объяснить, что кешировать getCategory - бессмысленно Кроме того, также показана неверная конструкция SELECT c использованием DISTINCT Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 Кроме того, также показана неверная конструкция SELECT c использованием DISTINCT Если вас не устраивает, сделайте пулл реквест на гитхаб опенкарта. Данная конструкция стоит как в 1.5, так и в 2.0. Вам здесь пытаются объяснить, что кешировать getCategory - бессмысленно Еще раз напишите обоснование бесмысленности. Не понимаю вашу мысль. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... chukcha Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 Повторять две страницы? Увольте. Те кто заинтересовался - прочтет и поймет. Там 1. Вопрос для понимания 2. Тесты 3. Рассуждения о бессмысленности кеширования одной строки в выборке Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Вы, коллега, полагаю, с высоконагруженными проектами не работали? В любом случае, нужно пояснить: - mysql не резиновый, и при высокой посещаемости всякая мелочь, которой очень много, начинает реально тормозить - а бывает, что сервер базы вообще выносят отдельно, и любые запросы к нему - это дополнительные затраты времени - а еще бывает, что в команде разработчиков кто-то начал делать запросы к незакешированному методу (бывает и в цикле), а тимлид не уследил, потому что он не тысячерукий бог Шива, и снова пошла нагрузка - и т.д. и т.п. Так что это нормальная практика. 100 файлов кеша от getcategory на мелком сайте погоды не делают, а на большом могут сэкономить нервные клетки разработчиков. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Вы, коллега, полагаю, с высоконагруженными проектами не работали? В любом случае, нужно пояснить: - mysql не резиновый, и при высокой посещаемости всякая мелочь, которой очень много, начинает реально тормозить - а бывает, что сервер базы вообще выносят отдельно, и любые запросы к нему - это дополнительные затраты времени - а еще бывает, что в команде разработчиков кто-то начал делать запросы к незакешированному методу (бывает и в цикле), а тимлид не уследил, потому что он не тысячерукий бог Шива, и снова пошла нагрузка - и т.д. и т.п. Так что это нормальная практика. 100 файлов кеша от getcategory на мелком сайте погоды не делают, а на большом могут сэкономить нервные клетки разработчиков. Я работал. И однозначно могу сказать что вы пишите бред! Mysql - резиновый и упирается только в ресурсы сервера. Большое количество товаров - это большое количество постоянных изменений данных, поэтому кеш здесь не то что не панацея - а совсем не вариант. А бывает что не только базы выносят на сервер, а под сегменты таблиц ставят отдельную редиску, которая обслуживает к прмеру клиентов, у которых имя начинается на A, а потом еще одну, у которых на B и так 33 штуки до Z. 630 000 - это не мало и не много. MySql кушает и не кашляет. Но вот некоторые реализации требуют напильника. Умные матюки про teamlead - оставьте молоденьким девчонкам. 100 файлов кеша на getCategory это в 100 раз хуже, чем один кеш на все дерево. И в 10 000 раз хуже, чем один запрос на все дерево и формирование дерева через узлы массива. Вобщем крайне рекомендую, прежде чем писать такие комментарии всерьех подумать, есть ли у вас для них квалификация. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Большое количество товаров - это большое количество постоянных изменений данных, поэтому кеш здесь не то что не панацея - а совсем не вариант. Такое ощущение, что у вас товары меняются ежесекундно. :-) Кеш очень даже неплох. Прикидываете среднее время изменения одного товара - это будет время жизни его кеша. Товар поменялся, почистили его кеш и связанные с ним кеши (категорий, модулей и т.д.), остальные кеши не трогаете. В чем проблема? 100 файлов кеша на getCategory это в 100 раз хуже, чем один кеш на все дерево. И в 10 000 раз хуже, чем один запрос на все дерево и формирование дерева через узлы массива. А вы выше читали мой коммент про многоуровневые кеши (номер 35 в теме)? Или чисто забежали в тему, чтобы отписаться? Если вам достаточно кешировать все дерево, и вы абсолютно уверены, что никто не дергает методы моделей без кеширования - ну, я только порадуюсь за вас. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Вы не за меня радуйтесь - а за себя грустите. Потому как тот механизм который предлагаете вы, база отрабатывает быстрее чем кеш! И в нем смысла нет.Еще раз повторяю. Заканчивайте вредные советы! Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Такое ощущение, что у вас товары меняются ежесекундно. :-) Кеш очень даже неплох. Прикидываете среднее время изменения одного товара - это будет время жизни его кеша. Товар поменялся, почистили его кеш и связанные с ним кеши (категорий, модулей и т.д.), остальные кеши не трогаете. В чем проблема? А вы выше читали мой коммент про многоуровневые кеши (номер 35 в теме)? Или чисто забежали в тему, чтобы отписаться? Если вам достаточно кешировать все дерево, и вы абсолютно уверены, что никто не дергает методы моделей без кеширования - ну, я только порадуюсь за вас. Все придумано и реализовано до вас в модуле Turbo. 1 Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Otvet Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 @druzhkov, ок, я малость смешал в кучу придется расписать... 1. getCategory очень легкий запрос, и вызывается единицы раз на страницу. Mysql работает значительно быстрее нежели засоренная ФС через glob 2. getCategories чуть тяжелее, вызывается множественно только во всяких меню. Не имеет смысла кешировать детали паззла если можно собранный P/S Создавая кучу файлов, пускай даже прямого влияния на сам кешированный запрос и не будет, зато замедлит работу кеша в целом, например сео_про. И мифическая оптимизация приведет к общему минусу Не стоит сравнивать mysql с ФС, как минимум до тех пор пока: это не SSD физически полностью не выделен, что позволяет задействовать аппаратные технологии ускорения ФС (а когда на одном устройстве сотня клиентов этого не будет) используется glob Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Потому как тот механизм который предлагаете вы, база отрабатывает быстрее чем кеш! Вот тест: public function test() { $this->load->model('catalog/category'); $mtime = explode(" ", microtime()); $start_time = $mtime[1] + $mtime[0]; for ($j = 0; $j < 100000; $j++) { $category_info = $this->model_catalog_category->getCategory(209); } $mtime = explode(" ", microtime()); printf ("page generated %f sec", $mtime[1] + $mtime[0] - $start_time); } Из базы 8.771922 sec , из кеша 3.218499 sec. Замечания, наблюдения? Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Вот тест: public function test() { $this->load->model('catalog/category'); $mtime = explode(" ", microtime()); $start_time = $mtime[1] + $mtime[0]; for ($j = 0; $j < 100000; $j++) { $category_info = $this->model_catalog_category->getCategory(209); } $mtime = explode(" ", microtime()); printf ("page generated %f sec", $mtime[1] + $mtime[0] - $start_time); } Из базы 8.771922 sec , из кеша 3.218499 sec. Замечания, наблюдения? Параметры базы, параметры сервера, структура таблиц, индексы на таблицах, количество файлов в папке с кешем, очередь чтения c диска в боевом режиме, внутренний механизм кеширования mysql - не, не слышал? Если на reg.ru на шареде за две копейки - разница будет раз в 100 отличаться. Только разница между вашими теоретическими выкладками и моими тезисами в том, что вы знаете слово teamlead и живете в синтетических тестах, а я сутки на пролет занимаюсь построением больших систем и оптимизацией средних. Поэтому все о чем вы сейчас пытаетесь с пеной у рта рассказать, пройдено в третьем классе так сказать. Я долго не мог понять, кто эти специалисты, после которых люди приходят ко мне со словами "пятеро уже работали, а тормозит как тормозило". И еще конкретно этот пример оптимизируется совершенно иным методом. Если речь идет о методе из 2.x, если внимательно посмотреть в запрос в нем идет выборка SELECT * из нескольких таблиц c последующей сортировкой по lcase(name). Если включить немного мозг и изучить матчасть по mysql. То логичным будет делать выборку SELECT category_id с составным индексом по полям status и parent_id. В этом случае скорость работы запроса увеличвается в несколько сот раз на больших магазинах. И после этого к результирующему набору дособрать необходимые данные (name, title, descr etc...) и уже средствами php по минимальному набору данных осуществить сортировку по названию. Ни один кеш стандартного метода и рядом стоять не будет, я уже молчу про глобальное снижение нагрузки на всю систему. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Назад 1 2 3 Вперёд Страница 2 из 3 Создайте аккаунт или войдите в него для комментирования Вы должны быть пользователем, чтобы оставить комментарий Создать аккаунт Зарегистрируйтесь для получения аккаунта. Это просто! Зарегистрировать аккаунт Войти Уже зарегистрированы? Войдите здесь. Войти сейчас Поделиться Больше способов поделиться... Подписчики 0 Перейти к списку тем Сейчас на странице 0 пользователей Нет пользователей, просматривающих эту страницу. Последние темы Последние дополнения Последние новости Вся активность Главная Поддержка и ответы на вопросы Отчёты об ошибках Помогите разобраться с логом Mysql Покупцям Оплата розширень фізичними особами Оплата розширень юридичними особами Політика повернень Розробникам Регламент розміщення розширень Регламент продажу та підтримки розширень Віртуальний обліковий запис автора Політика просування оголошень API каталогу розширень Вирішення спорів щодо авторських прав Корисна інформація Публічна оферта Політика повернень Політика конфіденційності Платіжна політика Політика передачі особистих даних Політика прозорості Останні розширення Deals – адаптивный универсальный шаблон Автор: octemplates Динамичесткая инфострока в шапке + позиция в макете для opencart\ocstore 2x, 3x Автор: Lito911 Единицы Измерения Товара Автор: RoS Opencart Product Search by Image Автор: slavoglo Простой массовый редактор цен. Fast Price Edit Автор: Sha × Уже зарегистрированы? Войти Регистрация Раздел покупок Назад Приобретенные дополнения Ваши счета Список желаний Альтернативные контакты Форум Новости ocStore Назад Официальный сайт Демо ocStore 3.0.3.2 Демо ocStore 2.3.0.2.4 Скачать ocStore Документация История версий ocStore Блоги Модули Шаблоны Назад Бесплатные шаблоны Платные шаблоны Где покупать модули? Услуги FAQ OpenCart.Pro Назад Демо Купить Сравнение × Создать... Важная информация На нашем сайте используются файлы cookie и происходит обработка некоторых персональных данных пользователей, чтобы улучшить пользовательский интерфейс. Чтобы узнать для чего и какие персональные данные мы обрабатываем перейдите по ссылке. Если Вы нажмете «Я даю согласие», это означает, что Вы понимаете и принимаете все условия, указанные в этом Уведомлении о Конфиденциальности. Я принимаю
sharman35 Опубликовано: 30 ноября 2016 Автор Поделиться Опубликовано: 30 ноября 2016 Настройки магазина -> Количество товаров в подкатегории: нет именно так и стоит. по другому не было. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться...
chukcha Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 Цитата DISTINCT преобразовывается к GROUP BY для всех столбцов, для DISTINCT в сочетании с ORDER BY, помимо этого, во многих случаях также требуется временная таблица. Вот-вот. А это дополнительные расходы для ОДНОЙ записи. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... ArtemPitov Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 именно так и стоит. по другому не было. тут уже нужно смотреть сколько товаров и что тормозит систему Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... chukcha Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 db_log в поощь Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... sharman35 Опубликовано: 30 ноября 2016 Автор Поделиться Опубликовано: 30 ноября 2016 тут уже нужно смотреть сколько товаров и что тормозит систему пока что 36к, будет около 630к. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Otvet Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 Да чего мелочиться - давайте кешировать готовые страницы. :-) Это кусок из модифицированного мной кеша, там все раскладывается по папочкам, и совершенно не напрягает. К тому же все единообразно: на входе метода модели проверили кеш, далее запросили, на выходе сохранили. как раз таки кешировать страницы это та же степь в модели плодить кеши getCategory, потом каждый раз дергать сотню файлов при построении дерева это глупость а закешировать одно дерево (module/category или header) в 1 файл это оптимизация Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... chukcha Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 Да чего мелочиться - давайте кешировать готовые страницы. Не совсем Можно, полностью закешировать некоторые модули, например рекомендуемые, слайдеры, которые не требуют динамических данных Можно закешировать футер, если в него не попадают, какие-нибудь динамические данные header кешировать нельзя, из-за наличия динамических данных стилей, скриптов Т.е. подход к кешированию, должен быть обдуманный OFFTOP Но, для правильной организации кеша, нужно предусмотреть другой механизм генерации 1. Генерация контента 2. Генерация position 3. Генерация footer 4. Генерация header И это все в разных потоках п.2 можно исключить, потому что он принадлежит потоку Т.е. в output попадает не сгенерированный контент А элементы массива $output['header'] $output['content'] array( 'column_left', 'content' 'column_right' ) $output['footer'] Но эти рассуждения НИ О ЧЕМ... Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 как раз таки кешировать страницы это та же степь в модели плодить кеши getCategory, потом каждый раз дергать сотню файлов при построении дерева это глупость а закешировать одно дерево (module/category или header) в 1 файл это оптимизация Вы не путайте getCategory и getCategories. При построении меню используется второе. Соответственно: если будут только корневые директории - прочитаем 1 файл корневые + поддиректории - прочитаем, условно, 10 файлов корневые + поддиректории + подподдиректории - прочитаем, условно, 100 файлов (здесь да, имеет смысл сохранять готовое дерево) Правильно кеширование делать именно в моделях, т.к. неизвестно из какого контроллера прийдет туда запрос. Это основа, и она всегда должна работать быстро. Ну, если и этого не хватает - тогда добавляйте дополнительный кеш уже на уровне контроллера, целого модуля, блока или вообще целой страницы. Например, вот такая "матрешка" для высоконагруженного проекта: - кеш mysql - кеш на уровне моделей (файловый, мемкеш) - кеш на уровне контроллеров (особо тяжелые куски) - кеш модуля - кеш всей страницы Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... chukcha Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 public function getCategory($category_id) { $category_info = $this->cache->get((int)$this->config->get('config_language_id') . '.' . (int)$this->config->get('config_store_id') . '.' . (int)$category_id); if (FALSE === $category_info) { $query = $this->db->query("SELECT DISTINCT * FROM " . DB_PREFIX . "category c LEFT JOIN " . DB_PREFIX . "category_description cd ON (c.category_id = cd.category_id) LEFT JOIN " . DB_PREFIX . "category_to_store c2s ON (c.category_id = c2s.category_id) WHERE c.category_id = '" . (int)$category_id . "' AND cd.language_id = '" . (int)$this->config->get('config_language_id') . "' AND c2s.store_id = '" . (int)$this->config->get('config_store_id') . "' AND c.status = '1'"); $category_info = $query->row; $this->cache->set((int)$this->config->get('config_language_id') . '.' . (int)$this->config->get('config_store_id') . '.' . (int)$category_id, $category_info); } return $category_info; } @druzhkov, кто предложил этот код? Вы не путайте getCategory и getCategories. Кто и что путает? Вы уж определитесь. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 Кто и что путает? Вы уж определитесь. Вот запрос топикстартера: SELECT * FROM oc_category c LEFT JOIN oc_category_description cd ON (c.category_id = cd.category_id) LEFT JOIN oc_category_to_store c2s ON (c.category_id = c2s.category_id) WHERE c.parent_id = '503' AND cd.language_id = '1' AND c2s.store_id = '0' AND c.status = '1' ORDER BY c.sort_order, LCASE(cd.name) Вот мой код из getCategories: SELECT * FROM " . DB_PREFIX . "category c LEFT JOIN " . DB_PREFIX . "category_description cd ON (c.category_id = cd.category_id) LEFT JOIN " . DB_PREFIX . "category_to_store c2s ON (c.category_id = c2s.category_id) WHERE c.parent_id = '" . (int)$parent_id . "' AND cd.language_id = '" . (int)$this->config->get('config_language_id') . "' AND c2s.store_id = '" . (int)$this->config->get('config_store_id') . "' AND c.status = '1' ORDER BY c.sort_order, LCASE(cd.name) Совпадают? Я не понимаю, чего вы привязались к getCategory. Если не нравится, можно туда не смотреть. Это попутно скопировались из редактора. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... chukcha Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 Что скопировалось? Это $category_info = $this->cache->get((int)$this->config->get('config_language_id') . '.' . (int)$this->config->get('config_store_id') . '.' . (int)$category_id); что-то я не вижу разницы в запросе Один скомпилированный, второй - в модели. Кто предложил кешировать этот запрос? (привел пример) Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 что-то я не вижу разницы в запросе Один скомпилированный, второй - в модели. Кто предложил кешировать этот запрос? (привел пример) Разницы и не должно быть. ТС привел лог и сказал, что тормозит магазин. Логично заключить, что это медленные запросы. Я привел вариант, как их можно закешировать. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... chukcha Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 Вам здесь пытаются объяснить, что кешировать getCategory - бессмысленно Кроме того, также показана неверная конструкция SELECT c использованием DISTINCT Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 Кроме того, также показана неверная конструкция SELECT c использованием DISTINCT Если вас не устраивает, сделайте пулл реквест на гитхаб опенкарта. Данная конструкция стоит как в 1.5, так и в 2.0. Вам здесь пытаются объяснить, что кешировать getCategory - бессмысленно Еще раз напишите обоснование бесмысленности. Не понимаю вашу мысль. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... chukcha Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 Повторять две страницы? Увольте. Те кто заинтересовался - прочтет и поймет. Там 1. Вопрос для понимания 2. Тесты 3. Рассуждения о бессмысленности кеширования одной строки в выборке Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Вы, коллега, полагаю, с высоконагруженными проектами не работали? В любом случае, нужно пояснить: - mysql не резиновый, и при высокой посещаемости всякая мелочь, которой очень много, начинает реально тормозить - а бывает, что сервер базы вообще выносят отдельно, и любые запросы к нему - это дополнительные затраты времени - а еще бывает, что в команде разработчиков кто-то начал делать запросы к незакешированному методу (бывает и в цикле), а тимлид не уследил, потому что он не тысячерукий бог Шива, и снова пошла нагрузка - и т.д. и т.п. Так что это нормальная практика. 100 файлов кеша от getcategory на мелком сайте погоды не делают, а на большом могут сэкономить нервные клетки разработчиков. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Вы, коллега, полагаю, с высоконагруженными проектами не работали? В любом случае, нужно пояснить: - mysql не резиновый, и при высокой посещаемости всякая мелочь, которой очень много, начинает реально тормозить - а бывает, что сервер базы вообще выносят отдельно, и любые запросы к нему - это дополнительные затраты времени - а еще бывает, что в команде разработчиков кто-то начал делать запросы к незакешированному методу (бывает и в цикле), а тимлид не уследил, потому что он не тысячерукий бог Шива, и снова пошла нагрузка - и т.д. и т.п. Так что это нормальная практика. 100 файлов кеша от getcategory на мелком сайте погоды не делают, а на большом могут сэкономить нервные клетки разработчиков. Я работал. И однозначно могу сказать что вы пишите бред! Mysql - резиновый и упирается только в ресурсы сервера. Большое количество товаров - это большое количество постоянных изменений данных, поэтому кеш здесь не то что не панацея - а совсем не вариант. А бывает что не только базы выносят на сервер, а под сегменты таблиц ставят отдельную редиску, которая обслуживает к прмеру клиентов, у которых имя начинается на A, а потом еще одну, у которых на B и так 33 штуки до Z. 630 000 - это не мало и не много. MySql кушает и не кашляет. Но вот некоторые реализации требуют напильника. Умные матюки про teamlead - оставьте молоденьким девчонкам. 100 файлов кеша на getCategory это в 100 раз хуже, чем один кеш на все дерево. И в 10 000 раз хуже, чем один запрос на все дерево и формирование дерева через узлы массива. Вобщем крайне рекомендую, прежде чем писать такие комментарии всерьех подумать, есть ли у вас для них квалификация. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Большое количество товаров - это большое количество постоянных изменений данных, поэтому кеш здесь не то что не панацея - а совсем не вариант. Такое ощущение, что у вас товары меняются ежесекундно. :-) Кеш очень даже неплох. Прикидываете среднее время изменения одного товара - это будет время жизни его кеша. Товар поменялся, почистили его кеш и связанные с ним кеши (категорий, модулей и т.д.), остальные кеши не трогаете. В чем проблема? 100 файлов кеша на getCategory это в 100 раз хуже, чем один кеш на все дерево. И в 10 000 раз хуже, чем один запрос на все дерево и формирование дерева через узлы массива. А вы выше читали мой коммент про многоуровневые кеши (номер 35 в теме)? Или чисто забежали в тему, чтобы отписаться? Если вам достаточно кешировать все дерево, и вы абсолютно уверены, что никто не дергает методы моделей без кеширования - ну, я только порадуюсь за вас. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Вы не за меня радуйтесь - а за себя грустите. Потому как тот механизм который предлагаете вы, база отрабатывает быстрее чем кеш! И в нем смысла нет.Еще раз повторяю. Заканчивайте вредные советы! Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Такое ощущение, что у вас товары меняются ежесекундно. :-) Кеш очень даже неплох. Прикидываете среднее время изменения одного товара - это будет время жизни его кеша. Товар поменялся, почистили его кеш и связанные с ним кеши (категорий, модулей и т.д.), остальные кеши не трогаете. В чем проблема? А вы выше читали мой коммент про многоуровневые кеши (номер 35 в теме)? Или чисто забежали в тему, чтобы отписаться? Если вам достаточно кешировать все дерево, и вы абсолютно уверены, что никто не дергает методы моделей без кеширования - ну, я только порадуюсь за вас. Все придумано и реализовано до вас в модуле Turbo. 1 Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Otvet Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 @druzhkov, ок, я малость смешал в кучу придется расписать... 1. getCategory очень легкий запрос, и вызывается единицы раз на страницу. Mysql работает значительно быстрее нежели засоренная ФС через glob 2. getCategories чуть тяжелее, вызывается множественно только во всяких меню. Не имеет смысла кешировать детали паззла если можно собранный P/S Создавая кучу файлов, пускай даже прямого влияния на сам кешированный запрос и не будет, зато замедлит работу кеша в целом, например сео_про. И мифическая оптимизация приведет к общему минусу Не стоит сравнивать mysql с ФС, как минимум до тех пор пока: это не SSD физически полностью не выделен, что позволяет задействовать аппаратные технологии ускорения ФС (а когда на одном устройстве сотня клиентов этого не будет) используется glob Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Потому как тот механизм который предлагаете вы, база отрабатывает быстрее чем кеш! Вот тест: public function test() { $this->load->model('catalog/category'); $mtime = explode(" ", microtime()); $start_time = $mtime[1] + $mtime[0]; for ($j = 0; $j < 100000; $j++) { $category_info = $this->model_catalog_category->getCategory(209); } $mtime = explode(" ", microtime()); printf ("page generated %f sec", $mtime[1] + $mtime[0] - $start_time); } Из базы 8.771922 sec , из кеша 3.218499 sec. Замечания, наблюдения? Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Вот тест: public function test() { $this->load->model('catalog/category'); $mtime = explode(" ", microtime()); $start_time = $mtime[1] + $mtime[0]; for ($j = 0; $j < 100000; $j++) { $category_info = $this->model_catalog_category->getCategory(209); } $mtime = explode(" ", microtime()); printf ("page generated %f sec", $mtime[1] + $mtime[0] - $start_time); } Из базы 8.771922 sec , из кеша 3.218499 sec. Замечания, наблюдения? Параметры базы, параметры сервера, структура таблиц, индексы на таблицах, количество файлов в папке с кешем, очередь чтения c диска в боевом режиме, внутренний механизм кеширования mysql - не, не слышал? Если на reg.ru на шареде за две копейки - разница будет раз в 100 отличаться. Только разница между вашими теоретическими выкладками и моими тезисами в том, что вы знаете слово teamlead и живете в синтетических тестах, а я сутки на пролет занимаюсь построением больших систем и оптимизацией средних. Поэтому все о чем вы сейчас пытаетесь с пеной у рта рассказать, пройдено в третьем классе так сказать. Я долго не мог понять, кто эти специалисты, после которых люди приходят ко мне со словами "пятеро уже работали, а тормозит как тормозило". И еще конкретно этот пример оптимизируется совершенно иным методом. Если речь идет о методе из 2.x, если внимательно посмотреть в запрос в нем идет выборка SELECT * из нескольких таблиц c последующей сортировкой по lcase(name). Если включить немного мозг и изучить матчасть по mysql. То логичным будет делать выборку SELECT category_id с составным индексом по полям status и parent_id. В этом случае скорость работы запроса увеличвается в несколько сот раз на больших магазинах. И после этого к результирующему набору дособрать необходимые данные (name, title, descr etc...) и уже средствами php по минимальному набору данных осуществить сортировку по названию. Ни один кеш стандартного метода и рядом стоять не будет, я уже молчу про глобальное снижение нагрузки на всю систему. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Назад 1 2 3 Вперёд Страница 2 из 3 Создайте аккаунт или войдите в него для комментирования Вы должны быть пользователем, чтобы оставить комментарий Создать аккаунт Зарегистрируйтесь для получения аккаунта. Это просто! Зарегистрировать аккаунт Войти Уже зарегистрированы? Войдите здесь. Войти сейчас Поделиться Больше способов поделиться... Подписчики 0 Перейти к списку тем Сейчас на странице 0 пользователей Нет пользователей, просматривающих эту страницу. Последние темы Последние дополнения Последние новости Вся активность Главная Поддержка и ответы на вопросы Отчёты об ошибках Помогите разобраться с логом Mysql Покупцям Оплата розширень фізичними особами Оплата розширень юридичними особами Політика повернень Розробникам Регламент розміщення розширень Регламент продажу та підтримки розширень Віртуальний обліковий запис автора Політика просування оголошень API каталогу розширень Вирішення спорів щодо авторських прав Корисна інформація Публічна оферта Політика повернень Політика конфіденційності Платіжна політика Політика передачі особистих даних Політика прозорості Останні розширення Deals – адаптивный универсальный шаблон Автор: octemplates Динамичесткая инфострока в шапке + позиция в макете для opencart\ocstore 2x, 3x Автор: Lito911 Единицы Измерения Товара Автор: RoS Opencart Product Search by Image Автор: slavoglo Простой массовый редактор цен. Fast Price Edit Автор: Sha × Уже зарегистрированы? Войти Регистрация Раздел покупок Назад Приобретенные дополнения Ваши счета Список желаний Альтернативные контакты Форум Новости ocStore Назад Официальный сайт Демо ocStore 3.0.3.2 Демо ocStore 2.3.0.2.4 Скачать ocStore Документация История версий ocStore Блоги Модули Шаблоны Назад Бесплатные шаблоны Платные шаблоны Где покупать модули? Услуги FAQ OpenCart.Pro Назад Демо Купить Сравнение × Создать... Важная информация На нашем сайте используются файлы cookie и происходит обработка некоторых персональных данных пользователей, чтобы улучшить пользовательский интерфейс. Чтобы узнать для чего и какие персональные данные мы обрабатываем перейдите по ссылке. Если Вы нажмете «Я даю согласие», это означает, что Вы понимаете и принимаете все условия, указанные в этом Уведомлении о Конфиденциальности. Я принимаю
ArtemPitov Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 именно так и стоит. по другому не было. тут уже нужно смотреть сколько товаров и что тормозит систему Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... chukcha Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 db_log в поощь Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... sharman35 Опубликовано: 30 ноября 2016 Автор Поделиться Опубликовано: 30 ноября 2016 тут уже нужно смотреть сколько товаров и что тормозит систему пока что 36к, будет около 630к. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Otvet Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 Да чего мелочиться - давайте кешировать готовые страницы. :-) Это кусок из модифицированного мной кеша, там все раскладывается по папочкам, и совершенно не напрягает. К тому же все единообразно: на входе метода модели проверили кеш, далее запросили, на выходе сохранили. как раз таки кешировать страницы это та же степь в модели плодить кеши getCategory, потом каждый раз дергать сотню файлов при построении дерева это глупость а закешировать одно дерево (module/category или header) в 1 файл это оптимизация Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... chukcha Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 Да чего мелочиться - давайте кешировать готовые страницы. Не совсем Можно, полностью закешировать некоторые модули, например рекомендуемые, слайдеры, которые не требуют динамических данных Можно закешировать футер, если в него не попадают, какие-нибудь динамические данные header кешировать нельзя, из-за наличия динамических данных стилей, скриптов Т.е. подход к кешированию, должен быть обдуманный OFFTOP Но, для правильной организации кеша, нужно предусмотреть другой механизм генерации 1. Генерация контента 2. Генерация position 3. Генерация footer 4. Генерация header И это все в разных потоках п.2 можно исключить, потому что он принадлежит потоку Т.е. в output попадает не сгенерированный контент А элементы массива $output['header'] $output['content'] array( 'column_left', 'content' 'column_right' ) $output['footer'] Но эти рассуждения НИ О ЧЕМ... Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 как раз таки кешировать страницы это та же степь в модели плодить кеши getCategory, потом каждый раз дергать сотню файлов при построении дерева это глупость а закешировать одно дерево (module/category или header) в 1 файл это оптимизация Вы не путайте getCategory и getCategories. При построении меню используется второе. Соответственно: если будут только корневые директории - прочитаем 1 файл корневые + поддиректории - прочитаем, условно, 10 файлов корневые + поддиректории + подподдиректории - прочитаем, условно, 100 файлов (здесь да, имеет смысл сохранять готовое дерево) Правильно кеширование делать именно в моделях, т.к. неизвестно из какого контроллера прийдет туда запрос. Это основа, и она всегда должна работать быстро. Ну, если и этого не хватает - тогда добавляйте дополнительный кеш уже на уровне контроллера, целого модуля, блока или вообще целой страницы. Например, вот такая "матрешка" для высоконагруженного проекта: - кеш mysql - кеш на уровне моделей (файловый, мемкеш) - кеш на уровне контроллеров (особо тяжелые куски) - кеш модуля - кеш всей страницы Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... chukcha Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 public function getCategory($category_id) { $category_info = $this->cache->get((int)$this->config->get('config_language_id') . '.' . (int)$this->config->get('config_store_id') . '.' . (int)$category_id); if (FALSE === $category_info) { $query = $this->db->query("SELECT DISTINCT * FROM " . DB_PREFIX . "category c LEFT JOIN " . DB_PREFIX . "category_description cd ON (c.category_id = cd.category_id) LEFT JOIN " . DB_PREFIX . "category_to_store c2s ON (c.category_id = c2s.category_id) WHERE c.category_id = '" . (int)$category_id . "' AND cd.language_id = '" . (int)$this->config->get('config_language_id') . "' AND c2s.store_id = '" . (int)$this->config->get('config_store_id') . "' AND c.status = '1'"); $category_info = $query->row; $this->cache->set((int)$this->config->get('config_language_id') . '.' . (int)$this->config->get('config_store_id') . '.' . (int)$category_id, $category_info); } return $category_info; } @druzhkov, кто предложил этот код? Вы не путайте getCategory и getCategories. Кто и что путает? Вы уж определитесь. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 Кто и что путает? Вы уж определитесь. Вот запрос топикстартера: SELECT * FROM oc_category c LEFT JOIN oc_category_description cd ON (c.category_id = cd.category_id) LEFT JOIN oc_category_to_store c2s ON (c.category_id = c2s.category_id) WHERE c.parent_id = '503' AND cd.language_id = '1' AND c2s.store_id = '0' AND c.status = '1' ORDER BY c.sort_order, LCASE(cd.name) Вот мой код из getCategories: SELECT * FROM " . DB_PREFIX . "category c LEFT JOIN " . DB_PREFIX . "category_description cd ON (c.category_id = cd.category_id) LEFT JOIN " . DB_PREFIX . "category_to_store c2s ON (c.category_id = c2s.category_id) WHERE c.parent_id = '" . (int)$parent_id . "' AND cd.language_id = '" . (int)$this->config->get('config_language_id') . "' AND c2s.store_id = '" . (int)$this->config->get('config_store_id') . "' AND c.status = '1' ORDER BY c.sort_order, LCASE(cd.name) Совпадают? Я не понимаю, чего вы привязались к getCategory. Если не нравится, можно туда не смотреть. Это попутно скопировались из редактора. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... chukcha Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 Что скопировалось? Это $category_info = $this->cache->get((int)$this->config->get('config_language_id') . '.' . (int)$this->config->get('config_store_id') . '.' . (int)$category_id); что-то я не вижу разницы в запросе Один скомпилированный, второй - в модели. Кто предложил кешировать этот запрос? (привел пример) Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 что-то я не вижу разницы в запросе Один скомпилированный, второй - в модели. Кто предложил кешировать этот запрос? (привел пример) Разницы и не должно быть. ТС привел лог и сказал, что тормозит магазин. Логично заключить, что это медленные запросы. Я привел вариант, как их можно закешировать. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... chukcha Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 Вам здесь пытаются объяснить, что кешировать getCategory - бессмысленно Кроме того, также показана неверная конструкция SELECT c использованием DISTINCT Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 Кроме того, также показана неверная конструкция SELECT c использованием DISTINCT Если вас не устраивает, сделайте пулл реквест на гитхаб опенкарта. Данная конструкция стоит как в 1.5, так и в 2.0. Вам здесь пытаются объяснить, что кешировать getCategory - бессмысленно Еще раз напишите обоснование бесмысленности. Не понимаю вашу мысль. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... chukcha Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 Повторять две страницы? Увольте. Те кто заинтересовался - прочтет и поймет. Там 1. Вопрос для понимания 2. Тесты 3. Рассуждения о бессмысленности кеширования одной строки в выборке Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Вы, коллега, полагаю, с высоконагруженными проектами не работали? В любом случае, нужно пояснить: - mysql не резиновый, и при высокой посещаемости всякая мелочь, которой очень много, начинает реально тормозить - а бывает, что сервер базы вообще выносят отдельно, и любые запросы к нему - это дополнительные затраты времени - а еще бывает, что в команде разработчиков кто-то начал делать запросы к незакешированному методу (бывает и в цикле), а тимлид не уследил, потому что он не тысячерукий бог Шива, и снова пошла нагрузка - и т.д. и т.п. Так что это нормальная практика. 100 файлов кеша от getcategory на мелком сайте погоды не делают, а на большом могут сэкономить нервные клетки разработчиков. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Вы, коллега, полагаю, с высоконагруженными проектами не работали? В любом случае, нужно пояснить: - mysql не резиновый, и при высокой посещаемости всякая мелочь, которой очень много, начинает реально тормозить - а бывает, что сервер базы вообще выносят отдельно, и любые запросы к нему - это дополнительные затраты времени - а еще бывает, что в команде разработчиков кто-то начал делать запросы к незакешированному методу (бывает и в цикле), а тимлид не уследил, потому что он не тысячерукий бог Шива, и снова пошла нагрузка - и т.д. и т.п. Так что это нормальная практика. 100 файлов кеша от getcategory на мелком сайте погоды не делают, а на большом могут сэкономить нервные клетки разработчиков. Я работал. И однозначно могу сказать что вы пишите бред! Mysql - резиновый и упирается только в ресурсы сервера. Большое количество товаров - это большое количество постоянных изменений данных, поэтому кеш здесь не то что не панацея - а совсем не вариант. А бывает что не только базы выносят на сервер, а под сегменты таблиц ставят отдельную редиску, которая обслуживает к прмеру клиентов, у которых имя начинается на A, а потом еще одну, у которых на B и так 33 штуки до Z. 630 000 - это не мало и не много. MySql кушает и не кашляет. Но вот некоторые реализации требуют напильника. Умные матюки про teamlead - оставьте молоденьким девчонкам. 100 файлов кеша на getCategory это в 100 раз хуже, чем один кеш на все дерево. И в 10 000 раз хуже, чем один запрос на все дерево и формирование дерева через узлы массива. Вобщем крайне рекомендую, прежде чем писать такие комментарии всерьех подумать, есть ли у вас для них квалификация. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Большое количество товаров - это большое количество постоянных изменений данных, поэтому кеш здесь не то что не панацея - а совсем не вариант. Такое ощущение, что у вас товары меняются ежесекундно. :-) Кеш очень даже неплох. Прикидываете среднее время изменения одного товара - это будет время жизни его кеша. Товар поменялся, почистили его кеш и связанные с ним кеши (категорий, модулей и т.д.), остальные кеши не трогаете. В чем проблема? 100 файлов кеша на getCategory это в 100 раз хуже, чем один кеш на все дерево. И в 10 000 раз хуже, чем один запрос на все дерево и формирование дерева через узлы массива. А вы выше читали мой коммент про многоуровневые кеши (номер 35 в теме)? Или чисто забежали в тему, чтобы отписаться? Если вам достаточно кешировать все дерево, и вы абсолютно уверены, что никто не дергает методы моделей без кеширования - ну, я только порадуюсь за вас. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Вы не за меня радуйтесь - а за себя грустите. Потому как тот механизм который предлагаете вы, база отрабатывает быстрее чем кеш! И в нем смысла нет.Еще раз повторяю. Заканчивайте вредные советы! Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Такое ощущение, что у вас товары меняются ежесекундно. :-) Кеш очень даже неплох. Прикидываете среднее время изменения одного товара - это будет время жизни его кеша. Товар поменялся, почистили его кеш и связанные с ним кеши (категорий, модулей и т.д.), остальные кеши не трогаете. В чем проблема? А вы выше читали мой коммент про многоуровневые кеши (номер 35 в теме)? Или чисто забежали в тему, чтобы отписаться? Если вам достаточно кешировать все дерево, и вы абсолютно уверены, что никто не дергает методы моделей без кеширования - ну, я только порадуюсь за вас. Все придумано и реализовано до вас в модуле Turbo. 1 Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Otvet Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 @druzhkov, ок, я малость смешал в кучу придется расписать... 1. getCategory очень легкий запрос, и вызывается единицы раз на страницу. Mysql работает значительно быстрее нежели засоренная ФС через glob 2. getCategories чуть тяжелее, вызывается множественно только во всяких меню. Не имеет смысла кешировать детали паззла если можно собранный P/S Создавая кучу файлов, пускай даже прямого влияния на сам кешированный запрос и не будет, зато замедлит работу кеша в целом, например сео_про. И мифическая оптимизация приведет к общему минусу Не стоит сравнивать mysql с ФС, как минимум до тех пор пока: это не SSD физически полностью не выделен, что позволяет задействовать аппаратные технологии ускорения ФС (а когда на одном устройстве сотня клиентов этого не будет) используется glob Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Потому как тот механизм который предлагаете вы, база отрабатывает быстрее чем кеш! Вот тест: public function test() { $this->load->model('catalog/category'); $mtime = explode(" ", microtime()); $start_time = $mtime[1] + $mtime[0]; for ($j = 0; $j < 100000; $j++) { $category_info = $this->model_catalog_category->getCategory(209); } $mtime = explode(" ", microtime()); printf ("page generated %f sec", $mtime[1] + $mtime[0] - $start_time); } Из базы 8.771922 sec , из кеша 3.218499 sec. Замечания, наблюдения? Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Вот тест: public function test() { $this->load->model('catalog/category'); $mtime = explode(" ", microtime()); $start_time = $mtime[1] + $mtime[0]; for ($j = 0; $j < 100000; $j++) { $category_info = $this->model_catalog_category->getCategory(209); } $mtime = explode(" ", microtime()); printf ("page generated %f sec", $mtime[1] + $mtime[0] - $start_time); } Из базы 8.771922 sec , из кеша 3.218499 sec. Замечания, наблюдения? Параметры базы, параметры сервера, структура таблиц, индексы на таблицах, количество файлов в папке с кешем, очередь чтения c диска в боевом режиме, внутренний механизм кеширования mysql - не, не слышал? Если на reg.ru на шареде за две копейки - разница будет раз в 100 отличаться. Только разница между вашими теоретическими выкладками и моими тезисами в том, что вы знаете слово teamlead и живете в синтетических тестах, а я сутки на пролет занимаюсь построением больших систем и оптимизацией средних. Поэтому все о чем вы сейчас пытаетесь с пеной у рта рассказать, пройдено в третьем классе так сказать. Я долго не мог понять, кто эти специалисты, после которых люди приходят ко мне со словами "пятеро уже работали, а тормозит как тормозило". И еще конкретно этот пример оптимизируется совершенно иным методом. Если речь идет о методе из 2.x, если внимательно посмотреть в запрос в нем идет выборка SELECT * из нескольких таблиц c последующей сортировкой по lcase(name). Если включить немного мозг и изучить матчасть по mysql. То логичным будет делать выборку SELECT category_id с составным индексом по полям status и parent_id. В этом случае скорость работы запроса увеличвается в несколько сот раз на больших магазинах. И после этого к результирующему набору дособрать необходимые данные (name, title, descr etc...) и уже средствами php по минимальному набору данных осуществить сортировку по названию. Ни один кеш стандартного метода и рядом стоять не будет, я уже молчу про глобальное снижение нагрузки на всю систему. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Назад 1 2 3 Вперёд Страница 2 из 3 Создайте аккаунт или войдите в него для комментирования Вы должны быть пользователем, чтобы оставить комментарий Создать аккаунт Зарегистрируйтесь для получения аккаунта. Это просто! Зарегистрировать аккаунт Войти Уже зарегистрированы? Войдите здесь. Войти сейчас Поделиться Больше способов поделиться... Подписчики 0 Перейти к списку тем Сейчас на странице 0 пользователей Нет пользователей, просматривающих эту страницу. Последние темы Последние дополнения Последние новости Вся активность Главная Поддержка и ответы на вопросы Отчёты об ошибках Помогите разобраться с логом Mysql Покупцям Оплата розширень фізичними особами Оплата розширень юридичними особами Політика повернень Розробникам Регламент розміщення розширень Регламент продажу та підтримки розширень Віртуальний обліковий запис автора Політика просування оголошень API каталогу розширень Вирішення спорів щодо авторських прав Корисна інформація Публічна оферта Політика повернень Політика конфіденційності Платіжна політика Політика передачі особистих даних Політика прозорості Останні розширення Deals – адаптивный универсальный шаблон Автор: octemplates Динамичесткая инфострока в шапке + позиция в макете для opencart\ocstore 2x, 3x Автор: Lito911 Единицы Измерения Товара Автор: RoS Opencart Product Search by Image Автор: slavoglo Простой массовый редактор цен. Fast Price Edit Автор: Sha × Уже зарегистрированы? Войти Регистрация Раздел покупок Назад Приобретенные дополнения Ваши счета Список желаний Альтернативные контакты Форум Новости ocStore Назад Официальный сайт Демо ocStore 3.0.3.2 Демо ocStore 2.3.0.2.4 Скачать ocStore Документация История версий ocStore Блоги Модули Шаблоны Назад Бесплатные шаблоны Платные шаблоны Где покупать модули? Услуги FAQ OpenCart.Pro Назад Демо Купить Сравнение × Создать... Важная информация На нашем сайте используются файлы cookie и происходит обработка некоторых персональных данных пользователей, чтобы улучшить пользовательский интерфейс. Чтобы узнать для чего и какие персональные данные мы обрабатываем перейдите по ссылке. Если Вы нажмете «Я даю согласие», это означает, что Вы понимаете и принимаете все условия, указанные в этом Уведомлении о Конфиденциальности. Я принимаю
chukcha Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 db_log в поощь Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... sharman35 Опубликовано: 30 ноября 2016 Автор Поделиться Опубликовано: 30 ноября 2016 тут уже нужно смотреть сколько товаров и что тормозит систему пока что 36к, будет около 630к. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Otvet Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 Да чего мелочиться - давайте кешировать готовые страницы. :-) Это кусок из модифицированного мной кеша, там все раскладывается по папочкам, и совершенно не напрягает. К тому же все единообразно: на входе метода модели проверили кеш, далее запросили, на выходе сохранили. как раз таки кешировать страницы это та же степь в модели плодить кеши getCategory, потом каждый раз дергать сотню файлов при построении дерева это глупость а закешировать одно дерево (module/category или header) в 1 файл это оптимизация Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... chukcha Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 Да чего мелочиться - давайте кешировать готовые страницы. Не совсем Можно, полностью закешировать некоторые модули, например рекомендуемые, слайдеры, которые не требуют динамических данных Можно закешировать футер, если в него не попадают, какие-нибудь динамические данные header кешировать нельзя, из-за наличия динамических данных стилей, скриптов Т.е. подход к кешированию, должен быть обдуманный OFFTOP Но, для правильной организации кеша, нужно предусмотреть другой механизм генерации 1. Генерация контента 2. Генерация position 3. Генерация footer 4. Генерация header И это все в разных потоках п.2 можно исключить, потому что он принадлежит потоку Т.е. в output попадает не сгенерированный контент А элементы массива $output['header'] $output['content'] array( 'column_left', 'content' 'column_right' ) $output['footer'] Но эти рассуждения НИ О ЧЕМ... Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 как раз таки кешировать страницы это та же степь в модели плодить кеши getCategory, потом каждый раз дергать сотню файлов при построении дерева это глупость а закешировать одно дерево (module/category или header) в 1 файл это оптимизация Вы не путайте getCategory и getCategories. При построении меню используется второе. Соответственно: если будут только корневые директории - прочитаем 1 файл корневые + поддиректории - прочитаем, условно, 10 файлов корневые + поддиректории + подподдиректории - прочитаем, условно, 100 файлов (здесь да, имеет смысл сохранять готовое дерево) Правильно кеширование делать именно в моделях, т.к. неизвестно из какого контроллера прийдет туда запрос. Это основа, и она всегда должна работать быстро. Ну, если и этого не хватает - тогда добавляйте дополнительный кеш уже на уровне контроллера, целого модуля, блока или вообще целой страницы. Например, вот такая "матрешка" для высоконагруженного проекта: - кеш mysql - кеш на уровне моделей (файловый, мемкеш) - кеш на уровне контроллеров (особо тяжелые куски) - кеш модуля - кеш всей страницы Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... chukcha Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 public function getCategory($category_id) { $category_info = $this->cache->get((int)$this->config->get('config_language_id') . '.' . (int)$this->config->get('config_store_id') . '.' . (int)$category_id); if (FALSE === $category_info) { $query = $this->db->query("SELECT DISTINCT * FROM " . DB_PREFIX . "category c LEFT JOIN " . DB_PREFIX . "category_description cd ON (c.category_id = cd.category_id) LEFT JOIN " . DB_PREFIX . "category_to_store c2s ON (c.category_id = c2s.category_id) WHERE c.category_id = '" . (int)$category_id . "' AND cd.language_id = '" . (int)$this->config->get('config_language_id') . "' AND c2s.store_id = '" . (int)$this->config->get('config_store_id') . "' AND c.status = '1'"); $category_info = $query->row; $this->cache->set((int)$this->config->get('config_language_id') . '.' . (int)$this->config->get('config_store_id') . '.' . (int)$category_id, $category_info); } return $category_info; } @druzhkov, кто предложил этот код? Вы не путайте getCategory и getCategories. Кто и что путает? Вы уж определитесь. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 Кто и что путает? Вы уж определитесь. Вот запрос топикстартера: SELECT * FROM oc_category c LEFT JOIN oc_category_description cd ON (c.category_id = cd.category_id) LEFT JOIN oc_category_to_store c2s ON (c.category_id = c2s.category_id) WHERE c.parent_id = '503' AND cd.language_id = '1' AND c2s.store_id = '0' AND c.status = '1' ORDER BY c.sort_order, LCASE(cd.name) Вот мой код из getCategories: SELECT * FROM " . DB_PREFIX . "category c LEFT JOIN " . DB_PREFIX . "category_description cd ON (c.category_id = cd.category_id) LEFT JOIN " . DB_PREFIX . "category_to_store c2s ON (c.category_id = c2s.category_id) WHERE c.parent_id = '" . (int)$parent_id . "' AND cd.language_id = '" . (int)$this->config->get('config_language_id') . "' AND c2s.store_id = '" . (int)$this->config->get('config_store_id') . "' AND c.status = '1' ORDER BY c.sort_order, LCASE(cd.name) Совпадают? Я не понимаю, чего вы привязались к getCategory. Если не нравится, можно туда не смотреть. Это попутно скопировались из редактора. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... chukcha Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 Что скопировалось? Это $category_info = $this->cache->get((int)$this->config->get('config_language_id') . '.' . (int)$this->config->get('config_store_id') . '.' . (int)$category_id); что-то я не вижу разницы в запросе Один скомпилированный, второй - в модели. Кто предложил кешировать этот запрос? (привел пример) Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 что-то я не вижу разницы в запросе Один скомпилированный, второй - в модели. Кто предложил кешировать этот запрос? (привел пример) Разницы и не должно быть. ТС привел лог и сказал, что тормозит магазин. Логично заключить, что это медленные запросы. Я привел вариант, как их можно закешировать. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... chukcha Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 Вам здесь пытаются объяснить, что кешировать getCategory - бессмысленно Кроме того, также показана неверная конструкция SELECT c использованием DISTINCT Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 Кроме того, также показана неверная конструкция SELECT c использованием DISTINCT Если вас не устраивает, сделайте пулл реквест на гитхаб опенкарта. Данная конструкция стоит как в 1.5, так и в 2.0. Вам здесь пытаются объяснить, что кешировать getCategory - бессмысленно Еще раз напишите обоснование бесмысленности. Не понимаю вашу мысль. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... chukcha Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 Повторять две страницы? Увольте. Те кто заинтересовался - прочтет и поймет. Там 1. Вопрос для понимания 2. Тесты 3. Рассуждения о бессмысленности кеширования одной строки в выборке Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Вы, коллега, полагаю, с высоконагруженными проектами не работали? В любом случае, нужно пояснить: - mysql не резиновый, и при высокой посещаемости всякая мелочь, которой очень много, начинает реально тормозить - а бывает, что сервер базы вообще выносят отдельно, и любые запросы к нему - это дополнительные затраты времени - а еще бывает, что в команде разработчиков кто-то начал делать запросы к незакешированному методу (бывает и в цикле), а тимлид не уследил, потому что он не тысячерукий бог Шива, и снова пошла нагрузка - и т.д. и т.п. Так что это нормальная практика. 100 файлов кеша от getcategory на мелком сайте погоды не делают, а на большом могут сэкономить нервные клетки разработчиков. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Вы, коллега, полагаю, с высоконагруженными проектами не работали? В любом случае, нужно пояснить: - mysql не резиновый, и при высокой посещаемости всякая мелочь, которой очень много, начинает реально тормозить - а бывает, что сервер базы вообще выносят отдельно, и любые запросы к нему - это дополнительные затраты времени - а еще бывает, что в команде разработчиков кто-то начал делать запросы к незакешированному методу (бывает и в цикле), а тимлид не уследил, потому что он не тысячерукий бог Шива, и снова пошла нагрузка - и т.д. и т.п. Так что это нормальная практика. 100 файлов кеша от getcategory на мелком сайте погоды не делают, а на большом могут сэкономить нервные клетки разработчиков. Я работал. И однозначно могу сказать что вы пишите бред! Mysql - резиновый и упирается только в ресурсы сервера. Большое количество товаров - это большое количество постоянных изменений данных, поэтому кеш здесь не то что не панацея - а совсем не вариант. А бывает что не только базы выносят на сервер, а под сегменты таблиц ставят отдельную редиску, которая обслуживает к прмеру клиентов, у которых имя начинается на A, а потом еще одну, у которых на B и так 33 штуки до Z. 630 000 - это не мало и не много. MySql кушает и не кашляет. Но вот некоторые реализации требуют напильника. Умные матюки про teamlead - оставьте молоденьким девчонкам. 100 файлов кеша на getCategory это в 100 раз хуже, чем один кеш на все дерево. И в 10 000 раз хуже, чем один запрос на все дерево и формирование дерева через узлы массива. Вобщем крайне рекомендую, прежде чем писать такие комментарии всерьех подумать, есть ли у вас для них квалификация. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Большое количество товаров - это большое количество постоянных изменений данных, поэтому кеш здесь не то что не панацея - а совсем не вариант. Такое ощущение, что у вас товары меняются ежесекундно. :-) Кеш очень даже неплох. Прикидываете среднее время изменения одного товара - это будет время жизни его кеша. Товар поменялся, почистили его кеш и связанные с ним кеши (категорий, модулей и т.д.), остальные кеши не трогаете. В чем проблема? 100 файлов кеша на getCategory это в 100 раз хуже, чем один кеш на все дерево. И в 10 000 раз хуже, чем один запрос на все дерево и формирование дерева через узлы массива. А вы выше читали мой коммент про многоуровневые кеши (номер 35 в теме)? Или чисто забежали в тему, чтобы отписаться? Если вам достаточно кешировать все дерево, и вы абсолютно уверены, что никто не дергает методы моделей без кеширования - ну, я только порадуюсь за вас. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Вы не за меня радуйтесь - а за себя грустите. Потому как тот механизм который предлагаете вы, база отрабатывает быстрее чем кеш! И в нем смысла нет.Еще раз повторяю. Заканчивайте вредные советы! Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Такое ощущение, что у вас товары меняются ежесекундно. :-) Кеш очень даже неплох. Прикидываете среднее время изменения одного товара - это будет время жизни его кеша. Товар поменялся, почистили его кеш и связанные с ним кеши (категорий, модулей и т.д.), остальные кеши не трогаете. В чем проблема? А вы выше читали мой коммент про многоуровневые кеши (номер 35 в теме)? Или чисто забежали в тему, чтобы отписаться? Если вам достаточно кешировать все дерево, и вы абсолютно уверены, что никто не дергает методы моделей без кеширования - ну, я только порадуюсь за вас. Все придумано и реализовано до вас в модуле Turbo. 1 Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Otvet Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 @druzhkov, ок, я малость смешал в кучу придется расписать... 1. getCategory очень легкий запрос, и вызывается единицы раз на страницу. Mysql работает значительно быстрее нежели засоренная ФС через glob 2. getCategories чуть тяжелее, вызывается множественно только во всяких меню. Не имеет смысла кешировать детали паззла если можно собранный P/S Создавая кучу файлов, пускай даже прямого влияния на сам кешированный запрос и не будет, зато замедлит работу кеша в целом, например сео_про. И мифическая оптимизация приведет к общему минусу Не стоит сравнивать mysql с ФС, как минимум до тех пор пока: это не SSD физически полностью не выделен, что позволяет задействовать аппаратные технологии ускорения ФС (а когда на одном устройстве сотня клиентов этого не будет) используется glob Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Потому как тот механизм который предлагаете вы, база отрабатывает быстрее чем кеш! Вот тест: public function test() { $this->load->model('catalog/category'); $mtime = explode(" ", microtime()); $start_time = $mtime[1] + $mtime[0]; for ($j = 0; $j < 100000; $j++) { $category_info = $this->model_catalog_category->getCategory(209); } $mtime = explode(" ", microtime()); printf ("page generated %f sec", $mtime[1] + $mtime[0] - $start_time); } Из базы 8.771922 sec , из кеша 3.218499 sec. Замечания, наблюдения? Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Вот тест: public function test() { $this->load->model('catalog/category'); $mtime = explode(" ", microtime()); $start_time = $mtime[1] + $mtime[0]; for ($j = 0; $j < 100000; $j++) { $category_info = $this->model_catalog_category->getCategory(209); } $mtime = explode(" ", microtime()); printf ("page generated %f sec", $mtime[1] + $mtime[0] - $start_time); } Из базы 8.771922 sec , из кеша 3.218499 sec. Замечания, наблюдения? Параметры базы, параметры сервера, структура таблиц, индексы на таблицах, количество файлов в папке с кешем, очередь чтения c диска в боевом режиме, внутренний механизм кеширования mysql - не, не слышал? Если на reg.ru на шареде за две копейки - разница будет раз в 100 отличаться. Только разница между вашими теоретическими выкладками и моими тезисами в том, что вы знаете слово teamlead и живете в синтетических тестах, а я сутки на пролет занимаюсь построением больших систем и оптимизацией средних. Поэтому все о чем вы сейчас пытаетесь с пеной у рта рассказать, пройдено в третьем классе так сказать. Я долго не мог понять, кто эти специалисты, после которых люди приходят ко мне со словами "пятеро уже работали, а тормозит как тормозило". И еще конкретно этот пример оптимизируется совершенно иным методом. Если речь идет о методе из 2.x, если внимательно посмотреть в запрос в нем идет выборка SELECT * из нескольких таблиц c последующей сортировкой по lcase(name). Если включить немного мозг и изучить матчасть по mysql. То логичным будет делать выборку SELECT category_id с составным индексом по полям status и parent_id. В этом случае скорость работы запроса увеличвается в несколько сот раз на больших магазинах. И после этого к результирующему набору дособрать необходимые данные (name, title, descr etc...) и уже средствами php по минимальному набору данных осуществить сортировку по названию. Ни один кеш стандартного метода и рядом стоять не будет, я уже молчу про глобальное снижение нагрузки на всю систему. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Назад 1 2 3 Вперёд Страница 2 из 3 Создайте аккаунт или войдите в него для комментирования Вы должны быть пользователем, чтобы оставить комментарий Создать аккаунт Зарегистрируйтесь для получения аккаунта. Это просто! Зарегистрировать аккаунт Войти Уже зарегистрированы? Войдите здесь. Войти сейчас Поделиться Больше способов поделиться... Подписчики 0 Перейти к списку тем Сейчас на странице 0 пользователей Нет пользователей, просматривающих эту страницу. Последние темы Последние дополнения Последние новости Вся активность Главная Поддержка и ответы на вопросы Отчёты об ошибках Помогите разобраться с логом Mysql Покупцям Оплата розширень фізичними особами Оплата розширень юридичними особами Політика повернень Розробникам Регламент розміщення розширень Регламент продажу та підтримки розширень Віртуальний обліковий запис автора Політика просування оголошень API каталогу розширень Вирішення спорів щодо авторських прав Корисна інформація Публічна оферта Політика повернень Політика конфіденційності Платіжна політика Політика передачі особистих даних Політика прозорості Останні розширення Deals – адаптивный универсальный шаблон Автор: octemplates Динамичесткая инфострока в шапке + позиция в макете для opencart\ocstore 2x, 3x Автор: Lito911 Единицы Измерения Товара Автор: RoS Opencart Product Search by Image Автор: slavoglo Простой массовый редактор цен. Fast Price Edit Автор: Sha × Уже зарегистрированы? Войти Регистрация Раздел покупок Назад Приобретенные дополнения Ваши счета Список желаний Альтернативные контакты Форум Новости ocStore Назад Официальный сайт Демо ocStore 3.0.3.2 Демо ocStore 2.3.0.2.4 Скачать ocStore Документация История версий ocStore Блоги Модули Шаблоны Назад Бесплатные шаблоны Платные шаблоны Где покупать модули? Услуги FAQ OpenCart.Pro Назад Демо Купить Сравнение × Создать... Важная информация На нашем сайте используются файлы cookie и происходит обработка некоторых персональных данных пользователей, чтобы улучшить пользовательский интерфейс. Чтобы узнать для чего и какие персональные данные мы обрабатываем перейдите по ссылке. Если Вы нажмете «Я даю согласие», это означает, что Вы понимаете и принимаете все условия, указанные в этом Уведомлении о Конфиденциальности. Я принимаю
sharman35 Опубликовано: 30 ноября 2016 Автор Поделиться Опубликовано: 30 ноября 2016 тут уже нужно смотреть сколько товаров и что тормозит систему пока что 36к, будет около 630к. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться...
Otvet Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 Да чего мелочиться - давайте кешировать готовые страницы. :-) Это кусок из модифицированного мной кеша, там все раскладывается по папочкам, и совершенно не напрягает. К тому же все единообразно: на входе метода модели проверили кеш, далее запросили, на выходе сохранили. как раз таки кешировать страницы это та же степь в модели плодить кеши getCategory, потом каждый раз дергать сотню файлов при построении дерева это глупость а закешировать одно дерево (module/category или header) в 1 файл это оптимизация Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... chukcha Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 Да чего мелочиться - давайте кешировать готовые страницы. Не совсем Можно, полностью закешировать некоторые модули, например рекомендуемые, слайдеры, которые не требуют динамических данных Можно закешировать футер, если в него не попадают, какие-нибудь динамические данные header кешировать нельзя, из-за наличия динамических данных стилей, скриптов Т.е. подход к кешированию, должен быть обдуманный OFFTOP Но, для правильной организации кеша, нужно предусмотреть другой механизм генерации 1. Генерация контента 2. Генерация position 3. Генерация footer 4. Генерация header И это все в разных потоках п.2 можно исключить, потому что он принадлежит потоку Т.е. в output попадает не сгенерированный контент А элементы массива $output['header'] $output['content'] array( 'column_left', 'content' 'column_right' ) $output['footer'] Но эти рассуждения НИ О ЧЕМ... Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 как раз таки кешировать страницы это та же степь в модели плодить кеши getCategory, потом каждый раз дергать сотню файлов при построении дерева это глупость а закешировать одно дерево (module/category или header) в 1 файл это оптимизация Вы не путайте getCategory и getCategories. При построении меню используется второе. Соответственно: если будут только корневые директории - прочитаем 1 файл корневые + поддиректории - прочитаем, условно, 10 файлов корневые + поддиректории + подподдиректории - прочитаем, условно, 100 файлов (здесь да, имеет смысл сохранять готовое дерево) Правильно кеширование делать именно в моделях, т.к. неизвестно из какого контроллера прийдет туда запрос. Это основа, и она всегда должна работать быстро. Ну, если и этого не хватает - тогда добавляйте дополнительный кеш уже на уровне контроллера, целого модуля, блока или вообще целой страницы. Например, вот такая "матрешка" для высоконагруженного проекта: - кеш mysql - кеш на уровне моделей (файловый, мемкеш) - кеш на уровне контроллеров (особо тяжелые куски) - кеш модуля - кеш всей страницы Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... chukcha Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 public function getCategory($category_id) { $category_info = $this->cache->get((int)$this->config->get('config_language_id') . '.' . (int)$this->config->get('config_store_id') . '.' . (int)$category_id); if (FALSE === $category_info) { $query = $this->db->query("SELECT DISTINCT * FROM " . DB_PREFIX . "category c LEFT JOIN " . DB_PREFIX . "category_description cd ON (c.category_id = cd.category_id) LEFT JOIN " . DB_PREFIX . "category_to_store c2s ON (c.category_id = c2s.category_id) WHERE c.category_id = '" . (int)$category_id . "' AND cd.language_id = '" . (int)$this->config->get('config_language_id') . "' AND c2s.store_id = '" . (int)$this->config->get('config_store_id') . "' AND c.status = '1'"); $category_info = $query->row; $this->cache->set((int)$this->config->get('config_language_id') . '.' . (int)$this->config->get('config_store_id') . '.' . (int)$category_id, $category_info); } return $category_info; } @druzhkov, кто предложил этот код? Вы не путайте getCategory и getCategories. Кто и что путает? Вы уж определитесь. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 Кто и что путает? Вы уж определитесь. Вот запрос топикстартера: SELECT * FROM oc_category c LEFT JOIN oc_category_description cd ON (c.category_id = cd.category_id) LEFT JOIN oc_category_to_store c2s ON (c.category_id = c2s.category_id) WHERE c.parent_id = '503' AND cd.language_id = '1' AND c2s.store_id = '0' AND c.status = '1' ORDER BY c.sort_order, LCASE(cd.name) Вот мой код из getCategories: SELECT * FROM " . DB_PREFIX . "category c LEFT JOIN " . DB_PREFIX . "category_description cd ON (c.category_id = cd.category_id) LEFT JOIN " . DB_PREFIX . "category_to_store c2s ON (c.category_id = c2s.category_id) WHERE c.parent_id = '" . (int)$parent_id . "' AND cd.language_id = '" . (int)$this->config->get('config_language_id') . "' AND c2s.store_id = '" . (int)$this->config->get('config_store_id') . "' AND c.status = '1' ORDER BY c.sort_order, LCASE(cd.name) Совпадают? Я не понимаю, чего вы привязались к getCategory. Если не нравится, можно туда не смотреть. Это попутно скопировались из редактора. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... chukcha Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 Что скопировалось? Это $category_info = $this->cache->get((int)$this->config->get('config_language_id') . '.' . (int)$this->config->get('config_store_id') . '.' . (int)$category_id); что-то я не вижу разницы в запросе Один скомпилированный, второй - в модели. Кто предложил кешировать этот запрос? (привел пример) Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 что-то я не вижу разницы в запросе Один скомпилированный, второй - в модели. Кто предложил кешировать этот запрос? (привел пример) Разницы и не должно быть. ТС привел лог и сказал, что тормозит магазин. Логично заключить, что это медленные запросы. Я привел вариант, как их можно закешировать. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... chukcha Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 Вам здесь пытаются объяснить, что кешировать getCategory - бессмысленно Кроме того, также показана неверная конструкция SELECT c использованием DISTINCT Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 Кроме того, также показана неверная конструкция SELECT c использованием DISTINCT Если вас не устраивает, сделайте пулл реквест на гитхаб опенкарта. Данная конструкция стоит как в 1.5, так и в 2.0. Вам здесь пытаются объяснить, что кешировать getCategory - бессмысленно Еще раз напишите обоснование бесмысленности. Не понимаю вашу мысль. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... chukcha Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 Повторять две страницы? Увольте. Те кто заинтересовался - прочтет и поймет. Там 1. Вопрос для понимания 2. Тесты 3. Рассуждения о бессмысленности кеширования одной строки в выборке Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Вы, коллега, полагаю, с высоконагруженными проектами не работали? В любом случае, нужно пояснить: - mysql не резиновый, и при высокой посещаемости всякая мелочь, которой очень много, начинает реально тормозить - а бывает, что сервер базы вообще выносят отдельно, и любые запросы к нему - это дополнительные затраты времени - а еще бывает, что в команде разработчиков кто-то начал делать запросы к незакешированному методу (бывает и в цикле), а тимлид не уследил, потому что он не тысячерукий бог Шива, и снова пошла нагрузка - и т.д. и т.п. Так что это нормальная практика. 100 файлов кеша от getcategory на мелком сайте погоды не делают, а на большом могут сэкономить нервные клетки разработчиков. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Вы, коллега, полагаю, с высоконагруженными проектами не работали? В любом случае, нужно пояснить: - mysql не резиновый, и при высокой посещаемости всякая мелочь, которой очень много, начинает реально тормозить - а бывает, что сервер базы вообще выносят отдельно, и любые запросы к нему - это дополнительные затраты времени - а еще бывает, что в команде разработчиков кто-то начал делать запросы к незакешированному методу (бывает и в цикле), а тимлид не уследил, потому что он не тысячерукий бог Шива, и снова пошла нагрузка - и т.д. и т.п. Так что это нормальная практика. 100 файлов кеша от getcategory на мелком сайте погоды не делают, а на большом могут сэкономить нервные клетки разработчиков. Я работал. И однозначно могу сказать что вы пишите бред! Mysql - резиновый и упирается только в ресурсы сервера. Большое количество товаров - это большое количество постоянных изменений данных, поэтому кеш здесь не то что не панацея - а совсем не вариант. А бывает что не только базы выносят на сервер, а под сегменты таблиц ставят отдельную редиску, которая обслуживает к прмеру клиентов, у которых имя начинается на A, а потом еще одну, у которых на B и так 33 штуки до Z. 630 000 - это не мало и не много. MySql кушает и не кашляет. Но вот некоторые реализации требуют напильника. Умные матюки про teamlead - оставьте молоденьким девчонкам. 100 файлов кеша на getCategory это в 100 раз хуже, чем один кеш на все дерево. И в 10 000 раз хуже, чем один запрос на все дерево и формирование дерева через узлы массива. Вобщем крайне рекомендую, прежде чем писать такие комментарии всерьех подумать, есть ли у вас для них квалификация. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Большое количество товаров - это большое количество постоянных изменений данных, поэтому кеш здесь не то что не панацея - а совсем не вариант. Такое ощущение, что у вас товары меняются ежесекундно. :-) Кеш очень даже неплох. Прикидываете среднее время изменения одного товара - это будет время жизни его кеша. Товар поменялся, почистили его кеш и связанные с ним кеши (категорий, модулей и т.д.), остальные кеши не трогаете. В чем проблема? 100 файлов кеша на getCategory это в 100 раз хуже, чем один кеш на все дерево. И в 10 000 раз хуже, чем один запрос на все дерево и формирование дерева через узлы массива. А вы выше читали мой коммент про многоуровневые кеши (номер 35 в теме)? Или чисто забежали в тему, чтобы отписаться? Если вам достаточно кешировать все дерево, и вы абсолютно уверены, что никто не дергает методы моделей без кеширования - ну, я только порадуюсь за вас. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Вы не за меня радуйтесь - а за себя грустите. Потому как тот механизм который предлагаете вы, база отрабатывает быстрее чем кеш! И в нем смысла нет.Еще раз повторяю. Заканчивайте вредные советы! Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Такое ощущение, что у вас товары меняются ежесекундно. :-) Кеш очень даже неплох. Прикидываете среднее время изменения одного товара - это будет время жизни его кеша. Товар поменялся, почистили его кеш и связанные с ним кеши (категорий, модулей и т.д.), остальные кеши не трогаете. В чем проблема? А вы выше читали мой коммент про многоуровневые кеши (номер 35 в теме)? Или чисто забежали в тему, чтобы отписаться? Если вам достаточно кешировать все дерево, и вы абсолютно уверены, что никто не дергает методы моделей без кеширования - ну, я только порадуюсь за вас. Все придумано и реализовано до вас в модуле Turbo. 1 Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Otvet Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 @druzhkov, ок, я малость смешал в кучу придется расписать... 1. getCategory очень легкий запрос, и вызывается единицы раз на страницу. Mysql работает значительно быстрее нежели засоренная ФС через glob 2. getCategories чуть тяжелее, вызывается множественно только во всяких меню. Не имеет смысла кешировать детали паззла если можно собранный P/S Создавая кучу файлов, пускай даже прямого влияния на сам кешированный запрос и не будет, зато замедлит работу кеша в целом, например сео_про. И мифическая оптимизация приведет к общему минусу Не стоит сравнивать mysql с ФС, как минимум до тех пор пока: это не SSD физически полностью не выделен, что позволяет задействовать аппаратные технологии ускорения ФС (а когда на одном устройстве сотня клиентов этого не будет) используется glob Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Потому как тот механизм который предлагаете вы, база отрабатывает быстрее чем кеш! Вот тест: public function test() { $this->load->model('catalog/category'); $mtime = explode(" ", microtime()); $start_time = $mtime[1] + $mtime[0]; for ($j = 0; $j < 100000; $j++) { $category_info = $this->model_catalog_category->getCategory(209); } $mtime = explode(" ", microtime()); printf ("page generated %f sec", $mtime[1] + $mtime[0] - $start_time); } Из базы 8.771922 sec , из кеша 3.218499 sec. Замечания, наблюдения? Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Вот тест: public function test() { $this->load->model('catalog/category'); $mtime = explode(" ", microtime()); $start_time = $mtime[1] + $mtime[0]; for ($j = 0; $j < 100000; $j++) { $category_info = $this->model_catalog_category->getCategory(209); } $mtime = explode(" ", microtime()); printf ("page generated %f sec", $mtime[1] + $mtime[0] - $start_time); } Из базы 8.771922 sec , из кеша 3.218499 sec. Замечания, наблюдения? Параметры базы, параметры сервера, структура таблиц, индексы на таблицах, количество файлов в папке с кешем, очередь чтения c диска в боевом режиме, внутренний механизм кеширования mysql - не, не слышал? Если на reg.ru на шареде за две копейки - разница будет раз в 100 отличаться. Только разница между вашими теоретическими выкладками и моими тезисами в том, что вы знаете слово teamlead и живете в синтетических тестах, а я сутки на пролет занимаюсь построением больших систем и оптимизацией средних. Поэтому все о чем вы сейчас пытаетесь с пеной у рта рассказать, пройдено в третьем классе так сказать. Я долго не мог понять, кто эти специалисты, после которых люди приходят ко мне со словами "пятеро уже работали, а тормозит как тормозило". И еще конкретно этот пример оптимизируется совершенно иным методом. Если речь идет о методе из 2.x, если внимательно посмотреть в запрос в нем идет выборка SELECT * из нескольких таблиц c последующей сортировкой по lcase(name). Если включить немного мозг и изучить матчасть по mysql. То логичным будет делать выборку SELECT category_id с составным индексом по полям status и parent_id. В этом случае скорость работы запроса увеличвается в несколько сот раз на больших магазинах. И после этого к результирующему набору дособрать необходимые данные (name, title, descr etc...) и уже средствами php по минимальному набору данных осуществить сортировку по названию. Ни один кеш стандартного метода и рядом стоять не будет, я уже молчу про глобальное снижение нагрузки на всю систему. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Назад 1 2 3 Вперёд Страница 2 из 3 Создайте аккаунт или войдите в него для комментирования Вы должны быть пользователем, чтобы оставить комментарий Создать аккаунт Зарегистрируйтесь для получения аккаунта. Это просто! Зарегистрировать аккаунт Войти Уже зарегистрированы? Войдите здесь. Войти сейчас Поделиться Больше способов поделиться... Подписчики 0 Перейти к списку тем Сейчас на странице 0 пользователей Нет пользователей, просматривающих эту страницу. Последние темы Последние дополнения Последние новости Вся активность Главная Поддержка и ответы на вопросы Отчёты об ошибках Помогите разобраться с логом Mysql Покупцям Оплата розширень фізичними особами Оплата розширень юридичними особами Політика повернень Розробникам Регламент розміщення розширень Регламент продажу та підтримки розширень Віртуальний обліковий запис автора Політика просування оголошень API каталогу розширень Вирішення спорів щодо авторських прав Корисна інформація Публічна оферта Політика повернень Політика конфіденційності Платіжна політика Політика передачі особистих даних Політика прозорості Останні розширення Deals – адаптивный универсальный шаблон Автор: octemplates Динамичесткая инфострока в шапке + позиция в макете для opencart\ocstore 2x, 3x Автор: Lito911 Единицы Измерения Товара Автор: RoS Opencart Product Search by Image Автор: slavoglo Простой массовый редактор цен. Fast Price Edit Автор: Sha × Уже зарегистрированы? Войти Регистрация Раздел покупок Назад Приобретенные дополнения Ваши счета Список желаний Альтернативные контакты Форум Новости ocStore Назад Официальный сайт Демо ocStore 3.0.3.2 Демо ocStore 2.3.0.2.4 Скачать ocStore Документация История версий ocStore Блоги Модули Шаблоны Назад Бесплатные шаблоны Платные шаблоны Где покупать модули? Услуги FAQ OpenCart.Pro Назад Демо Купить Сравнение × Создать... Важная информация На нашем сайте используются файлы cookie и происходит обработка некоторых персональных данных пользователей, чтобы улучшить пользовательский интерфейс. Чтобы узнать для чего и какие персональные данные мы обрабатываем перейдите по ссылке. Если Вы нажмете «Я даю согласие», это означает, что Вы понимаете и принимаете все условия, указанные в этом Уведомлении о Конфиденциальности. Я принимаю
chukcha Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 Да чего мелочиться - давайте кешировать готовые страницы. Не совсем Можно, полностью закешировать некоторые модули, например рекомендуемые, слайдеры, которые не требуют динамических данных Можно закешировать футер, если в него не попадают, какие-нибудь динамические данные header кешировать нельзя, из-за наличия динамических данных стилей, скриптов Т.е. подход к кешированию, должен быть обдуманный OFFTOP Но, для правильной организации кеша, нужно предусмотреть другой механизм генерации 1. Генерация контента 2. Генерация position 3. Генерация footer 4. Генерация header И это все в разных потоках п.2 можно исключить, потому что он принадлежит потоку Т.е. в output попадает не сгенерированный контент А элементы массива $output['header'] $output['content'] array( 'column_left', 'content' 'column_right' ) $output['footer'] Но эти рассуждения НИ О ЧЕМ... Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 как раз таки кешировать страницы это та же степь в модели плодить кеши getCategory, потом каждый раз дергать сотню файлов при построении дерева это глупость а закешировать одно дерево (module/category или header) в 1 файл это оптимизация Вы не путайте getCategory и getCategories. При построении меню используется второе. Соответственно: если будут только корневые директории - прочитаем 1 файл корневые + поддиректории - прочитаем, условно, 10 файлов корневые + поддиректории + подподдиректории - прочитаем, условно, 100 файлов (здесь да, имеет смысл сохранять готовое дерево) Правильно кеширование делать именно в моделях, т.к. неизвестно из какого контроллера прийдет туда запрос. Это основа, и она всегда должна работать быстро. Ну, если и этого не хватает - тогда добавляйте дополнительный кеш уже на уровне контроллера, целого модуля, блока или вообще целой страницы. Например, вот такая "матрешка" для высоконагруженного проекта: - кеш mysql - кеш на уровне моделей (файловый, мемкеш) - кеш на уровне контроллеров (особо тяжелые куски) - кеш модуля - кеш всей страницы Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... chukcha Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 public function getCategory($category_id) { $category_info = $this->cache->get((int)$this->config->get('config_language_id') . '.' . (int)$this->config->get('config_store_id') . '.' . (int)$category_id); if (FALSE === $category_info) { $query = $this->db->query("SELECT DISTINCT * FROM " . DB_PREFIX . "category c LEFT JOIN " . DB_PREFIX . "category_description cd ON (c.category_id = cd.category_id) LEFT JOIN " . DB_PREFIX . "category_to_store c2s ON (c.category_id = c2s.category_id) WHERE c.category_id = '" . (int)$category_id . "' AND cd.language_id = '" . (int)$this->config->get('config_language_id') . "' AND c2s.store_id = '" . (int)$this->config->get('config_store_id') . "' AND c.status = '1'"); $category_info = $query->row; $this->cache->set((int)$this->config->get('config_language_id') . '.' . (int)$this->config->get('config_store_id') . '.' . (int)$category_id, $category_info); } return $category_info; } @druzhkov, кто предложил этот код? Вы не путайте getCategory и getCategories. Кто и что путает? Вы уж определитесь. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 Кто и что путает? Вы уж определитесь. Вот запрос топикстартера: SELECT * FROM oc_category c LEFT JOIN oc_category_description cd ON (c.category_id = cd.category_id) LEFT JOIN oc_category_to_store c2s ON (c.category_id = c2s.category_id) WHERE c.parent_id = '503' AND cd.language_id = '1' AND c2s.store_id = '0' AND c.status = '1' ORDER BY c.sort_order, LCASE(cd.name) Вот мой код из getCategories: SELECT * FROM " . DB_PREFIX . "category c LEFT JOIN " . DB_PREFIX . "category_description cd ON (c.category_id = cd.category_id) LEFT JOIN " . DB_PREFIX . "category_to_store c2s ON (c.category_id = c2s.category_id) WHERE c.parent_id = '" . (int)$parent_id . "' AND cd.language_id = '" . (int)$this->config->get('config_language_id') . "' AND c2s.store_id = '" . (int)$this->config->get('config_store_id') . "' AND c.status = '1' ORDER BY c.sort_order, LCASE(cd.name) Совпадают? Я не понимаю, чего вы привязались к getCategory. Если не нравится, можно туда не смотреть. Это попутно скопировались из редактора. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... chukcha Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 Что скопировалось? Это $category_info = $this->cache->get((int)$this->config->get('config_language_id') . '.' . (int)$this->config->get('config_store_id') . '.' . (int)$category_id); что-то я не вижу разницы в запросе Один скомпилированный, второй - в модели. Кто предложил кешировать этот запрос? (привел пример) Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 что-то я не вижу разницы в запросе Один скомпилированный, второй - в модели. Кто предложил кешировать этот запрос? (привел пример) Разницы и не должно быть. ТС привел лог и сказал, что тормозит магазин. Логично заключить, что это медленные запросы. Я привел вариант, как их можно закешировать. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... chukcha Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 Вам здесь пытаются объяснить, что кешировать getCategory - бессмысленно Кроме того, также показана неверная конструкция SELECT c использованием DISTINCT Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 Кроме того, также показана неверная конструкция SELECT c использованием DISTINCT Если вас не устраивает, сделайте пулл реквест на гитхаб опенкарта. Данная конструкция стоит как в 1.5, так и в 2.0. Вам здесь пытаются объяснить, что кешировать getCategory - бессмысленно Еще раз напишите обоснование бесмысленности. Не понимаю вашу мысль. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... chukcha Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 Повторять две страницы? Увольте. Те кто заинтересовался - прочтет и поймет. Там 1. Вопрос для понимания 2. Тесты 3. Рассуждения о бессмысленности кеширования одной строки в выборке Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Вы, коллега, полагаю, с высоконагруженными проектами не работали? В любом случае, нужно пояснить: - mysql не резиновый, и при высокой посещаемости всякая мелочь, которой очень много, начинает реально тормозить - а бывает, что сервер базы вообще выносят отдельно, и любые запросы к нему - это дополнительные затраты времени - а еще бывает, что в команде разработчиков кто-то начал делать запросы к незакешированному методу (бывает и в цикле), а тимлид не уследил, потому что он не тысячерукий бог Шива, и снова пошла нагрузка - и т.д. и т.п. Так что это нормальная практика. 100 файлов кеша от getcategory на мелком сайте погоды не делают, а на большом могут сэкономить нервные клетки разработчиков. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Вы, коллега, полагаю, с высоконагруженными проектами не работали? В любом случае, нужно пояснить: - mysql не резиновый, и при высокой посещаемости всякая мелочь, которой очень много, начинает реально тормозить - а бывает, что сервер базы вообще выносят отдельно, и любые запросы к нему - это дополнительные затраты времени - а еще бывает, что в команде разработчиков кто-то начал делать запросы к незакешированному методу (бывает и в цикле), а тимлид не уследил, потому что он не тысячерукий бог Шива, и снова пошла нагрузка - и т.д. и т.п. Так что это нормальная практика. 100 файлов кеша от getcategory на мелком сайте погоды не делают, а на большом могут сэкономить нервные клетки разработчиков. Я работал. И однозначно могу сказать что вы пишите бред! Mysql - резиновый и упирается только в ресурсы сервера. Большое количество товаров - это большое количество постоянных изменений данных, поэтому кеш здесь не то что не панацея - а совсем не вариант. А бывает что не только базы выносят на сервер, а под сегменты таблиц ставят отдельную редиску, которая обслуживает к прмеру клиентов, у которых имя начинается на A, а потом еще одну, у которых на B и так 33 штуки до Z. 630 000 - это не мало и не много. MySql кушает и не кашляет. Но вот некоторые реализации требуют напильника. Умные матюки про teamlead - оставьте молоденьким девчонкам. 100 файлов кеша на getCategory это в 100 раз хуже, чем один кеш на все дерево. И в 10 000 раз хуже, чем один запрос на все дерево и формирование дерева через узлы массива. Вобщем крайне рекомендую, прежде чем писать такие комментарии всерьех подумать, есть ли у вас для них квалификация. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Большое количество товаров - это большое количество постоянных изменений данных, поэтому кеш здесь не то что не панацея - а совсем не вариант. Такое ощущение, что у вас товары меняются ежесекундно. :-) Кеш очень даже неплох. Прикидываете среднее время изменения одного товара - это будет время жизни его кеша. Товар поменялся, почистили его кеш и связанные с ним кеши (категорий, модулей и т.д.), остальные кеши не трогаете. В чем проблема? 100 файлов кеша на getCategory это в 100 раз хуже, чем один кеш на все дерево. И в 10 000 раз хуже, чем один запрос на все дерево и формирование дерева через узлы массива. А вы выше читали мой коммент про многоуровневые кеши (номер 35 в теме)? Или чисто забежали в тему, чтобы отписаться? Если вам достаточно кешировать все дерево, и вы абсолютно уверены, что никто не дергает методы моделей без кеширования - ну, я только порадуюсь за вас. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Вы не за меня радуйтесь - а за себя грустите. Потому как тот механизм который предлагаете вы, база отрабатывает быстрее чем кеш! И в нем смысла нет.Еще раз повторяю. Заканчивайте вредные советы! Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Такое ощущение, что у вас товары меняются ежесекундно. :-) Кеш очень даже неплох. Прикидываете среднее время изменения одного товара - это будет время жизни его кеша. Товар поменялся, почистили его кеш и связанные с ним кеши (категорий, модулей и т.д.), остальные кеши не трогаете. В чем проблема? А вы выше читали мой коммент про многоуровневые кеши (номер 35 в теме)? Или чисто забежали в тему, чтобы отписаться? Если вам достаточно кешировать все дерево, и вы абсолютно уверены, что никто не дергает методы моделей без кеширования - ну, я только порадуюсь за вас. Все придумано и реализовано до вас в модуле Turbo. 1 Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Otvet Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 @druzhkov, ок, я малость смешал в кучу придется расписать... 1. getCategory очень легкий запрос, и вызывается единицы раз на страницу. Mysql работает значительно быстрее нежели засоренная ФС через glob 2. getCategories чуть тяжелее, вызывается множественно только во всяких меню. Не имеет смысла кешировать детали паззла если можно собранный P/S Создавая кучу файлов, пускай даже прямого влияния на сам кешированный запрос и не будет, зато замедлит работу кеша в целом, например сео_про. И мифическая оптимизация приведет к общему минусу Не стоит сравнивать mysql с ФС, как минимум до тех пор пока: это не SSD физически полностью не выделен, что позволяет задействовать аппаратные технологии ускорения ФС (а когда на одном устройстве сотня клиентов этого не будет) используется glob Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Потому как тот механизм который предлагаете вы, база отрабатывает быстрее чем кеш! Вот тест: public function test() { $this->load->model('catalog/category'); $mtime = explode(" ", microtime()); $start_time = $mtime[1] + $mtime[0]; for ($j = 0; $j < 100000; $j++) { $category_info = $this->model_catalog_category->getCategory(209); } $mtime = explode(" ", microtime()); printf ("page generated %f sec", $mtime[1] + $mtime[0] - $start_time); } Из базы 8.771922 sec , из кеша 3.218499 sec. Замечания, наблюдения? Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Вот тест: public function test() { $this->load->model('catalog/category'); $mtime = explode(" ", microtime()); $start_time = $mtime[1] + $mtime[0]; for ($j = 0; $j < 100000; $j++) { $category_info = $this->model_catalog_category->getCategory(209); } $mtime = explode(" ", microtime()); printf ("page generated %f sec", $mtime[1] + $mtime[0] - $start_time); } Из базы 8.771922 sec , из кеша 3.218499 sec. Замечания, наблюдения? Параметры базы, параметры сервера, структура таблиц, индексы на таблицах, количество файлов в папке с кешем, очередь чтения c диска в боевом режиме, внутренний механизм кеширования mysql - не, не слышал? Если на reg.ru на шареде за две копейки - разница будет раз в 100 отличаться. Только разница между вашими теоретическими выкладками и моими тезисами в том, что вы знаете слово teamlead и живете в синтетических тестах, а я сутки на пролет занимаюсь построением больших систем и оптимизацией средних. Поэтому все о чем вы сейчас пытаетесь с пеной у рта рассказать, пройдено в третьем классе так сказать. Я долго не мог понять, кто эти специалисты, после которых люди приходят ко мне со словами "пятеро уже работали, а тормозит как тормозило". И еще конкретно этот пример оптимизируется совершенно иным методом. Если речь идет о методе из 2.x, если внимательно посмотреть в запрос в нем идет выборка SELECT * из нескольких таблиц c последующей сортировкой по lcase(name). Если включить немного мозг и изучить матчасть по mysql. То логичным будет делать выборку SELECT category_id с составным индексом по полям status и parent_id. В этом случае скорость работы запроса увеличвается в несколько сот раз на больших магазинах. И после этого к результирующему набору дособрать необходимые данные (name, title, descr etc...) и уже средствами php по минимальному набору данных осуществить сортировку по названию. Ни один кеш стандартного метода и рядом стоять не будет, я уже молчу про глобальное снижение нагрузки на всю систему. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Назад 1 2 3 Вперёд Страница 2 из 3 Создайте аккаунт или войдите в него для комментирования Вы должны быть пользователем, чтобы оставить комментарий Создать аккаунт Зарегистрируйтесь для получения аккаунта. Это просто! Зарегистрировать аккаунт Войти Уже зарегистрированы? Войдите здесь. Войти сейчас Поделиться Больше способов поделиться... Подписчики 0 Перейти к списку тем Сейчас на странице 0 пользователей Нет пользователей, просматривающих эту страницу. Последние темы Последние дополнения Последние новости Вся активность Главная Поддержка и ответы на вопросы Отчёты об ошибках Помогите разобраться с логом Mysql Покупцям Оплата розширень фізичними особами Оплата розширень юридичними особами Політика повернень Розробникам Регламент розміщення розширень Регламент продажу та підтримки розширень Віртуальний обліковий запис автора Політика просування оголошень API каталогу розширень Вирішення спорів щодо авторських прав Корисна інформація Публічна оферта Політика повернень Політика конфіденційності Платіжна політика Політика передачі особистих даних Політика прозорості Останні розширення Deals – адаптивный универсальный шаблон Автор: octemplates Динамичесткая инфострока в шапке + позиция в макете для opencart\ocstore 2x, 3x Автор: Lito911 Единицы Измерения Товара Автор: RoS Opencart Product Search by Image Автор: slavoglo Простой массовый редактор цен. Fast Price Edit Автор: Sha × Уже зарегистрированы? Войти Регистрация Раздел покупок Назад Приобретенные дополнения Ваши счета Список желаний Альтернативные контакты Форум Новости ocStore Назад Официальный сайт Демо ocStore 3.0.3.2 Демо ocStore 2.3.0.2.4 Скачать ocStore Документация История версий ocStore Блоги Модули Шаблоны Назад Бесплатные шаблоны Платные шаблоны Где покупать модули? Услуги FAQ OpenCart.Pro Назад Демо Купить Сравнение × Создать... Важная информация На нашем сайте используются файлы cookie и происходит обработка некоторых персональных данных пользователей, чтобы улучшить пользовательский интерфейс. Чтобы узнать для чего и какие персональные данные мы обрабатываем перейдите по ссылке. Если Вы нажмете «Я даю согласие», это означает, что Вы понимаете и принимаете все условия, указанные в этом Уведомлении о Конфиденциальности. Я принимаю
druzhkov Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 как раз таки кешировать страницы это та же степь в модели плодить кеши getCategory, потом каждый раз дергать сотню файлов при построении дерева это глупость а закешировать одно дерево (module/category или header) в 1 файл это оптимизация Вы не путайте getCategory и getCategories. При построении меню используется второе. Соответственно: если будут только корневые директории - прочитаем 1 файл корневые + поддиректории - прочитаем, условно, 10 файлов корневые + поддиректории + подподдиректории - прочитаем, условно, 100 файлов (здесь да, имеет смысл сохранять готовое дерево) Правильно кеширование делать именно в моделях, т.к. неизвестно из какого контроллера прийдет туда запрос. Это основа, и она всегда должна работать быстро. Ну, если и этого не хватает - тогда добавляйте дополнительный кеш уже на уровне контроллера, целого модуля, блока или вообще целой страницы. Например, вот такая "матрешка" для высоконагруженного проекта: - кеш mysql - кеш на уровне моделей (файловый, мемкеш) - кеш на уровне контроллеров (особо тяжелые куски) - кеш модуля - кеш всей страницы Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... chukcha Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 public function getCategory($category_id) { $category_info = $this->cache->get((int)$this->config->get('config_language_id') . '.' . (int)$this->config->get('config_store_id') . '.' . (int)$category_id); if (FALSE === $category_info) { $query = $this->db->query("SELECT DISTINCT * FROM " . DB_PREFIX . "category c LEFT JOIN " . DB_PREFIX . "category_description cd ON (c.category_id = cd.category_id) LEFT JOIN " . DB_PREFIX . "category_to_store c2s ON (c.category_id = c2s.category_id) WHERE c.category_id = '" . (int)$category_id . "' AND cd.language_id = '" . (int)$this->config->get('config_language_id') . "' AND c2s.store_id = '" . (int)$this->config->get('config_store_id') . "' AND c.status = '1'"); $category_info = $query->row; $this->cache->set((int)$this->config->get('config_language_id') . '.' . (int)$this->config->get('config_store_id') . '.' . (int)$category_id, $category_info); } return $category_info; } @druzhkov, кто предложил этот код? Вы не путайте getCategory и getCategories. Кто и что путает? Вы уж определитесь. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 Кто и что путает? Вы уж определитесь. Вот запрос топикстартера: SELECT * FROM oc_category c LEFT JOIN oc_category_description cd ON (c.category_id = cd.category_id) LEFT JOIN oc_category_to_store c2s ON (c.category_id = c2s.category_id) WHERE c.parent_id = '503' AND cd.language_id = '1' AND c2s.store_id = '0' AND c.status = '1' ORDER BY c.sort_order, LCASE(cd.name) Вот мой код из getCategories: SELECT * FROM " . DB_PREFIX . "category c LEFT JOIN " . DB_PREFIX . "category_description cd ON (c.category_id = cd.category_id) LEFT JOIN " . DB_PREFIX . "category_to_store c2s ON (c.category_id = c2s.category_id) WHERE c.parent_id = '" . (int)$parent_id . "' AND cd.language_id = '" . (int)$this->config->get('config_language_id') . "' AND c2s.store_id = '" . (int)$this->config->get('config_store_id') . "' AND c.status = '1' ORDER BY c.sort_order, LCASE(cd.name) Совпадают? Я не понимаю, чего вы привязались к getCategory. Если не нравится, можно туда не смотреть. Это попутно скопировались из редактора. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... chukcha Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 Что скопировалось? Это $category_info = $this->cache->get((int)$this->config->get('config_language_id') . '.' . (int)$this->config->get('config_store_id') . '.' . (int)$category_id); что-то я не вижу разницы в запросе Один скомпилированный, второй - в модели. Кто предложил кешировать этот запрос? (привел пример) Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 что-то я не вижу разницы в запросе Один скомпилированный, второй - в модели. Кто предложил кешировать этот запрос? (привел пример) Разницы и не должно быть. ТС привел лог и сказал, что тормозит магазин. Логично заключить, что это медленные запросы. Я привел вариант, как их можно закешировать. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... chukcha Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 Вам здесь пытаются объяснить, что кешировать getCategory - бессмысленно Кроме того, также показана неверная конструкция SELECT c использованием DISTINCT Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 Кроме того, также показана неверная конструкция SELECT c использованием DISTINCT Если вас не устраивает, сделайте пулл реквест на гитхаб опенкарта. Данная конструкция стоит как в 1.5, так и в 2.0. Вам здесь пытаются объяснить, что кешировать getCategory - бессмысленно Еще раз напишите обоснование бесмысленности. Не понимаю вашу мысль. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... chukcha Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 Повторять две страницы? Увольте. Те кто заинтересовался - прочтет и поймет. Там 1. Вопрос для понимания 2. Тесты 3. Рассуждения о бессмысленности кеширования одной строки в выборке Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Вы, коллега, полагаю, с высоконагруженными проектами не работали? В любом случае, нужно пояснить: - mysql не резиновый, и при высокой посещаемости всякая мелочь, которой очень много, начинает реально тормозить - а бывает, что сервер базы вообще выносят отдельно, и любые запросы к нему - это дополнительные затраты времени - а еще бывает, что в команде разработчиков кто-то начал делать запросы к незакешированному методу (бывает и в цикле), а тимлид не уследил, потому что он не тысячерукий бог Шива, и снова пошла нагрузка - и т.д. и т.п. Так что это нормальная практика. 100 файлов кеша от getcategory на мелком сайте погоды не делают, а на большом могут сэкономить нервные клетки разработчиков. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Вы, коллега, полагаю, с высоконагруженными проектами не работали? В любом случае, нужно пояснить: - mysql не резиновый, и при высокой посещаемости всякая мелочь, которой очень много, начинает реально тормозить - а бывает, что сервер базы вообще выносят отдельно, и любые запросы к нему - это дополнительные затраты времени - а еще бывает, что в команде разработчиков кто-то начал делать запросы к незакешированному методу (бывает и в цикле), а тимлид не уследил, потому что он не тысячерукий бог Шива, и снова пошла нагрузка - и т.д. и т.п. Так что это нормальная практика. 100 файлов кеша от getcategory на мелком сайте погоды не делают, а на большом могут сэкономить нервные клетки разработчиков. Я работал. И однозначно могу сказать что вы пишите бред! Mysql - резиновый и упирается только в ресурсы сервера. Большое количество товаров - это большое количество постоянных изменений данных, поэтому кеш здесь не то что не панацея - а совсем не вариант. А бывает что не только базы выносят на сервер, а под сегменты таблиц ставят отдельную редиску, которая обслуживает к прмеру клиентов, у которых имя начинается на A, а потом еще одну, у которых на B и так 33 штуки до Z. 630 000 - это не мало и не много. MySql кушает и не кашляет. Но вот некоторые реализации требуют напильника. Умные матюки про teamlead - оставьте молоденьким девчонкам. 100 файлов кеша на getCategory это в 100 раз хуже, чем один кеш на все дерево. И в 10 000 раз хуже, чем один запрос на все дерево и формирование дерева через узлы массива. Вобщем крайне рекомендую, прежде чем писать такие комментарии всерьех подумать, есть ли у вас для них квалификация. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Большое количество товаров - это большое количество постоянных изменений данных, поэтому кеш здесь не то что не панацея - а совсем не вариант. Такое ощущение, что у вас товары меняются ежесекундно. :-) Кеш очень даже неплох. Прикидываете среднее время изменения одного товара - это будет время жизни его кеша. Товар поменялся, почистили его кеш и связанные с ним кеши (категорий, модулей и т.д.), остальные кеши не трогаете. В чем проблема? 100 файлов кеша на getCategory это в 100 раз хуже, чем один кеш на все дерево. И в 10 000 раз хуже, чем один запрос на все дерево и формирование дерева через узлы массива. А вы выше читали мой коммент про многоуровневые кеши (номер 35 в теме)? Или чисто забежали в тему, чтобы отписаться? Если вам достаточно кешировать все дерево, и вы абсолютно уверены, что никто не дергает методы моделей без кеширования - ну, я только порадуюсь за вас. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Вы не за меня радуйтесь - а за себя грустите. Потому как тот механизм который предлагаете вы, база отрабатывает быстрее чем кеш! И в нем смысла нет.Еще раз повторяю. Заканчивайте вредные советы! Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Такое ощущение, что у вас товары меняются ежесекундно. :-) Кеш очень даже неплох. Прикидываете среднее время изменения одного товара - это будет время жизни его кеша. Товар поменялся, почистили его кеш и связанные с ним кеши (категорий, модулей и т.д.), остальные кеши не трогаете. В чем проблема? А вы выше читали мой коммент про многоуровневые кеши (номер 35 в теме)? Или чисто забежали в тему, чтобы отписаться? Если вам достаточно кешировать все дерево, и вы абсолютно уверены, что никто не дергает методы моделей без кеширования - ну, я только порадуюсь за вас. Все придумано и реализовано до вас в модуле Turbo. 1 Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Otvet Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 @druzhkov, ок, я малость смешал в кучу придется расписать... 1. getCategory очень легкий запрос, и вызывается единицы раз на страницу. Mysql работает значительно быстрее нежели засоренная ФС через glob 2. getCategories чуть тяжелее, вызывается множественно только во всяких меню. Не имеет смысла кешировать детали паззла если можно собранный P/S Создавая кучу файлов, пускай даже прямого влияния на сам кешированный запрос и не будет, зато замедлит работу кеша в целом, например сео_про. И мифическая оптимизация приведет к общему минусу Не стоит сравнивать mysql с ФС, как минимум до тех пор пока: это не SSD физически полностью не выделен, что позволяет задействовать аппаратные технологии ускорения ФС (а когда на одном устройстве сотня клиентов этого не будет) используется glob Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Потому как тот механизм который предлагаете вы, база отрабатывает быстрее чем кеш! Вот тест: public function test() { $this->load->model('catalog/category'); $mtime = explode(" ", microtime()); $start_time = $mtime[1] + $mtime[0]; for ($j = 0; $j < 100000; $j++) { $category_info = $this->model_catalog_category->getCategory(209); } $mtime = explode(" ", microtime()); printf ("page generated %f sec", $mtime[1] + $mtime[0] - $start_time); } Из базы 8.771922 sec , из кеша 3.218499 sec. Замечания, наблюдения? Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Вот тест: public function test() { $this->load->model('catalog/category'); $mtime = explode(" ", microtime()); $start_time = $mtime[1] + $mtime[0]; for ($j = 0; $j < 100000; $j++) { $category_info = $this->model_catalog_category->getCategory(209); } $mtime = explode(" ", microtime()); printf ("page generated %f sec", $mtime[1] + $mtime[0] - $start_time); } Из базы 8.771922 sec , из кеша 3.218499 sec. Замечания, наблюдения? Параметры базы, параметры сервера, структура таблиц, индексы на таблицах, количество файлов в папке с кешем, очередь чтения c диска в боевом режиме, внутренний механизм кеширования mysql - не, не слышал? Если на reg.ru на шареде за две копейки - разница будет раз в 100 отличаться. Только разница между вашими теоретическими выкладками и моими тезисами в том, что вы знаете слово teamlead и живете в синтетических тестах, а я сутки на пролет занимаюсь построением больших систем и оптимизацией средних. Поэтому все о чем вы сейчас пытаетесь с пеной у рта рассказать, пройдено в третьем классе так сказать. Я долго не мог понять, кто эти специалисты, после которых люди приходят ко мне со словами "пятеро уже работали, а тормозит как тормозило". И еще конкретно этот пример оптимизируется совершенно иным методом. Если речь идет о методе из 2.x, если внимательно посмотреть в запрос в нем идет выборка SELECT * из нескольких таблиц c последующей сортировкой по lcase(name). Если включить немного мозг и изучить матчасть по mysql. То логичным будет делать выборку SELECT category_id с составным индексом по полям status и parent_id. В этом случае скорость работы запроса увеличвается в несколько сот раз на больших магазинах. И после этого к результирующему набору дособрать необходимые данные (name, title, descr etc...) и уже средствами php по минимальному набору данных осуществить сортировку по названию. Ни один кеш стандартного метода и рядом стоять не будет, я уже молчу про глобальное снижение нагрузки на всю систему. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Назад 1 2 3 Вперёд Страница 2 из 3 Создайте аккаунт или войдите в него для комментирования Вы должны быть пользователем, чтобы оставить комментарий Создать аккаунт Зарегистрируйтесь для получения аккаунта. Это просто! Зарегистрировать аккаунт Войти Уже зарегистрированы? Войдите здесь. Войти сейчас Поделиться Больше способов поделиться... Подписчики 0 Перейти к списку тем Сейчас на странице 0 пользователей Нет пользователей, просматривающих эту страницу. Последние темы Последние дополнения Последние новости Вся активность Главная Поддержка и ответы на вопросы Отчёты об ошибках Помогите разобраться с логом Mysql Покупцям Оплата розширень фізичними особами Оплата розширень юридичними особами Політика повернень Розробникам Регламент розміщення розширень Регламент продажу та підтримки розширень Віртуальний обліковий запис автора Політика просування оголошень API каталогу розширень Вирішення спорів щодо авторських прав Корисна інформація Публічна оферта Політика повернень Політика конфіденційності Платіжна політика Політика передачі особистих даних Політика прозорості Останні розширення Deals – адаптивный универсальный шаблон Автор: octemplates Динамичесткая инфострока в шапке + позиция в макете для opencart\ocstore 2x, 3x Автор: Lito911 Единицы Измерения Товара Автор: RoS Opencart Product Search by Image Автор: slavoglo Простой массовый редактор цен. Fast Price Edit Автор: Sha × Уже зарегистрированы? Войти Регистрация Раздел покупок Назад Приобретенные дополнения Ваши счета Список желаний Альтернативные контакты Форум Новости ocStore Назад Официальный сайт Демо ocStore 3.0.3.2 Демо ocStore 2.3.0.2.4 Скачать ocStore Документация История версий ocStore Блоги Модули Шаблоны Назад Бесплатные шаблоны Платные шаблоны Где покупать модули? Услуги FAQ OpenCart.Pro Назад Демо Купить Сравнение × Создать... Важная информация На нашем сайте используются файлы cookie и происходит обработка некоторых персональных данных пользователей, чтобы улучшить пользовательский интерфейс. Чтобы узнать для чего и какие персональные данные мы обрабатываем перейдите по ссылке. Если Вы нажмете «Я даю согласие», это означает, что Вы понимаете и принимаете все условия, указанные в этом Уведомлении о Конфиденциальности. Я принимаю
chukcha Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 public function getCategory($category_id) { $category_info = $this->cache->get((int)$this->config->get('config_language_id') . '.' . (int)$this->config->get('config_store_id') . '.' . (int)$category_id); if (FALSE === $category_info) { $query = $this->db->query("SELECT DISTINCT * FROM " . DB_PREFIX . "category c LEFT JOIN " . DB_PREFIX . "category_description cd ON (c.category_id = cd.category_id) LEFT JOIN " . DB_PREFIX . "category_to_store c2s ON (c.category_id = c2s.category_id) WHERE c.category_id = '" . (int)$category_id . "' AND cd.language_id = '" . (int)$this->config->get('config_language_id') . "' AND c2s.store_id = '" . (int)$this->config->get('config_store_id') . "' AND c.status = '1'"); $category_info = $query->row; $this->cache->set((int)$this->config->get('config_language_id') . '.' . (int)$this->config->get('config_store_id') . '.' . (int)$category_id, $category_info); } return $category_info; } @druzhkov, кто предложил этот код? Вы не путайте getCategory и getCategories. Кто и что путает? Вы уж определитесь. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 Кто и что путает? Вы уж определитесь. Вот запрос топикстартера: SELECT * FROM oc_category c LEFT JOIN oc_category_description cd ON (c.category_id = cd.category_id) LEFT JOIN oc_category_to_store c2s ON (c.category_id = c2s.category_id) WHERE c.parent_id = '503' AND cd.language_id = '1' AND c2s.store_id = '0' AND c.status = '1' ORDER BY c.sort_order, LCASE(cd.name) Вот мой код из getCategories: SELECT * FROM " . DB_PREFIX . "category c LEFT JOIN " . DB_PREFIX . "category_description cd ON (c.category_id = cd.category_id) LEFT JOIN " . DB_PREFIX . "category_to_store c2s ON (c.category_id = c2s.category_id) WHERE c.parent_id = '" . (int)$parent_id . "' AND cd.language_id = '" . (int)$this->config->get('config_language_id') . "' AND c2s.store_id = '" . (int)$this->config->get('config_store_id') . "' AND c.status = '1' ORDER BY c.sort_order, LCASE(cd.name) Совпадают? Я не понимаю, чего вы привязались к getCategory. Если не нравится, можно туда не смотреть. Это попутно скопировались из редактора. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... chukcha Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 Что скопировалось? Это $category_info = $this->cache->get((int)$this->config->get('config_language_id') . '.' . (int)$this->config->get('config_store_id') . '.' . (int)$category_id); что-то я не вижу разницы в запросе Один скомпилированный, второй - в модели. Кто предложил кешировать этот запрос? (привел пример) Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 что-то я не вижу разницы в запросе Один скомпилированный, второй - в модели. Кто предложил кешировать этот запрос? (привел пример) Разницы и не должно быть. ТС привел лог и сказал, что тормозит магазин. Логично заключить, что это медленные запросы. Я привел вариант, как их можно закешировать. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... chukcha Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 Вам здесь пытаются объяснить, что кешировать getCategory - бессмысленно Кроме того, также показана неверная конструкция SELECT c использованием DISTINCT Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 Кроме того, также показана неверная конструкция SELECT c использованием DISTINCT Если вас не устраивает, сделайте пулл реквест на гитхаб опенкарта. Данная конструкция стоит как в 1.5, так и в 2.0. Вам здесь пытаются объяснить, что кешировать getCategory - бессмысленно Еще раз напишите обоснование бесмысленности. Не понимаю вашу мысль. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... chukcha Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 Повторять две страницы? Увольте. Те кто заинтересовался - прочтет и поймет. Там 1. Вопрос для понимания 2. Тесты 3. Рассуждения о бессмысленности кеширования одной строки в выборке Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Вы, коллега, полагаю, с высоконагруженными проектами не работали? В любом случае, нужно пояснить: - mysql не резиновый, и при высокой посещаемости всякая мелочь, которой очень много, начинает реально тормозить - а бывает, что сервер базы вообще выносят отдельно, и любые запросы к нему - это дополнительные затраты времени - а еще бывает, что в команде разработчиков кто-то начал делать запросы к незакешированному методу (бывает и в цикле), а тимлид не уследил, потому что он не тысячерукий бог Шива, и снова пошла нагрузка - и т.д. и т.п. Так что это нормальная практика. 100 файлов кеша от getcategory на мелком сайте погоды не делают, а на большом могут сэкономить нервные клетки разработчиков. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Вы, коллега, полагаю, с высоконагруженными проектами не работали? В любом случае, нужно пояснить: - mysql не резиновый, и при высокой посещаемости всякая мелочь, которой очень много, начинает реально тормозить - а бывает, что сервер базы вообще выносят отдельно, и любые запросы к нему - это дополнительные затраты времени - а еще бывает, что в команде разработчиков кто-то начал делать запросы к незакешированному методу (бывает и в цикле), а тимлид не уследил, потому что он не тысячерукий бог Шива, и снова пошла нагрузка - и т.д. и т.п. Так что это нормальная практика. 100 файлов кеша от getcategory на мелком сайте погоды не делают, а на большом могут сэкономить нервные клетки разработчиков. Я работал. И однозначно могу сказать что вы пишите бред! Mysql - резиновый и упирается только в ресурсы сервера. Большое количество товаров - это большое количество постоянных изменений данных, поэтому кеш здесь не то что не панацея - а совсем не вариант. А бывает что не только базы выносят на сервер, а под сегменты таблиц ставят отдельную редиску, которая обслуживает к прмеру клиентов, у которых имя начинается на A, а потом еще одну, у которых на B и так 33 штуки до Z. 630 000 - это не мало и не много. MySql кушает и не кашляет. Но вот некоторые реализации требуют напильника. Умные матюки про teamlead - оставьте молоденьким девчонкам. 100 файлов кеша на getCategory это в 100 раз хуже, чем один кеш на все дерево. И в 10 000 раз хуже, чем один запрос на все дерево и формирование дерева через узлы массива. Вобщем крайне рекомендую, прежде чем писать такие комментарии всерьех подумать, есть ли у вас для них квалификация. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Большое количество товаров - это большое количество постоянных изменений данных, поэтому кеш здесь не то что не панацея - а совсем не вариант. Такое ощущение, что у вас товары меняются ежесекундно. :-) Кеш очень даже неплох. Прикидываете среднее время изменения одного товара - это будет время жизни его кеша. Товар поменялся, почистили его кеш и связанные с ним кеши (категорий, модулей и т.д.), остальные кеши не трогаете. В чем проблема? 100 файлов кеша на getCategory это в 100 раз хуже, чем один кеш на все дерево. И в 10 000 раз хуже, чем один запрос на все дерево и формирование дерева через узлы массива. А вы выше читали мой коммент про многоуровневые кеши (номер 35 в теме)? Или чисто забежали в тему, чтобы отписаться? Если вам достаточно кешировать все дерево, и вы абсолютно уверены, что никто не дергает методы моделей без кеширования - ну, я только порадуюсь за вас. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Вы не за меня радуйтесь - а за себя грустите. Потому как тот механизм который предлагаете вы, база отрабатывает быстрее чем кеш! И в нем смысла нет.Еще раз повторяю. Заканчивайте вредные советы! Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Такое ощущение, что у вас товары меняются ежесекундно. :-) Кеш очень даже неплох. Прикидываете среднее время изменения одного товара - это будет время жизни его кеша. Товар поменялся, почистили его кеш и связанные с ним кеши (категорий, модулей и т.д.), остальные кеши не трогаете. В чем проблема? А вы выше читали мой коммент про многоуровневые кеши (номер 35 в теме)? Или чисто забежали в тему, чтобы отписаться? Если вам достаточно кешировать все дерево, и вы абсолютно уверены, что никто не дергает методы моделей без кеширования - ну, я только порадуюсь за вас. Все придумано и реализовано до вас в модуле Turbo. 1 Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Otvet Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 @druzhkov, ок, я малость смешал в кучу придется расписать... 1. getCategory очень легкий запрос, и вызывается единицы раз на страницу. Mysql работает значительно быстрее нежели засоренная ФС через glob 2. getCategories чуть тяжелее, вызывается множественно только во всяких меню. Не имеет смысла кешировать детали паззла если можно собранный P/S Создавая кучу файлов, пускай даже прямого влияния на сам кешированный запрос и не будет, зато замедлит работу кеша в целом, например сео_про. И мифическая оптимизация приведет к общему минусу Не стоит сравнивать mysql с ФС, как минимум до тех пор пока: это не SSD физически полностью не выделен, что позволяет задействовать аппаратные технологии ускорения ФС (а когда на одном устройстве сотня клиентов этого не будет) используется glob Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Потому как тот механизм который предлагаете вы, база отрабатывает быстрее чем кеш! Вот тест: public function test() { $this->load->model('catalog/category'); $mtime = explode(" ", microtime()); $start_time = $mtime[1] + $mtime[0]; for ($j = 0; $j < 100000; $j++) { $category_info = $this->model_catalog_category->getCategory(209); } $mtime = explode(" ", microtime()); printf ("page generated %f sec", $mtime[1] + $mtime[0] - $start_time); } Из базы 8.771922 sec , из кеша 3.218499 sec. Замечания, наблюдения? Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Вот тест: public function test() { $this->load->model('catalog/category'); $mtime = explode(" ", microtime()); $start_time = $mtime[1] + $mtime[0]; for ($j = 0; $j < 100000; $j++) { $category_info = $this->model_catalog_category->getCategory(209); } $mtime = explode(" ", microtime()); printf ("page generated %f sec", $mtime[1] + $mtime[0] - $start_time); } Из базы 8.771922 sec , из кеша 3.218499 sec. Замечания, наблюдения? Параметры базы, параметры сервера, структура таблиц, индексы на таблицах, количество файлов в папке с кешем, очередь чтения c диска в боевом режиме, внутренний механизм кеширования mysql - не, не слышал? Если на reg.ru на шареде за две копейки - разница будет раз в 100 отличаться. Только разница между вашими теоретическими выкладками и моими тезисами в том, что вы знаете слово teamlead и живете в синтетических тестах, а я сутки на пролет занимаюсь построением больших систем и оптимизацией средних. Поэтому все о чем вы сейчас пытаетесь с пеной у рта рассказать, пройдено в третьем классе так сказать. Я долго не мог понять, кто эти специалисты, после которых люди приходят ко мне со словами "пятеро уже работали, а тормозит как тормозило". И еще конкретно этот пример оптимизируется совершенно иным методом. Если речь идет о методе из 2.x, если внимательно посмотреть в запрос в нем идет выборка SELECT * из нескольких таблиц c последующей сортировкой по lcase(name). Если включить немного мозг и изучить матчасть по mysql. То логичным будет делать выборку SELECT category_id с составным индексом по полям status и parent_id. В этом случае скорость работы запроса увеличвается в несколько сот раз на больших магазинах. И после этого к результирующему набору дособрать необходимые данные (name, title, descr etc...) и уже средствами php по минимальному набору данных осуществить сортировку по названию. Ни один кеш стандартного метода и рядом стоять не будет, я уже молчу про глобальное снижение нагрузки на всю систему. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Назад 1 2 3 Вперёд Страница 2 из 3 Создайте аккаунт или войдите в него для комментирования Вы должны быть пользователем, чтобы оставить комментарий Создать аккаунт Зарегистрируйтесь для получения аккаунта. Это просто! Зарегистрировать аккаунт Войти Уже зарегистрированы? Войдите здесь. Войти сейчас Поделиться Больше способов поделиться... Подписчики 0 Перейти к списку тем Сейчас на странице 0 пользователей Нет пользователей, просматривающих эту страницу. Последние темы Последние дополнения Последние новости Вся активность Главная Поддержка и ответы на вопросы Отчёты об ошибках Помогите разобраться с логом Mysql Покупцям Оплата розширень фізичними особами Оплата розширень юридичними особами Політика повернень Розробникам Регламент розміщення розширень Регламент продажу та підтримки розширень Віртуальний обліковий запис автора Політика просування оголошень API каталогу розширень Вирішення спорів щодо авторських прав Корисна інформація Публічна оферта Політика повернень Політика конфіденційності Платіжна політика Політика передачі особистих даних Політика прозорості Останні розширення Deals – адаптивный универсальный шаблон Автор: octemplates Динамичесткая инфострока в шапке + позиция в макете для opencart\ocstore 2x, 3x Автор: Lito911 Единицы Измерения Товара Автор: RoS Opencart Product Search by Image Автор: slavoglo Простой массовый редактор цен. Fast Price Edit Автор: Sha × Уже зарегистрированы? Войти Регистрация Раздел покупок Назад Приобретенные дополнения Ваши счета Список желаний Альтернативные контакты Форум Новости ocStore Назад Официальный сайт Демо ocStore 3.0.3.2 Демо ocStore 2.3.0.2.4 Скачать ocStore Документация История версий ocStore Блоги Модули Шаблоны Назад Бесплатные шаблоны Платные шаблоны Где покупать модули? Услуги FAQ OpenCart.Pro Назад Демо Купить Сравнение × Создать... Важная информация На нашем сайте используются файлы cookie и происходит обработка некоторых персональных данных пользователей, чтобы улучшить пользовательский интерфейс. Чтобы узнать для чего и какие персональные данные мы обрабатываем перейдите по ссылке. Если Вы нажмете «Я даю согласие», это означает, что Вы понимаете и принимаете все условия, указанные в этом Уведомлении о Конфиденциальности. Я принимаю
druzhkov Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 Кто и что путает? Вы уж определитесь. Вот запрос топикстартера: SELECT * FROM oc_category c LEFT JOIN oc_category_description cd ON (c.category_id = cd.category_id) LEFT JOIN oc_category_to_store c2s ON (c.category_id = c2s.category_id) WHERE c.parent_id = '503' AND cd.language_id = '1' AND c2s.store_id = '0' AND c.status = '1' ORDER BY c.sort_order, LCASE(cd.name) Вот мой код из getCategories: SELECT * FROM " . DB_PREFIX . "category c LEFT JOIN " . DB_PREFIX . "category_description cd ON (c.category_id = cd.category_id) LEFT JOIN " . DB_PREFIX . "category_to_store c2s ON (c.category_id = c2s.category_id) WHERE c.parent_id = '" . (int)$parent_id . "' AND cd.language_id = '" . (int)$this->config->get('config_language_id') . "' AND c2s.store_id = '" . (int)$this->config->get('config_store_id') . "' AND c.status = '1' ORDER BY c.sort_order, LCASE(cd.name) Совпадают? Я не понимаю, чего вы привязались к getCategory. Если не нравится, можно туда не смотреть. Это попутно скопировались из редактора. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... chukcha Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 Что скопировалось? Это $category_info = $this->cache->get((int)$this->config->get('config_language_id') . '.' . (int)$this->config->get('config_store_id') . '.' . (int)$category_id); что-то я не вижу разницы в запросе Один скомпилированный, второй - в модели. Кто предложил кешировать этот запрос? (привел пример) Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 что-то я не вижу разницы в запросе Один скомпилированный, второй - в модели. Кто предложил кешировать этот запрос? (привел пример) Разницы и не должно быть. ТС привел лог и сказал, что тормозит магазин. Логично заключить, что это медленные запросы. Я привел вариант, как их можно закешировать. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... chukcha Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 Вам здесь пытаются объяснить, что кешировать getCategory - бессмысленно Кроме того, также показана неверная конструкция SELECT c использованием DISTINCT Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 Кроме того, также показана неверная конструкция SELECT c использованием DISTINCT Если вас не устраивает, сделайте пулл реквест на гитхаб опенкарта. Данная конструкция стоит как в 1.5, так и в 2.0. Вам здесь пытаются объяснить, что кешировать getCategory - бессмысленно Еще раз напишите обоснование бесмысленности. Не понимаю вашу мысль. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... chukcha Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 Повторять две страницы? Увольте. Те кто заинтересовался - прочтет и поймет. Там 1. Вопрос для понимания 2. Тесты 3. Рассуждения о бессмысленности кеширования одной строки в выборке Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Вы, коллега, полагаю, с высоконагруженными проектами не работали? В любом случае, нужно пояснить: - mysql не резиновый, и при высокой посещаемости всякая мелочь, которой очень много, начинает реально тормозить - а бывает, что сервер базы вообще выносят отдельно, и любые запросы к нему - это дополнительные затраты времени - а еще бывает, что в команде разработчиков кто-то начал делать запросы к незакешированному методу (бывает и в цикле), а тимлид не уследил, потому что он не тысячерукий бог Шива, и снова пошла нагрузка - и т.д. и т.п. Так что это нормальная практика. 100 файлов кеша от getcategory на мелком сайте погоды не делают, а на большом могут сэкономить нервные клетки разработчиков. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Вы, коллега, полагаю, с высоконагруженными проектами не работали? В любом случае, нужно пояснить: - mysql не резиновый, и при высокой посещаемости всякая мелочь, которой очень много, начинает реально тормозить - а бывает, что сервер базы вообще выносят отдельно, и любые запросы к нему - это дополнительные затраты времени - а еще бывает, что в команде разработчиков кто-то начал делать запросы к незакешированному методу (бывает и в цикле), а тимлид не уследил, потому что он не тысячерукий бог Шива, и снова пошла нагрузка - и т.д. и т.п. Так что это нормальная практика. 100 файлов кеша от getcategory на мелком сайте погоды не делают, а на большом могут сэкономить нервные клетки разработчиков. Я работал. И однозначно могу сказать что вы пишите бред! Mysql - резиновый и упирается только в ресурсы сервера. Большое количество товаров - это большое количество постоянных изменений данных, поэтому кеш здесь не то что не панацея - а совсем не вариант. А бывает что не только базы выносят на сервер, а под сегменты таблиц ставят отдельную редиску, которая обслуживает к прмеру клиентов, у которых имя начинается на A, а потом еще одну, у которых на B и так 33 штуки до Z. 630 000 - это не мало и не много. MySql кушает и не кашляет. Но вот некоторые реализации требуют напильника. Умные матюки про teamlead - оставьте молоденьким девчонкам. 100 файлов кеша на getCategory это в 100 раз хуже, чем один кеш на все дерево. И в 10 000 раз хуже, чем один запрос на все дерево и формирование дерева через узлы массива. Вобщем крайне рекомендую, прежде чем писать такие комментарии всерьех подумать, есть ли у вас для них квалификация. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Большое количество товаров - это большое количество постоянных изменений данных, поэтому кеш здесь не то что не панацея - а совсем не вариант. Такое ощущение, что у вас товары меняются ежесекундно. :-) Кеш очень даже неплох. Прикидываете среднее время изменения одного товара - это будет время жизни его кеша. Товар поменялся, почистили его кеш и связанные с ним кеши (категорий, модулей и т.д.), остальные кеши не трогаете. В чем проблема? 100 файлов кеша на getCategory это в 100 раз хуже, чем один кеш на все дерево. И в 10 000 раз хуже, чем один запрос на все дерево и формирование дерева через узлы массива. А вы выше читали мой коммент про многоуровневые кеши (номер 35 в теме)? Или чисто забежали в тему, чтобы отписаться? Если вам достаточно кешировать все дерево, и вы абсолютно уверены, что никто не дергает методы моделей без кеширования - ну, я только порадуюсь за вас. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Вы не за меня радуйтесь - а за себя грустите. Потому как тот механизм который предлагаете вы, база отрабатывает быстрее чем кеш! И в нем смысла нет.Еще раз повторяю. Заканчивайте вредные советы! Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Такое ощущение, что у вас товары меняются ежесекундно. :-) Кеш очень даже неплох. Прикидываете среднее время изменения одного товара - это будет время жизни его кеша. Товар поменялся, почистили его кеш и связанные с ним кеши (категорий, модулей и т.д.), остальные кеши не трогаете. В чем проблема? А вы выше читали мой коммент про многоуровневые кеши (номер 35 в теме)? Или чисто забежали в тему, чтобы отписаться? Если вам достаточно кешировать все дерево, и вы абсолютно уверены, что никто не дергает методы моделей без кеширования - ну, я только порадуюсь за вас. Все придумано и реализовано до вас в модуле Turbo. 1 Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Otvet Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 @druzhkov, ок, я малость смешал в кучу придется расписать... 1. getCategory очень легкий запрос, и вызывается единицы раз на страницу. Mysql работает значительно быстрее нежели засоренная ФС через glob 2. getCategories чуть тяжелее, вызывается множественно только во всяких меню. Не имеет смысла кешировать детали паззла если можно собранный P/S Создавая кучу файлов, пускай даже прямого влияния на сам кешированный запрос и не будет, зато замедлит работу кеша в целом, например сео_про. И мифическая оптимизация приведет к общему минусу Не стоит сравнивать mysql с ФС, как минимум до тех пор пока: это не SSD физически полностью не выделен, что позволяет задействовать аппаратные технологии ускорения ФС (а когда на одном устройстве сотня клиентов этого не будет) используется glob Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Потому как тот механизм который предлагаете вы, база отрабатывает быстрее чем кеш! Вот тест: public function test() { $this->load->model('catalog/category'); $mtime = explode(" ", microtime()); $start_time = $mtime[1] + $mtime[0]; for ($j = 0; $j < 100000; $j++) { $category_info = $this->model_catalog_category->getCategory(209); } $mtime = explode(" ", microtime()); printf ("page generated %f sec", $mtime[1] + $mtime[0] - $start_time); } Из базы 8.771922 sec , из кеша 3.218499 sec. Замечания, наблюдения? Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Вот тест: public function test() { $this->load->model('catalog/category'); $mtime = explode(" ", microtime()); $start_time = $mtime[1] + $mtime[0]; for ($j = 0; $j < 100000; $j++) { $category_info = $this->model_catalog_category->getCategory(209); } $mtime = explode(" ", microtime()); printf ("page generated %f sec", $mtime[1] + $mtime[0] - $start_time); } Из базы 8.771922 sec , из кеша 3.218499 sec. Замечания, наблюдения? Параметры базы, параметры сервера, структура таблиц, индексы на таблицах, количество файлов в папке с кешем, очередь чтения c диска в боевом режиме, внутренний механизм кеширования mysql - не, не слышал? Если на reg.ru на шареде за две копейки - разница будет раз в 100 отличаться. Только разница между вашими теоретическими выкладками и моими тезисами в том, что вы знаете слово teamlead и живете в синтетических тестах, а я сутки на пролет занимаюсь построением больших систем и оптимизацией средних. Поэтому все о чем вы сейчас пытаетесь с пеной у рта рассказать, пройдено в третьем классе так сказать. Я долго не мог понять, кто эти специалисты, после которых люди приходят ко мне со словами "пятеро уже работали, а тормозит как тормозило". И еще конкретно этот пример оптимизируется совершенно иным методом. Если речь идет о методе из 2.x, если внимательно посмотреть в запрос в нем идет выборка SELECT * из нескольких таблиц c последующей сортировкой по lcase(name). Если включить немного мозг и изучить матчасть по mysql. То логичным будет делать выборку SELECT category_id с составным индексом по полям status и parent_id. В этом случае скорость работы запроса увеличвается в несколько сот раз на больших магазинах. И после этого к результирующему набору дособрать необходимые данные (name, title, descr etc...) и уже средствами php по минимальному набору данных осуществить сортировку по названию. Ни один кеш стандартного метода и рядом стоять не будет, я уже молчу про глобальное снижение нагрузки на всю систему. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Назад 1 2 3 Вперёд Страница 2 из 3 Создайте аккаунт или войдите в него для комментирования Вы должны быть пользователем, чтобы оставить комментарий Создать аккаунт Зарегистрируйтесь для получения аккаунта. Это просто! Зарегистрировать аккаунт Войти Уже зарегистрированы? Войдите здесь. Войти сейчас Поделиться Больше способов поделиться... Подписчики 0 Перейти к списку тем Сейчас на странице 0 пользователей Нет пользователей, просматривающих эту страницу. Последние темы Последние дополнения Последние новости Вся активность Главная Поддержка и ответы на вопросы Отчёты об ошибках Помогите разобраться с логом Mysql Покупцям Оплата розширень фізичними особами Оплата розширень юридичними особами Політика повернень Розробникам Регламент розміщення розширень Регламент продажу та підтримки розширень Віртуальний обліковий запис автора Політика просування оголошень API каталогу розширень Вирішення спорів щодо авторських прав Корисна інформація Публічна оферта Політика повернень Політика конфіденційності Платіжна політика Політика передачі особистих даних Політика прозорості Останні розширення Deals – адаптивный универсальный шаблон Автор: octemplates Динамичесткая инфострока в шапке + позиция в макете для opencart\ocstore 2x, 3x Автор: Lito911 Единицы Измерения Товара Автор: RoS Opencart Product Search by Image Автор: slavoglo Простой массовый редактор цен. Fast Price Edit Автор: Sha × Уже зарегистрированы? Войти Регистрация Раздел покупок Назад Приобретенные дополнения Ваши счета Список желаний Альтернативные контакты Форум Новости ocStore Назад Официальный сайт Демо ocStore 3.0.3.2 Демо ocStore 2.3.0.2.4 Скачать ocStore Документация История версий ocStore Блоги Модули Шаблоны Назад Бесплатные шаблоны Платные шаблоны Где покупать модули? Услуги FAQ OpenCart.Pro Назад Демо Купить Сравнение × Создать... Важная информация На нашем сайте используются файлы cookie и происходит обработка некоторых персональных данных пользователей, чтобы улучшить пользовательский интерфейс. Чтобы узнать для чего и какие персональные данные мы обрабатываем перейдите по ссылке. Если Вы нажмете «Я даю согласие», это означает, что Вы понимаете и принимаете все условия, указанные в этом Уведомлении о Конфиденциальности. Я принимаю
chukcha Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 Что скопировалось? Это $category_info = $this->cache->get((int)$this->config->get('config_language_id') . '.' . (int)$this->config->get('config_store_id') . '.' . (int)$category_id); что-то я не вижу разницы в запросе Один скомпилированный, второй - в модели. Кто предложил кешировать этот запрос? (привел пример) Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 что-то я не вижу разницы в запросе Один скомпилированный, второй - в модели. Кто предложил кешировать этот запрос? (привел пример) Разницы и не должно быть. ТС привел лог и сказал, что тормозит магазин. Логично заключить, что это медленные запросы. Я привел вариант, как их можно закешировать. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... chukcha Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 Вам здесь пытаются объяснить, что кешировать getCategory - бессмысленно Кроме того, также показана неверная конструкция SELECT c использованием DISTINCT Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 Кроме того, также показана неверная конструкция SELECT c использованием DISTINCT Если вас не устраивает, сделайте пулл реквест на гитхаб опенкарта. Данная конструкция стоит как в 1.5, так и в 2.0. Вам здесь пытаются объяснить, что кешировать getCategory - бессмысленно Еще раз напишите обоснование бесмысленности. Не понимаю вашу мысль. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... chukcha Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 Повторять две страницы? Увольте. Те кто заинтересовался - прочтет и поймет. Там 1. Вопрос для понимания 2. Тесты 3. Рассуждения о бессмысленности кеширования одной строки в выборке Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Вы, коллега, полагаю, с высоконагруженными проектами не работали? В любом случае, нужно пояснить: - mysql не резиновый, и при высокой посещаемости всякая мелочь, которой очень много, начинает реально тормозить - а бывает, что сервер базы вообще выносят отдельно, и любые запросы к нему - это дополнительные затраты времени - а еще бывает, что в команде разработчиков кто-то начал делать запросы к незакешированному методу (бывает и в цикле), а тимлид не уследил, потому что он не тысячерукий бог Шива, и снова пошла нагрузка - и т.д. и т.п. Так что это нормальная практика. 100 файлов кеша от getcategory на мелком сайте погоды не делают, а на большом могут сэкономить нервные клетки разработчиков. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Вы, коллега, полагаю, с высоконагруженными проектами не работали? В любом случае, нужно пояснить: - mysql не резиновый, и при высокой посещаемости всякая мелочь, которой очень много, начинает реально тормозить - а бывает, что сервер базы вообще выносят отдельно, и любые запросы к нему - это дополнительные затраты времени - а еще бывает, что в команде разработчиков кто-то начал делать запросы к незакешированному методу (бывает и в цикле), а тимлид не уследил, потому что он не тысячерукий бог Шива, и снова пошла нагрузка - и т.д. и т.п. Так что это нормальная практика. 100 файлов кеша от getcategory на мелком сайте погоды не делают, а на большом могут сэкономить нервные клетки разработчиков. Я работал. И однозначно могу сказать что вы пишите бред! Mysql - резиновый и упирается только в ресурсы сервера. Большое количество товаров - это большое количество постоянных изменений данных, поэтому кеш здесь не то что не панацея - а совсем не вариант. А бывает что не только базы выносят на сервер, а под сегменты таблиц ставят отдельную редиску, которая обслуживает к прмеру клиентов, у которых имя начинается на A, а потом еще одну, у которых на B и так 33 штуки до Z. 630 000 - это не мало и не много. MySql кушает и не кашляет. Но вот некоторые реализации требуют напильника. Умные матюки про teamlead - оставьте молоденьким девчонкам. 100 файлов кеша на getCategory это в 100 раз хуже, чем один кеш на все дерево. И в 10 000 раз хуже, чем один запрос на все дерево и формирование дерева через узлы массива. Вобщем крайне рекомендую, прежде чем писать такие комментарии всерьех подумать, есть ли у вас для них квалификация. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Большое количество товаров - это большое количество постоянных изменений данных, поэтому кеш здесь не то что не панацея - а совсем не вариант. Такое ощущение, что у вас товары меняются ежесекундно. :-) Кеш очень даже неплох. Прикидываете среднее время изменения одного товара - это будет время жизни его кеша. Товар поменялся, почистили его кеш и связанные с ним кеши (категорий, модулей и т.д.), остальные кеши не трогаете. В чем проблема? 100 файлов кеша на getCategory это в 100 раз хуже, чем один кеш на все дерево. И в 10 000 раз хуже, чем один запрос на все дерево и формирование дерева через узлы массива. А вы выше читали мой коммент про многоуровневые кеши (номер 35 в теме)? Или чисто забежали в тему, чтобы отписаться? Если вам достаточно кешировать все дерево, и вы абсолютно уверены, что никто не дергает методы моделей без кеширования - ну, я только порадуюсь за вас. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Вы не за меня радуйтесь - а за себя грустите. Потому как тот механизм который предлагаете вы, база отрабатывает быстрее чем кеш! И в нем смысла нет.Еще раз повторяю. Заканчивайте вредные советы! Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Такое ощущение, что у вас товары меняются ежесекундно. :-) Кеш очень даже неплох. Прикидываете среднее время изменения одного товара - это будет время жизни его кеша. Товар поменялся, почистили его кеш и связанные с ним кеши (категорий, модулей и т.д.), остальные кеши не трогаете. В чем проблема? А вы выше читали мой коммент про многоуровневые кеши (номер 35 в теме)? Или чисто забежали в тему, чтобы отписаться? Если вам достаточно кешировать все дерево, и вы абсолютно уверены, что никто не дергает методы моделей без кеширования - ну, я только порадуюсь за вас. Все придумано и реализовано до вас в модуле Turbo. 1 Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Otvet Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 @druzhkov, ок, я малость смешал в кучу придется расписать... 1. getCategory очень легкий запрос, и вызывается единицы раз на страницу. Mysql работает значительно быстрее нежели засоренная ФС через glob 2. getCategories чуть тяжелее, вызывается множественно только во всяких меню. Не имеет смысла кешировать детали паззла если можно собранный P/S Создавая кучу файлов, пускай даже прямого влияния на сам кешированный запрос и не будет, зато замедлит работу кеша в целом, например сео_про. И мифическая оптимизация приведет к общему минусу Не стоит сравнивать mysql с ФС, как минимум до тех пор пока: это не SSD физически полностью не выделен, что позволяет задействовать аппаратные технологии ускорения ФС (а когда на одном устройстве сотня клиентов этого не будет) используется glob Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Потому как тот механизм который предлагаете вы, база отрабатывает быстрее чем кеш! Вот тест: public function test() { $this->load->model('catalog/category'); $mtime = explode(" ", microtime()); $start_time = $mtime[1] + $mtime[0]; for ($j = 0; $j < 100000; $j++) { $category_info = $this->model_catalog_category->getCategory(209); } $mtime = explode(" ", microtime()); printf ("page generated %f sec", $mtime[1] + $mtime[0] - $start_time); } Из базы 8.771922 sec , из кеша 3.218499 sec. Замечания, наблюдения? Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Вот тест: public function test() { $this->load->model('catalog/category'); $mtime = explode(" ", microtime()); $start_time = $mtime[1] + $mtime[0]; for ($j = 0; $j < 100000; $j++) { $category_info = $this->model_catalog_category->getCategory(209); } $mtime = explode(" ", microtime()); printf ("page generated %f sec", $mtime[1] + $mtime[0] - $start_time); } Из базы 8.771922 sec , из кеша 3.218499 sec. Замечания, наблюдения? Параметры базы, параметры сервера, структура таблиц, индексы на таблицах, количество файлов в папке с кешем, очередь чтения c диска в боевом режиме, внутренний механизм кеширования mysql - не, не слышал? Если на reg.ru на шареде за две копейки - разница будет раз в 100 отличаться. Только разница между вашими теоретическими выкладками и моими тезисами в том, что вы знаете слово teamlead и живете в синтетических тестах, а я сутки на пролет занимаюсь построением больших систем и оптимизацией средних. Поэтому все о чем вы сейчас пытаетесь с пеной у рта рассказать, пройдено в третьем классе так сказать. Я долго не мог понять, кто эти специалисты, после которых люди приходят ко мне со словами "пятеро уже работали, а тормозит как тормозило". И еще конкретно этот пример оптимизируется совершенно иным методом. Если речь идет о методе из 2.x, если внимательно посмотреть в запрос в нем идет выборка SELECT * из нескольких таблиц c последующей сортировкой по lcase(name). Если включить немного мозг и изучить матчасть по mysql. То логичным будет делать выборку SELECT category_id с составным индексом по полям status и parent_id. В этом случае скорость работы запроса увеличвается в несколько сот раз на больших магазинах. И после этого к результирующему набору дособрать необходимые данные (name, title, descr etc...) и уже средствами php по минимальному набору данных осуществить сортировку по названию. Ни один кеш стандартного метода и рядом стоять не будет, я уже молчу про глобальное снижение нагрузки на всю систему. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Назад 1 2 3 Вперёд Страница 2 из 3 Создайте аккаунт или войдите в него для комментирования Вы должны быть пользователем, чтобы оставить комментарий Создать аккаунт Зарегистрируйтесь для получения аккаунта. Это просто! Зарегистрировать аккаунт Войти Уже зарегистрированы? Войдите здесь. Войти сейчас Поделиться Больше способов поделиться... Подписчики 0 Перейти к списку тем Сейчас на странице 0 пользователей Нет пользователей, просматривающих эту страницу. Последние темы Последние дополнения Последние новости Вся активность Главная Поддержка и ответы на вопросы Отчёты об ошибках Помогите разобраться с логом Mysql Покупцям Оплата розширень фізичними особами Оплата розширень юридичними особами Політика повернень Розробникам Регламент розміщення розширень Регламент продажу та підтримки розширень Віртуальний обліковий запис автора Політика просування оголошень API каталогу розширень Вирішення спорів щодо авторських прав Корисна інформація Публічна оферта Політика повернень Політика конфіденційності Платіжна політика Політика передачі особистих даних Політика прозорості Останні розширення Deals – адаптивный универсальный шаблон Автор: octemplates Динамичесткая инфострока в шапке + позиция в макете для opencart\ocstore 2x, 3x Автор: Lito911 Единицы Измерения Товара Автор: RoS Opencart Product Search by Image Автор: slavoglo Простой массовый редактор цен. Fast Price Edit Автор: Sha × Уже зарегистрированы? Войти Регистрация Раздел покупок Назад Приобретенные дополнения Ваши счета Список желаний Альтернативные контакты Форум Новости ocStore Назад Официальный сайт Демо ocStore 3.0.3.2 Демо ocStore 2.3.0.2.4 Скачать ocStore Документация История версий ocStore Блоги Модули Шаблоны Назад Бесплатные шаблоны Платные шаблоны Где покупать модули? Услуги FAQ OpenCart.Pro Назад Демо Купить Сравнение × Создать... Важная информация На нашем сайте используются файлы cookie и происходит обработка некоторых персональных данных пользователей, чтобы улучшить пользовательский интерфейс. Чтобы узнать для чего и какие персональные данные мы обрабатываем перейдите по ссылке. Если Вы нажмете «Я даю согласие», это означает, что Вы понимаете и принимаете все условия, указанные в этом Уведомлении о Конфиденциальности. Я принимаю
druzhkov Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 что-то я не вижу разницы в запросе Один скомпилированный, второй - в модели. Кто предложил кешировать этот запрос? (привел пример) Разницы и не должно быть. ТС привел лог и сказал, что тормозит магазин. Логично заключить, что это медленные запросы. Я привел вариант, как их можно закешировать. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... chukcha Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 Вам здесь пытаются объяснить, что кешировать getCategory - бессмысленно Кроме того, также показана неверная конструкция SELECT c использованием DISTINCT Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 Кроме того, также показана неверная конструкция SELECT c использованием DISTINCT Если вас не устраивает, сделайте пулл реквест на гитхаб опенкарта. Данная конструкция стоит как в 1.5, так и в 2.0. Вам здесь пытаются объяснить, что кешировать getCategory - бессмысленно Еще раз напишите обоснование бесмысленности. Не понимаю вашу мысль. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... chukcha Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 Повторять две страницы? Увольте. Те кто заинтересовался - прочтет и поймет. Там 1. Вопрос для понимания 2. Тесты 3. Рассуждения о бессмысленности кеширования одной строки в выборке Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Вы, коллега, полагаю, с высоконагруженными проектами не работали? В любом случае, нужно пояснить: - mysql не резиновый, и при высокой посещаемости всякая мелочь, которой очень много, начинает реально тормозить - а бывает, что сервер базы вообще выносят отдельно, и любые запросы к нему - это дополнительные затраты времени - а еще бывает, что в команде разработчиков кто-то начал делать запросы к незакешированному методу (бывает и в цикле), а тимлид не уследил, потому что он не тысячерукий бог Шива, и снова пошла нагрузка - и т.д. и т.п. Так что это нормальная практика. 100 файлов кеша от getcategory на мелком сайте погоды не делают, а на большом могут сэкономить нервные клетки разработчиков. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Вы, коллега, полагаю, с высоконагруженными проектами не работали? В любом случае, нужно пояснить: - mysql не резиновый, и при высокой посещаемости всякая мелочь, которой очень много, начинает реально тормозить - а бывает, что сервер базы вообще выносят отдельно, и любые запросы к нему - это дополнительные затраты времени - а еще бывает, что в команде разработчиков кто-то начал делать запросы к незакешированному методу (бывает и в цикле), а тимлид не уследил, потому что он не тысячерукий бог Шива, и снова пошла нагрузка - и т.д. и т.п. Так что это нормальная практика. 100 файлов кеша от getcategory на мелком сайте погоды не делают, а на большом могут сэкономить нервные клетки разработчиков. Я работал. И однозначно могу сказать что вы пишите бред! Mysql - резиновый и упирается только в ресурсы сервера. Большое количество товаров - это большое количество постоянных изменений данных, поэтому кеш здесь не то что не панацея - а совсем не вариант. А бывает что не только базы выносят на сервер, а под сегменты таблиц ставят отдельную редиску, которая обслуживает к прмеру клиентов, у которых имя начинается на A, а потом еще одну, у которых на B и так 33 штуки до Z. 630 000 - это не мало и не много. MySql кушает и не кашляет. Но вот некоторые реализации требуют напильника. Умные матюки про teamlead - оставьте молоденьким девчонкам. 100 файлов кеша на getCategory это в 100 раз хуже, чем один кеш на все дерево. И в 10 000 раз хуже, чем один запрос на все дерево и формирование дерева через узлы массива. Вобщем крайне рекомендую, прежде чем писать такие комментарии всерьех подумать, есть ли у вас для них квалификация. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Большое количество товаров - это большое количество постоянных изменений данных, поэтому кеш здесь не то что не панацея - а совсем не вариант. Такое ощущение, что у вас товары меняются ежесекундно. :-) Кеш очень даже неплох. Прикидываете среднее время изменения одного товара - это будет время жизни его кеша. Товар поменялся, почистили его кеш и связанные с ним кеши (категорий, модулей и т.д.), остальные кеши не трогаете. В чем проблема? 100 файлов кеша на getCategory это в 100 раз хуже, чем один кеш на все дерево. И в 10 000 раз хуже, чем один запрос на все дерево и формирование дерева через узлы массива. А вы выше читали мой коммент про многоуровневые кеши (номер 35 в теме)? Или чисто забежали в тему, чтобы отписаться? Если вам достаточно кешировать все дерево, и вы абсолютно уверены, что никто не дергает методы моделей без кеширования - ну, я только порадуюсь за вас. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Вы не за меня радуйтесь - а за себя грустите. Потому как тот механизм который предлагаете вы, база отрабатывает быстрее чем кеш! И в нем смысла нет.Еще раз повторяю. Заканчивайте вредные советы! Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Такое ощущение, что у вас товары меняются ежесекундно. :-) Кеш очень даже неплох. Прикидываете среднее время изменения одного товара - это будет время жизни его кеша. Товар поменялся, почистили его кеш и связанные с ним кеши (категорий, модулей и т.д.), остальные кеши не трогаете. В чем проблема? А вы выше читали мой коммент про многоуровневые кеши (номер 35 в теме)? Или чисто забежали в тему, чтобы отписаться? Если вам достаточно кешировать все дерево, и вы абсолютно уверены, что никто не дергает методы моделей без кеширования - ну, я только порадуюсь за вас. Все придумано и реализовано до вас в модуле Turbo. 1 Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Otvet Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 @druzhkov, ок, я малость смешал в кучу придется расписать... 1. getCategory очень легкий запрос, и вызывается единицы раз на страницу. Mysql работает значительно быстрее нежели засоренная ФС через glob 2. getCategories чуть тяжелее, вызывается множественно только во всяких меню. Не имеет смысла кешировать детали паззла если можно собранный P/S Создавая кучу файлов, пускай даже прямого влияния на сам кешированный запрос и не будет, зато замедлит работу кеша в целом, например сео_про. И мифическая оптимизация приведет к общему минусу Не стоит сравнивать mysql с ФС, как минимум до тех пор пока: это не SSD физически полностью не выделен, что позволяет задействовать аппаратные технологии ускорения ФС (а когда на одном устройстве сотня клиентов этого не будет) используется glob Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Потому как тот механизм который предлагаете вы, база отрабатывает быстрее чем кеш! Вот тест: public function test() { $this->load->model('catalog/category'); $mtime = explode(" ", microtime()); $start_time = $mtime[1] + $mtime[0]; for ($j = 0; $j < 100000; $j++) { $category_info = $this->model_catalog_category->getCategory(209); } $mtime = explode(" ", microtime()); printf ("page generated %f sec", $mtime[1] + $mtime[0] - $start_time); } Из базы 8.771922 sec , из кеша 3.218499 sec. Замечания, наблюдения? Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Вот тест: public function test() { $this->load->model('catalog/category'); $mtime = explode(" ", microtime()); $start_time = $mtime[1] + $mtime[0]; for ($j = 0; $j < 100000; $j++) { $category_info = $this->model_catalog_category->getCategory(209); } $mtime = explode(" ", microtime()); printf ("page generated %f sec", $mtime[1] + $mtime[0] - $start_time); } Из базы 8.771922 sec , из кеша 3.218499 sec. Замечания, наблюдения? Параметры базы, параметры сервера, структура таблиц, индексы на таблицах, количество файлов в папке с кешем, очередь чтения c диска в боевом режиме, внутренний механизм кеширования mysql - не, не слышал? Если на reg.ru на шареде за две копейки - разница будет раз в 100 отличаться. Только разница между вашими теоретическими выкладками и моими тезисами в том, что вы знаете слово teamlead и живете в синтетических тестах, а я сутки на пролет занимаюсь построением больших систем и оптимизацией средних. Поэтому все о чем вы сейчас пытаетесь с пеной у рта рассказать, пройдено в третьем классе так сказать. Я долго не мог понять, кто эти специалисты, после которых люди приходят ко мне со словами "пятеро уже работали, а тормозит как тормозило". И еще конкретно этот пример оптимизируется совершенно иным методом. Если речь идет о методе из 2.x, если внимательно посмотреть в запрос в нем идет выборка SELECT * из нескольких таблиц c последующей сортировкой по lcase(name). Если включить немного мозг и изучить матчасть по mysql. То логичным будет делать выборку SELECT category_id с составным индексом по полям status и parent_id. В этом случае скорость работы запроса увеличвается в несколько сот раз на больших магазинах. И после этого к результирующему набору дособрать необходимые данные (name, title, descr etc...) и уже средствами php по минимальному набору данных осуществить сортировку по названию. Ни один кеш стандартного метода и рядом стоять не будет, я уже молчу про глобальное снижение нагрузки на всю систему. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Назад 1 2 3 Вперёд Страница 2 из 3 Создайте аккаунт или войдите в него для комментирования Вы должны быть пользователем, чтобы оставить комментарий Создать аккаунт Зарегистрируйтесь для получения аккаунта. Это просто! Зарегистрировать аккаунт Войти Уже зарегистрированы? Войдите здесь. Войти сейчас Поделиться Больше способов поделиться... Подписчики 0 Перейти к списку тем Сейчас на странице 0 пользователей Нет пользователей, просматривающих эту страницу. Последние темы Последние дополнения Последние новости Вся активность Главная Поддержка и ответы на вопросы Отчёты об ошибках Помогите разобраться с логом Mysql Покупцям Оплата розширень фізичними особами Оплата розширень юридичними особами Політика повернень Розробникам Регламент розміщення розширень Регламент продажу та підтримки розширень Віртуальний обліковий запис автора Політика просування оголошень API каталогу розширень Вирішення спорів щодо авторських прав Корисна інформація Публічна оферта Політика повернень Політика конфіденційності Платіжна політика Політика передачі особистих даних Політика прозорості Останні розширення Deals – адаптивный универсальный шаблон Автор: octemplates Динамичесткая инфострока в шапке + позиция в макете для opencart\ocstore 2x, 3x Автор: Lito911 Единицы Измерения Товара Автор: RoS Opencart Product Search by Image Автор: slavoglo Простой массовый редактор цен. Fast Price Edit Автор: Sha × Уже зарегистрированы? Войти Регистрация Раздел покупок Назад Приобретенные дополнения Ваши счета Список желаний Альтернативные контакты Форум Новости ocStore Назад Официальный сайт Демо ocStore 3.0.3.2 Демо ocStore 2.3.0.2.4 Скачать ocStore Документация История версий ocStore Блоги Модули Шаблоны Назад Бесплатные шаблоны Платные шаблоны Где покупать модули? Услуги FAQ OpenCart.Pro Назад Демо Купить Сравнение × Создать... Важная информация На нашем сайте используются файлы cookie и происходит обработка некоторых персональных данных пользователей, чтобы улучшить пользовательский интерфейс. Чтобы узнать для чего и какие персональные данные мы обрабатываем перейдите по ссылке. Если Вы нажмете «Я даю согласие», это означает, что Вы понимаете и принимаете все условия, указанные в этом Уведомлении о Конфиденциальности. Я принимаю
chukcha Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 Вам здесь пытаются объяснить, что кешировать getCategory - бессмысленно Кроме того, также показана неверная конструкция SELECT c использованием DISTINCT Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 Кроме того, также показана неверная конструкция SELECT c использованием DISTINCT Если вас не устраивает, сделайте пулл реквест на гитхаб опенкарта. Данная конструкция стоит как в 1.5, так и в 2.0. Вам здесь пытаются объяснить, что кешировать getCategory - бессмысленно Еще раз напишите обоснование бесмысленности. Не понимаю вашу мысль. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... chukcha Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 Повторять две страницы? Увольте. Те кто заинтересовался - прочтет и поймет. Там 1. Вопрос для понимания 2. Тесты 3. Рассуждения о бессмысленности кеширования одной строки в выборке Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Вы, коллега, полагаю, с высоконагруженными проектами не работали? В любом случае, нужно пояснить: - mysql не резиновый, и при высокой посещаемости всякая мелочь, которой очень много, начинает реально тормозить - а бывает, что сервер базы вообще выносят отдельно, и любые запросы к нему - это дополнительные затраты времени - а еще бывает, что в команде разработчиков кто-то начал делать запросы к незакешированному методу (бывает и в цикле), а тимлид не уследил, потому что он не тысячерукий бог Шива, и снова пошла нагрузка - и т.д. и т.п. Так что это нормальная практика. 100 файлов кеша от getcategory на мелком сайте погоды не делают, а на большом могут сэкономить нервные клетки разработчиков. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Вы, коллега, полагаю, с высоконагруженными проектами не работали? В любом случае, нужно пояснить: - mysql не резиновый, и при высокой посещаемости всякая мелочь, которой очень много, начинает реально тормозить - а бывает, что сервер базы вообще выносят отдельно, и любые запросы к нему - это дополнительные затраты времени - а еще бывает, что в команде разработчиков кто-то начал делать запросы к незакешированному методу (бывает и в цикле), а тимлид не уследил, потому что он не тысячерукий бог Шива, и снова пошла нагрузка - и т.д. и т.п. Так что это нормальная практика. 100 файлов кеша от getcategory на мелком сайте погоды не делают, а на большом могут сэкономить нервные клетки разработчиков. Я работал. И однозначно могу сказать что вы пишите бред! Mysql - резиновый и упирается только в ресурсы сервера. Большое количество товаров - это большое количество постоянных изменений данных, поэтому кеш здесь не то что не панацея - а совсем не вариант. А бывает что не только базы выносят на сервер, а под сегменты таблиц ставят отдельную редиску, которая обслуживает к прмеру клиентов, у которых имя начинается на A, а потом еще одну, у которых на B и так 33 штуки до Z. 630 000 - это не мало и не много. MySql кушает и не кашляет. Но вот некоторые реализации требуют напильника. Умные матюки про teamlead - оставьте молоденьким девчонкам. 100 файлов кеша на getCategory это в 100 раз хуже, чем один кеш на все дерево. И в 10 000 раз хуже, чем один запрос на все дерево и формирование дерева через узлы массива. Вобщем крайне рекомендую, прежде чем писать такие комментарии всерьех подумать, есть ли у вас для них квалификация. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Большое количество товаров - это большое количество постоянных изменений данных, поэтому кеш здесь не то что не панацея - а совсем не вариант. Такое ощущение, что у вас товары меняются ежесекундно. :-) Кеш очень даже неплох. Прикидываете среднее время изменения одного товара - это будет время жизни его кеша. Товар поменялся, почистили его кеш и связанные с ним кеши (категорий, модулей и т.д.), остальные кеши не трогаете. В чем проблема? 100 файлов кеша на getCategory это в 100 раз хуже, чем один кеш на все дерево. И в 10 000 раз хуже, чем один запрос на все дерево и формирование дерева через узлы массива. А вы выше читали мой коммент про многоуровневые кеши (номер 35 в теме)? Или чисто забежали в тему, чтобы отписаться? Если вам достаточно кешировать все дерево, и вы абсолютно уверены, что никто не дергает методы моделей без кеширования - ну, я только порадуюсь за вас. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Вы не за меня радуйтесь - а за себя грустите. Потому как тот механизм который предлагаете вы, база отрабатывает быстрее чем кеш! И в нем смысла нет.Еще раз повторяю. Заканчивайте вредные советы! Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Такое ощущение, что у вас товары меняются ежесекундно. :-) Кеш очень даже неплох. Прикидываете среднее время изменения одного товара - это будет время жизни его кеша. Товар поменялся, почистили его кеш и связанные с ним кеши (категорий, модулей и т.д.), остальные кеши не трогаете. В чем проблема? А вы выше читали мой коммент про многоуровневые кеши (номер 35 в теме)? Или чисто забежали в тему, чтобы отписаться? Если вам достаточно кешировать все дерево, и вы абсолютно уверены, что никто не дергает методы моделей без кеширования - ну, я только порадуюсь за вас. Все придумано и реализовано до вас в модуле Turbo. 1 Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Otvet Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 @druzhkov, ок, я малость смешал в кучу придется расписать... 1. getCategory очень легкий запрос, и вызывается единицы раз на страницу. Mysql работает значительно быстрее нежели засоренная ФС через glob 2. getCategories чуть тяжелее, вызывается множественно только во всяких меню. Не имеет смысла кешировать детали паззла если можно собранный P/S Создавая кучу файлов, пускай даже прямого влияния на сам кешированный запрос и не будет, зато замедлит работу кеша в целом, например сео_про. И мифическая оптимизация приведет к общему минусу Не стоит сравнивать mysql с ФС, как минимум до тех пор пока: это не SSD физически полностью не выделен, что позволяет задействовать аппаратные технологии ускорения ФС (а когда на одном устройстве сотня клиентов этого не будет) используется glob Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Потому как тот механизм который предлагаете вы, база отрабатывает быстрее чем кеш! Вот тест: public function test() { $this->load->model('catalog/category'); $mtime = explode(" ", microtime()); $start_time = $mtime[1] + $mtime[0]; for ($j = 0; $j < 100000; $j++) { $category_info = $this->model_catalog_category->getCategory(209); } $mtime = explode(" ", microtime()); printf ("page generated %f sec", $mtime[1] + $mtime[0] - $start_time); } Из базы 8.771922 sec , из кеша 3.218499 sec. Замечания, наблюдения? Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Вот тест: public function test() { $this->load->model('catalog/category'); $mtime = explode(" ", microtime()); $start_time = $mtime[1] + $mtime[0]; for ($j = 0; $j < 100000; $j++) { $category_info = $this->model_catalog_category->getCategory(209); } $mtime = explode(" ", microtime()); printf ("page generated %f sec", $mtime[1] + $mtime[0] - $start_time); } Из базы 8.771922 sec , из кеша 3.218499 sec. Замечания, наблюдения? Параметры базы, параметры сервера, структура таблиц, индексы на таблицах, количество файлов в папке с кешем, очередь чтения c диска в боевом режиме, внутренний механизм кеширования mysql - не, не слышал? Если на reg.ru на шареде за две копейки - разница будет раз в 100 отличаться. Только разница между вашими теоретическими выкладками и моими тезисами в том, что вы знаете слово teamlead и живете в синтетических тестах, а я сутки на пролет занимаюсь построением больших систем и оптимизацией средних. Поэтому все о чем вы сейчас пытаетесь с пеной у рта рассказать, пройдено в третьем классе так сказать. Я долго не мог понять, кто эти специалисты, после которых люди приходят ко мне со словами "пятеро уже работали, а тормозит как тормозило". И еще конкретно этот пример оптимизируется совершенно иным методом. Если речь идет о методе из 2.x, если внимательно посмотреть в запрос в нем идет выборка SELECT * из нескольких таблиц c последующей сортировкой по lcase(name). Если включить немного мозг и изучить матчасть по mysql. То логичным будет делать выборку SELECT category_id с составным индексом по полям status и parent_id. В этом случае скорость работы запроса увеличвается в несколько сот раз на больших магазинах. И после этого к результирующему набору дособрать необходимые данные (name, title, descr etc...) и уже средствами php по минимальному набору данных осуществить сортировку по названию. Ни один кеш стандартного метода и рядом стоять не будет, я уже молчу про глобальное снижение нагрузки на всю систему. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Назад 1 2 3 Вперёд Страница 2 из 3 Создайте аккаунт или войдите в него для комментирования Вы должны быть пользователем, чтобы оставить комментарий Создать аккаунт Зарегистрируйтесь для получения аккаунта. Это просто! Зарегистрировать аккаунт Войти Уже зарегистрированы? Войдите здесь. Войти сейчас Поделиться Больше способов поделиться... Подписчики 0 Перейти к списку тем Сейчас на странице 0 пользователей Нет пользователей, просматривающих эту страницу. Последние темы Последние дополнения Последние новости Вся активность Главная Поддержка и ответы на вопросы Отчёты об ошибках Помогите разобраться с логом Mysql Покупцям Оплата розширень фізичними особами Оплата розширень юридичними особами Політика повернень Розробникам Регламент розміщення розширень Регламент продажу та підтримки розширень Віртуальний обліковий запис автора Політика просування оголошень API каталогу розширень Вирішення спорів щодо авторських прав Корисна інформація Публічна оферта Політика повернень Політика конфіденційності Платіжна політика Політика передачі особистих даних Політика прозорості Останні розширення Deals – адаптивный универсальный шаблон Автор: octemplates Динамичесткая инфострока в шапке + позиция в макете для opencart\ocstore 2x, 3x Автор: Lito911 Единицы Измерения Товара Автор: RoS Opencart Product Search by Image Автор: slavoglo Простой массовый редактор цен. Fast Price Edit Автор: Sha × Уже зарегистрированы? Войти Регистрация Раздел покупок Назад Приобретенные дополнения Ваши счета Список желаний Альтернативные контакты Форум Новости ocStore Назад Официальный сайт Демо ocStore 3.0.3.2 Демо ocStore 2.3.0.2.4 Скачать ocStore Документация История версий ocStore Блоги Модули Шаблоны Назад Бесплатные шаблоны Платные шаблоны Где покупать модули? Услуги FAQ OpenCart.Pro Назад Демо Купить Сравнение × Создать... Важная информация На нашем сайте используются файлы cookie и происходит обработка некоторых персональных данных пользователей, чтобы улучшить пользовательский интерфейс. Чтобы узнать для чего и какие персональные данные мы обрабатываем перейдите по ссылке. Если Вы нажмете «Я даю согласие», это означает, что Вы понимаете и принимаете все условия, указанные в этом Уведомлении о Конфиденциальности. Я принимаю
druzhkov Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 Кроме того, также показана неверная конструкция SELECT c использованием DISTINCT Если вас не устраивает, сделайте пулл реквест на гитхаб опенкарта. Данная конструкция стоит как в 1.5, так и в 2.0. Вам здесь пытаются объяснить, что кешировать getCategory - бессмысленно Еще раз напишите обоснование бесмысленности. Не понимаю вашу мысль. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... chukcha Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 Повторять две страницы? Увольте. Те кто заинтересовался - прочтет и поймет. Там 1. Вопрос для понимания 2. Тесты 3. Рассуждения о бессмысленности кеширования одной строки в выборке Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Вы, коллега, полагаю, с высоконагруженными проектами не работали? В любом случае, нужно пояснить: - mysql не резиновый, и при высокой посещаемости всякая мелочь, которой очень много, начинает реально тормозить - а бывает, что сервер базы вообще выносят отдельно, и любые запросы к нему - это дополнительные затраты времени - а еще бывает, что в команде разработчиков кто-то начал делать запросы к незакешированному методу (бывает и в цикле), а тимлид не уследил, потому что он не тысячерукий бог Шива, и снова пошла нагрузка - и т.д. и т.п. Так что это нормальная практика. 100 файлов кеша от getcategory на мелком сайте погоды не делают, а на большом могут сэкономить нервные клетки разработчиков. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Вы, коллега, полагаю, с высоконагруженными проектами не работали? В любом случае, нужно пояснить: - mysql не резиновый, и при высокой посещаемости всякая мелочь, которой очень много, начинает реально тормозить - а бывает, что сервер базы вообще выносят отдельно, и любые запросы к нему - это дополнительные затраты времени - а еще бывает, что в команде разработчиков кто-то начал делать запросы к незакешированному методу (бывает и в цикле), а тимлид не уследил, потому что он не тысячерукий бог Шива, и снова пошла нагрузка - и т.д. и т.п. Так что это нормальная практика. 100 файлов кеша от getcategory на мелком сайте погоды не делают, а на большом могут сэкономить нервные клетки разработчиков. Я работал. И однозначно могу сказать что вы пишите бред! Mysql - резиновый и упирается только в ресурсы сервера. Большое количество товаров - это большое количество постоянных изменений данных, поэтому кеш здесь не то что не панацея - а совсем не вариант. А бывает что не только базы выносят на сервер, а под сегменты таблиц ставят отдельную редиску, которая обслуживает к прмеру клиентов, у которых имя начинается на A, а потом еще одну, у которых на B и так 33 штуки до Z. 630 000 - это не мало и не много. MySql кушает и не кашляет. Но вот некоторые реализации требуют напильника. Умные матюки про teamlead - оставьте молоденьким девчонкам. 100 файлов кеша на getCategory это в 100 раз хуже, чем один кеш на все дерево. И в 10 000 раз хуже, чем один запрос на все дерево и формирование дерева через узлы массива. Вобщем крайне рекомендую, прежде чем писать такие комментарии всерьех подумать, есть ли у вас для них квалификация. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Большое количество товаров - это большое количество постоянных изменений данных, поэтому кеш здесь не то что не панацея - а совсем не вариант. Такое ощущение, что у вас товары меняются ежесекундно. :-) Кеш очень даже неплох. Прикидываете среднее время изменения одного товара - это будет время жизни его кеша. Товар поменялся, почистили его кеш и связанные с ним кеши (категорий, модулей и т.д.), остальные кеши не трогаете. В чем проблема? 100 файлов кеша на getCategory это в 100 раз хуже, чем один кеш на все дерево. И в 10 000 раз хуже, чем один запрос на все дерево и формирование дерева через узлы массива. А вы выше читали мой коммент про многоуровневые кеши (номер 35 в теме)? Или чисто забежали в тему, чтобы отписаться? Если вам достаточно кешировать все дерево, и вы абсолютно уверены, что никто не дергает методы моделей без кеширования - ну, я только порадуюсь за вас. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Вы не за меня радуйтесь - а за себя грустите. Потому как тот механизм который предлагаете вы, база отрабатывает быстрее чем кеш! И в нем смысла нет.Еще раз повторяю. Заканчивайте вредные советы! Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Такое ощущение, что у вас товары меняются ежесекундно. :-) Кеш очень даже неплох. Прикидываете среднее время изменения одного товара - это будет время жизни его кеша. Товар поменялся, почистили его кеш и связанные с ним кеши (категорий, модулей и т.д.), остальные кеши не трогаете. В чем проблема? А вы выше читали мой коммент про многоуровневые кеши (номер 35 в теме)? Или чисто забежали в тему, чтобы отписаться? Если вам достаточно кешировать все дерево, и вы абсолютно уверены, что никто не дергает методы моделей без кеширования - ну, я только порадуюсь за вас. Все придумано и реализовано до вас в модуле Turbo. 1 Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Otvet Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 @druzhkov, ок, я малость смешал в кучу придется расписать... 1. getCategory очень легкий запрос, и вызывается единицы раз на страницу. Mysql работает значительно быстрее нежели засоренная ФС через glob 2. getCategories чуть тяжелее, вызывается множественно только во всяких меню. Не имеет смысла кешировать детали паззла если можно собранный P/S Создавая кучу файлов, пускай даже прямого влияния на сам кешированный запрос и не будет, зато замедлит работу кеша в целом, например сео_про. И мифическая оптимизация приведет к общему минусу Не стоит сравнивать mysql с ФС, как минимум до тех пор пока: это не SSD физически полностью не выделен, что позволяет задействовать аппаратные технологии ускорения ФС (а когда на одном устройстве сотня клиентов этого не будет) используется glob Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Потому как тот механизм который предлагаете вы, база отрабатывает быстрее чем кеш! Вот тест: public function test() { $this->load->model('catalog/category'); $mtime = explode(" ", microtime()); $start_time = $mtime[1] + $mtime[0]; for ($j = 0; $j < 100000; $j++) { $category_info = $this->model_catalog_category->getCategory(209); } $mtime = explode(" ", microtime()); printf ("page generated %f sec", $mtime[1] + $mtime[0] - $start_time); } Из базы 8.771922 sec , из кеша 3.218499 sec. Замечания, наблюдения? Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Вот тест: public function test() { $this->load->model('catalog/category'); $mtime = explode(" ", microtime()); $start_time = $mtime[1] + $mtime[0]; for ($j = 0; $j < 100000; $j++) { $category_info = $this->model_catalog_category->getCategory(209); } $mtime = explode(" ", microtime()); printf ("page generated %f sec", $mtime[1] + $mtime[0] - $start_time); } Из базы 8.771922 sec , из кеша 3.218499 sec. Замечания, наблюдения? Параметры базы, параметры сервера, структура таблиц, индексы на таблицах, количество файлов в папке с кешем, очередь чтения c диска в боевом режиме, внутренний механизм кеширования mysql - не, не слышал? Если на reg.ru на шареде за две копейки - разница будет раз в 100 отличаться. Только разница между вашими теоретическими выкладками и моими тезисами в том, что вы знаете слово teamlead и живете в синтетических тестах, а я сутки на пролет занимаюсь построением больших систем и оптимизацией средних. Поэтому все о чем вы сейчас пытаетесь с пеной у рта рассказать, пройдено в третьем классе так сказать. Я долго не мог понять, кто эти специалисты, после которых люди приходят ко мне со словами "пятеро уже работали, а тормозит как тормозило". И еще конкретно этот пример оптимизируется совершенно иным методом. Если речь идет о методе из 2.x, если внимательно посмотреть в запрос в нем идет выборка SELECT * из нескольких таблиц c последующей сортировкой по lcase(name). Если включить немного мозг и изучить матчасть по mysql. То логичным будет делать выборку SELECT category_id с составным индексом по полям status и parent_id. В этом случае скорость работы запроса увеличвается в несколько сот раз на больших магазинах. И после этого к результирующему набору дособрать необходимые данные (name, title, descr etc...) и уже средствами php по минимальному набору данных осуществить сортировку по названию. Ни один кеш стандартного метода и рядом стоять не будет, я уже молчу про глобальное снижение нагрузки на всю систему. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Назад 1 2 3 Вперёд Страница 2 из 3 Создайте аккаунт или войдите в него для комментирования Вы должны быть пользователем, чтобы оставить комментарий Создать аккаунт Зарегистрируйтесь для получения аккаунта. Это просто! Зарегистрировать аккаунт Войти Уже зарегистрированы? Войдите здесь. Войти сейчас Поделиться Больше способов поделиться... Подписчики 0 Перейти к списку тем Сейчас на странице 0 пользователей Нет пользователей, просматривающих эту страницу. Последние темы Последние дополнения Последние новости Вся активность Главная Поддержка и ответы на вопросы Отчёты об ошибках Помогите разобраться с логом Mysql Покупцям Оплата розширень фізичними особами Оплата розширень юридичними особами Політика повернень Розробникам Регламент розміщення розширень Регламент продажу та підтримки розширень Віртуальний обліковий запис автора Політика просування оголошень API каталогу розширень Вирішення спорів щодо авторських прав Корисна інформація Публічна оферта Політика повернень Політика конфіденційності Платіжна політика Політика передачі особистих даних Політика прозорості Останні розширення Deals – адаптивный универсальный шаблон Автор: octemplates Динамичесткая инфострока в шапке + позиция в макете для opencart\ocstore 2x, 3x Автор: Lito911 Единицы Измерения Товара Автор: RoS Opencart Product Search by Image Автор: slavoglo Простой массовый редактор цен. Fast Price Edit Автор: Sha × Уже зарегистрированы? Войти Регистрация Раздел покупок Назад Приобретенные дополнения Ваши счета Список желаний Альтернативные контакты Форум Новости ocStore Назад Официальный сайт Демо ocStore 3.0.3.2 Демо ocStore 2.3.0.2.4 Скачать ocStore Документация История версий ocStore Блоги Модули Шаблоны Назад Бесплатные шаблоны Платные шаблоны Где покупать модули? Услуги FAQ OpenCart.Pro Назад Демо Купить Сравнение × Создать... Важная информация На нашем сайте используются файлы cookie и происходит обработка некоторых персональных данных пользователей, чтобы улучшить пользовательский интерфейс. Чтобы узнать для чего и какие персональные данные мы обрабатываем перейдите по ссылке. Если Вы нажмете «Я даю согласие», это означает, что Вы понимаете и принимаете все условия, указанные в этом Уведомлении о Конфиденциальности. Я принимаю
chukcha Опубликовано: 30 ноября 2016 Поделиться Опубликовано: 30 ноября 2016 Повторять две страницы? Увольте. Те кто заинтересовался - прочтет и поймет. Там 1. Вопрос для понимания 2. Тесты 3. Рассуждения о бессмысленности кеширования одной строки в выборке Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Вы, коллега, полагаю, с высоконагруженными проектами не работали? В любом случае, нужно пояснить: - mysql не резиновый, и при высокой посещаемости всякая мелочь, которой очень много, начинает реально тормозить - а бывает, что сервер базы вообще выносят отдельно, и любые запросы к нему - это дополнительные затраты времени - а еще бывает, что в команде разработчиков кто-то начал делать запросы к незакешированному методу (бывает и в цикле), а тимлид не уследил, потому что он не тысячерукий бог Шива, и снова пошла нагрузка - и т.д. и т.п. Так что это нормальная практика. 100 файлов кеша от getcategory на мелком сайте погоды не делают, а на большом могут сэкономить нервные клетки разработчиков. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Вы, коллега, полагаю, с высоконагруженными проектами не работали? В любом случае, нужно пояснить: - mysql не резиновый, и при высокой посещаемости всякая мелочь, которой очень много, начинает реально тормозить - а бывает, что сервер базы вообще выносят отдельно, и любые запросы к нему - это дополнительные затраты времени - а еще бывает, что в команде разработчиков кто-то начал делать запросы к незакешированному методу (бывает и в цикле), а тимлид не уследил, потому что он не тысячерукий бог Шива, и снова пошла нагрузка - и т.д. и т.п. Так что это нормальная практика. 100 файлов кеша от getcategory на мелком сайте погоды не делают, а на большом могут сэкономить нервные клетки разработчиков. Я работал. И однозначно могу сказать что вы пишите бред! Mysql - резиновый и упирается только в ресурсы сервера. Большое количество товаров - это большое количество постоянных изменений данных, поэтому кеш здесь не то что не панацея - а совсем не вариант. А бывает что не только базы выносят на сервер, а под сегменты таблиц ставят отдельную редиску, которая обслуживает к прмеру клиентов, у которых имя начинается на A, а потом еще одну, у которых на B и так 33 штуки до Z. 630 000 - это не мало и не много. MySql кушает и не кашляет. Но вот некоторые реализации требуют напильника. Умные матюки про teamlead - оставьте молоденьким девчонкам. 100 файлов кеша на getCategory это в 100 раз хуже, чем один кеш на все дерево. И в 10 000 раз хуже, чем один запрос на все дерево и формирование дерева через узлы массива. Вобщем крайне рекомендую, прежде чем писать такие комментарии всерьех подумать, есть ли у вас для них квалификация. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Большое количество товаров - это большое количество постоянных изменений данных, поэтому кеш здесь не то что не панацея - а совсем не вариант. Такое ощущение, что у вас товары меняются ежесекундно. :-) Кеш очень даже неплох. Прикидываете среднее время изменения одного товара - это будет время жизни его кеша. Товар поменялся, почистили его кеш и связанные с ним кеши (категорий, модулей и т.д.), остальные кеши не трогаете. В чем проблема? 100 файлов кеша на getCategory это в 100 раз хуже, чем один кеш на все дерево. И в 10 000 раз хуже, чем один запрос на все дерево и формирование дерева через узлы массива. А вы выше читали мой коммент про многоуровневые кеши (номер 35 в теме)? Или чисто забежали в тему, чтобы отписаться? Если вам достаточно кешировать все дерево, и вы абсолютно уверены, что никто не дергает методы моделей без кеширования - ну, я только порадуюсь за вас. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Вы не за меня радуйтесь - а за себя грустите. Потому как тот механизм который предлагаете вы, база отрабатывает быстрее чем кеш! И в нем смысла нет.Еще раз повторяю. Заканчивайте вредные советы! Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Такое ощущение, что у вас товары меняются ежесекундно. :-) Кеш очень даже неплох. Прикидываете среднее время изменения одного товара - это будет время жизни его кеша. Товар поменялся, почистили его кеш и связанные с ним кеши (категорий, модулей и т.д.), остальные кеши не трогаете. В чем проблема? А вы выше читали мой коммент про многоуровневые кеши (номер 35 в теме)? Или чисто забежали в тему, чтобы отписаться? Если вам достаточно кешировать все дерево, и вы абсолютно уверены, что никто не дергает методы моделей без кеширования - ну, я только порадуюсь за вас. Все придумано и реализовано до вас в модуле Turbo. 1 Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Otvet Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 @druzhkov, ок, я малость смешал в кучу придется расписать... 1. getCategory очень легкий запрос, и вызывается единицы раз на страницу. Mysql работает значительно быстрее нежели засоренная ФС через glob 2. getCategories чуть тяжелее, вызывается множественно только во всяких меню. Не имеет смысла кешировать детали паззла если можно собранный P/S Создавая кучу файлов, пускай даже прямого влияния на сам кешированный запрос и не будет, зато замедлит работу кеша в целом, например сео_про. И мифическая оптимизация приведет к общему минусу Не стоит сравнивать mysql с ФС, как минимум до тех пор пока: это не SSD физически полностью не выделен, что позволяет задействовать аппаратные технологии ускорения ФС (а когда на одном устройстве сотня клиентов этого не будет) используется glob Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Потому как тот механизм который предлагаете вы, база отрабатывает быстрее чем кеш! Вот тест: public function test() { $this->load->model('catalog/category'); $mtime = explode(" ", microtime()); $start_time = $mtime[1] + $mtime[0]; for ($j = 0; $j < 100000; $j++) { $category_info = $this->model_catalog_category->getCategory(209); } $mtime = explode(" ", microtime()); printf ("page generated %f sec", $mtime[1] + $mtime[0] - $start_time); } Из базы 8.771922 sec , из кеша 3.218499 sec. Замечания, наблюдения? Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Вот тест: public function test() { $this->load->model('catalog/category'); $mtime = explode(" ", microtime()); $start_time = $mtime[1] + $mtime[0]; for ($j = 0; $j < 100000; $j++) { $category_info = $this->model_catalog_category->getCategory(209); } $mtime = explode(" ", microtime()); printf ("page generated %f sec", $mtime[1] + $mtime[0] - $start_time); } Из базы 8.771922 sec , из кеша 3.218499 sec. Замечания, наблюдения? Параметры базы, параметры сервера, структура таблиц, индексы на таблицах, количество файлов в папке с кешем, очередь чтения c диска в боевом режиме, внутренний механизм кеширования mysql - не, не слышал? Если на reg.ru на шареде за две копейки - разница будет раз в 100 отличаться. Только разница между вашими теоретическими выкладками и моими тезисами в том, что вы знаете слово teamlead и живете в синтетических тестах, а я сутки на пролет занимаюсь построением больших систем и оптимизацией средних. Поэтому все о чем вы сейчас пытаетесь с пеной у рта рассказать, пройдено в третьем классе так сказать. Я долго не мог понять, кто эти специалисты, после которых люди приходят ко мне со словами "пятеро уже работали, а тормозит как тормозило". И еще конкретно этот пример оптимизируется совершенно иным методом. Если речь идет о методе из 2.x, если внимательно посмотреть в запрос в нем идет выборка SELECT * из нескольких таблиц c последующей сортировкой по lcase(name). Если включить немного мозг и изучить матчасть по mysql. То логичным будет делать выборку SELECT category_id с составным индексом по полям status и parent_id. В этом случае скорость работы запроса увеличвается в несколько сот раз на больших магазинах. И после этого к результирующему набору дособрать необходимые данные (name, title, descr etc...) и уже средствами php по минимальному набору данных осуществить сортировку по названию. Ни один кеш стандартного метода и рядом стоять не будет, я уже молчу про глобальное снижение нагрузки на всю систему. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Назад 1 2 3 Вперёд Страница 2 из 3 Создайте аккаунт или войдите в него для комментирования Вы должны быть пользователем, чтобы оставить комментарий Создать аккаунт Зарегистрируйтесь для получения аккаунта. Это просто! Зарегистрировать аккаунт Войти Уже зарегистрированы? Войдите здесь. Войти сейчас Поделиться Больше способов поделиться... Подписчики 0 Перейти к списку тем Сейчас на странице 0 пользователей Нет пользователей, просматривающих эту страницу. Последние темы Последние дополнения Последние новости Вся активность Главная Поддержка и ответы на вопросы Отчёты об ошибках Помогите разобраться с логом Mysql Покупцям Оплата розширень фізичними особами Оплата розширень юридичними особами Політика повернень Розробникам Регламент розміщення розширень Регламент продажу та підтримки розширень Віртуальний обліковий запис автора Політика просування оголошень API каталогу розширень Вирішення спорів щодо авторських прав Корисна інформація Публічна оферта Політика повернень Політика конфіденційності Платіжна політика Політика передачі особистих даних Політика прозорості Останні розширення Deals – адаптивный универсальный шаблон Автор: octemplates Динамичесткая инфострока в шапке + позиция в макете для opencart\ocstore 2x, 3x Автор: Lito911 Единицы Измерения Товара Автор: RoS Opencart Product Search by Image Автор: slavoglo Простой массовый редактор цен. Fast Price Edit Автор: Sha × Уже зарегистрированы? Войти Регистрация Раздел покупок Назад Приобретенные дополнения Ваши счета Список желаний Альтернативные контакты Форум Новости ocStore Назад Официальный сайт Демо ocStore 3.0.3.2 Демо ocStore 2.3.0.2.4 Скачать ocStore Документация История версий ocStore Блоги Модули Шаблоны Назад Бесплатные шаблоны Платные шаблоны Где покупать модули? Услуги FAQ OpenCart.Pro Назад Демо Купить Сравнение × Создать... Важная информация На нашем сайте используются файлы cookie и происходит обработка некоторых персональных данных пользователей, чтобы улучшить пользовательский интерфейс. Чтобы узнать для чего и какие персональные данные мы обрабатываем перейдите по ссылке. Если Вы нажмете «Я даю согласие», это означает, что Вы понимаете и принимаете все условия, указанные в этом Уведомлении о Конфиденциальности. Я принимаю
druzhkov Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Вы, коллега, полагаю, с высоконагруженными проектами не работали? В любом случае, нужно пояснить: - mysql не резиновый, и при высокой посещаемости всякая мелочь, которой очень много, начинает реально тормозить - а бывает, что сервер базы вообще выносят отдельно, и любые запросы к нему - это дополнительные затраты времени - а еще бывает, что в команде разработчиков кто-то начал делать запросы к незакешированному методу (бывает и в цикле), а тимлид не уследил, потому что он не тысячерукий бог Шива, и снова пошла нагрузка - и т.д. и т.п. Так что это нормальная практика. 100 файлов кеша от getcategory на мелком сайте погоды не делают, а на большом могут сэкономить нервные клетки разработчиков. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Вы, коллега, полагаю, с высоконагруженными проектами не работали? В любом случае, нужно пояснить: - mysql не резиновый, и при высокой посещаемости всякая мелочь, которой очень много, начинает реально тормозить - а бывает, что сервер базы вообще выносят отдельно, и любые запросы к нему - это дополнительные затраты времени - а еще бывает, что в команде разработчиков кто-то начал делать запросы к незакешированному методу (бывает и в цикле), а тимлид не уследил, потому что он не тысячерукий бог Шива, и снова пошла нагрузка - и т.д. и т.п. Так что это нормальная практика. 100 файлов кеша от getcategory на мелком сайте погоды не делают, а на большом могут сэкономить нервные клетки разработчиков. Я работал. И однозначно могу сказать что вы пишите бред! Mysql - резиновый и упирается только в ресурсы сервера. Большое количество товаров - это большое количество постоянных изменений данных, поэтому кеш здесь не то что не панацея - а совсем не вариант. А бывает что не только базы выносят на сервер, а под сегменты таблиц ставят отдельную редиску, которая обслуживает к прмеру клиентов, у которых имя начинается на A, а потом еще одну, у которых на B и так 33 штуки до Z. 630 000 - это не мало и не много. MySql кушает и не кашляет. Но вот некоторые реализации требуют напильника. Умные матюки про teamlead - оставьте молоденьким девчонкам. 100 файлов кеша на getCategory это в 100 раз хуже, чем один кеш на все дерево. И в 10 000 раз хуже, чем один запрос на все дерево и формирование дерева через узлы массива. Вобщем крайне рекомендую, прежде чем писать такие комментарии всерьех подумать, есть ли у вас для них квалификация. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Большое количество товаров - это большое количество постоянных изменений данных, поэтому кеш здесь не то что не панацея - а совсем не вариант. Такое ощущение, что у вас товары меняются ежесекундно. :-) Кеш очень даже неплох. Прикидываете среднее время изменения одного товара - это будет время жизни его кеша. Товар поменялся, почистили его кеш и связанные с ним кеши (категорий, модулей и т.д.), остальные кеши не трогаете. В чем проблема? 100 файлов кеша на getCategory это в 100 раз хуже, чем один кеш на все дерево. И в 10 000 раз хуже, чем один запрос на все дерево и формирование дерева через узлы массива. А вы выше читали мой коммент про многоуровневые кеши (номер 35 в теме)? Или чисто забежали в тему, чтобы отписаться? Если вам достаточно кешировать все дерево, и вы абсолютно уверены, что никто не дергает методы моделей без кеширования - ну, я только порадуюсь за вас. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Вы не за меня радуйтесь - а за себя грустите. Потому как тот механизм который предлагаете вы, база отрабатывает быстрее чем кеш! И в нем смысла нет.Еще раз повторяю. Заканчивайте вредные советы! Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Такое ощущение, что у вас товары меняются ежесекундно. :-) Кеш очень даже неплох. Прикидываете среднее время изменения одного товара - это будет время жизни его кеша. Товар поменялся, почистили его кеш и связанные с ним кеши (категорий, модулей и т.д.), остальные кеши не трогаете. В чем проблема? А вы выше читали мой коммент про многоуровневые кеши (номер 35 в теме)? Или чисто забежали в тему, чтобы отписаться? Если вам достаточно кешировать все дерево, и вы абсолютно уверены, что никто не дергает методы моделей без кеширования - ну, я только порадуюсь за вас. Все придумано и реализовано до вас в модуле Turbo. 1 Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Otvet Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 @druzhkov, ок, я малость смешал в кучу придется расписать... 1. getCategory очень легкий запрос, и вызывается единицы раз на страницу. Mysql работает значительно быстрее нежели засоренная ФС через glob 2. getCategories чуть тяжелее, вызывается множественно только во всяких меню. Не имеет смысла кешировать детали паззла если можно собранный P/S Создавая кучу файлов, пускай даже прямого влияния на сам кешированный запрос и не будет, зато замедлит работу кеша в целом, например сео_про. И мифическая оптимизация приведет к общему минусу Не стоит сравнивать mysql с ФС, как минимум до тех пор пока: это не SSD физически полностью не выделен, что позволяет задействовать аппаратные технологии ускорения ФС (а когда на одном устройстве сотня клиентов этого не будет) используется glob Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Потому как тот механизм который предлагаете вы, база отрабатывает быстрее чем кеш! Вот тест: public function test() { $this->load->model('catalog/category'); $mtime = explode(" ", microtime()); $start_time = $mtime[1] + $mtime[0]; for ($j = 0; $j < 100000; $j++) { $category_info = $this->model_catalog_category->getCategory(209); } $mtime = explode(" ", microtime()); printf ("page generated %f sec", $mtime[1] + $mtime[0] - $start_time); } Из базы 8.771922 sec , из кеша 3.218499 sec. Замечания, наблюдения? Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Вот тест: public function test() { $this->load->model('catalog/category'); $mtime = explode(" ", microtime()); $start_time = $mtime[1] + $mtime[0]; for ($j = 0; $j < 100000; $j++) { $category_info = $this->model_catalog_category->getCategory(209); } $mtime = explode(" ", microtime()); printf ("page generated %f sec", $mtime[1] + $mtime[0] - $start_time); } Из базы 8.771922 sec , из кеша 3.218499 sec. Замечания, наблюдения? Параметры базы, параметры сервера, структура таблиц, индексы на таблицах, количество файлов в папке с кешем, очередь чтения c диска в боевом режиме, внутренний механизм кеширования mysql - не, не слышал? Если на reg.ru на шареде за две копейки - разница будет раз в 100 отличаться. Только разница между вашими теоретическими выкладками и моими тезисами в том, что вы знаете слово teamlead и живете в синтетических тестах, а я сутки на пролет занимаюсь построением больших систем и оптимизацией средних. Поэтому все о чем вы сейчас пытаетесь с пеной у рта рассказать, пройдено в третьем классе так сказать. Я долго не мог понять, кто эти специалисты, после которых люди приходят ко мне со словами "пятеро уже работали, а тормозит как тормозило". И еще конкретно этот пример оптимизируется совершенно иным методом. Если речь идет о методе из 2.x, если внимательно посмотреть в запрос в нем идет выборка SELECT * из нескольких таблиц c последующей сортировкой по lcase(name). Если включить немного мозг и изучить матчасть по mysql. То логичным будет делать выборку SELECT category_id с составным индексом по полям status и parent_id. В этом случае скорость работы запроса увеличвается в несколько сот раз на больших магазинах. И после этого к результирующему набору дособрать необходимые данные (name, title, descr etc...) и уже средствами php по минимальному набору данных осуществить сортировку по названию. Ни один кеш стандартного метода и рядом стоять не будет, я уже молчу про глобальное снижение нагрузки на всю систему. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Назад 1 2 3 Вперёд Страница 2 из 3 Создайте аккаунт или войдите в него для комментирования Вы должны быть пользователем, чтобы оставить комментарий Создать аккаунт Зарегистрируйтесь для получения аккаунта. Это просто! Зарегистрировать аккаунт Войти Уже зарегистрированы? Войдите здесь. Войти сейчас Поделиться Больше способов поделиться... Подписчики 0 Перейти к списку тем Сейчас на странице 0 пользователей Нет пользователей, просматривающих эту страницу. Последние темы Последние дополнения Последние новости Вся активность Главная Поддержка и ответы на вопросы Отчёты об ошибках Помогите разобраться с логом Mysql Покупцям Оплата розширень фізичними особами Оплата розширень юридичними особами Політика повернень Розробникам Регламент розміщення розширень Регламент продажу та підтримки розширень Віртуальний обліковий запис автора Політика просування оголошень API каталогу розширень Вирішення спорів щодо авторських прав Корисна інформація Публічна оферта Політика повернень Політика конфіденційності Платіжна політика Політика передачі особистих даних Політика прозорості Останні розширення Deals – адаптивный универсальный шаблон Автор: octemplates Динамичесткая инфострока в шапке + позиция в макете для opencart\ocstore 2x, 3x Автор: Lito911 Единицы Измерения Товара Автор: RoS Opencart Product Search by Image Автор: slavoglo Простой массовый редактор цен. Fast Price Edit Автор: Sha × Уже зарегистрированы? Войти Регистрация Раздел покупок Назад Приобретенные дополнения Ваши счета Список желаний Альтернативные контакты Форум Новости ocStore Назад Официальный сайт Демо ocStore 3.0.3.2 Демо ocStore 2.3.0.2.4 Скачать ocStore Документация История версий ocStore Блоги Модули Шаблоны Назад Бесплатные шаблоны Платные шаблоны Где покупать модули? Услуги FAQ OpenCart.Pro Назад Демо Купить Сравнение × Создать... Важная информация На нашем сайте используются файлы cookie и происходит обработка некоторых персональных данных пользователей, чтобы улучшить пользовательский интерфейс. Чтобы узнать для чего и какие персональные данные мы обрабатываем перейдите по ссылке. Если Вы нажмете «Я даю согласие», это означает, что Вы понимаете и принимаете все условия, указанные в этом Уведомлении о Конфиденциальности. Я принимаю
Yoda Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Вы, коллега, полагаю, с высоконагруженными проектами не работали? В любом случае, нужно пояснить: - mysql не резиновый, и при высокой посещаемости всякая мелочь, которой очень много, начинает реально тормозить - а бывает, что сервер базы вообще выносят отдельно, и любые запросы к нему - это дополнительные затраты времени - а еще бывает, что в команде разработчиков кто-то начал делать запросы к незакешированному методу (бывает и в цикле), а тимлид не уследил, потому что он не тысячерукий бог Шива, и снова пошла нагрузка - и т.д. и т.п. Так что это нормальная практика. 100 файлов кеша от getcategory на мелком сайте погоды не делают, а на большом могут сэкономить нервные клетки разработчиков. Я работал. И однозначно могу сказать что вы пишите бред! Mysql - резиновый и упирается только в ресурсы сервера. Большое количество товаров - это большое количество постоянных изменений данных, поэтому кеш здесь не то что не панацея - а совсем не вариант. А бывает что не только базы выносят на сервер, а под сегменты таблиц ставят отдельную редиску, которая обслуживает к прмеру клиентов, у которых имя начинается на A, а потом еще одну, у которых на B и так 33 штуки до Z. 630 000 - это не мало и не много. MySql кушает и не кашляет. Но вот некоторые реализации требуют напильника. Умные матюки про teamlead - оставьте молоденьким девчонкам. 100 файлов кеша на getCategory это в 100 раз хуже, чем один кеш на все дерево. И в 10 000 раз хуже, чем один запрос на все дерево и формирование дерева через узлы массива. Вобщем крайне рекомендую, прежде чем писать такие комментарии всерьех подумать, есть ли у вас для них квалификация. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться...
druzhkov Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Большое количество товаров - это большое количество постоянных изменений данных, поэтому кеш здесь не то что не панацея - а совсем не вариант. Такое ощущение, что у вас товары меняются ежесекундно. :-) Кеш очень даже неплох. Прикидываете среднее время изменения одного товара - это будет время жизни его кеша. Товар поменялся, почистили его кеш и связанные с ним кеши (категорий, модулей и т.д.), остальные кеши не трогаете. В чем проблема? 100 файлов кеша на getCategory это в 100 раз хуже, чем один кеш на все дерево. И в 10 000 раз хуже, чем один запрос на все дерево и формирование дерева через узлы массива. А вы выше читали мой коммент про многоуровневые кеши (номер 35 в теме)? Или чисто забежали в тему, чтобы отписаться? Если вам достаточно кешировать все дерево, и вы абсолютно уверены, что никто не дергает методы моделей без кеширования - ну, я только порадуюсь за вас. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Вы не за меня радуйтесь - а за себя грустите. Потому как тот механизм который предлагаете вы, база отрабатывает быстрее чем кеш! И в нем смысла нет.Еще раз повторяю. Заканчивайте вредные советы! Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Такое ощущение, что у вас товары меняются ежесекундно. :-) Кеш очень даже неплох. Прикидываете среднее время изменения одного товара - это будет время жизни его кеша. Товар поменялся, почистили его кеш и связанные с ним кеши (категорий, модулей и т.д.), остальные кеши не трогаете. В чем проблема? А вы выше читали мой коммент про многоуровневые кеши (номер 35 в теме)? Или чисто забежали в тему, чтобы отписаться? Если вам достаточно кешировать все дерево, и вы абсолютно уверены, что никто не дергает методы моделей без кеширования - ну, я только порадуюсь за вас. Все придумано и реализовано до вас в модуле Turbo. 1 Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Otvet Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 @druzhkov, ок, я малость смешал в кучу придется расписать... 1. getCategory очень легкий запрос, и вызывается единицы раз на страницу. Mysql работает значительно быстрее нежели засоренная ФС через glob 2. getCategories чуть тяжелее, вызывается множественно только во всяких меню. Не имеет смысла кешировать детали паззла если можно собранный P/S Создавая кучу файлов, пускай даже прямого влияния на сам кешированный запрос и не будет, зато замедлит работу кеша в целом, например сео_про. И мифическая оптимизация приведет к общему минусу Не стоит сравнивать mysql с ФС, как минимум до тех пор пока: это не SSD физически полностью не выделен, что позволяет задействовать аппаратные технологии ускорения ФС (а когда на одном устройстве сотня клиентов этого не будет) используется glob Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Потому как тот механизм который предлагаете вы, база отрабатывает быстрее чем кеш! Вот тест: public function test() { $this->load->model('catalog/category'); $mtime = explode(" ", microtime()); $start_time = $mtime[1] + $mtime[0]; for ($j = 0; $j < 100000; $j++) { $category_info = $this->model_catalog_category->getCategory(209); } $mtime = explode(" ", microtime()); printf ("page generated %f sec", $mtime[1] + $mtime[0] - $start_time); } Из базы 8.771922 sec , из кеша 3.218499 sec. Замечания, наблюдения? Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Вот тест: public function test() { $this->load->model('catalog/category'); $mtime = explode(" ", microtime()); $start_time = $mtime[1] + $mtime[0]; for ($j = 0; $j < 100000; $j++) { $category_info = $this->model_catalog_category->getCategory(209); } $mtime = explode(" ", microtime()); printf ("page generated %f sec", $mtime[1] + $mtime[0] - $start_time); } Из базы 8.771922 sec , из кеша 3.218499 sec. Замечания, наблюдения? Параметры базы, параметры сервера, структура таблиц, индексы на таблицах, количество файлов в папке с кешем, очередь чтения c диска в боевом режиме, внутренний механизм кеширования mysql - не, не слышал? Если на reg.ru на шареде за две копейки - разница будет раз в 100 отличаться. Только разница между вашими теоретическими выкладками и моими тезисами в том, что вы знаете слово teamlead и живете в синтетических тестах, а я сутки на пролет занимаюсь построением больших систем и оптимизацией средних. Поэтому все о чем вы сейчас пытаетесь с пеной у рта рассказать, пройдено в третьем классе так сказать. Я долго не мог понять, кто эти специалисты, после которых люди приходят ко мне со словами "пятеро уже работали, а тормозит как тормозило". И еще конкретно этот пример оптимизируется совершенно иным методом. Если речь идет о методе из 2.x, если внимательно посмотреть в запрос в нем идет выборка SELECT * из нескольких таблиц c последующей сортировкой по lcase(name). Если включить немного мозг и изучить матчасть по mysql. То логичным будет делать выборку SELECT category_id с составным индексом по полям status и parent_id. В этом случае скорость работы запроса увеличвается в несколько сот раз на больших магазинах. И после этого к результирующему набору дособрать необходимые данные (name, title, descr etc...) и уже средствами php по минимальному набору данных осуществить сортировку по названию. Ни один кеш стандартного метода и рядом стоять не будет, я уже молчу про глобальное снижение нагрузки на всю систему. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Назад 1 2 3 Вперёд Страница 2 из 3 Создайте аккаунт или войдите в него для комментирования Вы должны быть пользователем, чтобы оставить комментарий Создать аккаунт Зарегистрируйтесь для получения аккаунта. Это просто! Зарегистрировать аккаунт Войти Уже зарегистрированы? Войдите здесь. Войти сейчас Поделиться Больше способов поделиться... Подписчики 0 Перейти к списку тем Сейчас на странице 0 пользователей Нет пользователей, просматривающих эту страницу. Последние темы Последние дополнения Последние новости Вся активность Главная Поддержка и ответы на вопросы Отчёты об ошибках Помогите разобраться с логом Mysql Покупцям Оплата розширень фізичними особами Оплата розширень юридичними особами Політика повернень Розробникам Регламент розміщення розширень Регламент продажу та підтримки розширень Віртуальний обліковий запис автора Політика просування оголошень API каталогу розширень Вирішення спорів щодо авторських прав Корисна інформація Публічна оферта Політика повернень Політика конфіденційності Платіжна політика Політика передачі особистих даних Політика прозорості Останні розширення Deals – адаптивный универсальный шаблон Автор: octemplates Динамичесткая инфострока в шапке + позиция в макете для opencart\ocstore 2x, 3x Автор: Lito911 Единицы Измерения Товара Автор: RoS Opencart Product Search by Image Автор: slavoglo Простой массовый редактор цен. Fast Price Edit Автор: Sha
Yoda Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Вы не за меня радуйтесь - а за себя грустите. Потому как тот механизм который предлагаете вы, база отрабатывает быстрее чем кеш! И в нем смысла нет.Еще раз повторяю. Заканчивайте вредные советы! Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться...
snastik Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Такое ощущение, что у вас товары меняются ежесекундно. :-) Кеш очень даже неплох. Прикидываете среднее время изменения одного товара - это будет время жизни его кеша. Товар поменялся, почистили его кеш и связанные с ним кеши (категорий, модулей и т.д.), остальные кеши не трогаете. В чем проблема? А вы выше читали мой коммент про многоуровневые кеши (номер 35 в теме)? Или чисто забежали в тему, чтобы отписаться? Если вам достаточно кешировать все дерево, и вы абсолютно уверены, что никто не дергает методы моделей без кеширования - ну, я только порадуюсь за вас. Все придумано и реализовано до вас в модуле Turbo. 1 Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Otvet Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 @druzhkov, ок, я малость смешал в кучу придется расписать... 1. getCategory очень легкий запрос, и вызывается единицы раз на страницу. Mysql работает значительно быстрее нежели засоренная ФС через glob 2. getCategories чуть тяжелее, вызывается множественно только во всяких меню. Не имеет смысла кешировать детали паззла если можно собранный P/S Создавая кучу файлов, пускай даже прямого влияния на сам кешированный запрос и не будет, зато замедлит работу кеша в целом, например сео_про. И мифическая оптимизация приведет к общему минусу Не стоит сравнивать mysql с ФС, как минимум до тех пор пока: это не SSD физически полностью не выделен, что позволяет задействовать аппаратные технологии ускорения ФС (а когда на одном устройстве сотня клиентов этого не будет) используется glob Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Потому как тот механизм который предлагаете вы, база отрабатывает быстрее чем кеш! Вот тест: public function test() { $this->load->model('catalog/category'); $mtime = explode(" ", microtime()); $start_time = $mtime[1] + $mtime[0]; for ($j = 0; $j < 100000; $j++) { $category_info = $this->model_catalog_category->getCategory(209); } $mtime = explode(" ", microtime()); printf ("page generated %f sec", $mtime[1] + $mtime[0] - $start_time); } Из базы 8.771922 sec , из кеша 3.218499 sec. Замечания, наблюдения? Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Вот тест: public function test() { $this->load->model('catalog/category'); $mtime = explode(" ", microtime()); $start_time = $mtime[1] + $mtime[0]; for ($j = 0; $j < 100000; $j++) { $category_info = $this->model_catalog_category->getCategory(209); } $mtime = explode(" ", microtime()); printf ("page generated %f sec", $mtime[1] + $mtime[0] - $start_time); } Из базы 8.771922 sec , из кеша 3.218499 sec. Замечания, наблюдения? Параметры базы, параметры сервера, структура таблиц, индексы на таблицах, количество файлов в папке с кешем, очередь чтения c диска в боевом режиме, внутренний механизм кеширования mysql - не, не слышал? Если на reg.ru на шареде за две копейки - разница будет раз в 100 отличаться. Только разница между вашими теоретическими выкладками и моими тезисами в том, что вы знаете слово teamlead и живете в синтетических тестах, а я сутки на пролет занимаюсь построением больших систем и оптимизацией средних. Поэтому все о чем вы сейчас пытаетесь с пеной у рта рассказать, пройдено в третьем классе так сказать. Я долго не мог понять, кто эти специалисты, после которых люди приходят ко мне со словами "пятеро уже работали, а тормозит как тормозило". И еще конкретно этот пример оптимизируется совершенно иным методом. Если речь идет о методе из 2.x, если внимательно посмотреть в запрос в нем идет выборка SELECT * из нескольких таблиц c последующей сортировкой по lcase(name). Если включить немного мозг и изучить матчасть по mysql. То логичным будет делать выборку SELECT category_id с составным индексом по полям status и parent_id. В этом случае скорость работы запроса увеличвается в несколько сот раз на больших магазинах. И после этого к результирующему набору дособрать необходимые данные (name, title, descr etc...) и уже средствами php по минимальному набору данных осуществить сортировку по названию. Ни один кеш стандартного метода и рядом стоять не будет, я уже молчу про глобальное снижение нагрузки на всю систему. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Назад 1 2 3 Вперёд Страница 2 из 3 Создайте аккаунт или войдите в него для комментирования Вы должны быть пользователем, чтобы оставить комментарий Создать аккаунт Зарегистрируйтесь для получения аккаунта. Это просто! Зарегистрировать аккаунт Войти Уже зарегистрированы? Войдите здесь. Войти сейчас Поделиться Больше способов поделиться... Подписчики 0 Перейти к списку тем Сейчас на странице 0 пользователей Нет пользователей, просматривающих эту страницу. Последние темы Последние дополнения Последние новости Вся активность Главная Поддержка и ответы на вопросы Отчёты об ошибках Помогите разобраться с логом Mysql
Otvet Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 @druzhkov, ок, я малость смешал в кучу придется расписать... 1. getCategory очень легкий запрос, и вызывается единицы раз на страницу. Mysql работает значительно быстрее нежели засоренная ФС через glob 2. getCategories чуть тяжелее, вызывается множественно только во всяких меню. Не имеет смысла кешировать детали паззла если можно собранный P/S Создавая кучу файлов, пускай даже прямого влияния на сам кешированный запрос и не будет, зато замедлит работу кеша в целом, например сео_про. И мифическая оптимизация приведет к общему минусу Не стоит сравнивать mysql с ФС, как минимум до тех пор пока: это не SSD физически полностью не выделен, что позволяет задействовать аппаратные технологии ускорения ФС (а когда на одном устройстве сотня клиентов этого не будет) используется glob Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... druzhkov Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Потому как тот механизм который предлагаете вы, база отрабатывает быстрее чем кеш! Вот тест: public function test() { $this->load->model('catalog/category'); $mtime = explode(" ", microtime()); $start_time = $mtime[1] + $mtime[0]; for ($j = 0; $j < 100000; $j++) { $category_info = $this->model_catalog_category->getCategory(209); } $mtime = explode(" ", microtime()); printf ("page generated %f sec", $mtime[1] + $mtime[0] - $start_time); } Из базы 8.771922 sec , из кеша 3.218499 sec. Замечания, наблюдения? Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Вот тест: public function test() { $this->load->model('catalog/category'); $mtime = explode(" ", microtime()); $start_time = $mtime[1] + $mtime[0]; for ($j = 0; $j < 100000; $j++) { $category_info = $this->model_catalog_category->getCategory(209); } $mtime = explode(" ", microtime()); printf ("page generated %f sec", $mtime[1] + $mtime[0] - $start_time); } Из базы 8.771922 sec , из кеша 3.218499 sec. Замечания, наблюдения? Параметры базы, параметры сервера, структура таблиц, индексы на таблицах, количество файлов в папке с кешем, очередь чтения c диска в боевом режиме, внутренний механизм кеширования mysql - не, не слышал? Если на reg.ru на шареде за две копейки - разница будет раз в 100 отличаться. Только разница между вашими теоретическими выкладками и моими тезисами в том, что вы знаете слово teamlead и живете в синтетических тестах, а я сутки на пролет занимаюсь построением больших систем и оптимизацией средних. Поэтому все о чем вы сейчас пытаетесь с пеной у рта рассказать, пройдено в третьем классе так сказать. Я долго не мог понять, кто эти специалисты, после которых люди приходят ко мне со словами "пятеро уже работали, а тормозит как тормозило". И еще конкретно этот пример оптимизируется совершенно иным методом. Если речь идет о методе из 2.x, если внимательно посмотреть в запрос в нем идет выборка SELECT * из нескольких таблиц c последующей сортировкой по lcase(name). Если включить немного мозг и изучить матчасть по mysql. То логичным будет делать выборку SELECT category_id с составным индексом по полям status и parent_id. В этом случае скорость работы запроса увеличвается в несколько сот раз на больших магазинах. И после этого к результирующему набору дособрать необходимые данные (name, title, descr etc...) и уже средствами php по минимальному набору данных осуществить сортировку по названию. Ни один кеш стандартного метода и рядом стоять не будет, я уже молчу про глобальное снижение нагрузки на всю систему. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Назад 1 2 3 Вперёд Страница 2 из 3 Создайте аккаунт или войдите в него для комментирования Вы должны быть пользователем, чтобы оставить комментарий Создать аккаунт Зарегистрируйтесь для получения аккаунта. Это просто! Зарегистрировать аккаунт Войти Уже зарегистрированы? Войдите здесь. Войти сейчас Поделиться Больше способов поделиться... Подписчики 0 Перейти к списку тем Сейчас на странице 0 пользователей Нет пользователей, просматривающих эту страницу.
druzhkov Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Потому как тот механизм который предлагаете вы, база отрабатывает быстрее чем кеш! Вот тест: public function test() { $this->load->model('catalog/category'); $mtime = explode(" ", microtime()); $start_time = $mtime[1] + $mtime[0]; for ($j = 0; $j < 100000; $j++) { $category_info = $this->model_catalog_category->getCategory(209); } $mtime = explode(" ", microtime()); printf ("page generated %f sec", $mtime[1] + $mtime[0] - $start_time); } Из базы 8.771922 sec , из кеша 3.218499 sec. Замечания, наблюдения? Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Yoda Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Вот тест: public function test() { $this->load->model('catalog/category'); $mtime = explode(" ", microtime()); $start_time = $mtime[1] + $mtime[0]; for ($j = 0; $j < 100000; $j++) { $category_info = $this->model_catalog_category->getCategory(209); } $mtime = explode(" ", microtime()); printf ("page generated %f sec", $mtime[1] + $mtime[0] - $start_time); } Из базы 8.771922 sec , из кеша 3.218499 sec. Замечания, наблюдения? Параметры базы, параметры сервера, структура таблиц, индексы на таблицах, количество файлов в папке с кешем, очередь чтения c диска в боевом режиме, внутренний механизм кеширования mysql - не, не слышал? Если на reg.ru на шареде за две копейки - разница будет раз в 100 отличаться. Только разница между вашими теоретическими выкладками и моими тезисами в том, что вы знаете слово teamlead и живете в синтетических тестах, а я сутки на пролет занимаюсь построением больших систем и оптимизацией средних. Поэтому все о чем вы сейчас пытаетесь с пеной у рта рассказать, пройдено в третьем классе так сказать. Я долго не мог понять, кто эти специалисты, после которых люди приходят ко мне со словами "пятеро уже работали, а тормозит как тормозило". И еще конкретно этот пример оптимизируется совершенно иным методом. Если речь идет о методе из 2.x, если внимательно посмотреть в запрос в нем идет выборка SELECT * из нескольких таблиц c последующей сортировкой по lcase(name). Если включить немного мозг и изучить матчасть по mysql. То логичным будет делать выборку SELECT category_id с составным индексом по полям status и parent_id. В этом случае скорость работы запроса увеличвается в несколько сот раз на больших магазинах. И после этого к результирующему набору дособрать необходимые данные (name, title, descr etc...) и уже средствами php по минимальному набору данных осуществить сортировку по названию. Ни один кеш стандартного метода и рядом стоять не будет, я уже молчу про глобальное снижение нагрузки на всю систему. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Назад 1 2 3 Вперёд Страница 2 из 3 Создайте аккаунт или войдите в него для комментирования Вы должны быть пользователем, чтобы оставить комментарий Создать аккаунт Зарегистрируйтесь для получения аккаунта. Это просто! Зарегистрировать аккаунт Войти Уже зарегистрированы? Войдите здесь. Войти сейчас Поделиться Больше способов поделиться... Подписчики 0
Yoda Опубликовано: 1 декабря 2016 Поделиться Опубликовано: 1 декабря 2016 Вот тест: public function test() { $this->load->model('catalog/category'); $mtime = explode(" ", microtime()); $start_time = $mtime[1] + $mtime[0]; for ($j = 0; $j < 100000; $j++) { $category_info = $this->model_catalog_category->getCategory(209); } $mtime = explode(" ", microtime()); printf ("page generated %f sec", $mtime[1] + $mtime[0] - $start_time); } Из базы 8.771922 sec , из кеша 3.218499 sec. Замечания, наблюдения? Параметры базы, параметры сервера, структура таблиц, индексы на таблицах, количество файлов в папке с кешем, очередь чтения c диска в боевом режиме, внутренний механизм кеширования mysql - не, не слышал? Если на reg.ru на шареде за две копейки - разница будет раз в 100 отличаться. Только разница между вашими теоретическими выкладками и моими тезисами в том, что вы знаете слово teamlead и живете в синтетических тестах, а я сутки на пролет занимаюсь построением больших систем и оптимизацией средних. Поэтому все о чем вы сейчас пытаетесь с пеной у рта рассказать, пройдено в третьем классе так сказать. Я долго не мог понять, кто эти специалисты, после которых люди приходят ко мне со словами "пятеро уже работали, а тормозит как тормозило". И еще конкретно этот пример оптимизируется совершенно иным методом. Если речь идет о методе из 2.x, если внимательно посмотреть в запрос в нем идет выборка SELECT * из нескольких таблиц c последующей сортировкой по lcase(name). Если включить немного мозг и изучить матчасть по mysql. То логичным будет делать выборку SELECT category_id с составным индексом по полям status и parent_id. В этом случае скорость работы запроса увеличвается в несколько сот раз на больших магазинах. И после этого к результирующему набору дособрать необходимые данные (name, title, descr etc...) и уже средствами php по минимальному набору данных осуществить сортировку по названию. Ни один кеш стандартного метода и рядом стоять не будет, я уже молчу про глобальное снижение нагрузки на всю систему. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться...
Рекомендованные сообщения