- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Маркетинг для шоколадной фабрики. На 34% выше средний чек
Через устранение узких мест
Оксана Мамчуева
В 2023 году 36,9% всех DDoS-атак пришлось на сферу финансов
А 24,9% – на сегмент электронной коммерции
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Может кто-нибудь подскажет, что можно сделать?
Имеется варезник на DLE. Посещаемость - максимум 30-40 уников. Всего опубликовано 20к постов. Размер БД - 165mb. Стоит на виртуальном хостинге.
Сегодня пришло такое письмо от хостера:
Со стороны Вашего аккаунта,фиксируется чрезмерная нагрузка. Речь идёт о нагрузке на сервер БД со стороны базы данных ***.
Время выполнения запросов к данной БД достигает 21 сек,что является очень высоким показателем.
Нормальное время выполнения запроса 1-4 сек.
Просим Вас провести оптимизацию БД и устранить проблему в течении 12 часов, т.к. нагрузка со стороны Вашего аккаунта создает проблемы в работе всего сервера виртуального хостинга.
В данном случае наиболее правильным решением будет переход на VPS или VIP хостинг.
И т.д.
Приводится и лог с проблемными запросами:
Count: 22 Time=21.95s (483s) Lock=0.00s (0s) Rows=12.0 (264), db_site[db_site]@localhost
SELECT id, short_story, title, date, category, alt_name, flag FROM dle_post WHERE MATCH (title, short_story, full_story, xfields) AGAINST ('S') AND id != N AND approve=N LIMIT N
Count: 2 Time=40.50s (81s) Lock=0.00s (0s) Rows=0.0 (0), db_site[db_site]@localhost
INSERT INTO dle_post (date, autor, short_story, full_story, xfields, title, keywords, category, alt_name, allow_comm, approve, allow_main, fixed, allow_rate, allow_br, symbol, flag, tags) values ('S', 'S', 'S$
Count: 1 Time=14.00s (14s) Lock=2.00s (2s) Rows=14.0 (14), db_site[db_site]@localhost
SELECT id, autor, date, short_story, full_story, xfields, title, category, alt_name, comm_num, allow_comm, allow_rate, fixed, rating, vote_num, news_read, votes, flag, editdate, editor, reason, view_edit, tag$
Может кто подсказать, где здесь собака зарыта и что можно сделать, чтобы уменьшить нагрузку?
Сам я в этом полный ноль.
P.S. Сайт стоит на этом хостинге с марта.
Месяц назад получил письмо с таким же содержанием. Провел оптимизацию БД через админку. Месяц - тишина, а сегодня снова...
кэширование в настройках dle включите...
кэширование в настройках dle включите...
кэширование включено.
Обнаружил, кстати, что почти месяц на сайте идет активная регистрация с целью спама.
Только за сегодня более сотни регистраций. Как я понимаю, нагрузку на БД это дает?
И еще вопрос, как отключить регистрацию так, чтобы уже зарегистрированные пользователи могли проходить авторизацию?
В настройках есть отключение регистрации
Урл покажите
kgtu5 как я понимаю, при отключении регистрации через админку отключается и авторизация... Тогда на сайте не смогут логиниться журналисты.
УРЛ скинул в личку
В админке где-то есть ограничение по количеству юзеров. Поставьте текущее количество юзеров, больше никто не сможет регистрироваться.
Но в запросах лог поиска , а не регистрации.
попробуй для начала это
4dle.ru/tips/1147159258-medlennye-zaprosy.html
В админке где-то есть ограничение по количеству юзеров. Поставьте текущее количество юзеров, больше никто не сможет регистрироваться.
До этого уже сам догадался.
SELECT id, short_story, title, date, category, alt_name, flag FROM dle_post WHERE MATCH (title, short_story, full_story, xfields) AGAINST ('S') AND id != N AND approve=N LIMIT NПолнотекстовый поиск по нескольким полям? Круто, чо!
Зачем искать текст в short_story, если он ищется и в full_story? Как я понял short_story это что-топа превью статьи?
Зачем искать текст в short_story, если он ищется и в full_story?
Не у всех там одинаковый текст... Иногда превью содержит иной контент...