Vvmebel.com

Новости с мира ПК
2 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Нагрузка на сервер хостинга

Какой хостинг подойдёт при высокой посещаемости

В марте 2016-го я вынужден был переезжать на другой хостинг. До того момента, с 2012 года, я сидел чуть ли ни на первом попавшемся под руку хостинге во время создания сайта — Mainhost. И всем меня устраивал, и техподдержка на уровне, и платил около 100 рублей при 20.000 чел/сутки. Если нагрузка на процессор превышала допустимую норму, то просто списывали несколько рублей за такой день и всё.

Но потом у них поменялась политика, и сказали, что так больше нельзя, в смысле — доплачивать. А ни какой другой тариф у них мой сайт не потянет! Хоть дали время на переезд, сколько попросил. И стал я искать новый дом для сайта, а главными критериями стали – нагрузка на процессор и стоимость.

Какую нагрузку выдерживают хостинги

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

Самая большая загвоздка — это то, что в тарифах какого угодно хостинга нельзя прочитать, сколько он потянет, а тем более примерить эти цифры для своего сайта. В основном, вообще не пишется ничего на этот счёт. Иногда пишут на каких тарифах сколько «попугаев процессора» тебе полагается. Каждый пишет, что у него очень классный и быстрый хостинг. Но эта информация максимально оторвана от конкретно твоего сайта.

Иногда, даже есть калькулятор, который посчитает тебе нужный тариф, и для меня всегда насчитывали очень дорогой, т.к. большая посещаемость. Но я понимал, что такого быть не может: сейчас плачу 100р, а оказывается меньше 1000р в месяц никак не влезть. Что-то тут не так… Короче, я решил, чтобы узнать потянет ли какой-то хостинг сайт – нужно проверять конкретный сайт на этом хостинге.

Принцип тестирования сайта на других хостингах

Покупать тариф у каждого провайдера просто чтобы его потестировать – не благодарное дело. Поэтому я выбирал только тех, у кого есть тестовый период, в среднем он 2 недели. На каждый тестовый хостинг переносятся файлы и база данных сайта. Я всё делал вручную и довёл процесс до автоматизма. Но можно попросить это сделать службу поддержки, просто так дольше ждать придётся На результаты проверки не влияет какая у вас CMS – WordPress, Joomla, DLE или любая другая, главное чтобы хостинг поддерживал такие системы.

Менять NS-сервера на новые НЕ НАДО! Чтобы у себя на компьютере открыть сайт с тестируемого хостинга нужно просто прописать в файле «c:WindowsSystem32driversetchosts» такую строчку:

Например (я прописываю также свои поддомены):

IP-адрес вашего нового размещения можно узнать из писем после регистрации, в панели управления или спросить в тех. поддержке. Теперь в браузере будет открываться сайт с нового хостинга (если всё заработало), а для обычных посетителей ничего не поменяется, у них сайт будет работать с вашего текущего хостинг-провайдера.

Иногда браузер тупит и не видит что вы прописали новый IP, тогда нужно почистить кэш браузера. На примере Google Chrome покажу как понять, с какого сервера у вас грузится сайт:

  • Нажимаем «F12», внизу появится панель разработчика
  • Обновляем страницу «Ctrl+F5»
  • Переходим на вкладку «Network», кликаем по первой позиции в списке и смотрим направо

Иногда нужно по несколько раз обновить страницу, чтобы там засветился новый IP-адрес. Когда всё заработало, нужно установить программу для тестирования нагрузочной способности. Вообще, это целая наука, а программы такого рода продают за тысячи долларов. Из бесплатных мне ничего не понравилось, либо слишком сложно. Поэтому будем пользоваться тестовым периодом. Скачиваем и устанавливаем программу WAPT.

Это самое понятное, что мне попалось с триальным сроком 1 месяц с возможностью продления ещё на один. Лекарств для подобного софта в сети обнаружено не было.

Принцип работы такой:

  • Программа загружает указанную нами страницу сайта и запоминает все её элементы
  • Отсеиваем все скрипты, стили, картинки со сторонних серверов
  • Просим программу «посетить» эту страницу нужным количеством человек
  • Смотрим как менялась скорость загрузки, количество ошибок и другие параметры

Как проверить нагрузочную способность хостингов

При первом запуске открывается мастер создания первого проекта (у меня всё на английском, но вроде я дал ссылку на русскую версию), на первом шаге нужно выбрать тип нарастания нагрузки:

  • Ramp-up – постепенное,
  • Constant – постоянное,
  • Periodic – периодически меняющаяся.

Выбираем «Ramp-up» и на втором шаге настраиваем его:

  • Количество виртуальных посетителей (users) от 1 до 20,
  • С шагом «1», повышая каждые 10 секунд.

В пробной версии максимальное число users – 20 одновременно. Но этого вполне достаточно для проверок. В финальных отчётах программа пишет общее количество сессий за время теста, и при 20 users их набирается тысячи за 10 минут теста. Т.е., получается, что это подходит для сайтов и со 100 000 чел/сутки, а может и больше, в общем — индивидуально.

При моём тестировании разных хостингов, не каждый выдерживал цифру 20. При этом я брал виртуальный хостинг и один на VPS, но о результатах ниже. На третьем шаге выставляем общую продолжительность теста, пусть будет 10 минут.

После завершения мастера появится окно настроек профиля:

Оставляем по умолчанию и заходим в «Edit options»

Здесь нужно включить запись элементов страницы, таких как картинки, скрипты «.js» и стили «.css». Так мы проверим не только нагрузку на процессор, но и реальную загрузку всех элементов. Два раза «ОК» и мы уже в главном окне, запись включена. Теперь надо вбить адрес страницы для тестирования. Вставляйте ссылку на одну из самых посещаемых страниц, и чтобы на ней были картинки, а не только текст.

На этом шаге ещё могут выскочить окошки установки и соглашения с сертификатами безопасности, на всё соглашайтесь. Когда страница загрузилась и новые элементы в дереве слева перестали добавляться – останавливаем запись кнопкой «Stop Rec» на панели:

Теперь у нас есть проект нашего сайта, но могут появиться и другие ветки, например от счётчиков посещений. Посмотрите и удалите все лишние:

Далее, нужно кликнуть по своему проекту и справа перейти на вкладку «Page Elements»

Здесь нужно сделать важную штуку: в списке загружаемых элементов оставить только ресурсы со своего домена, в моём случае «it-like.ru» и мои поддомены. Это нужно для того, чтобы в процессе теста нагрузочной способности не терялось время на загрузку ресурсов с внешних серверов. Как правило, это скрипты счётчиков, реклама, CDN-картинки.

Сохраняемся, в принципе всё готово, все другие параметры по умолчанию. Перед первым запуском нужно запустить проверку теста из панели «Verify Test». Просто со всем соглашаемся. Теперь можно наконец-то запустить сам тест кнопкой «Run Test» на панели. В процессе будут рисоваться графики.

Результаты тестирования некоторых хостеров

Давайте разберём для примера проверку хостера «Provisov»:

  • Чёрный график всегда ровный – количество виртуальных посетителей
  • Сиреневый – среднее время загрузки страницы
  • Красный – среднее время загрузки со всеми элементами
  • Жёлтый – сколько раз успел загрузить страницу за 1 секунду

Результаты хорошие, время загрузки небольшое и плавно увеличивается. Перейдём на вкладку «Bandwidth»

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

Следующая вкладка «Errors». Здесь статистика по ошибкам:

Многовато. В идеале ошибок должно быть ноль, но такое редко встречается. Бывает, что по всем графикам красота, а ошибки зашкаливают. Значит просто не получена информация с сервера.

Для сравнения возьмём хостинг «Timeweb»

Результаты плохенькие, время загрузки с элементами страницы – большое! Соответственно, мало страниц в секунду загружается. Ошибки также присутствуют:

А вот провайдер «Appletec»

Тоже так себе, очень нестабильно.

Хостинг «Link-Host», графики производительности:

Красота, а теперь посмотрим на ошибки:

Примерно 10% всех запросов выполнены с ошибками, то, о чём я чуть выше писал. Вот за счёт этого и красота, такое обхожу стороной. Некоторые хостинги очень разочаруют, например «Netangels» оказался вообще никакущим, страница ошибок:

Для любителей VPS, попробовал я AdminVPS. Хорошая компания с отличной техподдержкой и невысокими ценами. Но на тарифе около 5 баксов мой сайт хуже прошёл тест, чем на виртуальном хостинге за 2-3 бакса:

Объясняется это очень просто: на VPS ваши ресурсы ограничены конкретными значениями, а на виртуалке обычно такого нет. Т.е., грубо говоря, если никто больше не нуждается в ресурсах, то всё – ваше. Но, если нод (сервер), на котором расположен ваш сайт перегружен, то картина будет обратная. И да, у хостеров много нодов, и поэтому кто-то может жаловаться на компанию, а у другого будет всё хорошо, просто их сайты на разных нодах.

Такие же результаты будут на любом VPS за небольшие деньги, и при штатной нагрузке сайта работа будет более стабильной, чем на виртуальных хостингах, а чрезмерно повышенную нагрузку всё-таки отрабатывает без падений. Я выбрал этот вариант, жаль не осталось идеальных графиков с включённым кешем, там красота.

И, в конце-то концов, нашёл я новый хостинг – Webstix (обновление 2018, хостинг теперь называется GBNHost). Результаты:

Читать еще:  Кавычки в word

Я был в шоке, абсолютно левый, случайно попавшийся хостинг показал категорично лучшие результаты в моих тестах. И даже то, что там была новая для меня и подглючивающая панель управления сайтом – VestaCP, я всё-равно туда переехал. Но через месяц панель заменили на мою любимую ISPManager, чему я очень обрадовался 🙂

Мои советы по выбору хостинга

Не бойтесь переезжать, набейте себе руку развёртыванием сайта у разных хостеров, и этот процесс станет максимально прозрачным. Я знаю, страшно менять NS-сервера на новые. А вдруг в «реале» что-то пойдёт не так? Но есть способ как перенести сайт без рисков неудачи.

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

Причины и способы борьбы с чрезмерной нагрузкой на сервер

Бесперебойная работа приложений и сервисов напрямую зависит от нагрузки, оказываемой на виртуальный сервер (VPS). Сбои в работе VPS могут вызвать разные причины — от резко возросшей посещаемости до атак киберпреступников.

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

Как протестировать нагрузку на VPS и уменьшить ее самостоятельно расскажем в данной статье.

Что такое нагрузка на VPS

Нагрузка на сервер — количественная оценка характеристик ресурсов хостинга, расходуемых во время выполнения текущих задач. Иными словами, это процент загрузки ресурсов сервера — процессора (CPU), оперативной памяти (RAM или ОЗУ) и дискового пространства.

Виды нагрузки

  1. На базу данных.
    Чем вызвано: тяжелые SQL-запросы, отсутствие оптимизации и некорректные настройки конфигурационного файла.
  2. Навеб-сервер.
    Чем вызвано: увеличение посещаемости интернет-ресурса, находящегося на VDS.

Мониторинг виртуального сервера

Мониторинг VPS — систематический сбор и обработка информации о степени загрузки с разных учетных записей ресурсов виртуального сервера. Мониторинг позволяет предотвратить развитие негативных последствий сбоев работы сервера ещё на начальном этапе. Для этого чаще всего нужно либо оптимизировать аккаунт, создающий повышенную нагрузку, либо расширить его ресурсную базу.

Как проводить мониторинг VPS

Для анализа сетевой активности используется утилита atop . Она записывается в лог событий, в котором можно найти процесс, приводящий к перегрузке сервера.

В Linux Ubuntu утилиту можно установить, воспользовавшись командой из терминала:

После инсталляции требуется запустить команду:

В терминале отобразится информация, разделенная на две секции. В первой — основная (загруженность CPU, RAM и диска), а во второй — данные о выбранном процессе.

Посмотреть нагрузку на сервер можно при помощи команды:

Использование дисковых ресурсов сервера можно увидеть в строке DSK («busy» — процентное соотношение текущего потребления). Если последнее значение эквивалентно 100%, это означает, что проблема заключается в операциях ввода/вывода или использовании самого VDS.

Посмотреть сетевую активность можно при помощи команды:

Она выводит список всех процессов, работающих в системе, в режиме реального времени. Обновление экрана происходит каждые 3-4 секунды. В первых строках отображается информация о системе, а ниже — список всех процессов, который упорядочен по убыванию.

Программы для диагностики

Диагностика применяется для выявления проблемного программного обеспечения, вызывающего высокую нагрузку на сервер. Существует много сервисов, позволяющих выполнить этот анализ. Их условно можно классифицировать на две категории.

  1. Простые — показывают время загрузки веб-страницы.
  2. Сложные — могут имитировать подключения из разных мест и производить DDoS-атаку на тестируемое приложение.

Список онлайн-сервисов мониторинга VDS

  • Locust. Масштабируемый инструмент для нагрузочного тестирования, написанный на Python. Отличный способ оценить производительность серверной части ресурса.
  • Host-Tracker. Позволяет выполнить тестирование сервера на нагрузку, одновременно подключаясь из 90 точек со всего земного шара.
  • OpManager. Бесплатная версия сервиса позволяет отслеживать 3 сетевых устройства. С его помощью можно осуществлять проактивный мониторинг состояния сети, серверов, маршрутизаторов и коммутаторов.
  • WebLOAD. Универсальный сервис для мониторинга позволяет проверить все страницы приложения и вывести время загрузки каждой из них. Пользователи на этом ресурсе могут заказать платную оптимизацию сайта.
  • LoadImpact. Выполняет тест нагрузки на сервер, используя одновременно 50 подключений, которые открывают до 20 страниц. Отчет отображается в графическом виде.
  • LoadNinja. Быстрое тестирование нагрузки на сервер, основанное не на виртуальной эмуляции, а на реальном браузере.

Причины перегрузки

Чтобы эффективно снизить нагрузку на VPS, требуется разобраться в причинах ее возникновения. Среди наиболее частых причин эксперты называют резкое увеличение количества посетителей, отсутствие оптимизации программ и СУБД, а также DDoS-атаки сервера.

Увеличение количества посетителей

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

Решение № 1 — модернизация

Когда оптимизировать нечего или нет времени заниматься настройкой VDS, нужно выполнить апгрейд последнего. Происходит это при значительном увеличении числа посетителей.
Это является еще одной причиной, по которой нужно использовать VPS. Для решения проблемы достаточно сменить тарифный план, воспользовавшись более мощным виртуальным сервером.

Нужен надёжный виртуальные сервер с возможностью масштабирования и защитой от DDоS-атак и круглосуточной техподдержкой? Выбирайте VPS от Eternalhost!

Решение № 2 — оптимизация работы сервера

Снижаем нагрузку на VDS, используя правильные настройки кеширования для Apache и Nginx при помощи правки конфигурационного файла.

Для Apache

Директивы (инструкции), которые управляют кешем Apache, можно прописать в файл виртуального хоста или .htaccess (файл дополнительной конфигурации) проекта. Оптимальным является второй вариант.

Для этого нужно открыть файл .htaccess и внести строки:

Далее требуется активировать Expires-модуль при помощи команды sudo a2enmod expires и перезапустить web-сервер: sudo service apache2 restart .

После этого следует включить модуль, указав:

Для Nginx

Настройка кеширования для web-сервера Nginx заключается в редактировании конфигурационного файла. К его коду нужно добавить:

Если создать файл «cache.conf» в директории «/etc/nginx/conf.d/», то можно управлять кешированием. В файле указываются параметры, описанные ниже.

  • Директория кеша: proxy_cache_path /var/cache/nginx.
  • Уровень вложенности каталогов: levels=1:2:3.
  • Базовый размер кеша в Мб: keys_zone=static_cache:100m.
  • Время, через которое происходит удаление кеша (мин): inactive=120m.
  • Указание максимального размера данных, подлежащих кешированию в Мб: max_size=500M.
  • Количество обращений к серверу: proxy_cache_min_uses 1.

После настройки файла, сервер нужно перезапустить, воспользовавшись командой:

Оптимизация программ, сервисов и СУБД

Скорость работы VDS зависит от настройки скриптового языка PHP, который генерирует контент для приложения, осуществляет подключение и работу с СУБД.

Решение № 1 — настройка скриптового языка PHP

Снижение нагрузки на VDS достигается при помощи грамотно настроенного PHP. Для его настройки нужно найти файл «php.ini», воспользовавшись поиском файлов на сервере. Далее его следует скачать, открыть в любом редакторе и изменить параметры, указанные ниже.

После этого необходимо перезапустить сервер, воспользовавшись командой из консоли sudo service apache2 restart или sudo service php5-frm restart.

Решение № 2 — оптимизация MySQL

Для оптимизации MySQL требуется открыть файл «my.conf», который находится в директории с установленной СУБД «/etc/». Затем параметры нужно изменить таким образом:

После внесения изменений файл требуется сохранить, а в терминале запустить движок СУБД MariaDB при помощи команды «sudo systemctl start mariadb».

Решение № 3 — ограничение индексации

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

Например, статьи, не содержащие полезную информацию, можно смело скрывать от роботов поисковых систем при помощи текстового файла «robots.txt».

Пример robots.txt

Решение № 4 — сжатие изображений

Для оптимизации ресурса любые графические файлы следует сжимать специальными сервисами. Это позволяет увеличить скорость открытия веб-страниц и уменьшить нагрузку на VDS. Подробнее об этом можно почитать в отдельной статье.

Решение № 5 — лимиты скачивания

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

Решение № 6 — ошибки в программном коде

Неверный код, на котором написано web-приложение, является основной причиной нагрузки на VDS. За помощью требуется обратиться к программисту или найти ошибки самостоятельно.

Решение № 7 — использование легкой CMS

Нагрузка, оказываемая на виртуальный сервер, зависит от CMS, которая на нем установлена. WordPress — универсальное решение, которое рекомендуют специалисты для большинства типов сайтов. Её главные достоинства — простота установки, нетребовательность к ресурсам и стабильность выпускаемых модулей.

Кибератаки

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

Заключение

Постоянные мониторинг и диагностика нагрузки на VDS, а также оптимизация программного обеспечения и СУБД способны предотвратить его перегрузку. Если это произошло, то необходимо провести настройку веб-сервера, оптимизировать работу СУБД и настроить PHP.

Отзывы и обзоры хостинга

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

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

Читать еще:  Восстановление файла хост

Что же делать при получении такого неприятного сюрприза?

Если хостер сообщает вам о создаваемой «нагрузке на процессор», или «нагрузке на винчестер», требуйте конкретики. Вам должны предоставить если не графики создаваемой нагрузки, то хотя бы точно назвать ее причины. Рассмотрим ряд наиболее часто возникающих проблем.

Нагрузка на CPU при запуске PHP- или Perl-скриптов

В таких случаях хостер не всегда может четко сказать, какой именно скрипт создает проблему, и определить это вам нужно будет самостоятельно. Если вы используете модульную CMS, например Joomla!, WordPress или Drupal, то причиной может быть некорректная работа отдельного модуля.

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

Нагрузка на CPU и (или) дисковую систему от веб-сервера Apache

Излишняя нагрузка может создаваться веб-сервером Apache при отдаче сайтом большого количества графики и другой статики. Архитектура Apache устроена таким образом, что одним потоком или процессом обрабатывается только один запрос. Соответственно, если на вашем сайте очень много графической информации, то на ее отдачу будет тратиться неоправданно большое число ресурсов процессора и ОЗУ. Существенной также будет и нагрузка на диск сервера.

В этом случае можно использовать веб-сервер Nginx в качестве фронт-енда к Apache. Nginx за счет асинхронной архитектуры позволяет обрабатывать тысячи соединений в рамках одного процесса, и отдает статику гораздо легче и быстрее. Проблема лишь в том, что на многих хостингах в качестве веб-сервера используется только Apache, а связка Nginx+Apaсhe используется довольно редко (список хостингов с Nginx). Тем не менее, при переходе на VPS можно настроить данную связку без проблем. Обычно перенос сайтов на VPS с хостинга и настройку необходимого ПО может выполнить ваш хостинг-провайдер даже без дополнительной оплаты.

Избыточное число запросов к сайту

Большое число однотипных запросов к сайту с одного IP или множества IP-адресов (так называемый HTTP-флуд — одна из разновидностей DDoS-атак). Помочь может блокировка проблемных IP в файле .htaccess с помощью директивы «deny from».

Если на хостинге используется только Apache, и отражать проблемные запросы средствами того же Nginx у хостера нет возможности, а атака имеет интенсивный характер, хостер может заблокировать ваш аккаунт на сервере, и попросить перенести сайты на VPS или выделенный сервер.

Если атака возникает в первый раз, то логично обратиться к хостинг-провайдеру за помощью в ее отражении, или хотя бы потребовать разблокировки аккаунта и возможности продолжения работы с хостингом сразу после прекращения атаки. Если такая проблема возникает систематически, то переход на VPS или сервер, и его грамотная настройка для отказоустойчивой работы сайта (например, установка скриптов автоблокировки IP бот-машин на основании анализа логов, установка Nginx в качестве фронт-енда к Apache и фильтрация проблемных запросов на его уровне), действительно имеет смысл.

Существенный рост посещаемости проекта

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

Если посещаемость вашего сайта близка к этим цифрам, то переход на VPS или VIP-хостинг будет правильным решением, которое положительно скажется на его дальнейшем развитии.

Нагрузка на CPU и дисковую систему со стороны MySQL

Нормальным временем для выполнения запроса к базе данных MySQL считается несколько десятков миллисекунд. Запросы, которые выполняются дольше (особенно более 0,5 секунд) часто создают избыточную нагрузку как на дисковую систему сервера, так и на его процессор. Если хостер предупреждает вас о подобной проблеме, запросите у него логи медленных запросов, и выполните оптимизацию структуры базы данных, а также очистите базу от неактуальной информации.

Избыточная нагрузка на почтовый сервис

Интенсивное использование почтового сервиса на хостинге для проведения моментальных массовых рассылок по сотням или тысячам получателей может вызвать существенную нагрузку на сервер. По этой причине, большинство провайдеров устанавливают определенные ограничения на отправку почты — обычно 25-50 писем в час или около 500-1000 писем в сутки. Данное ограничение направлено как на борьбу со спам-рассылками, так и на снижение нагрузки на почтовую подсистему сервера. Для обычной работы с почтой на сайте таких ограничений как правило достаточно, а для массовых рассылок лучше пользоваться почтовым хостингом, сервисами моментальных рассылок, или же приспособить для этой цели VPS.

Общие рекомендации

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

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

Если провайдер предлагает переход на более высокий тариф или же услугу более высокого класса, уточните, что именно это вам даст. Если аргументы действительно весомы, лучше к ним прислушаться. Если аргументы сводятся только к тому, что «так будет лучше во всех отношениях», ищите нового хостинг-провайдера.

Желаем вам как можно меньше проблем в работе с хостингом, и как можно больше успехов в развитии ваших проектов!

Нагрузка на сервер хостинга

Привет дорогие читатели, сегодня я открываю цикл статей, который будет интересен всем владельцам сайтов и блогов, планирующим вывести свою посещалку на 1000 уников в сутки и более. При достижении заветной 1000 человек в день, через какое-то время, всё зависит от хостинга — вы встретитесь с подобным запросом: Чрезмерная нагрузка на сервер!

И получите письмо примерно такого содержания:

Обращаем Ваше внимание, что Ваш аккаунт оказывает чрезмерную нагрузку на сервер.

Нагрузка на CPU характеризует суммарное время, затраченное процессорами сервера на обработку процессов аккаунта. Для снижения нагрузки следует оптимизировать скрипты, исключить выполнение требующих значительных вычислительных ресурсов процессов.

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

По данным статистики нагрузка на сервер:
Дата, нагрузка на CPU, нагрузка на MySQL
2014-03-09 144.83cp 21
2014-03-08 50.33cp 34
2014-03-05 111.85cp 9
— что превышает допустимые значения на текущем тарифном плане: нагрузка на CPU до 50 cp, MySQL до 1000.

Мы можем предложить Вам следующие варианты решения сложившейся ситуации:
1. Устранить источник нагрузки, самостоятельно оптимизировав сайты, используя средства CMS, либо специализированное ПО (профайлеры, фреймворки) на локальном компьютере.
2. Обратиться к соответствующим специалистам для снижения оказываемой нагрузки, в случае если Вы не готовы самостоятельно произвести оптимизацию.
3. Рассмотреть вариант перехода на тарифный план с более высокими ограничениями (Eterno, Premium, Битрикс.1Сайт), либо на техническое решение без ограничений по нагрузке (выделенный или виртуальный сервер).

Статистически, рост нагрузки чаще всего возникает по одной из следующих причин:
1) рост посещаемости;
2) использование неоптимизированных скриптов;
3) отключение кеширования;
4) действие вредоносного кода;
5) нежелательная активность поисковых или иных ботов;
6) увеличение объёма обрабатываемых данных.

В течение 3 дней (до 2014-03-13 включительно) Вам необходимо снизить создаваемую нагрузку до ограничений тарифного плана, после чего проконтролировать создаваемую аккаунтом нагрузку; либо принять решение об адекватной смене условий размещения. Если по истечении этого срока будет по-прежнему наблюдаться повышенная нагрузка, мы будем вынуждены приостановить работу аккаунта. Также мы будем вынуждены приостановить работу в том случае, если нагрузка будет вызывать нестабильную работу сервера.

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

Дочитали письмо до конца? Правда — страшно? Ваш сайт оказывает чрезмерную нагрузку на сервер, а Вы даже не знаете как с этим бороться. И если в течении энного количества дней не устраните нагрузку, то любимый сайт просто отключат. Или нужно будет переходить на более дорогостоящий тарифный план, который по экономическим причинам вас лично никак не устраивает!

Что делать? Что это за чрезмерная нагрузка на сервер и как с ней бороться?

График нагрузки на моем хостинге в конце декабря 2013 года, показанный на рисунке выше реальный. Т.е. допустимую моим тарифным планом норму нагрузки в 50 CP мой аккаунт состоящий из 5-ти блогов превысил в примерно в 140 раз перевалив за отметку нагрузки на CPU в 7000 CP. Тут реально в пору задуматься — что произошло и почему появилась такая большая нагрузка.

Читать еще:  Для данного отношения укажите домен атрибута количество

Я тогда с таким столкнулся впервые. Скажу сразу, что по итогу выяснил, что мой любимый трэвел-блог подвергся ddos-атаке, с которой я справился примерно за месяц. Я приобрел бесценный опыт, нашел доступные любому человеку способы анализа нагрузки на сервер, и пути борьбы с этим.

В итоге, я перенес свой блог на выделенный сервер находящийся в Голландии, и теперь сплю спокойно, зная, что мой блог никто не отключит. Потому что, какая бы не была ddos-атака, или иная ситуация, вызывающая чрезмерную нагрузку на сервер, теперь у меня собственный хостинг, созданный на виртуальной машине, на базе линукса. И если эта нагрузка вешает мой сайт, я нашел бесплатный сервис, который в течении 15 минут перегружает его, и он — любимый снова работает! Что позволяет мне спокойно путешествовать, по неделе не имея интернета, не волноваться, что мой блог упал и не работает.

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

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

Как выяснить откуда идет нагрузка? Я сам думал несколько дней — что делать, среди моих знакомых блоггеров никто не сталкивался с превышением стандартной нагрузки аж в 140 раз. Нашлось самое оптимальное решение, которое я рекомендую всем. Первым делом, для определения источника нагрузки, нужно просмотреть так называемые лог-файлы. На моем хостинге в панели управления их можно включить в разделе — Управление лог-файлами:

Если на вашем хостинге нет подобного раздела — то пишите в службу поддержки, они должны их включить и предоставить вам. Что такое лог-файлы? По-сути, это простой тестовой файл в который записываются все обращения из сети на ваш блог, выглядит этот файл примерно вот так:

Обычно если писать лог-файл за день, да еще и с атакой, то он может за 24 часа получиться очень весомых размеров до сотни мегабайт. Т.е. несколько тысяч строк, которые показаны выше. Как разобрать такой огромный файл? И как понять — где же источник нагрузки?
Для начала нужно уметь прочесть каждую строку нашего лог-файла, вот возьмем к примеру такую строку:

Сначала показан домен моего блога, далее цифры «91.221.60.82» — это IP-адрес, с которого пришел запрос, далее показан путь самого запроса, в данном случае обращение к графическому файлу pix.png, далее идет код ответа моего сайта — 404 (в данном случае ошибка — страница не найдена). Дальше, можно узнать сведения из какого броузера пришел запрос и какое устройство использовалось для входа в интернет.

Для анализа лог-файлов самые важные данные в этой строке: путь запроса, код ответа сервера. Именно эти данные помогут понять — что происходит и что с этим делать, а IP-адрес может нам пригодится для того, чтобы блокировать нежелательные для нашего сайта запросы.

Это простая теория, а как же разглядеть и понять — что происходит на сайте, если таких строк может быть несколько тысяч в день? Я сам пару дней думал над этим вопросом. Ведь, даже имея аналитический склад ума трудно увидеть в тысячах строк какие-то закономерности. Тут мне на помощь пришла забавная программа для анализа лог-файлов.

Забавна она тем, что в отличии от подобных программ, выглядит в виде старинной электронной игры — и графически показывает каждое из этих тысяч обращений на сервер в реальном времени. Т.е. скачав свой лог-файл и запустив его в этой программе, вы увидите — с каких IP приходят запросы, на какие пути они приходят чаще всего, и самое главное — какой ответ сервера эти запросы получают.

Запустив эту программу, я сразу понял, в чем причина моих проблем. Одни и те же IP долбили несуществующие картинки на моем блоге и получали в ответ очень не хороший отклик — 404 (ошибка на сервере). И этих запросов было по 5-10 в несколько секунд, отсюда и превышение нагрузки на сервер в 140 раз. Данная программа называется логстальгия и выглядит вот так:

В левом верхнем углу показано реальное серверное время и дата, слева вылетают шарики (запросы от определенных IP) и летят направо в сторону определенных путей сайта. И эти шарики отбивает бита, которая символизирует сам сервер. При каждом отбитии шарика показывается код ответа сервера, на данном рисунке 200 (ответ — ок). Если к примеру происходит ошибка 404 или любой другой не очень хороший ответ сервера, то шарик не улетает в обратную сторону, а улетает вправо, как раз и создавая нагрузку на сервер. Программа бесплатная и скачать ее можно прямо здесь — logstalgia-1.0.3.win32.

Внизу программы есть временная строка, где можно спокойно переместится в любое время этой записи, или поставить на паузу пробелом. Конечно, без наглядного пособия трудно понять о чем я сейчас пытаюсь написать. Но, если вы столкнетесь с чрезмерной нагрузкой на сервер, то прочтете пару раз, и поймете. Программа, которую я выложил выше, мне лично, очень сильно помогла понять, что вообще происходит. Надеюсь и вам она тоже поможет!

На этом на сегодня всё, постараюсь почаще выходить на связь, поэтому, продолжение этой серии статей следует…

По традиции пару слов о себе и своей путешествующей семье. Мы прилетели на любимый остров Бали, настроили здесь свой быт и теперь можем и отдыхать и работать! Шлю вам балийский привет!

Я и дочь в нашем традиционном балийском доме

Если у Вас есть свои решения, дополнения — как бороться с нагрузкой создаваемой сайтом, пишите в комментариях, обмен опытом еще никому не вредил!

Что такое «разрешенная статистическая нагрузка СР» на хостинге и как выбрать необходимое значение

Содержание статьи

  • Что такое «разрешенная статистическая нагрузка СР» на хостинге и как выбрать необходимое значение
  • Как правильно выбрать вид хостинга для сайта
  • Как регистрация в каталогах статей влияет на сайт

Что такое CP и CPU?

Итак, вы заканчиваете работу над своим сайтом и готовитесь приступить к следующему шагу — переносу его с локального сервера своего компьютера на хостинг. При выборе тарифного плана вы обнаружили загадочную фразу: «Разрешённая нагрузка 65 CP в день». Как вычисляется данный параметр? А самое главное, максимальная нагрузка 65 CP — это много или мало?

CP (cpu points) — это величина, показывающая количество времени, потраченного процессором на обработку поставленных задач. Обычно на хостинге указывают два параметра: нагрузка на центральный процессор (CPUCentral Processing Unit) веб-сервера и сервера баз данных (MySQL).

Нагрузка на CPU веб-сервера

СP показывает количество времени в минутах, затраченное на выполнение всех процессов клиента (клиентского оборудования). Например, 0,2cp означает, что время работы процессора составило 0,2 минуты (т.е. 12 секунд). Полученные в течении каждого часа данные всех клиентов складываются и заносятся в базу данных. Если полученное число превысит установленное провайдером допустимое значение, то в следующий период (час) все процессы будут работать с пониженным приоритетом. Что бы узнать допустимое максимальное значение, необходимо разрешенную нагрузку разделить на 24. Таким образом, если на хостинге этот параметр составляет 65ср, то получается 65/24 = 2,708cp в час. Это значит, что если суммарное время выполнения процессов всех клиентов составит более 2 мин. 43 сек., в следующий час приоритет будет снижен.

Измерение указанных значений производится системой Process accounting в ОС Linux; данные выводятся на панель управления хостингом (не путать с панелью управления сайтом).

Нагрузка на CPU сервера MySQL

В данном случае CP измеряется не в минутах, а в секундах. Фраза «разрешённая нагрузка 2500 CP для MySQL в день» означает, что допустимая суммарная нагрузка за день составляет 41 мин. 40 сек., но не более 1 мин.44 сек. в час.

От чего зависит CP?

Величина CP зависит от многих причин: тематики и посещаемости сайта, его настроек, наличия модулей и т.д. Чем больше востребованы пользователями материалы сайта, тем выше его посещаемость. Нельзя просто так оценить нагрузку, которую будет создавать сайт на сервер, можно только назвать прогнозируемое значение, причем лишь после детального изучения его страниц.

Какую допустимую нагрузку выбрать начинающему веб-программисту?

В большинстве случаев для первого сайта вполне достаточно того минимума, который предлагают самые простые тарифные планы хостинга. После индексации страницы сайта появятся в выдаче поисковиков; количество пользователей будет постепенно увеличиваться, а значит, возрастет нагрузка на сервер. С этого момента нужно периодически просматривать графики статической нагрузки, обычно представленные на основной странице панели управления хостингом в виде диаграммы. Если показатели приблизятся к критическим, необходимо либо поменять тарифный план, либо увеличить суточный лимит (зависит от условий, определяемых провайдером).

Ссылка на основную публикацию
Adblock
detector
×
×