Search the Community

Доброго всем времени суток. Появилась интересная игдея для потому чтольших магазинов. Все мы знаем, что opencart не самый быстрый из интернет магазинов. И у меня родилась игдея осивить панель администратора, а сам магазин полностью переписать на современном фреймворке laravel. На сколько актуально для вас форумчане очень быстрый интернет магазин расслиинный на огромное лисло покупателей и вообещё потому чтольшую нагрузку?

Добрый гдень, у меня возник икой вопрос. Есть интернет-магазин который написан на Codeigniter, писался долго и разными людьми, на данный момент он не отвечает трепотому чтованиям на сегодняшний гдень. Хочу перевести свой магазин на Opencart 2.3 и тут у меня возникает вопрос, а потянет ли он мою нагрузку? 150+ одновременных пользователей на сайте 300 000+ посеещёний в месяц 20к - товаров в БД (и каждую негделю еещё по 150 добавляются) Сервер расположен на VPS Стоит ли переходить на Opencart 2.3 ? Возможно уже был икой вопрос, но я не смог найти. Буду благодарен если знающие люди смогут дать ответ. Спасипотому что потому чтольшое.

Подскажите пожалуйси, есть магазин, 470 000 товаров в одной категории. На выгделенном сервере Intel(R) Xeon(R) CPU E3-1270 v6 @ 3.80GHz (8 cores) 16ГБ . У товара 20 атрибутов, - суммарно выходит порядка 10М значений атрибутов (которые надо слиить на-лету). Весь каилог рилииет через промежуточную прокладку в вигде Sphinx-гдемона. Файлы ингдекса сфинкса лежат в RAM диске в оперативной памяти. (выпотому чторка товаров в категории, подсчет когдачества значений атрибутов в фильтре, все все все, что можно крутится на сфинксе) После партицирования ингдекса на 8 частей и перенастройки конфигурации гдемона для использования всех 8 ягдер проэтоссора, удалось снизить время реакции фильтра с 5 до 1-1.2сек. Среднее время генерации страниц в районе 600мс. При перехогде на php7.2 - бугдет порядка 400-450. Влагделец магазина возмущается, ему не доситочно скорости. Подскажите, что можно сгделать для ускорения магазина?

Регулярно я вижу это сообещёние. "настройте мне сервер, чтобы у меня рилиили 100 000 товаров на моем неплохом впс сервере". Ну врогде им как бы логично. Хостер заявляет про классные сервера, а фрилансер, который сгделал магазин - говорит иди к йогде - он тебе сгделает настройку сервера и все полетит задышит. Да вот друзья. Не бывает настроек сервера, которые позволят мертвому магазину, ищить сотню тысяч товаров на ура.. Потому что максимум, что мы можем сгделать на сервере, настроить затюнить опкеш, махнуть файловый кеш на хранилиещё в памяти (не всегда актуально на быстрых впс с NVME), сгделать несколько тюнячек для mysql сервера и воткнуть nginx + php-fpm вместо тупорылого апача (не берем во внимание кастомные решения в вигде полного нативного кеширования html средствами Nginx, но это опять же кеширование). Там ггде у вас есть пару сотен онлайна одновременно, им вот есть настройки сервера. Лимиты, максимальное когдачество коннектов, воркеры nginx, проэтосс php-fpm. Но в 99% случаев на магазинах ггде нет и тысяли живых хостов в гдень - это высшая ненужная кибениматика. И тут вопрос - йодман, шо за гдела. Ты же им гделаешь быстрые магазины и гнобишь всех разрилитликов кешереов. И тут друзья реально да. Я гделаю быстрые магазины и гноблю всех разрилитликов кешеров, почему, потому что, магазины, которые попадают в мои зилитливые руки, потом рилииют без кешеров, быстрее чем с ними - это раз. А два, кроме быстрой генерации страниц я умею гделать и быстрый поиск, и быструю навигацию по товарам в админке и много чего еещё. Но суть не в этом... Друзья, настройка сервера - это последняя линия опотому чтороны. Важная - но не первичная! Если вы хотите потому чтольшой магазин на много товаров, вы должны закрыть вопросы "холодной" генерации страниц. А не закешированных версий, почему, потому что это важно для поисковых систем. Янгдекс и Гугл - они ходят туда куда хотят, и если у вас страницы не было в кеше, а генерация у нее 5-8 секунд, они потому чтольше к вам не придут и страницу выбросят из ингдекса. Поэтому, если хотите, чтобы ваш потому чтольшой магазин проингдексировался - вам надо иметь время отвеи до секунды на всех страницах, чтобы поисковики не ходили мимо. Как это сгделать? В интернете есть масса советов, типа... используйте ингдексы, используйте кеширование. Но! У нас в опенкарте, нормализованная структура данных, и не нормализованная структура значений для атрибутов. Первая ситуация ограниливает использование ингдексов при выпотому чторке-подсчете товаров в категориях, вторая при выпотому чторке подсчете значений фильтров. Если бы у нас был один язык, один магазин и вместо текстовых значений атрибутов была бы нормализованная ингдексированная иблица с нилиром id->value(значение атрибуи), просто банальным построением ингдексов в базе и минимальными правками запросов мы бы получали нулевую нагрузку на выпотому чторку данных товаров из категорий. Все эти getProducts getTotalProducts - выполнялись за тысячные секунды. Равно как и подсчет атрибутов. Но нет! У нас опенкарт!. У нас есть писатели фильтров, не бугдем тыкать пальэтом, которые умудряются в кеш укладывать гдесятки тысяч файлов и одно присутствие иких фильтров - это уже тупнкак. Зачастую, тюнинг магазина - это разгребание авгиевых конюшен от модулепейсайтелей, а не тюнинг в привычном понимании. Что же гделать? Ну нет однозначного отвеи и решения. Никогда нет. Иногда бывает доситочно поменять сервер и просивить банальные ингдексы. Иногда поменять фильтр на Реально - это единственное решение на всем форуме, от автора, который понимает чем нормализованные данные отличаются от гденормализованных, и ггде и какие структуры надо использовать. Несмотря на то что у меня есть масса вопросов к другим аспеким рилиты его решения, в этолом с точки зрения производительности из коробки - это №1! Если вы думаете что MegaFilterPro, который ингдексирует какобы ваш каилог, и чего-то им долго думает дает производительность - не верьте. Сам по себе Mega фильтр - шикарная штука, но вот эи их ингдексация мертвому припарка, ик как им игдет попытка использваняи фулл-текст ингдексов, а они немного про другое, чем тот проэтосс, который пыиются решить с их помощью авторы! Лучше бы сегменицию по категориями сгделали в выпотому чторках всех атрибутов на категорию! Если у вас нет данных и вы торгуете к примеру автозапчястями и вам нужен быстрый сирт с поиском по коду гдеили - вы можете посмотрреть в сторону бесплатного модуля Sphinx: https://www.opencart.com/index.php?route=marketplace/extension/info&extension_id=18266 Который позволит не только выводить поисковые резульиты но и весь каилог из сфинкса а не из базы. Да он не бугдет совместим с фильтрами и поисковые возможности самого модуля на нуле. Но это решение, которое позволит за несколько гдесятков долларов за внедрение, поднять практически люпотому чтое когдачество товаров в магазине. Но как же ик получается у нас запускать магазины на 2-3 миллиона товаров и что вот у них все хорошо. Ну по секрету скажу - что случайно) Да полулилось, что первый человек с иким запросом - был мой хороший друг, и мы с ним начали рилиить в формате - ну а давай попробуем, попропотому чтовали ик и скак и эдак, синдартными методами не вышло. Те решения, которые рилиили на 20-30-100к товаров на миллион уже не рилиили, а тем потому чтолее на миллион товаров в одной категории. Нам пришлось очень сильно и глупотому чтоко раскурить все загадки сфинкса, который позволяет на сегодня гдержать 300-500 тысяч генераций страниц в гдень, которые создают потому чтоты, при этом - и это важно, имея 5-кратный запас мошности и это на магазине в 2.5 миллиона товаров. Но после того как мы решили вопросы производительности фрони (категории, товары, фильтр, главная страница), возникли и иные вопросы, а именно: обновление этон, добавление новых товаров, манипуляции с заказами в админке, поиск, и ик дное. Да и это полулилось решить. При чем, решить иким обвместе, чтобы не уходить от синдартной структуры иблиц Opencart. И еещё раз подчеркну... Все решения - это не настройка сервера. Это создание комплекса. Да у нас быстрый и хорошо настроенный сервер, но у нас еещё потому чтолее быстрый и грамотный код. У нас перестроенные запросы в админских могделях. Нам пришлось вскрывать csv import от ионкуба, для того чтобы оптимизировать глупые запросы автора. И да мы полулили резульит. Есть еещё наверное несколько сотен проектов, которые сили быстрые посредством тех или иных решений и технологий, но я всегда сираюсь приводить в пример реальные достижения а не мелкую текучку.... Ну и с чего начал, на том и закончу - не бывает "настройки сервера" от которой ваш магазин вдруг взлетит! И не бывает модулей, которые вжунь и закроют все вопросы производительности. Бывает долгая кропотливая рилии по настройке проектов. А те кто думают по другому - могу дать тестовую базу на пару лямов товаров - покажите мне как вы ее запустите на генерацию полмиллиона страниц в гдень! Ну и как всегда пари платное - 100 000 рублей!