Search the Community

Регулярно я вижу это сообщение. "настройте мне сервер, чтобы у меня работали 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 рублей!

Доброго времени суток! Производился переезд с шаред хостинга на VPS. Сайт www.avtotool.com.ua Версия: Opencart 2.0.3.1 rs Стартовый бюджет: от $50 (или ваш разумный аргументированный вариант бюджета в дальнейшем при проведении работ) Условия оплаты: 50%/50% (до/после) Желательно из Украины, наличие связи по скайпу, опыт работы в настройке и грамотность. Возникшие вопросы с ошибками: 1) Посмотреть правильность настроек сервера VPS и произвести грамотную и правильную настройку. 2) Настройка пользователя и групп, а именно запуск APACHE сервера из под пользователя (при нынешней ситуации сайт работает только из под апач пользователя, то есть на все файлы необходимо ставить пользователя апач и его права, что не есть корректно и правильно, и очень осложняет работу сайту и его управление, возникают конфликты с модулями.) 3) Периодически сервер падает с ошибкой: Warning: mysql_connect(): Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2) in /var/www/avtotool/data/www/avtotool.com.ua/system/library/db/mysql.php on line 7 Notice: Error: Could not make a database link using avtoto00_oc2@localhost in /var/www/avtotool/data/www/avtotool.com.ua/system/library/db/mysql.php on line 8 4) Просмотреть и оптимизировать базу MySQL (добавить индексы и тд. если необходимо). 5) Корректная настройка по заданным критериям .htaccess и robots.txt 6) Просмотреть существующее ошибки и устранить их. - возможность редактирование заказов (сейчас ошибка); - убрать проверку полей на заполненность при редактирование заказа; - убрать конфликтность модулей если они есть; 7) Возможно дадите рекомендации что еще нужно сделать по сайту чтоб он нормально и быстро работал, и проделать такие работы. В общем необходимо правильно и грамотно настроить сайт, так как вы бы это сделали для себя. Жду Ваших предложений здесь в теме или в лс.

Как известно установить магазин (или сделать его перенос) можно несколькими способами (правильными и не очень). И потратить на это можно также разное количество времени. Заказчик обычно оценивает результат чисто визуально, по принципу работает/ не работает. Объяснить разницу в качестве бывает практически невозможно, т. к. обычно идет реакция "вы пытаетесь набить цену". Я всегда соблюдаю правило выставления нужных прав (вроде 777) только нужным папкам при установке/переносе. Если приходится переносить несколько сайтов, то это довольно рутинная и не очень быстрая работа. Приходится проверять и перепроверять: а все ли права выставил правильно. Но тут столкнулся с другим подходом к такой работе некоторых мастеров: они просто напросто выставляют всем папкам права 777. Быстро, но неправильно с точки зрения безопасности. Но заказчик ведь не ведает об этом. Заказчик рад, что ему сделали дешевле чем, например, просил я. Визуально все работает (до поры до времени). 2-й момент. В зависимости от того каким образом работает php на сервере (как модуль Апаче или fast CGI) я делаю настройку для php. Профессионалы знают, что, например, если php работает как модуль, то нужно прописывать настройки в таком случае в .htaccess. Но некоторые мастера вообще либо не знают, что нужно прописывать настройки php, либо просто плюют на это. И вижу очень часто, что php работает на сервере заказчика как модуль Апаче, но в корне магазина болтается файл php.ini и присутствует дистрибутивный файл .htaccess, что в корне не верно, т. к. нужные для магазина настройки не прописаны. Заказчик опять же доволен. До поры до времени? Вот и пытаюсь я понять, это нормальное явление или халтура? Т. е. когда исполнитель плюет на безопасность магазина и ставит абсолютно везде 777, когда не настраивается php для магазина? Я уж молчу про более грубые нарушения и бреши в безопасности (мог бы долго перечислять на конкретных примерах). Это нормально, господа? Мне, например, некоторые заказчики ставят в вину, что я "пишу много непонятного текста", а ему (заказчику) обещали сделать (перенос/установку) намного дешевле чем я. Т. е. в глазах заказчика халтурщик выглядит как "хороший специалист", а я вроде бы только "хотел развести его на бабки". Хотя дороже $100 я никогда не предлагал и не делал установку/перенос магазина даже с тысячами (десятками тысяч) товаров, гигабайтами картинок (без кеша), и базой на десятки или сотни две мегабайт. Халтурщик в выигрыше, ведь заказчику сразу то "разницы не видно, тогда зачем платить больше". А про низкую безопасность магазина такой мастер заказчику не скажет, и даже не по злому умыслу, он просто про нее вероятно не знает. Может быть и вправду можно делать халтурно работу? Ведь заказчик ее принимает и потом рассказывает как ему ее замечательно сделали.