Выбирая хостинг для своего, возможно, будущего сайта, его разработчики почему-то часто не учитывают один момент: сайт будет расти. И то, что является вполне достаточным сегодня завтра окажется очень тесными рамками, а смена хостинга для действующего проекта — дело весьма сложное и неприятное. C другой стороны, очень не хочется покупать выделенный Oracle-сервер для размещения одностраничного прайс-листа... Как же найти «золотую середину»?
Для начала, постарайтесь максимально четко ответить на простой вопрос: зачем вам нужен сайт? Если ваш ответ сводится к банальному «чтобы было», то лучше не спешить — мусора в интернете и так много, так стоит ли добавлять еще? Значительно лучше и полезнее сначала все продумать и спланировать, а потом уже сделать...
Следующим этапом станет попытка представить свой идеал сайта — то есть как он должен выглядеть и что делать, если все пойдет именно так, как вы планируете. Теперь отбросьте явно нереальные фантазии из серии «найдется пара лишних миллионов и я обгоню Гугл», а оставшееся рассортируйте в порядке важности.
Вот теперь надо начинать записывать настоящие и будущие требования к хостингу.
По большому счету, параметров, на которые стоит обращать внимание, не так уж и много: размер дискового пространства, трафик, физическое размещение сервера, установленное ПО, ограничения по его использованию и железо. Про такую вещь, как надежность хостинга (uptime) и резервное копирование ваших данных на случай сбоев можно и не говорить. Это вещи принципиальные.
Дисковое пространство. Этот параметр кажется не столь важным, особенно, если сайт только-только запускается и потому занимает мало места. Но тут очень легко ошибиться. Во-первых, обратите внимание на логи, которые имеют тенденцию расти очень быстро, особенно у популярных сайтов.
Во-вторых, если вы предоставите пользователям возможность загружать файлы к вам (например, для обмена), то место опять-таки будет съедаться очень быстро. В-третьих, такие вещи как форумы, особенно популярные, являются весьма прожорливыми. В сущности, есть много вещей, способных исчерпать все доступное место на диске. Поэтому стоит сразу же узнать сколько будет стоить превышение дисковой квоты и возможно ли ее увеличение при необходимости.
Трафик. Еще один очень важный параметр. Для начала, попробуем оценить средний трафик сайта. Предположим, что средний размер вашей страницы 200 Кб, пользователь в среднем смотрит 4 страницы и на сайт к вам заходит 500 человек в день. Просто перемножаем эти цифры и получаем трафик. Возможные ловушки здесь заключаются в том, что трафик распределяется неравномерно, а хостер может выставлять ограничения на дневной или месячный трафик. Предположим, что какое-то популярное издание напишет о вашем сайте. Вы получите очень резкое увеличение числа посетителей в течение одного-двух дней, причем такой пик вполне способен «сожрать» весь ваш месячный лимит. Поэтому, выбирая хостера стоит поинтересоваться во-первых, сколько стоит превышение трафика, а во-вторых, что происходит если вы лимит превышаете. Варианты могут быть самые разные. Некоторые провайдеры считают трафик за день и как только вы лимит выбрали, сайт блокируется. Другие — считают трафик за месяц (что позволяет выдержать небольшие пики посещаемости, но может и сильно подвести, если эти пики выберут весь лимит — до конца месяца ваш сайт окажется заблокированным). Большинство же провайдеров просто выставят вам дополнительный счет, но т.к. превышение трафика обычно стоит довольно дорого, то иногда имеет смысл брать тарифный план с запасом.
Кстати, не забудьте убедиться, что веб-сервер настроен на отдачу сжатых веб страниц (все современные браузеры умеют понимать и принимать заархивированные веб-страницы и разархивировать их уже на компьютере «получателя»). Это позволяет одновременно и снизить трафик (текст, из которого и состоят веб-страницы очень хорошо архивируется) и увеличить «видимую» скорость сервера (сжатые страницы передаются быстрее благодаря маленькому размеру).
Физическое размещение сервера. Тут стоит ориентироваться на посетителей — в большинстве случаев, чем ближе (физически) находится сервер, тем быстрее доступ к нему и меньше вероятность каких-то задержек. В то же время, если сервер от вас далеко, то его сложнее обновлять — все из-за тех же задержек. Поэтому выбирая хостинг стоит протестировать насколько хорошо сервер «виден» вам и вашим будущим посетителям — для этого существует утилита traceroute (в Windows — tracert.exe).
Установленное ПО. Этот параметр исключительно важен при развитии сайта. К нему относится то, какая операционная система установлена на сервере, какой веб-сервер используется, какие дополнительные модули установлены, какие языки программирования поддерживаются, какие СУБД... Разумеется, эти данные в первую очередь нужны веб-мастеру, который программирует ваш сайт, но ведь он знает только ваши текущие требования и не имеет представления о планах развития. В отношении программного обеспечения какие-либо советы давать сложнее всего — тут слишком многое зависит от личных пристрастий, но можно отметить несколько универсальных моментов.
Поддержка какого-либо скриптового языка является необходимой для любого сколько-нибудь серьезного проекта. Скрипты вам потребуются для самых разных нужд — начиная с банального счетчика и заканчивая авторизацией пользователей, так что хостинг, не предоставляющий такой возможности можно вообще не рассматривать.
Поддержка баз данных нужна для динамических сайтов. Разумеется, можно выкрутиться записывая данные в файлы, но при усложнении проекта это станет достаточно серьезным ограничением, поэтому если у вас в планах развития сайта намечается какая-то динамика и интерактивность, а планируемая посещаемость сайта превышает сотню человек в день, то БД можно считать необходимой.
Популярность используемого программного обеспечения очень поможет избежать «изобретения велосипедов». В Сети есть много архивов готовых скриптов, которые (возможно, с некоторой модификацией) удобно использовать на своем сайте, вместо того, чтобы писать новые. Но если ваш хостер поддерживает только какие-то экзотичные комбинации, то и скриптов, для них подходящих, найдется не так много! В принципе, стандартом де-факто можно считать сочентание PHP + MySQL — для него проще всего будет получить консультацию в Сети или подобрать готовый скрипт. Впрочем, поддержку Perl’а тоже не стоит сбрасывать со счетов — все-таки это один из наиболее распространенных языков, для которого скрипты и книжки писались много лет...
Ограничения на использование ПО — еще один важный параметр. Естественно, относится он только к виртуальному хостингу. Итак, ограничения. Они могут быть самыми разными — начиная с загрузки процессора и максимального времени работы скриптов, и заканчивая размером базы данных. Тут, увы, вообще невозможно сказать что-либо определенное, т.к. потребности в тех или иных ресурсах очень сильно зависят от сайта. Впрочем, есть два универсальных момента: с одной стороны, любые ограничения рано или поздно начнут вас тормозить, а с другой — нет такого скрипта, который нельзя было бы оптимизировать... Поэтому, выбирая хостинг просто посмотрите, где ограничений меньше, и обсудите с хостером возможности плавной смены тарифного плана на тот, который дает большую свободу, если встретите ограничения.
Железо. По большому счету, на виртуальном хостинге железо вас интересовать не должно. И в большинстве случаев вы с подобными проблемами не столкнетесь — у хостера работают профессионалы и сервера собирают грамотно. Но все же если планируемый сайт отличается от «среднестатистического», то имеет смысл с хостером проконсультироваться. Например, если предполагается полностью динамический и популярный ресурс, работающий с большой базой данных, то можно обратить особое внимание на скорость обмена с диском. Теоретически можно столкнуться и с нехваткой скорости процессора, если ваши скрипты производят какие-то сложные вычисления, но в достаточно редких случаях. Впрочем, если в развитии своего сайта вы дошли до таких экстремальных случаев, то вам пора задуматься о выделенном сервере.
Вот и все. Теперь осталось только пару дней помучать хостера вопросами, после чего торжественно разместить на сервере тот index.html, ради которого все и затевалось.