druzhkov

Проблему с сайтом решили. Вот здесь статья с разбором ситуации.

Все редактируется в catalog/language. Ищите соответствующие файлы там.

С высокой вероятностью целостность и проверяется в этих строчках. Стандартная практика - возвращать строго false при любых ошибках открытия (нет файла, битый и т.д.) Для уточнения нужно заглянуть в код метода open.

Для mysqliz нужны дополнительные скрипты, "из коробки" он не идет. Это так, на будущее.

Попробуйте драйвер mysql (без "i"). Еще я посмотрел другой конфиг, тоже на таймвебе, там стоит драйвер mysqliz.

Это я сам исправлял ее, ссылки на скачивание нет.

А что в error.log? На худой конец можно глазами посмотреть список всех системных логов (скорее всего, в /var/log), и заглянуть в те, которые изменились в момент обрыва связи.

Что говорит access.log? Пока можно предположить только какое-нибудь зацикливание...

Не совсем понятно: заход с IE наглухо подвешивает весь сайт? То есть даже из других браузеров / с других компьютеров не зайти?

Соглашусь, хотя вот реальный кейс: у магазина был прописан ящик gmail, что вызывало проблемы. Манипуляции в SPF не помогли. Плюнули, прописали несуществующий no-reply@домен (+ внесли изменения в system/library/mail.php), сразу всё встало на свои места, SPF - корректная, DKIM - корректная, gmail доволен. Тут еще момент, что в opencart ящик из настроек впихивается во все поля: from, reply-to, return-path. Так что да, в общем случае, надо реальный ящик заводить.

На gmail искать причину удобно - нажимаете "посмотреть оригинал", он открывает письмо с табличкой сверху, там можно ознакомиться, почему в спам и т.д. Еще есть сервис https://www.mail-tester.com/ , который тоже делает проверки.

Вот буквально на днях был такой сайт. Кеш забился на 100 тыс. (!!) файлов, и сайт просто задохнулся. Видимо, с какого-то момента просто перестал успевать вычищать старые файлы. Поставил доработанную библиотеку для работы с кешем - всё стало работать как часики.

[email protected] - довольно странный отправитель. Как будто хостер обрабатывает письмо перед отправкой. Запрос туда писали?

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

Я прекрасно знаю влияние этих параметров. Это я запускал на своем компе - конечно, тюнинга особого нет. Ладно, попробуем на шареде таймвеба: Из базы: 4.74962 sec Из кеша: 2.904995 sec Полагаю, на таймвебе все-таки база получше настроена, чем у меня. В файловом кеше округленно лежит 1000 файлов. Так вроде всё типовое. Диск SSD. Индексы по базе проставлены. Еще вопросы, замечания?

Вот тест: 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. Замечания, наблюдения?

Такое ощущение, что у вас товары меняются ежесекундно. :-) Кеш очень даже неплох. Прикидываете среднее время изменения одного товара - это будет время жизни его кеша. Товар поменялся, почистили его кеш и связанные с ним кеши (категорий, модулей и т.д.), остальные кеши не трогаете. В чем проблема? А вы выше читали мой коммент про многоуровневые кеши (номер 35 в теме)? Или чисто забежали в тему, чтобы отписаться? Если вам достаточно кешировать все дерево, и вы абсолютно уверены, что никто не дергает методы моделей без кеширования - ну, я только порадуюсь за вас.

Вы, коллега, полагаю, с высоконагруженными проектами не работали? В любом случае, нужно пояснить: - mysql не резиновый, и при высокой посещаемости всякая мелочь, которой очень много, начинает реально тормозить - а бывает, что сервер базы вообще выносят отдельно, и любые запросы к нему - это дополнительные затраты времени - а еще бывает, что в команде разработчиков кто-то начал делать запросы к незакешированному методу (бывает и в цикле), а тимлид не уследил, потому что он не тысячерукий бог Шива, и снова пошла нагрузка - и т.д. и т.п. Так что это нормальная практика. 100 файлов кеша от getcategory на мелком сайте погоды не делают, а на большом могут сэкономить нервные клетки разработчиков.

Если вас не устраивает, сделайте пулл реквест на гитхаб опенкарта. Данная конструкция стоит как в 1.5, так и в 2.0. Еще раз напишите обоснование бесмысленности. Не понимаю вашу мысль.

Разницы и не должно быть. ТС привел лог и сказал, что тормозит магазин. Логично заключить, что это медленные запросы. Я привел вариант, как их можно закешировать.

Вот запрос топикстартера: 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. Если не нравится, можно туда не смотреть. Это попутно скопировались из редактора.

Вы не путайте getCategory и getCategories. При построении меню используется второе. Соответственно: если будут только корневые директории - прочитаем 1 файл корневые + поддиректории - прочитаем, условно, 10 файлов корневые + поддиректории + подподдиректории - прочитаем, условно, 100 файлов (здесь да, имеет смысл сохранять готовое дерево) Правильно кеширование делать именно в моделях, т.к. неизвестно из какого контроллера прийдет туда запрос. Это основа, и она всегда должна работать быстро. Ну, если и этого не хватает - тогда добавляйте дополнительный кеш уже на уровне контроллера, целого модуля, блока или вообще целой страницы. Например, вот такая "матрешка" для высоконагруженного проекта: - кеш mysql - кеш на уровне моделей (файловый, мемкеш) - кеш на уровне контроллеров (особо тяжелые куски) - кеш модуля - кеш всей страницы

Да чего мелочиться - давайте кешировать готовые страницы. :-) Это кусок из модифицированного мной кеша, там все раскладывается по папочкам, и совершенно не напрягает. К тому же все единообразно: на входе метода модели проверили кеш, далее запросили, на выходе сохранили.

По такой же методике. Скорее всего, текст стоит в каком-то span, div, p, td , у которых есть свой идентификатор класса. Его и прячете. Если ничего подходящего не находится, оборачиваете текст в свой собственный span и прячете.

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