Yoda

Пользователи
  • Публикаций

    1 178
  • Зарегистрирован

  • Посещение

Репутация

475 Очень хороший

7 Подписчиков

Информация о Yoda

  • Звание
    Pro
  • День рождения 31 января

Контакты

  • Сайт
    http://ocshop.info/
  • Skype
    ocshop.support

Информация

  • Пол
    Не определился
  • Интересы
    Тюнинг и оптимизация больших магазинов.
    Долго дорого ... ну дальше вы сами знаете...

Посетители профиля

12 879 просмотров профиля
  1. Не дай бог вас угораздит связаться с этим сатанистом-наркоманом. Аферист и наркоман! Попался мне тут магазин в котором модулей наворованно тысяч на 40 рублей. Телефоны: 79221882616 66880281702 Скайп: remioner https://opencartforum.com/profile/698448-remmik/ https://vk.com/remmik Родина должна знать своих героев. Мало того что модули ворованные все. Плюс магазин сделан через одно место. Плюс майнер на фронтенде. Плюс пропал и бросил заказчика на произвол судьбы. Список модулей чуть позже.
  2. Мы же с вами не знакомы, но думаю на слово, вы просто поверите - я не грубый, я рациональный. На меня в детстве произвела неизгладимое впечатление история из фильма Бронкская история https://www.kinopoisk.ru/film/bronkskaya-istoriya-1993-7466/ В моменте где главный герой(молодой мафиози) за двадцатку долга бегал с пистолетом за жирным упырем, а взрослый мафиозо, положив руку молодому на плечо - сказал "чувак, ты только что за двадцать долларов откупился от огромной кучи вагна в твоей жизни". Очень простая мораль - не надо тратить время на пустоту, упырей и идиотов. Его можно потратить с большей пользой на созерцание мира и осознание того, что трава зеленая.
  3. Я думаю что не дадут вам этого сделать. Вы сами аппелировали к сообщесту. И вы не правы!
  4. Как бы тут ПАШИ не пытались рассказать про нехватку компетенции и еще что либо. Я считаю что 350 баллов репы на форуме с неба не берутся. Я полностью на вашей стороне. И пару раз сам попадал в эту ситуацию, когда заказчик вдруг решает, что ты ему должен решить все его проблемы, которые вылезут в ближайшие 1000 лет, просто потому что до тебя все работало. Ну или, меня не волнует что у тебя жена в роддоме. У МЕНЯ ПОЛОМАЛОСЬ ПОЧИНИ!!!! ПОЧИНИИИИ.... ЧИНИИИИИИИИИИИИИИИИИИ!!!! Мне наверное повезло в жизни, в формате того что, на меня где сядешь там и слезешь - но ситуации бывают разные. ЭТО НАЗЫВАЕТСЯ ФОРСМАЖОР! Если есть возможность откатиться в бекап до работ - откатитесь, распрощайтесь и забудьте. Если будут рога у заказчика. Аппелируйте к тому что, изначально вас не уведомили о полном наборе задач по работе и специфика реализации задачи потребовала намного больше времени и ресурсо-затрат. Поэтому или доплачивайте. Или забирайте бесплатно то что есть и АДДИОС! У всего должна быть мера!
  5. Любая репликация из двух узлов - по умолчанию ненадежна и подвержена коллизиям. Для стабильной работы необходима система хотя бы 1M + 2S + Advisor. Теоретически, возможно частично вы снимите ваши проблемы. Но получите на выходе еще больше проблем чем у вас сейчас связанных с мониторингом, стабильностью, рассинхронами этого огорода.
  6. А самый большой фейспалм этого всего в том, что у него не хватает мозгов сделать lang-детектор по урлу и инициализировать url-класс до lang. Так как в том виде как сейчас, возможности с первого раза без лишнего редиректа определить локаль, кроме как повторной инициализации lang-класса, без больших структурных изменений, я не вижу.
  7. Долго я туда смотрел, так и не понял зачем и зачем. Будем надеятся что хватит ума откатить.
  8. 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.... Если вам не требуются какие то супер-реал-тайм апдейты цен-наличия с поставщика, то в любом случае кумулятивное обновление всего набора данных с каким то временным интервалом - будет эффективнее чем атомарные апдейты.
  9. я сталкивался не раз и не два и не десять и с тем и с тем фильтром. В плане СЕО - ocfilter реализует на сегодня самый правильный механизм формирования посадочных. Кроме этого не забывайте есть еще такие факторы как: Скорость работы. Последняя версия OCFilter - это самолет по сравнению с этим дрым брым. Саппорт Госоподину @SooR можно в три часа ночи отправить фтп клиента и в ответ прочитать через 15 минут, если он онлайн - "все готово, все в порядке". У авторов дрым фильтра, очень большая занятость и скажем мягко местами неэтичная манера выражаться в отношении клиентов. Заявленные функции Все что есть в OCFilter - в нем действительно есть. DreamFilter - обещают быструю бесплатную тех поддержку ее нет! Также заявлена быстрая скорость работы - она достигается за счет кешей, а никак не за счет технологичной архитектуры, которая есть у @SooR. Запросы вида SELECT ...... FROM product .... LIKE('%КРАСНЫЙ%') - это фейспалм, на фоне заявленных суперспособностей. Для тех кто не понимает глубого специфики mysql - такая конструкция в принципе не может быстро работать. Простота интеграции. Опять же @SooR не закрывает код и у него очень понятный механизм интеграции в систему, чем не может похвастаться DRF, так как его автор решил, что после него хоть потом и забрал на свои закодированные модели целиком генерацию товаров и переопределил механизм формирования ссылок пагинации. Опять же это дичайший феспалм. Суть авторов: Просто почитайте как авторы описывают свой дрим фильтр 1000 вариантов фильтрациии, 10000 атрибутики, 150 стилей... Ну чистый тетрис из 90х 10000 в 1. Разводят нашего брата как последнего лоха. Так что выводы делайте сами. P.S - мега таки самый крутой. Но и он не без греха.
  10. Да нормальная тема. Только у нее другой заголовок должен быть. Предохраняйтесь - береженого бог бережет! Проверять лишний хлам в корне, изменения в robots.txt, удалять лишних ftp-пользователей, пользователей в вебмастере, системно менять пароли - никогда не вредно но и полезно.
  11. Статья от КЭПа, при чем от глупого кепа. Просто доступа в вебмастер недостаточно - необходимо еще принудительное указание основного зеркала в robots.txt - а это, без доступа к фтп, сделать невозможно. А если есть доступ к фтп. То у вас не то что трафик поисковый можно угнать, но и упущенные зря годы.
  12. Тут у меня вопрос - зачем и еще раз зачем? Что касается настройки репликации - вы это делаете из примера с ruhihgload. И это большая глупость. Если уж очень сильно хочется. То настройте репликацию баз. Поставьте HaProxy как балансировщик и будет вам счастье. Если не хочется заморачиваться с HaProxy, механизм репликации и балансировки есть их коробки в php http://php.net/manual/ru/book.mysqlnd-ms.php А если хотите совсем заморочится - попробуйте galera cluster и maxscale. Но все эти механизмы актуальны только для большой, оооочень большой нагрузки. Так например opencartforum, на котором вы это читаете в секунду обрабатывает десятки тысяч запросов, а пиковая мощность системы сотня-полторы тысяч запросов mysql в секунду. Я таких магазинов не видел. Даже магазины с трафиком 25-30 000 посетителей в день генерируют на порядок меньше. Если вы таким образом пытаетесь поднять производительность магазина - то сначала надо привести в порядок сами запросы и их количество. А репликация и шардинг - это механизмы горизонтального масштабирования, которые приходят на помощь в случае, если вертикальное масштабирование упирается в предел мощности одного сервера.