Цель нашей компании - постоянно повышать качество предоставляемых нами услуг, отвечать всем требованиям и пожеланиям клиентов и создавать наиболее комфортные условия для сотрудничества с нами. Как результат мы хотим видеть всех наших клиентов довольными предоставляемыми услугами, сервисом и технической поддержкой.
На виртуальном хостинге существует важная проблема (скорее даже, особенность этого вида хостинга), которой уделяется большое внимание нашими специалистами, - создаваемая на сервер нагрузка. Дело в том, что на сервере виртуального хостинга расположены десятки клиентских аккаунтов, которые "делят" ресурсы физического сервера между собой. Очень требовательные к ресурсам сайты могут существенно повысить нагрузку на сервер, что очевидно скажется на других клиентах-"соседях". Для предупреждения проблем у нас существуют системы оповещения в реальном времени, собственная система мониторинга за состоянием сервисов, показывающие не только общее состояние сервера, но и логирующие причины возникновения тех или иных проблем. Таким образом, если вы получили предупреждение о нагрузке, создаваемой вашим сайтом на сервер виртуального хостинга - эта статья для вас! Ознакомившись с ней, вы будете иметь представление о возможных причинах возникновения нагрузки и методах их устранения.
Существует два основных способа создать нагрузку на сервер виртуального хостинга: нагрузка на процессор и нагрузка на сервер БД MySQL.
Нагрузка на процессор может создаваться по нескольким причинам. Обычно нагрузка на процессор создается скриптами, которые по каким-либо причинам слишком долго исполняются, что влечет за собой превышение лимитов, отведенных тарифным планом. В редких случаях нагрузка создается умышленно недоброжелателями: сюда входят DDoS атаки, флудинг и т.п.
Самый распространенный вопрос клиента:
Я продолжительное время не изменял скрипты и не обновлял сайт. Почему вдруг стала возникать нагрузка на сервер? Ответов может быть несколько:
Что делать, если вы действительно, не производя никаких изменений на сайте, получили от нас письмо с предупреждением о нагрузке?
В присылаемых письмах мы сообщаем, что именно создает нагрузку на сервер. Принимать меры следует в соответствии с указанными в полученном письме данными. Первое, что может создавать нагрузку - это поисковые системы.
Почему?
Потому, что поисковые системы при индексации вашего аккаунта посылают одновременно большое количество запросов вашему сайту, в связи с чем происходит подвисание каких-либо "несущих" скриптов вашего сайта.
Что делать?
Первым делом стоит посмотреть, сколько было совершено запросов к вашему сайту. Для этого вам необходимо авторизоваться на сервере, используя ssh клиент, и выполнить команду:
Также можно использовать вместо Yandex и www.google.com/bot.html идентификаторы других поисковых систем, узнать которые можно, обратившись в службу поддержки необходимой поисковой системы либо изучив лог доступа.
Вместо example.org необходимо написать имя домена, расположенного на вашем аккаунте и о котором вы желаете получить информацию; вместо 22/Oct/2008 необходимо указать текущую дату. Иногда можно посмотреть, сколько было выполнено поисковых запросов и за предыдущее число, это зависит от ротации (обнуления) логов доступа. Помимо этого, вы можете настроить в панели управления архивацию логов доступа в домашнюю директорию вашего аккаунта для дальнейшего изучения. Для этого необходимо перейти в раздел "Управление необработанными лог-файлами" Cpanel вашего хостинга и указать "Архивировать журналы в домашнем каталоге в конце каждого месяца", после этого сохранить изменения. Также для анализа логов доступа можно использовать различные программы анализа веб логов. Например, можно использовать программу WebLog Expert.
Если при проверке вы обнаружили, что число запросов от поисковых систем превышает 1500, то уже стоит принять меры по снижению нагрузки. Для этого необходимо сделать следующее:
задает таймаут в 10 секунд, чтобы робот яндекса следующий запрос задавал не ранее, чем через 10 сек.
Также можно добавить правила и для других роботов, например, для Google:
Запретить индексацию некоторых совсем не нужных каталогов, например, каталогов с картинками, административную часть сайта и т.д., можно так:
Таким же способом можно ограничить индексацию и для других поисковых систем.
Файл Sitemap - это файл с дополнительной информацией о страницах сайта, подлежащих индексации. С помощью файла Sitemap вы можете сообщить поисковику, какие страницы вашего сайта нужно индексировать, как часто обновляется информация на страницах, а также, индексация каких страниц наиболее важна.
Если вы используете какую-либо CMS систему, часто данные системы уже наделены необходимым функционалом (создания карты сайта). Вам остается его активировать и создать файл sitemap. Если же ваша система не поддерживает создания карты сайта, то можно использовать для этого специальные утилиты. Например, программный продукт от google, ориентированный специально на создание sitemap.
Если ваш сайт имеет не слишком много страниц - до 500, то можно использовать online генерацию sitemap.
Для того чтобы указать поисковикам созданную карту сайта, можно также добавить в robots.txt следующее:
Регулярное обновление/изменения скриптов также может вызвать нагрузку. Даже если изменения внесены незначительные, но вы все равно получили предупреждение о создаваемой вашими скриптами нагрузке, необходимо изучить логи ошибок вашего сайта и устранить ошибки, указанные в них. Если ошибки есть, но самостоятельно вы исправить их не можете, обратитесь к разработчикам вашего сайта. Наша компания подобные услуги не предоставляет.
Если в письмах о нагрузке мы сообщаем о том, что какой-либо скрипт был завершен принудительно системой, в связи с достижением лимита на использование процессора, то вам необходимо определить, при каких обстоятельствах это происходит. Обычно подобное происходит на CMS, где несущим файлом является index.php, через который осуществляется подгрузка всех модулей сайта и самого контента. В этом случае вам стоит проанализировать подключенные модули и, по возможности, отказаться от использования наиболее "тяжелых", отключив их в системе. Если принудительно завершенным файлом является не файл CMS, а любой другой файл вашей системы, то необходимо проанализировать код, содержащийся в нем. Возможно, где-то можно сократить вызовы функций, где-то упростить вычисления, где-то сделать запрос к базе "легче" и т.д. Возможно, какие-то участки кода вообще не имеют значения для генерации страницы, например, про них просто забыли, а они работают и используют ресурсы напрасно. Исследуйте код на наличие простых ошибок; бесконечная рекурсия SSI; условие, которое должно было бы ограничивать перебор миллиона вариантов, но не ограничивает из-за ошибки; вечный редирект mod_rewrite... Можете совсем отказаться от использования этого файла на сервере.
Если ваш сайт тратит много времени на генерацию страниц, а содержание страниц изменяется редко, то можно один раз сгенерировать страницу и сохранить её в файл, а при новых обращениях отдавать данные из этого файла - кэширование. Обычно данная функция уже встроена во многих CMS системах. Кэширование необходимо включить с максимальным временем жизни кэша.
Также существуют пользователи сети Интернет, которые выкачивают себе на локальный компьютер сайт полностью, для дальнейшего изучения. Подобные программы называют "оффлайки" или "качалки сайтов". Отличаются данные программы тем, что за короткое время полностью выкачивают сайт, при их работе, серверу дается сразу несколько запросов, потому, что загрузка сайта происходит в несколько потоков, как писалось выше, для быстрого закачивания. Против этих "проделок" созданы лимиты отдачи страниц. Данный метод был разработан и впервые применен Андреем Якушевым.
Если же после всех описанных методов нагрузка не снизилась (о ее наличии информируем мы), то, вероятно, ваш аккаунт исчерпал лимиты тарифного плана. Вам стоит задуматься о приобретении тарифного плана на уровень выше.
Если на вашем сайте используется какая-либо CMS система, то, как правило, в подобных системах работа с базами данных продумана до мелочей, но это не всегда является гарантией того, что нагрузки не будет. Как же это решить? Вы можете попытаться самостоятельно оптимизировать запросы к БД либо попросить разработчика сделать это. Также, какой бы совершенной ни была структура базы данных, рано или поздно она начнет создавать нагрузку на сервер. Это происходит из-за накопления различного "мусора" в базах данных, и тогда, когда не выполняется регулярная оптимизация, под которой понимается чистка "дыр" (дефрагментация), обновление статистики и сортировка индексов. Сделать это можно, авторизовавшись на сервере, используя ssh клиент, и выполнив команду:
Это следует делать как минимум раз в месяц.
Если же вы используете специально разработанный под ваши нужды сайт с собственной структурой баз данных, то в этом случае необходимо оптимизировать ваши запросы. Методы оптимизации в каждом случае могут быть свои и их множество. Рассмотрим самые распространенные примеры и ошибки, связанные с работой с базами данных в виде "симптом/ошибка - решение":
Нужно помнить, что при связи таблиц "один-ко многим" количество строк в выборке будет расти при каждом очередном JOIN'е. Для подобных случаев целесообразнее бывает разбить подобный запрос на несколько простых.
При создании запросов избегайте, по возможности, выборки всех полей. Перечислите только те поля, которые вам действительно нужны. Кроме этого, не забывайте про покрывающие индексы. Даже если вам не необходимы все поля в таблице, лучше их перечислить. Во-первых, воспринимать код становится легче; во-вторых, со временем количество столбцов в вашей таблице может увеличиваться, соответственно выборка также будет расти.
1. Выборки
Правило очень простое - чем меньше запросов, тем лучше (хотя из этого, как и из любого правила, есть исключения). Не забывайте про конструкцию IN(). Приведенный код можно написать одним запросом:
2. Вставки
Гораздо более эффективно "склеить" и выполнить один запрос:
3. Обновления
Иногда бывает нужно обновить несколько строк в одной таблице. Если обновляемое значение одинаковое, то все просто:
Если изменяемое значение для каждой записи разное, то это можно сделать таким запросом:
Наши тесты показывают, что такой запрос выполняется в 2-3 раза быстрее, чем несколько отдельных запросов.
В таком запросе индекс использоваться не будет, даже если столбец blogs_count проиндексирован. Для того чтобы индекс использовался, над проиндексированным полем в запросе не должно выполняться преобразований. Для подобных запросов выносите функции преобразования в другую часть:
Аналогичный пример:
не будет использовать индекс по полю registered, тогда как
будет.
Если вам нужно выбрать количество строк, удовлетворяющих определенному условию, используйте запрос
а не выбирайте все строки лишь для того, чтобы подсчитать их количество.
Если вам нужны только n строк выборки, используйте LIMIT, вместо того, чтобы отбрасывать лишние строки в приложении.
Если в таблице больше, чем 4-5 тысяч строк, то
Если в таблице auto_increment'ный первичный ключ и нет пропусков:
либо:
что, однако, также может выполняться долго при очень большом количестве строк в таблице.
Многие думают, что подобный запрос вернет $per_page записей (обычно 10-20) и поэтому сработает быстро. Он и сработает быстро для нескольких первых страниц. Но если количество записей велико, и нужно выполнить запрос
Подобную конструкцию можно заменить одним запросом, при условии наличия первичного или уникального ключа по полю id: