Yoda

Я вам еще не грубил. Ведете вы себя все равно как ****.... И отзывы про вас не очень. Я не знаю ни суммы, ни ситуации. Я знаю одно - вы лично мне и @Tom обещали закрыть вопрос. Прошло 4 месяца, вы придумали какие то левые причины чтобы его не закрывать.

Какой хозяин сайта? Бабушку подключите еще свою. Разговор был конкретно с вами. Мне, @WarStyle и @Tom вы говорили абсолютно простой факт, все плохо, скоро вопрос закрою. А теперь вы начинаете юлить-мулить. Договор насколько я понимаю был с вами конкретно! Хотя судя по отзывам про ваш бизнес - это все почему-то неудивительно! Реально вам пошли на встречу и вошли в ситуацию. А вы себя повели как последнее ****, ну вы поняли!

Сдается мне вы совершенно другое говорили и клялись и божились что рассчитаетесь! Вам ваши цитаты привести? А теперь по классике - выдумали какие-то фантазии? и @Tom вы тоже в уши налили сказки?

Ну я думаю у меня будет не пустой камент! Но в наших селениях, неграмотных студентов забирают с четвертого курса на косарь! Забирают всех, кто знает как зайти на фтп! HRы пасутся в пяти местных институтах и пасут студентов с первого курса. Я тут недавно учился на заочке. Так вот на дневном факультете по моей специальности на втором семестре третьего курса никого нету!

Любая репликация из двух узлов - по умолчанию ненадежна и подвержена коллизиям. Для стабильной работы необходима система хотя бы 1M + 2S + Advisor. Теоретически, возможно частично вы снимите ваши проблемы. Но получите на выходе еще больше проблем чем у вас сейчас связанных с мониторингом, стабильностью, рассинхронами этого огорода.

Здесь плачет

А самый большой фейспалм этого всего в том, что у него не хватает мозгов сделать lang-детектор по урлу и инициализировать url-класс до lang. Так как в том виде как сейчас, возможности с первого раза без лишнего редиректа определить локаль, кроме как повторной инициализации lang-класса, без больших структурных изменений, я не вижу.

Долго я туда смотрел, так и не понял зачем и зачем. Будем надеятся что хватит ума откатить.

innodb + innodb_flush_log_at_trx_commit = 2 + глубокая оптимизация базы + нормальная разгрузка системы + полное отключение кеширования в mysql сервере и никакой репликации. Это самый примитивный и простой механизм. Если вы будете городить репликацию на неоптимизированной системе для таких задач. То все ляжет еще больше, не забывайте что синхронизация - это тоже ресурсоемкая задача. Необходимо проверить и минимизировать количество индексов на таблицах, их формирование и перестроение - та еще задача. Также не забывайте, про кеши. Про тот же кеш сео про, который обновляется нон стоп каждый раз при добавлении каждого товара, перегенерация которого тоже отжирает много ресурсов. И здесь нужно еще копать в сторону отключения в нем кеширования. Т.е. просто поверьте - у вас проблема не в базе а в глобальной настройке системы, что в 90% случаев можно решить "неинвазивными методами". Что касается нетривиального решения этой задачи, если бы я ее решал для себя я бы сделал совершенно по другому. Я бы сделал клон базы, исключительно с таблицами товаров, парсил бы товары в клон. И примитивным крон-скриптом раз в час синхронизировал сводными запросами напрямую из базы в базу актуализированные товары. Как то по принципу. Отключили front на 10 секунд. Или не отключили, а поставили на паузу, или отдаете готовый html-кеш, а по результатам апдейта сбрасываете. А потом как то INSERT IGNORE INTO front_base.oc_product SELECT * FROM parse_base.oc_product, либо еще быстрее через TRUNCATE parse_base.oc_product, INSERT ... SELECT * FROM.... Если вам не требуются какие то супер-реал-тайм апдейты цен-наличия с поставщика, то в любом случае кумулятивное обновление всего набора данных с каким то временным интервалом - будет эффективнее чем атомарные апдейты.

я сталкивался не раз и не два и не десять и с тем и с тем фильтром. В плане СЕО - ocfilter реализует на сегодня самый правильный механизм формирования посадочных. Кроме этого не забывайте есть еще такие факторы как: Скорость работы. Последняя версия OCFilter - это самолет по сравнению с этим дрым брым. Саппорт Госоподину @SooR можно в три часа ночи отправить фтп клиента и в ответ прочитать через 15 минут, если он онлайн - "все готово, все в порядке". У авторов дрым фильтра, очень большая занятость и скажем мягко местами неэтичная манера выражаться в отношении клиентов. Заявленные функции Все что есть в OCFilter - в нем действительно есть. DreamFilter - обещают быструю бесплатную тех поддержку ее нет! Также заявлена быстрая скорость работы - она достигается за счет кешей, а никак не за счет технологичной архитектуры, которая есть у @SooR. Запросы вида SELECT ...... FROM product .... LIKE('%КРАСНЫЙ%') - это фейспалм, на фоне заявленных суперспособностей. Для тех кто не понимает глубого специфики mysql - такая конструкция в принципе не может быстро работать. Простота интеграции. Опять же @SooR не закрывает код и у него очень понятный механизм интеграции в систему, чем не может похвастаться DRF, так как его автор решил, что после него хоть потом и забрал на свои закодированные модели целиком генерацию товаров и переопределил механизм формирования ссылок пагинации. Опять же это дичайший феспалм. Суть авторов: Просто почитайте как авторы описывают свой дрим фильтр 1000 вариантов фильтрациии, 10000 атрибутики, 150 стилей... Ну чистый тетрис из 90х 10000 в 1. Разводят нашего брата как последнего лоха. Так что выводы делайте сами. P.S - мега таки самый крутой. Но и он не без греха.

Да нормальная тема. Только у нее другой заголовок должен быть. Предохраняйтесь - береженого бог бережет! Проверять лишний хлам в корне, изменения в robots.txt, удалять лишних ftp-пользователей, пользователей в вебмастере, системно менять пароли - никогда не вредно но и полезно.

Статья от КЭПа, при чем от глупого кепа. Просто доступа в вебмастер недостаточно - необходимо еще принудительное указание основного зеркала в robots.txt - а это, без доступа к фтп, сделать невозможно. А если есть доступ к фтп. То у вас не то что трафик поисковый можно угнать, но и упущенные зря годы.

Тут у меня вопрос - зачем и еще раз зачем? Что касается настройки репликации - вы это делаете из примера с ruhihgload. И это большая глупость. Если уж очень сильно хочется. То настройте репликацию баз. Поставьте HaProxy как балансировщик и будет вам счастье. Если не хочется заморачиваться с HaProxy, механизм репликации и балансировки есть их коробки в php http://php.net/manual/ru/book.mysqlnd-ms.php А если хотите совсем заморочится - попробуйте galera cluster и maxscale. Но все эти механизмы актуальны только для большой, оооочень большой нагрузки. Так например opencartforum, на котором вы это читаете в секунду обрабатывает десятки тысяч запросов, а пиковая мощность системы сотня-полторы тысяч запросов mysql в секунду. Я таких магазинов не видел. Даже магазины с трафиком 25-30 000 посетителей в день генерируют на порядок меньше. Если вы таким образом пытаетесь поднять производительность магазина - то сначала надо привести в порядок сами запросы и их количество. А репликация и шардинг - это механизмы горизонтального масштабирования, которые приходят на помощь в случае, если вертикальное масштабирование упирается в предел мощности одного сервера.

Халфнопе, ты в своем уме? Ты видел код этого персонажа? Это же застрелись врагу не пожелаешь! Я бы под таким не подписывался!

Мне часто снится сон... Я вижу сеошницу, которая работала на газпром. Я в этом сне владелец илитного крематория. Мои верные Вася и Миха трупосжигатели, тащят ее связанную в печку и она орет благим матом.... Я ПРИЗНАЮ ЧТО Я РАЗВОДИЛА КЛИЕНТОВ НА БАБКИ ЗА ВОЗДУХ! ПРОСТИТЕ МЕНЯ! Я ОТДАМ ЛЕВУЮ ПОЧКУ, ЧТОБЫ ВОЗМЕСТИТЬ УБЫТКИ! И медленно михаил большой кочергой бьет ее по лицу. А Василий, привычно схватив крепко связанные ноги, кидает жирное тело в топку... ЗАНАВЕС!

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

Работают. Просто в лексиконе необходимо иметь достаточно количество синонимов понятий "тупые обезьяны", "криворукие демоны", и "хватит мне жевать мозг гнилыми зубами, дайте сюда быстро старшего администратора смены". Ну и потом внятно и доходчиво в красках объяснить супервайзеру суть проблемы. Также саппорт почти всех хостеров становится ласковым и пушистым при одном упоминании про потенциальную вероятность получить гневный отзыв на 101host.

По непроверенной информации он стал жертвой афроамериканцев с нетрадиционной ориентацией низкой социальной ответственности.

Это практически невозможно, так как пароли в явном виде не хранятся - только лишь менять алгоритм фомирования хешей/авторизации opencart на логику из drupal

Смысл есть. Предположим у вас 3000 человек в день посетителей. И сократив время загрузки еще на 20% вы получите 3% роста доходов. На самом деле цифры чуть больше чем 3%. И это деньги из воздуха.

Если доход от магазина не позволяет тратить даже 1000 рублей на хостинг стоит закрыться и поискать себя в других сферах! Как бы это не цинично звучало - это факт!

Что касается pageSpeed - то здесь вы и правы и не правы. На позиции в чистом виде - да, действительно нет никакой линейной зависимости от показателей. А вот на конверсию и поведение покупателей, особенно в регионах с плохим интернетом - влияние может быть коллосальное. Я очень много видел магазинов с картинками в меню весом в 20 мегабайт на каждую страницу. овер 1.5-2 секунды ttfb - уже начинает раздражать пользователей. Да и сам по себе гугл приходит чаще и лучше на быстрый магазин. В целом в конченом итоге это отражается на позициях ранжирования но косвенно, а в первую очередь после нормальной настройки магазина появляется прирост глубины просмотров, увеличивается конверсия и снижается показатель отказов.

Не разводи панику. Только для мобильных устройств, и только для ну очень медленных проектов. Основная часть выдачи не будет затронута, и влияние скорости будет минимальным. Почитай первоисточник.

Хостинг получше - не спасает! Приведу несколько примеров. Масса разработчиков используют запросы вида SELECT * .... даже не понимая, что делая запрос с описанными полями выборки, а потом 10 атомарных запросов для получения общих данных конструкция будет работать на несколько порядков быстрее. Есть разработчики, которые вешают поверх систему массу своего "хлама" который хочешь не хочешь выполняется на каждой странице, там где он в принципе не нужен, переопределяя и перехватывая все функции системы и бьют себя в грудь - что это круто и правильно. Есть разработчики, до которых годами нельзя достучаться с тем что у них косяки на примере с тем же автором мирокдаты, которому мы с марком около года ели мозг чайной ложкой, пока он признал ошибки. 99% авторов не волнует как их поделка будет работать на боевом проекте - у них на тесте заработало, а то что их код потребляет секунду времени - никого не волнует Фильтры используют group by text - text - это текстовое поле, которому нельзя назначить индекс и заведомо это тупая конструкция и это архитектура opencart. Seopro и масса seo модифкаторов, которые формируют наборы ссылок - используют большие коллекции пар ключ->значения, в ситуациях, когда обработка таких коллекций намного больше, чем работа без этого кеша. Корень проблем производительности не в Opencart - а в том что, навыки и понимания большей половины авторов модулей, увы оставляют желать лучшего, и развиваться они никак не хотят. И даже в тех моментах где можно и хотелось бы исправить косяки, код под кубом - и все приплыли. Также 2.x версия тупая наглухо из-за autoload конструкции. А учитывая, что есть любители всунуть в папку system/library какой нить свой кеш, или массивную стороннюю библиотеку - получаем кроме базовых fileseek процессов, еще и сканирование вагона инородных файлов. В итоге старт голого движка уже вываливается в полсекунды. И пока так будет - не будет быстрых магазинов из коробки.

Это же тебе ТС и написал! Не разводи демагогию! Все реализуемо и без проблем! А ты ходи дальше и не моги сложить себе цену! Реально утомляешь!