Уменьшить скорость загрузки и нагрузку на сервер

Amigo_9876, я в этих htop ничего не понимаю, надо смотреть, какие у вас лимиты в тарифе, что превышено, и что с этим делать.

У меня, например, был случай, что галерея почему-то генерировала херову тучу ненужных страниц, яндекс всё это дико индексировал, сервак грузился. Не надо было ничего оптимизировать, закрыл от индексации страницы галереи, и всё стало ок. Но конкретную проблему мне озвучила техподдержка хостера, а не просто "Вы грузите нам сервак, сделайте что-нибудь".

Может, и у вас что-нибудь в этом духе.

На нагрузку сервера, как я понимаю, влияет количество и качество запросов со страницы. Вот, например, пишут - http://live.cnews.ru/forum/index.php?showtopic=66591 Статья старая, но, надеюсь, суть ясна.

возможно она им и отдается, просто под другим юзером.

на скрине htop только одного пользователя.

не понятно 30к чего конкретно?

это по счетчику какому-то внешнему или по логам?

30к уников или запросов?

может быть 30к уников, но какие-нибудь долбохакеры брутфорсят какой-нибудь скрипт и запросов там уже под миллион :)

однозначно картину можно понять только по access.log'ам.

Нагрузку на сервер можно снизить с помощью кеширования, рефакторинга кода, оптимизации тяжелых запросов. Но быстрее всего, конечно, кеширование. Большая часть из проделанной вами работы повлияет только на скорость загрузки сайта. Если хотите более подробный ответ - напишите в ЛС. Попробую помочь.

Мой htop при посещаемости 2 тысячи запросов в секунду где-то также выглядит, на более слабой машине. Тут дело не в количестве запросов, а в том как все настроено. В 95% случаев можно настроить все таким образом, что нагрузка будет просто смешной. При этом сайт будет работать в разы быстрее. Оптимизация наше все.

Запрос запросу рознь. Отдать картинку и сгенерить и отдать страницу - вещи разные.

Ну у меня там несколько запросов в базу, пара к Redis, +парсинг и отдача шаблона. Не скажу, что прям ваще ресурсоемкое, но аналогичное на PHP7 с Twig и тем же Redis работает в 2.5 раза медленнее.

Первое решение было на Go, веб-сервер тоже асинхронный на Go отдающий статику.

Второе было Nginx, php7.0-fpm.

Конечно, все от кода и приложения зависит, но я к тому, что 30к в сутки, это 1 запрос в секунду при 8 часовом рабочем графике. Обычно график более размазан. 1 запрос в секунду - это не нагрузка.

1. TimeWeb уже неоднократно был замечен за тем, что предлагает пользователям хостинга переехать на новый тариф. При этом нагрузка на сервер вырастает внезапно и ничем не обосновывается. В большинстве случаев, это уловка хостера, чтобы вы платили больше.

2. Подсчет нагрузки на сервер, вещь весьма абстрактная и зависит от тысячи факторов. Например, используемое железо на сервере, количество клиентов на сервере, количество высокопосещаемых сайтов на сервере.

1 сайт-сосед может генерировать высокую пиковую нагрузку в течении суток несколько раз. Например, запускается крон и начинает делать бэкапы, качать данные, проводить синхронизации и т.д.. А если таких сайтов несколько? Что останется от ресурсов сервера вам? Правильно, малые крохи.

Теперь представим использование процессорного времени. Когда сервер пустой и процессор не нагружен, ваши задачи выполняются быстро, качественно и не создавая никакой нагрузки. В тоже время, когда процессор у сервера сильно загружен соседними сайтами, ваши задачи выполняются медленнее, от чего растет используемое процессорное время и превышаются псевдо-лимиты выделенные вам хостером.

Еще элементарный случай повышения нагрузки, это жесткие диски сервера. Умирающий хард работает со сбоями и медленно, соответственно грузит всю систему. Хард на котором выполняются тысячи ресурсоемких задач тоже будет тупить.

3. Отключение метрики и прочих внешних асинхронных скриптов никак не влияют на нагрузку хостера. Потому что они грузятся со сторонних серверов.

4. 30 кило в сутки, это не так уж и много, если конечно вы не используете сторонние плагины, которые могут отправлять сотни запросов к базе данных.

5. У движка может заглючить какой-нибудь скрипт. Было у меня на вордпрессе, wp-cron.php подвис и создавал лютейшую нагрузку на сервер. Но там мне хостер конкретно ткнул носом на этот файл и указал, что именно он создает дикую нагрузку.

Сейчас вообще стараюсь не использовать движки, особенно для сайтов, на которых контент публикуется\меняется редко.

6. Использование кеширования и сжатия поможет существенно снизить нагрузку, но может нарушить работоспособность некоторых скриптов. Тут нужно смотреть конкретно на пациента.

7. Подключите к сайту сторонние формы комментариев от соц сетей. А встроенные отключите. Снижается нагрузка, плюс освобождается место в базе данных.

8. Оптимизируйте количество запросов к базе данных, удалив из кода запросы-паразиты. Например, функцию, запрашивающую название сайта, которое берется с базы данных при каждой загрузке, можно заменить статичным текстом. Так же поступить с другими запросами, которые можно заменить на статические данные.

9. Картинки сжать, по возможности вынести на сторонний сервер.

10. Отключение плагинов или их замена на менее ресурсоемкие. Например, есть куча плагинов-"оркестров", которые выполняют несколько разных функций, некоторыми из них вы можете не пользоваться.

Например, возьмем вордпресс, с вашим движком не работал, но думаю аналогия полная. Есть там плагины по защите движка от взлома, грузят движок - мама не горюй! А всего-то нужно добавить несколько строчек в .htaccess которые заменят половину функций этого плагина. А вторую половину функций можно заменить другим, простеньким. Так можно поступить и с другими плагинами, удалив их и установив сторонний функционал. Например, встроенную капчу, можно заменить на Рекапчу и т.д.

Но в итоге с вероятностью 90%, если хостер не бросит затею по переводу вашего аккаунта на более дорогой ТП и вы решите съехать на другой хостинг, выяснится, что ваш сайт не потребляет и половины выделенных ресурсов.

---------- Добавлено 14.12.2016 в 07:10 ----------

И еще одно ИМХО.

Хостер, пугая клиента более дорогим тарифом, заставляет клиента пошевелиться и оптимизировать свой сайт.

Что естественно даст результаты в виде уменьшения нагрузки на сервер.

Возьмем к примеру один сервер на котором 500 клиентов.

Всем рассылаем сообщение о превышении лимитов.

Получаем фидбэк от клиентов и извиняемся перед теми у кого статичный сайт с посещалкой 10 уников в сутки. Мол произошла ошибка и т.д.

Часть клиентов, прислушаются к хостеру и возьмут тариф дороже. Прибыль, плюс освобождение места на сервере для новых клиентов.

Остальные клиенты начнут проводить работы над оптимизацией и общая нагрузка на сервер может снизиться в разы! Что дает возможность загнать на этот сервер еще 100-200 новых клиентов.

?????

PROFIT

PHP исполняется как CGI или как модуль апача? если второй вариант, то посмотрите PHP Акселераторы установлены/включены? если нет, установите или включите это сразу минимум +30-40% к производительности практически любого кода. Также можно пошаманить с настройками мускула (кешированием запросов).

правда, если у вас обычный хостинг, то вряд-ли кто даст это сделать

Конкретно таймвеб был не раз замечен за тем, что просто останавливал обслуживание сайтов при небольшом повышении нагрузки. Лично я 2 раза сталкивался, оба раза было весело в конторе, люди бегали с красными лицами и перманентно матерились. И оба раза перешли на более дорогой тариф кстати.

Конечно, сравнивать с вашим сайтом в 10 миллионов посещений даже не стоит, но у ТС вопрос совершенно не об этом :)

Хотелось бы видеть, какой именно сейчас тарифный план у ТС. Имхо судя по htop там у него нагрузки ни какой нет, т.е. оптимизировать сферического коня в вакууме довольно сложно.

для шареда за 200р в месяц? 30 кило в сутки это 20-40 в пик до 100 юзеров онлайн. вы живете именно за счет соседей, шаред не рассчитан на такую посещалку по нагрузкам...