Можно, за копеечку поделюсь скриптом
суммарная нагрузка не должна меняться от розрозненности или универсальности в данном контексте, т.к. все сайты будут абсолютно идентичны :)
Задача - сделать универсальный движ для 10 интернет-магазинов, и так как это реализация скорей для набить руку и повысить свой уровень, меня интересует вопрос нагрузки. По поводу файлового кеша я и думал как то так организовать, но нужно более детально продумывать, т.к. подобных моментов и узких мест будет множество.
задача как раз таки одна, так интереснее :)
С подпиской палка долбит в IPN до тех пор, пока запрос не отработается. После того как подписка истекает вы автоматически отписуетесь от услуг.
Вам в раздел работа для вебмастера, здесь советы онли
предложите вариант с мультиязычностью для всего. начиная от названий категорий заканчивая названиями различных типов и видов сортировок по определнному параметру для категории. В итоге имеем только для товаров 12-15-20 таблиц с инфой по каждой характеристике и каждому языку.
Используются не значит лучший вариант, это впринципе самый простой вариант организации полноценной мультиязычности. Но. Без нормального кеширования при 100к+ запросов в день под такую базу прийдется выделять очень нехилые ресурсы, что не есть оптимально
и в чем может быть кривизна рук, если у мемкеша аж 4 команды и десяток параметров настройки. Да и 2-4 гига под _только мемкеш_ это ресурсоемко, не кажется
давайте представим что на 1 базе крутится десяток проектов средней популярности\тематики, думаете не набереться и больше? :)
php preg_replace
mysql UPDATE
Продолжайте, я для этого и создавал топик :)
меня интересуют хай лоады впринципе, опенкарт лиш указан для примера
Как будет происходить инвалидация кеша запроса?
меня интересует сам принцип, хотя идея ниже
$cache_key = "catalog_{$sort}_{$desc}_{$filter}_{$page}";
крутилась в голове, но из неё появляется следующий вопрос - а если добавился новый товар в середину списка с ценами? делать инвалидацию всей категории во всех вхождениях кеша?
это пока теория, хочется не наступать на грабли в будущем
При джоине создается виртуальная таблица куда помещаются выбранные данные, хоть это и временно, это несет неудобства в плане потребления ОЗУ. В моем проекте на одной базе будет крутиться десяток проектов, использование множественных LEFT JOIN мне кажется нецелесообразным, т.к. сервер быстро завернется.
Спасибо за направление, буду самообразовываться
все с ним хорошо, но при нехватке памяти вытесняются старые данные, соответственно в определенный момент он просто потеряет смысл, т.к. инфа там будет храниться не более n времени
тоже спасибо, будет время обязательно почитаю, направление интересное
Статические страницы создаются в компоненте статические страницы, создание категорий там невозможно. Если нужен полноценный модуль новостей - ищите дополнение. Меню по-моему составляется автоматически из категорий магазина.
lang->modules->название модуля либо в корневом файле языков
а в чем трабл использовать json при больших обьемах данных?
