«Динамим» свой сайт

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

Итак, начнем.

 

 

Первый вопрос, который возникает сразу после появления идеи создать динамический сайт — это выбор платформы, СУБД, веб-сервера и языка программирования.

По поводу платформы и сервера я придерживаюсь традиционного мнения, что ничего лучше сочетания freeBSD + Apache еще не придумали. Не буду ни на чем настаивать и вступать в дискуссии — я заранее согласен с мнениями, что у меня просто руки кривые и я не могу грамотно настроить NT + IIS (я действительно не очень много возился с подобным сочетанием), но все мои (да и не только мои) эксперименты показали, что BSD и Apache намного устойчивее и производительнее. Линукс тоже неплох, но по мнению админов, использующих его под большой нагрузкой, — там требуется очень тщательная настройка (сам я веб-сервер на Линуксе никогда не поднимал, если не считать маленького сервера для тестирования интранет-сайта, но там нагрузка была почти нулевая). С другими версиями UNIX я вообще никогда не сталкивался, так что ничего умного не скажу.

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

Выбор СУБД — штука очень ответственная. Миграция баз данных занятие весьма неприятное и требующее кучи усилий и знаний, так что этому вопросу (выбору, а не миграции) стоит посвятить побольше времени. Разумеется, основным критерием тут является ваш программист — какую систему он знает лучше, ту и стоит использовать. Хотя стоит учитывать и объективные параметры...

Увы, специалистом в базах данных я тоже не являюсь. Знаю, что для больших промышленных систем обычно используют Oracle, но никогда с ним не работал. А для сайтов «младшего и среднего класса» наиболее популярными являются MySQL и PostgreSQL. Вопрос о преимуществах этих баз друг перед другом в Сети встречается очень часто, поэтому попробую кратко высказать свое мнение (опять же не претендующее на объективность и полноту).

Обе базы сравнительно просты в установке и настройке, но у Postgres'а настроек побольше и, соответственно, для его «доведения до ума» потребуется больше усилий. Хотя на относительно небольших сайтах и та и другая СУБД будут без проблем работать с настройками по умолчанию. У PostgreSQL больше «продвинутых» функций, которые сильно облегчают жизнь, например, JOIN, VIEW и т.п. MySQL очень хорошо и быстро работает с простыми выборками (SELECT), но значительно быстрее «ложится» если в таблицу часто что-то пишется: при записи блокируется вся таблица, а не одна строка, как в Postgres'е. Устойчивость обоих СУБД примерно одинакова (хотя, пожалуй, PostgreSQL лучше восстанавливается при возникновении проблем, но если уж он не смог восстановиться, то проблемы теперь у вас!). Недостатком Postgres'а можно считать сравнительно большое время, которое он тратит на установление соединения с клиентом, но при использовании persistent connections (т.е. подключений, которые не закрываются при окончании работы скрипта) этот недостаток исчезает.

В целом обе СУБД активно двигаются навстречу друг другу — Postgres увеличивает производительность (что весьма заметно при выходе новых версий), а MySQL добавляет функциональности, стараясь при этом не слишком затормозиться. В моих экспериментах Postgres вел себя более устойчиво при повышенной нагрузке, и в сочетании с более развитой функциональностью это подвигло меня сделать выбор в его пользу, когда я переводил ListSoft на динамическую работу. На сайте MySQL, впрочем, есть таблицы сравнения функциональности и производительности разных СУБД в которых ясно показано, что MySQL (разумеется) превосходит всех конкурентов. Так что настаивать не буду...

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

Выбор языка не особо критичен — как правило, значительно больше времени тратится на получение результата от базы данных, чем на его обработку и выдачу клиенту, поэтому ориентируйтесь на тот язык, на котором вам удобнее писать. В принципе, PHP сейчас развивается очень быстро и обладает кучей полезных возможностей, ориентированных именно на программирование для WWW. Так что, возможно, будет удобно начать с написания скриптов на нем, а потом переписывать критичные классы, скажем, на «Си» (если таковые найдутся).

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

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

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

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

— Памяти много не бывает. А если учесть, что сейчас она весьма подешевела, то экономить на ней не стоит — все равно много не наэкономите...
— Два слабых процессора работают лучше, чем один мощный (естественно, в разумных пределах!) и обходятся дешевле. Дело в том, что все серверные ОС умеют работать на многопроцессорных системах, а специфика веб-сервера заключается в том, что на нем запускается и работает много Апачей (и столько же Постгресов). Такие работы очень хорошо распараллеливаются...
— IDE диски — слишком медленные для напряженной работы с базами данных. Используйте SCSI. Правда они дорогие... Но быстрые... В принципе, можно использовать один SCSI (для базы, сервера, и скриптов) и один IDE — для бэкапов базы, логов и прочих «неспешных» вещей.
— Сервер работает круглосуточно и достаточно напряженно. Следовательно, не переходит в «спящий режим», следовательно сильно греется. Не забудьте купить дополнительный вентилятор, а то и два. Заодно поставьте утилитку, которая будет заниматься слежением за температурой и скоростью вращения вентиляторов и настройте ее на отправку вам тревожных сообщений, если что-то выходит за заданные рамки. А чтобы все это работало проследите еще. чтобы блок питания обладал достаточной мощностью.
— Перед покупкой железа не забудьте узнать у провайдера какой корпус нужен — тот, который монтируется в стойку, или обычный. Многие на этом «прокалываются»...
— Обязательно узнайте телефон «серверной комнаты» и кто там дежурит — если вдруг сервер зависнет и не будет пускать вас, то надо будет, чтобы кто-то нажал кнопку Reset...

Теперь, когда железо готово, пора ставить софт. Подумайте о следующих вещах:

— X-server — штука прожорливая, и вряд ли вы будете использовать GUI на сервере. SSH вполне достаточно.
— При настройке предусмотрите небольшой RAM-диск. Его очень удобно использовать для разнообразных временных файлов.
— Настраивая Апач, не забудьте про mod_deflate и mod_bwshare — очень помогает...
— В настройках СУБД отдайте ей побольше shared memory. Чем больше данных находится в кэше, тем быстрее все работает. Тут-то вам и пригодится память из предыдущего раздела! Грамотная настройка этого параметра позволяет увеличить производительность Постгреса (и, скорее всего, других СУБД тоже) в несколько раз. Пока я до этого дошел — успел несколько раз столкнуться с «затыками» базы... К сожалению, настройка подобных параметров практически не алгоритмизуется — приходится действовать «методом тыка».
— Для большинства сайтов можно безопасно отключить принудительную запись каждого изменения базы на диск (fsync). Пусть кешируются и пишутся постепенно. Времени экономится много, а возможные неприятности ограничены потерей нескольких последних записей и откатом транзакции. Разумеется, это индивидуально для каждого сайта — для банковских приложений такое поведение наверняка неприемлемо...
— Регулярно запускайте top, vmstat, iostat и pstat — поможет обнаружить «узкие места» еще до того, как они проявятся «во всей красе». Пренебрежение этим советом как-то стоило мне пары дней простоя сервера...
— Не забывайте про бэкапы! Насколько часто их делать зависит от ваших нужд, но делать надо. Бэкап на втором винчестере страхует не только от «софтовых» сбоев, но и от физической поломки диска. Копии бэкапов на CD тоже не помешают...
— Я надеюсь, что в своих скриптах вы предусмотрели отправку вам сообщений на e-mail и мобильный телефон о том, что не удается подключиться к базе, упал Апач и т.д. и т.п. Надеюсь также, что вы предусмотрели периодическую проверку наличия всех нужных процессов и их перезапуск, если вдруг они померли. Но увы, это не поможет, если, скажем, у вашего сервера сгорел блок питания... Поэтому договоритесь с кем-нибудь о регулярной проверке работы вашего сервера и отправке вам сообщения, если он не отвечает. Теоретически можно использовать банальный ping, но еще лучше, чтобы ваш сервер отправлял сообщения на сервер вашего партнера — это поможет подать вам сигнал если сервер окажется перегружен и куча процессов скопилась в очереди на выполнение (меня уже несколько раз выручало).
— Если вы не собираетесь подключаться к своей базе по сети (скажем, из офиса) — запретите такие подключения на сервере. Если собираетесь — ограничьте диапазон адресов. Лучше перебдеть, чем недобдеть...
— Очень многие функции — в частности, обсчет статистики — весьма ресурсоемки. Их вполне безболезненно можно сделать «квазидинамическими» — т.е. пересчитывать не при каждом просмотре пользователем страницы, а, скажем, раз в 10-20-30 минут и писать результаты в файл (помните про RAM-диск?) или базу...
— Многие скрипты, прекрасно работающие при тестировании в офисе, мгновенно (или, что хуже, постепенно) «ложатся» под «промышленной нагрузкой». Уделяйте этому внимание во время тестирования и оставляйте резервные копии старых, опробованных скриптов, чтобы к ним можно было быстро откатиться... На эти «грабли» я, увы, наступал неоднократно — причем «затыки» вызывались самыми непредсказуемыми вещами...
— Как правило, процентов 80-90 работы сервера заключается в выполнении всего нескольких скриптов. Именно их и надо оптимизировать в первую очередь. Удобным методом вычисления таких скриптов является банальная запись в файл имени вызываемой функции (каждой вызываемой функции!) и времени ее работы. Проанализировав этот файл вы сможете достаточно ясно увидеть чем следует заняться в первую очередь. Этот же метод очень удобно использовать для оптимизации SQL запросов... Методику эту я придумал сам, когда пытался понять почему сервер работает с повышенной нагрузкой, впрочем, я более чем уверен, что она совсем не нова и это был всего лишь очередной свежеизобретенный велосипед... Но его использование позволило мне совершить немало очень интересных открытий в плане того, чем же занимается сервер, так что очень рекомендую... Кстати, перенумеровать все SQL запросы более эффективно, чем пытаться пропарсить лог-файл СУБД — многие запросы очень похожи (или просто одинаковы) и из лога сложно понять какой именно скрипт их выдал...

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

Ссылки по теме

• Статья «Нужен хостинг для ма-а-а-аленького сайта...»
• Статья «Динамим» веб-страницы"

Статья получена: hostinfo.ru

загрузка...