- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Тренды маркетинга в 2024 году: мобильные продажи, углубленная аналитика и ИИ
Экспертная оценка Адмитад
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
- начать кэшировать (хотя при такой посещаемости это смешно)
На сайте стоит wp-super-cache, время хранения кеша — 2 дня.
---------- Добавлено 15.12.2015 в 11:17 ----------
Узнать, какие страницы/запросы создают основную нагрузку.
Вот тут проблема — каким образом. Учет процессорного времени идет по времени исполнения процесса php. Один процесс php обрабатывает до 500 запросов, т.е. время индивидуального запроса определить не получится. Единственное что я могу сделать — разнести выполнение запросов, идущих на разные точки входа по разным php-процессам, что уже и было сделано для админки и содержимого wp-content.
Соответственно, остается анализ статистики посещений. Статистика за вчера (отсеиваются запросы к статике, так как она не требует исполнения скриптов):
---------- Добавлено 15.12.2015 в 11:21 ----------
А что мешает хостеру зайти в консоль и посотреть потребление оперативки по команде top? Если это демон MySQL грузится, то нужно проверять сколько ему вообще отведено памяти. И самое главное: всё ли нормально с индексами таблиц. Они создаются? Они вообще есть?
MySQL находится на отдельном сервере и в нагрузку не считается. Считается только cron, скрипты сайта и работа с файлами.
eaccelerator — мертвый проэкт. У нас по умолчанию стоит и включен xcache.
---------- Добавлено 15.12.2015 в 11:22 ----------
попробуйте:
сколько насчитывает?
P.S. Сейчас сайт создает уровень нагрузки аналогичный этому сайту: http://avtopoligon.info/
Только к этому в день приходит 35 тысяч запросов.
Охереть, ребята я далек от нюансов, но должно же быть решение. Где сидит зараза которая так перегревает проц 😡
так мы че, тут, угадывать должны?
Тебе сказали, что делать. Я тебе целый список написал из вариантов решения.
- сменить хостера на менее жадного - (давно с ним, это первый глюк за лет 5)
- начать кэшировать (хотя при такой посещаемости это смешно) - сами ответили, но тем не менее стоит плагин кэширования
- оптимизировать нагрузку на сервер (от чего-то отказаться из функционала) функционал итак по минимуму
- просто бросить или просто продать сайт - дрючиться будет кто-то другой - думаю не та проблема, что бы просто слить только начинающий обростать жирком ресурс
- отказаться от тяжелой для хостера CMS - не думаю что этот конструктор слишком тяжел для этого хоста
Охереть, ребята я далек от нюансов, но должно же быть решение. Где сидит зараза которая так перегревает проц 😡
У меня была подобная проблема, нагрузка была сумасшедшей.
Хостер так же отписывал, что причину возникновения такой нагрузки не знает, ссылался на логи..
Плагин кеширования не помог мне.
По 20 раз смотрел логи, видел много заходов, при чем заходов не уников а ботов.
Они мне и делали нагрузку заходя ежесекундно.
Что сделал:
- Убрал лишние виджеты
- Оптимизацию БД сделал
- Обновил плагины и сам WP
- Поставил плагин wordfence, в разделе Live Traffic можно отслеживать кто и какие боты к тебе заходят и прямо там банить (после этого действия проблема исчезла).
Оказалось, что пару ботов прописались у меня на сайте.
- сменить хостера на менее жадного - (давно с ним, это первый глюк за лет 5)
Один из самых эффективных пунктов. Хостеры все-же заедаются, оверселлят, шейпят..
- начать кэшировать (хотя при такой посещаемости это смешно) - сами ответили, но тем не менее стоит плагин кэширования
Значит плохо работает ваше кэширование. Я ставил кусок кода, который скидывал весь кэш в виде HTML страниц в отдельной папке. После того, как кэш наполнялся, можно было отключить MySQL и снести все остальные папки кроме одной - с файлами кэша и сайт продолжал работать. Правда переставали работать различные интерактивные блоки, типа формы обратной связи и т.п., но нагрузка на сервер падала практически до нуля.
Вот тут проблема — каким образом. Учет процессорного времени идет по времени исполнения процесса php.
Стоит вести статистику _времени_ генерации ответа по каждому запросу.
Один процесс php обрабатывает до 500 запросов, т.е. время индивидуального запроса определить не получится.
Почему не получается? В лог можно писать время генерации ответа от бэкендов, по крайней мере в nginx.
Углубляться в проблему можно и дальше, поставить xdebug profiler например. Было бы желание.
И да, вордпресс кэшировать никогда не смешно, главное full page.