Библиотека Интернет Индустрии I2R.ru

Для начала постарайтесь максимально четко ответить на простой вопрос: зачем вам нужен сайт? Если ваш ответ сводится к банальному "чтобы было", то лучше не спешить - мусора в Интернете и так много, так стоит ли добавлять еще? Значительно лучше и полезнее сначала все продумать и спланировать, а потом уже сделать...

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

Вот теперь надо начинать записывать настоящие и будущие требования к хостингу.

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

Дисковое пространство. Этот параметр кажется не столь важным, особенно если сайт только-только запускается и потому занимает мало места. Но тут очень легко "нарваться". Во-первых, лог-файлы, которые имеют тенденцию расти очень быстро, особенно у популярных сайтов. Во-вторых, если вы предоставите пользователям возможность загружать файлы к вам (например, для обмена), то место опять-таки будет съедаться очень быстро. В-третьих, такие вещи, как форумы, особенно популярные, являются весьма прожорливыми. Да и мало ли что еще... Поэтому стоит сразу же узнать, сколько будет стоить превышение дисковой квоты и возможно ли ее увеличение при необходимости (я как-то нарвался на хостера, который наотрез отказался дать мне лишнюю сотню мегабайт диска)...

Трафик. Еще один очень важный параметр. Для начала попробуем оценить средний трафик сайта. Предположим, что средний размер вашей страницы 20 кб, пользователь в среднем смотрит 4 страницы, и на сайт к вам заходит 500 человек в день. Просто перемножаем эти цифры и получаем трафик чуть больше 1 Гб в месяц. Возможные ловушки здесь заключаются в том, что трафик распределяется неравномерно, а хостер может выставлять ограничения на дневной или месячный трафик. Предположим, что какое-то популярное издание напишет о вашем сайте. Вы получите очень резкое увеличение числа посетителей в течение одного-двух дней, причем такой пик вполне способен "сожрать" весь ваш месячный лимит. Поэтому, выбирая хостера, стоит поинтересоваться, во-первых, сколько стоит превышение трафика, а во-вторых, что происходит, если вы лимит превышаете. Варианты могут быть самые разные. Некоторые провайдеры считают трафик за день и, как только вы лимит выбрали, сайт блокируется. Другие считают трафик за месяц (что позволяет выдержать небольшие пики посещаемости, но может и сильно подвести, если эти пики выберут весь лимит - до конца месяца ваш сайт окажется заблокированным). Большинство же провайдеров просто выставят вам дополнительный счет, но т.к. превышение трафика обычно стоит довольно дорого, то иногда имеет смысл брать тарифный план с запасом.

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

Физическое размещение сервера. Тут стоит ориентироваться на посетителей - в большинстве случаев, чем ближе (физически) находится сервер, тем быстрее доступ к нему и меньше вероятность каких-то задержек. В то же время, если сервер от вас далеко, то его сложнее обновлять - все из-за тех же задержек. Поэтому, выбирая хостинг, стоит протестировать, насколько хорошо сервер "виден" вам и вашим будущим посетителям - для этого существует утилита traceroute (в Windows - tracert.exe).

Установленное ПО. Этот параметр исключительно важен при развитии сайта. К нему относится то, какая операционная система установлена на сервере, какой веб-сервер используется, какие дополнительные модули установлены, какие языки программирования поддерживаются, какие СУБД... Разумеется, эти данные в первую очередь нужны веб-мастеру, который программирует ваш сайт, но ведь он знает только ваши текущие требования и не имеет представления о планах развития! В отношении программного обеспечения какие-либо советы давать сложнее всего - тут слишком многое зависит от личных пристрастий, но можно отметить несколько универсальных моментов...

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

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

Популярность используемого программного обеспечения очень поможет избежать изобретения велосипедов. В Сети есть много архивов готовых скриптов, которые (возможно, с некоторой модификацией) удобно использовать на своем сайте вместо того, чтобы писать новые. Но если ваш хостер поддерживает только какие-то экзотичные комбинации, то и скриптов, для них подходящих, найдется не так много! В принципе, стандартом де-факто можно считать сочетание PHP + MySQL - для него проще всего будет получить консультацию в Сети или подобрать готовый скрипт. Впрочем, поддержку Perl'а тоже не стоит сбрасывать со счетов - все-таки, это один из наиболее распространенных языков, для которого скрипты и книжки писались много лет...

По поводу операционной системы ничего говорить не буду, чтобы не разжигать "религиозные войны", но недаром ведь freeBSD + Apache является наиболее распространенным сочетанием в Интернете... Хотя любители IIS мне тоже встречались...

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

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

Вот и все. Теперь осталось только пару дней помучать хостера вопросами, после чего торжественно разместить на сервере тот index.html, ради которого все и затевалось...