snastik

Ну у вас нормальное решение. Модуль продается - как есть. Саппорта нет и не будет!

Уже писал ранее - не надо никакого редиректа. Делаете верхнюю категорию с названием КАТАЛОГ ТОВАРОВ. Делаете ей урл catalog и получаете удовольствие. Think Different IBM !!!

Сделать категорию верхнего уровня с сео урлом catalog и в нее впихнуть все остальные.

Господа, отставить панику на корабле. Как говорил господин Мавроди - всем все платится. И таки да. Иногда у людей бывает отпуск. И интернет есть не во всех уголках нашей планеты.

Т.е. по вашему не хамство переходить на ты. И в формате эй ты иди сюда общаться с малознакомым человеком.

Хостинг Любой. Не панацея. Не хамите. Оптимизация опенкарт это искусство.

Готов рассмотреть ваше предложение. От 150 000 рублей в месяц. После предоплаты 50% готов выслушать детали.

Вот никогда не понимал, зачем вы даете такие комментарии, зная ответ на вопрос заранее? Т.е. просто сделат в тему ква и подколоть Марка вам не сложно, а ответить сразу на вопрос - почему то тяжело? К чему это ? У вас личное что-то ?

У вас такие смешные вопросы... А зачем что-то в принципе делать ? А ничего что, по идее 2.3 == 3.0, и те кто по быстрому подсуетился, сделали задел на будущее и сэкономили время... Ну и давайте на забывать, что хорошо что после 2.3 дошло что это major release, а не после 2.7

А вы всегда по воскресеньям не отходите от компьютера ?

Да

Нет

Я же вам писал в личку как быть дальше. Что касается запрета на индексацию - это самое ужасное что вы могли сделать!

Не важно Y|| или Opencart. Все равно привет flat-таблицы hash-индексами. Привет шардинг. Ну и если есть безграничный бюджет-то еще можно кластер slave-mysql серверов поставить с 512 гб памяти, и перенести всю обработку-хранение данных в память. Т.е. надо понимать, что производительность розетки обеспечивается не системой, на которой она развернута. А архитектурой комплекса. А в каких типах хранилищ крутить данные. И как их обрабатывать - это уже технические детали. Но это в случае разработки с 0. Если же допустим станет задача доводить Opencart до каких то диких показателей pageview. То тут очень долго можно обходится горизонтальным масштабированием. Самое главное укротить процессы регулярного обновления таблиц товаров. Если интересно, кстати могу в личку показать 500 000, или уже наверное 700к товаров, с временем ответа практически любой страницы до 300мс. Сразу говорю, что и как сделано - тайна за семью печатями.

Но на самом деле у всех этих методов - есть большая обратная сторона. Называется - денормализация. Автоматически все фильтры, поиск и любой постраничный вывод товаров. Который может быть необходим, нужно дорабатывать. При чем дорабатывать крепко. Часть фукнционала - без вопросов. Часть закодировано. А так как сервер который может держать 50 000-100 000 уников в день на магазине в 20-30к товаров стоит на сегодня всего $60 в месяц. Экономическая целесообразность танцев с бубном, нивелируется низкой стоимостью вычислительных ресурсов. Возможно через год-два. И будет какая то эконономия. Но все таки чем меньше критичных изменений в дефолтном коде - тем проще всем жить.

1. Запускаем паука, который планомерно укладывает в кеш страницы категорий/товаров, сохраняя их как plain/html (скорость отдачи таких страниц даж не 200мс, а десятитысячные доли секунды) 2. Вам же необходимо было посчитать тотал в категориях - вот берем и считаем. Или по крону. Или при первом обращении к странице с укладкой потом значения в таблицу и дальнейших манипуляций с этой таблицей, когда добавляете-удаляете-переносите товар. 3. https://habrahabr.ru/post/44608/ 4. http://www.opencart.com/index.php?route=extension/extension/info&extension_id=18266

1.5.5.1 - да. CDN для картинок и php-fm - это сектанты с fl.ru такие оптимизации предлагают. Актуально только для 500к+ pageview, когда сервер не справляется с отдачей статичного контента (не забываем что до этого мы переводим практически все страницы в статичный html). Т.е. нужн понимать, что apache 2, не сильно немощней nginx, и статики он может вылить в мир ровно столько, сколько может позволить это исходящий канал (берем в расчет, что сервер у нас не шаред )))). А вот если говорить о 100к товаров.. на категорию - то тут есть несколько вариантов. Либо делать отельную count табилцу и обновлять ее при изменении товара. И пагинацию переводить на wildcard как в Гугле. Либо использовать индексирующую прокладку в виде sphinx. Да да его можно не только для поиска использовать!

Поставьте ocstore 1.5.5.1 (с модификациями уважаемого Toporchillo) и чистый OPencart 1.5.5.1 налейте тестовую базу в пару тыщ товаров в одну категорию и увидите результат... Где то процентов 80 сокращения ttfb. Хотя на 100 000 товаров в одной категории. Ни индексы. Ни FOUND_ROWS не помогут )

Да может все и так. А может и нет. Ну никто вам не скажет ничего конкретного без детального анализа магазина. Кода. Базы данных. Логов посещений. Поиска эксплойтов и шеллов. Про роботс я написал - как одну из 100 возможных причин. Я не шучу.... Причин с тормозами может быть пару сотен легко.

mobiledetect - это для клинических случаев тип Journal. В 99% достаточно mediaquery и bootstrap-событий. Но если совсем уж хочется красиво - то jqeury в зубы, определяем ширину экрана и вперед. Нет же... Нам надо дубли дубли дубли дубли....

Это тема для холивара! База может не тормозить. Но берем магазин. 200 категорий... Берем пусть не четыре - пусть три дерева категорий (меню, витрина, подсказки в поиске), даже без подсчетов товаров. Клинические случаи, когда еще лупят в левый блок модуль категорий и в display:none, еще одно дерево для мобильного меню - не рассматриваем. Берем станадартный пусть получаем 600 лишних запросов. Для которых надо создать сокет. Отправить запрос в базу. Принять, обработать. Преобразовать из класса mysqli в массив в классе db. Получить для каждой сущности, даже пусть из кешированного набора алиасов сео ссылку. И так каждый раз для загрузки главной страницы. Совершенно дурное количество итераций. А база - да. Она такая. Она стерпит. Но есть обратная сторона медали... Есть 10 000 товаров. Есть набор данных с алиасами в сео про. Каждый раз. Вместо того чтобы выполнить при правильной архитектуре 100-200 моментальных запросов в базу для получения алиасов, идет обращение к массиву в 20 000 записей (в кеше сео-про есть как прямые так и обратные связи). И вот тут кеш категорически противопоказан. В каких то системах это наступает на 10 000 товаров, в каких то на 50 000. Но СимаЛенд тот же поднять с родным сео про - просто невозможно!

Сессия - по сути временный набор данных, которые можно хранить в виде файлов, в базе, или в каком либо индексируемом ram-контейнере, типа memecahe. Если у нас время жизни сессии час-два. И трафика не много. Тип хранилища - не принципиален. А если 20 000... Задержку работы файловой системы, даже на SSD никто не отменял. Подобный эффект бывает на магазинах с нечищенным кешем за полгода. Когда вроде бы все ок, а тормозит.

Есть опыт общения с шаблнопописателями. 90% кода шаблонов - это копипаст с буржуев. На комментарии из серии, "господа, у вас на главной дерево категорий построилось 4 раза, может вы это как то закешируете, или пихнете в глобальный класс", ответ - а зачем... Или... Сделайте глобальный супермассив с хитами продаж и дергайте из него стикеры, а не перебирайте базу по 50 раз, при генерации каждого товара. - Я самый умный. Что ты мне рассказываешь... Это не самые "неумелые" люди.

php 5.4 - как раз и нужно из-за изменения библиотеки работы с сессиями. Но гибкие сессии - это хорошо! А на больших проектах подвесить их в базу, просто счастье. Если у нас допустим время жизни - неделя. и за эту неделю пришло 20-30 уникальных хостов. По базе оно будет шуршать намного быстрее чем по файловой системе.

Марк, не обращай внимание на обелившегося админа варез-ресурса. Все посты персонажа - попытка набить репу. Не более.