Pull to refresh
74.34

Как выбрать по-настоящему хороший хостинг

Reading time 9 min
Views 48K
Почти на каждом сайте разработчиков платных тиражных CMS есть раздел «Сертифицированные хостинг-провайдеры», или «Рекомендуемые хостинги», или просто «Хостинги».



Разработчик CMS проверяет соответствие характеристик тестового тарифа, предоставленного хостером, минимальным техническим требованиям своей CMS. В идеале – устанавливает на этом тестовом тарифе свою систему и выполняет базовые операции.

Хостинг-провайдер попадает в список протестированных (сертифицированных) хостеров… и – обычно – на этом все взаимодействие с ним и заканчивается.

В 2008-ом году мы шли по этому же пути. Некоторой (полезной – на наш взгляд) особенностью было то, что для успешной сертификации тарифов помимо собственно тестов требовалось прохождение двух наших онлайн-курсов («Установка и настройка» и «Конфигурирование») сотрудниками хостера. Это давало нашим клиентам некоторую гарантию того, в случае возникновения каких-либо проблем или вопросов на данном конкретном хостинге его сотрудники будут готовы оказать необходимую помощь.

Однако в конце 2010 года мы поняли, что настала пора что-то менять в нашем партнерстве с хостинг-провайдерами. И вот почему…
  • К 2010-му году наш каталог хостинг-партнеров насчитывал более 100 компаний. При этом каталог был простым списком, не было никакой системы рейтингования. Иначе говоря, такой каталог становился совершенно бесполезным для конечных клиентов, так как не давал никакой помощи в выборе подходящего хостера.
  • Не было актуализации данных. Простой пример: хостер А создавал новый тариф хостинга под названием «Битрикс», который показывал отличную производительность. Затем через полгода-год забивал новые серверы клиентами так, что все просто еле шевелилось… Но мы об этом, к сожалению, уже не знали.

Устранение именно этих ключевых недостатков (а также несколько дополнительных приятных фич, о которых – немного дальше) – главная цель нового каталога-рейтинга «Рекомендуемых хостингов», который мы открыли в этом году.

О том, как мы тестируем хостинги, на что обращаем особое внимание, что вообще нужно иметь в виду при выборе хостинга любому клиенту, — хотим рассказать вам сегодня.
  • Во-первых, мы сохранили все те требования к хостинг-провайдерам, которые существовали и раньше (соответствие тарифов техническим требованиям CMS, прохождение курсов сотрудниками хостера).
  • Во-вторых, для тестов тарифов теперь не только проверяется соответствие формальным требованиям, но еще делается «живая» установка демо-сайта, для того, чтобы сделать замеры скорости работы с помощью «монитора производительности».
  • В-третьих, для каждого тарифа в каталоге осуществляется повторное тестирование каждые 6 месяцев.


Для расчета позиции хостера в рейтинге мы придумали вот такую формулу:



Остановлюсь на ней подробнее.

С тестовым периодом — все понятно. Наличие «простой установки» — это возможность инсталляции продуктов «1С-Битрикс» непосредственно из панели управления хостингом или же с помощью предустановленного скрипта bitrixsetup.php.

Основным критерием для определения позиции хостера в рейтинге стало соотношение «производительность / цена».

Параметр «цена» был добавлен очень осознанно. За последние годы сложилась нехорошая практика у хостинг-провайдеров: «Мы берем стандартные тарифы хостинга, немного тюним на них параметры, дописываем слово «Битрикс» и вешаем ценник в полтора-два раза больше обычного. Клиент купил CMS, купит и хостинг!»

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

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

Для замеров мы используем возможности стандартного модуля платформы «1С-Битрикс» — «Монитор производительности».



Вкладка «Конфигурация» отвечает за диагностику хостинга или сервера и настроек серверого ПО, вкладка «Битрикс» — те настройки самой платформы, которые могут влиять на производительность, «Разработка» — качество кода разработчика, «Масштабируемость» — простой встроенный инструмент для проведения простейших нагрузочных тестов.

Самый интересный для нас раздел – «Конфигурация». Именно им мы и пользовались, тестируя хостеров.

Один из самых частых вопросов, на который нам приходилось отвечать: «Как мы можем верить вашей измерялке, если она меряет производительность в каких-то непонятных «попугаях»? Почему у нас на мощном железе получаются низкие цифры? Ваша формула врет!»

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

Такой формулы нет! :)

Как работает монитор производительности

Мы запрашиваем несколько раз (10, если быть точными) некоторую системную страницу, на которой загружается только ядро продукта. По результатам 10 замеров оцениваем среднее время генерации этой страницы (именно серверное, а не время передачи страницы клиенту). Именно эта цифра есть «среднее время отклика». А общий итоговый индекс – это обратная величина. В нашем случае – 1/0.0137. Иными словами, на нашем тестовом хостинге за 1 секунду может быть сгенерировано 72 «пустые» (только с ядром) страницы.

Именно эта величина важна, так как для клиента имеет значение именно то, с какой скоростью открывается его сайт (генерируются страницы), а не каждый параметр по отдельности. Они указываются скорее для того, чтобы системный администратор (или даже просто опытный пользователь) мог быстрее и проще определить, где в его системе «узкие» места.

(Более подробно о работе монитора производительности можно прочитать в блоге Дениса Шаромова, руководителя службы технической поддержки «1С-Битрикс»)

С формулой разобрались и возвращаемся к нашим тестам.

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

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

PHP как CGI

PHP, запускаемый как CGI (не FastCGI!) – страшный атавизм. Быть такого не должно.

Чем такая схема плоха. Если в двух словах – на каждое обращение к php-скрипту запускается новый процесс интерпретатора PHP. Все это работает очень медленно, производительность сайта (любого сайта, написанного на PHP, не только на платформе «1С-Битрикс») будет крайне низкой.

Такие конфигурации, к счастью, встречаются все реже (за последние полгода в реальной жизни мы с таким не сталкивались), но, тем не менее, пока еще существуют.

Включенный параметр open_basedir в конфигурации PHP

Наверное, все знают, за что отвечает этот параметр – ограничивает «область видимости» файлов и директорий, которыми может оперировать PHP.

Многие хостеры включают этот параметр на виртуальном shared хостинге в целях обеспечения безопасности пользовательских данных (ограничивая доступ других пользователей на том же сервере).

Но далеко не все знают, что включение этого параметра снижает производительность PHP на 10-40%, а на нагруженных системах (особенно с большим количеством дисковых операций) – до 2-3 раз!



Смотрите, вот – тот же самый сервер, на котором выполнялся тест, показанный выше, но только с включенным open_basedir. Скорость генерации страниц снизилась почти в полтора раза. Мы видим, что конфигурация PHP отмечена «неоптимальной», а по ссылке «рекомендации» можно подробно прочитать о том, где именно возникают проблемы.

Нам повезло, на этом конкретном хостинге мы можем управлять этим параметром в PHP. А на многих хостингах это – неотключаемо ни при каких условиях.

Многие хостеры возражают нам: «Ну, сами понимаете, на шаред хостинге отключить это невозможно… Иначе будут проблемы с безопасностью.»

Это утверждение неверно. Соблюсти баланс безопасности и производительности можно самыми разными методами: начиная с запуска персональных копий веб-сервера (например, тот же Apache) для разных пользователей, заканчивая использованием FastCGI через php-fpm. Кстати, разные хостеры в нашем рейтинге используют и тот, и другой вариант.

Отмечу еще раз: данная особенность работы open_basedir присуща PHP вообще и всем проектам, написанным на этом языке, а не только платформе «1С-Битрикс» (попробуйте поискать, например, в Google «open_basedir performance»). Если ваш сайт на WordPress, Joomla, Drupal и любой другой CMS на PHP – обращайте на это внимание.

Не установлен прекомпилятор PHP

Еще один враг производительности – отсутствие на хостинге предустановленного прекомпилятора для PHP. Их существует достаточно много (APC, eAccelerator, XCache и т.п.), и все они выполняют примерно одну и ту же работу – ускоряют работу PHP, прекомпилируя интерпретируемый код. В зависимости от конкретного прекомпилятора, его настроек (например, количество доступной памяти), кода проекта прирост производительности может достигать нескольких раз.

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

На наше счастье, мы проделываем все эти операции на том хостинге, где мы все можем настроить «так, как нужно» и в итоге получить хороший (быстрый!) хостинг. На многих хостингах, к сожалению, набор изменяемых пользователем опций строго фиксирован, и добиться хороших результатов (кроме как – поменять хостинг) не представляется возможным.

Вернемся к цифрам:



Обратите внимание, параметры сервера (CPU, дисковые операции), базы данных практически не изменяются (естественно!), а, вот, правильная конфигурация PHP решает все.

Конечно, мы перечислили далеко не все вещи, которые влияют на производительность. Помимо собственно настроек PHP, имеют значение очень многие параметры конфигурации базы, правильно настроенные параметры веб-сервера, грамотно спроектированная двухуровневая (frontend+backend) архитектура…

Бывают хостинги (к сожалению, совершенно реальные), на которых плохо просто все, и тогда получается вот такой «трэш и угар»:



А на хорошем мощном железе, быстрых SAS-дисках, и при грамотных настройках – сайт просто «летает» (скриншот с реального, а не «сферического в вакууме» shared хостинга):



* * *

Еще один аспект, который хоть и не описан в формальных требованиях к хостерам, которые хотят пройти сертификацию «1С-Битрикс», но на который мы обязательно обращаем внимание – безопасность. Откровенно «дырявые» хостинги никогда не получают наши значки «Сертифицированный хостинг» и «Рекомендуемый хостинг».



Самая частая проблема – open_basedir выключили, но никаких других средств изоляции пользователей не придумали. Что в итоге получается: все клиенты хостинга работают с одним и тем же веб-сервером, процессы которого запущены под одним системным пользователем (иногда это бывает даже root).

В итоге каждый пользователь может «видеть» не только свои файлы и директории, но и данные других пользователей.

Простейшие проверки можно выполнить в административном интерфейсе «1С-Битрикс»:



Среди крупных известных хостеров мы, конечно, подобных откровенных «дыр» не нашли, но среди тех, у кого несколько десятков/сотен клиентов – сплошь и рядом.

Будьте внимательны и бдительны при выборе хостинга.

И если описанная выше проблема достаточно типична, то бывают и настолько безалаберные «хостеры», которые вызывают искреннее удивление – как они смогли привлечь хоть одного клиента.

Пара самых ярких примеров на нашей памяти.

Хостер У (потому что на Украине)

Получили тестовый аккаунт, поставили демо-сайт — интернет-магазин на редакции «Малый бизнес» (мы все хостинги тестируем для единообразия именно этой редакцией). Сделали через веб-интерфейс «ls –la /tmp»… и увидели несколько десятков файлов вида «login.txt», в которых хранились все параметры доступа к FTP, SSH, MySQL всех пользователей хостинга.

Хостер К (в Казахстане).

Стандартная процедура, тестовый аккаунт. Все неплохо с производительностью и (на первый взгляд) с безопасностью.

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

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

* * *

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

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

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

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

Наш рейтинг хостеров мы будем активно развивать и, надеюсь, со временем сделаем отличный объективный рейтинг хостинга вообще, а не только «special for bitrix». Почему бы и нет? :)

С уважением, Александр Демидов
руководитель направления арендных решений «1С-Битрикс»
Tags:
Hubs:
+26
Comments 97
Comments Comments 97

Articles

Information

Website
www.bitrix24.ru
Registered
Founded
2012
Employees
201–500 employees
Location
Россия
Representative