ИМ с большим кол-во товаров

Мой не делает.

Я вас успокою, если скажу, что имел дело с чужими SQL запросами в десятки килобайт длиной :) ?

Речь про ТЕКСТЫ запросов

Ну там

SELECT
  SELECT JOIN JOIN JOIN
     SELECT
        SELECT JOIN GROUP SORT

итд, итп. И так десятки килобайт текста, скажем 40кб... без пробелов.

Везде найдутся свои "шпешиалисты".

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

Собственно легко заполнить базу у "кандидатов" и отпрофилировать "насколько тормознее стало", дело 1-2 дней.

Для ТС-а это не срок, если он реально планирует сотнями тысяч товаров торговать.

Но вангую, что это очередной магазин-дор.

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

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

Движок не пишу дабы не сочли рекламой. Товаров 15000, посетителей в сутки 1500 - 2000, хватает 100 рублевого хостинга.

В любом случае, лучше сперва проверить движок каким-нибудь симулятором, типа Microsoft Web Application Stress.

Современные СУБД (системы управления базами данных, которые используются CMS и пр.) легко и непринужденно манипулируют и миллионами записей на 100 рублевых хостингах.

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

А обычная выдача для посетителей сайта не должна никаких проблем давать что на 1000, что на 100 000 товарах...

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

наверное битрикс будет лучшим вариантом.

Версия то какая Опенкарта? И что значит не держит? Смотрел и сайты на 1,5 версии с 150 000 товаров и сейчас на поддержки сайта с Опенкарт 2,3 там более 100 000 товаров и всё нормально.

Может быть вы просто не понимаете, что происходит? Или модулей наставили и теперь всё тормозит.

LEOnidUKG, полностью согласен, есть 2 клиентских магазина, так еще на 1.5.3 работают, в свое время самая стабильная версия была, я их и запускал. На каждом по 130-150 К товаров, даже скажу какой - рыболовный, и никаких проблем нет. Владельцы даже и не думают переходить на что-то сверх-модное. Ну а если уже на битриксе делать, то сразу надо на VDS ставить, шаред не потянет.

я.. я.. додумался.. в 2002м году, когда писал свой первый скрипт.

---------- Добавлено 05.09.2018 в 13:33 ----------

В данном случае лучшим вариантом будет самопись

У нас есть клиент, в ИМ больше 100 000 позиций. Сайт на IIS и MS SQL - проблем никаких. В первую очередь потому, что нет проблем с БД.

Да, магазину уже около 10 лет.