Yoda

Не пытайтесь - не получится. Я не хочу тыкать пальцем... Но это ДНО! Такая конструкция не оптимизируется, а писал это реально больной человек, я не шучу.

А ниче что ты js-скрипт привел в пример?, к которому psr по моему не имеет никакого отношения.

Да реально студент за косарь - если не верите, приезжайте покажу кафедру, познакомлю с HRами! 100%ответа за базар детектед!

Не сочтите за пиар. Если хватит скилла - то этого достаточно для того чтобы убить 80-90% зловредного трафика. https://ocshop.info/tag/ddos/

И вам не хворать, тамбовский волк вам товарищ! Я могу конечно процитировать меня в ваш адрес. Но здесь не мой бложик, и я не могу во всех красках передать, что я думаю о вас, ваших дополнениях. Да и не стоите вы лишнего внимания. Но могу однозначно сказать в свете данного поста для сообщества. Прикрутить сфинкс - просто, на пустом сервере, в привычном окружении, на голый магазин с дефолтным шаблоном. Но существуют проблемы. 1 - зачастую в наборе репозиториев системы либо отсутсвует либо присутствует старая версия поискового демона. Для того чтобы поставить нормальную стабильную версию необходимо либо собирать его из исходников, либо ковырять систему и добавлять репо, что может закончится падением системы. Так что на 90% это не apt-get install sphinxsearch. 2 - В бесплатном модуле идут откровенно устаревшие библиотеки конфиг. И для того чтобы его заставить заработать из коробки. Опять же приходится применять скилл. 3 - С PHP7 - sphinx-api библиотека наглухо отказывается работать/ 4 - В инструкции к модулю нет и намека, каким образом запускать поисковый демон, и как делать актуализацию. А также нет ни слова о том, почему лучше использовать regular индексы вместо RT. 5 - Также нужно учитывать, что интеграция в сторонние темы и магазины с большим фаршем функционала - это еще та задача. Так как ее необходимо произвести таким образом, чтобы была возможность безболезненного обновления-дополнения всего огорода пользователя. 6 - В зависимости от структуры данных и типа товаров в магазине необходимо создавать совершено разные конфиги, которые. 7 - И самое важное. Дефолтный конфиг практически ничем не отличается от обычного Mysql-поиска, плохо заточен под кириллицу и не в состоянии найти до 90% запросов, которые должен искать нормально настроенный поиск. 8 - В бесплатном модуле есть крайне странный способ исправления ошибок, который не работает на автодополнении. 9 - Многие владельцы магазинов, даже если у них есть свой сервер не являются опытными системными администраторами, поэтому крайне необходимо проводить лик-без по использованию системы и объяснять что делать в случае падения демона, либо каких либо ошибок с его со стороны, либо некорректной работы поиска. А теперь господа у меня вопрос в студию. К тем специалистам, которые обладают скиллом, для того чтобы провести все вышеприведенные манипуляции и настроить бесплатный модуль с корректной выдачей под любую версию php и серверного окружения и всеми остальными описанными плюшками. Сколько это должно стоить?

Я вам еще не грубил. Ведете вы себя все равно как ****.... И отзывы про вас не очень. Я не знаю ни суммы, ни ситуации. Я знаю одно - вы лично мне и @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%. И это деньги из воздуха.