- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу

Как удалить плохие SEO-ссылки и очистить ссылочную массу сайта
Применяем отклонение ссылок
Сервис Rookee

В 2023 году 36,9% всех DDoS-атак пришлось на сферу финансов
А 24,9% – на сегмент электронной коммерции
Оксана Мамчуева
Обновил плагин для Opencart 3 по автоматической очистке сессий: https://getmanyspeed.ru/articles/opencart-3-ochistka-staryh-sessij.html
А причиной стало обнаруженный баг в самом Opencart 3. Встроенная функция очистки, который вызывал мой плагина был написан с ошибкой и только в последней версии v3.0.3.7 это всё было исправлено.
Поэтому у кого версии более старые, могу свободно пользоваться данным модификатором.
Конечно, вы можете взять файл работы сессий с новой версии Opencart 3, но если честно, их решение вызывать подсчёты и надеяться на рандом при каждом обновлении страницы пользователем, кажется весьма странным.
Пока был в отпуске, пришлось вновь обновить модуль по очистке сессий Opencart 3, всё же в нём опять косяк и опять всё переделали в новой версии.
Поэтому моё решение актуально как никогда: https://getmanyspeed.ru/articles/opencart-3-ochistka-staryh-sessij.html
И кстати, у кого есть магазины Opencart, есть отличное решение по ускорению работы сайта: https://getmanyspeed.ru/articles/autotunespeed-avtomaticheskoe-uskorenie-raboty-opencartocstore-152h3h.html
По работе попросили сортировку в админке по дате Opencart/OcStore 3.0.3.7 поэтому сделал и выложил всем кому надо тут:
https://getmanyspeed.ru/articles/opencart-3-sortirovka-po-date-dobavlenija-i-modifikatsii-v-adminke.html
Интересная история случилась по исправлению работы сервера, хотя начиналась с якобы вирусов.
Дано:
VPS, Centos 7, ISP6, сайты на WP. Сайты не работают нормально уже практически месяц, подозрение на вирус. Хостер проверял на вирусы сервер, ничего не нашёл, говорит не знает что такое.
Поехали!
Начинаю конечно же изучать отчёты по вирусам, запускаю свои поисковики, изучаю файлы, ничего не бросается в глаза. При этом сайты висят в вечной загрузке, никакой нагрузки на сервере нет. Все сайты изолированы, но часть работает, а часть нет.
Ну думаю, дайка я посмотрю, что там apache делает с этими запросами т.к. даже на таймаут PHP они не реагируют. Для этого мне надо поставить lynx и.... я не могу этого сделать. YUM вышибает с ошибкой, что не может подключиться к основновному репозитарию т.к. нет подключения по ipv6. Проверяю сайты и панель, нигде не значиться ipv6, но в интерфейсе он есть и почему-то сервер ломиться именно по нему.
Так... выключил ipv6 на уровне ядра, перезагрузил интерфейс сетевой.
Пробую: yum update
curl#7 - "Failed connect to mirrorlist.centos.org:80; Operation now in progress"
Уже лучше, уже определяется домен, но не подключается. Порылся в интернете, есть куча советов, но плюнул на всё и перезагрузил сервер. И о чудо, все заработало! Заработали и сайты, и сервер обновился, и всё стало работать как надо.
Что это было... почему месяц назад всё работало, а сейчас нет, почему раньше ipv6 не давал признаков жизни, а был ли он тогда, мы уже никогда не узнаем. Клиент доволен, вирусов нет, сайты работают! Как-то так 😊
Не знаю банальная история или нет, но всё же расскажу. Назовём её: "Воссоединение сайтов"
Есть много сайтов на самописной CMS ещё со 2013-2015 годов. Они разбросаны по мелким VDS. Клиент решил всё собрать на одном мощном сервере т.к. управлять этой «армией» VDS стало невозможно, да и накладно.
Был взят мощный сервер и полностью настроен мной под большие нагрузки. Установлена панель ISP6 на Centos 8 Stream, а там кто не знает, по умолчанию ставиться Mysql 8.0 и это очень важно в данном контексте. Я не перевожу без особых причин на MariaDB в такой конфигурации и возможно зря, возможно нет.
После переноса 40 сайтов выясняется, что серверу не хватает ресурсов и MySQL постоянно нагружена. При этом на VDS всё было нормально.
Начинаю мониторить запросы и у нас тоннами сыпется запросы вида:
SELECT sql_calc_found_rows …….
Кто не знает, поясню, это запросы для подсчёта количества строк без учёта ограничения LIMIT. Данный запрос уже давно считается устаревшим, но всё же в MySQL 8 он работает. А работает он как всегда ужасно долго из-за своей специфики, поэтому его давно уже пора «сжечь».
Так, а почему проблем не было на старых VDS? Потому, что там MariaDB с включенным кэшированием, который просто запоминал этот запрос и всё, а в MySQL 8 кэширования нет вообще. В связи с этим начинают всплывать очень плохие запросы, которые нагружают сервер.
Возможно это и к лучшему с точки современной разработки, но нас сайт 2015 года, что делать то?
Проанализировав, было выяснено, что этот «sql_calc_found_rows» вызывается постоянно, если используется LIMIT. Нужен ли этот подсчёт или нет, не важно, главное давайте посчитаем, именно так решил разработчик CMS. Но запрос то не сразу выдаёт количество строк, надо вызвать ещё запрос:
SELECT FOUND_ROWS();
НО, его нет стандартно в классе запросов к MySQL, хотя у нас «серьёзный» проект на CodeIgniter! Значит сбор делается по ходу дела, где-то в коде? Замечательно! Грузим БД постоянно, а результат забираем, когда нам надо, "удобненько"…
Начинаю искать, где используется подсчёт этот, а нигде. Да! Он нигде не используется вообще! Единственное место во всём проекте, это подсчёт найденных данных в модуле, который отключён для этого проекта.
Молча убираю «sql_calc_found_rows» из запроса и всё.
Вот так старые проекты при масштабировании от 1000 записей до 700 000 через года, начинают создавать проблемы.
Был там ещё перевод на InnoDB, и простановка кучей индексов и мониторинг, но это всё рутина.
Спасибо, что дочитали! Если и Вам нужна помощь по оптимизации и исправлению ошибок, пишите.
Вот это я чудо чудесное узнал сегодня! Плагин для Wordpress LiteSpeed анонсировал ещё летом ЧУДО функцию Guest Mode
Ой, а что она делает то? Да просто ставит обманку на ваш сайт для всех сервисов, которые проверяют скорость сайта, чтобы показывать отличные результаты.
Возможно они как-то скрывают этот функционал? Нет! Они гордятся своим достижением:
https://blog.litespeedtech.com/2021/06/01/guest-mode-for-wordpress-in-lscwp-v4-0/
Как идёт проверка для таких гостей? Да по сути просто, в коде прописано так:
Плагин смотрит, кто заходит с этим юзер агентом и с этими IP и им показывает "оптимизированную", а точнее сказать сломанную версию сайта. Которая, конечно, чуть ли не белый лист показывает потому, что "оптимизируются" все CSS и Javascript.
У меня сервис по проверки на обманки, но разработчики этого плагина пошли дальше, он вешают куки специальные, чтобы уж точно нельзя подлог разглядеть, но я всё же смог обойти эту проверку и обновил свой сервис:
https://getmanyspeed.ru/stop-cheating.html
Не давайте себя обманывать! Никакие "галочки" в плагинах не ускорят Ваш сайт без индивидуального и грамотного подхода к каждому сайту!
По моей инициативе удалось пообщаться на тему возможного ускорения своей рабочей сборки.
Но так как я прямого доступа к хостингу не предоставил и не согласился на стороннюю поступательную программную отладку (были свои внутренние причины), то путём удалённых изменений улучшенных результатов не получил. Однако узнал новую и полезную для себя информацию, которая безусловно не менее ценна, чем мои ожидания.
К слову, предлагал деньги, Леонид оплату не принял, что тоже в определённом позитивном смысле характеризует.
Рекомендую.
p.s. Да и вообще за много лет прибывания на форуме не помню серьёзных претензий к Леониду.
В общем-то никаких претензий не помню :))
Много чего было сделано за эти недели, один из последних клиентов.
Дано
Виртуальный хостинг
ocStore 3.0.2.0
25 000 товаров
Время загрузки страниц 10-13 секунд
В принципе стандартная ситуация для конструктора под названием Opencart.
Берём напильник, обрабатываем БД в новый формат, проставляем более 600 индексов. Благо индексов накопилось много за годы работы. Делаем некоторые настройки магазина.
Итоги
Теперь страницы грузятся 0,4-0,6 секунды. Прелесть. Хостер больше не материться, клиенты радуются быстрому сайту, заказчик вздохнул с облегчением и пошёл пополнять магазин дальше!
Данное ускорение обошлось в 1500 рублей.
Поэтому, если у вас такие же проблемы на Opencart, пишите, помогу с удовольствием!
Свершилось! Реализовал модуль AutoTuneSpeed для DLE 10.x и выше.
Подробнее расписал тут: https://getmanyspeed.ru/articles/autotunespeed-avtomaticheskoe-uskorenie-raboty-dle.html
Особую благодарность выражаю очень хорошему клиенту, которую дал для тестирования несколько своих сайтов на разных версия DLE. Конечно в замен получил быстрые сайты и модуль совершенно бесплатно.
Тест на одном из сайтов.
Было
После включения модуля
Тщательная проверка проходила на внутренних страницах сайта т.к. на кино сайтах это более важные страницы, чем главное. Результаты порадовали всех!
Модуль совместим со всеми плагинами и проводит современные процедуры по оптимизации кода.