|
Продолжаем тему оптимизации работы веб-приложений. В данном разделе будут рассмотрены методы решения этой задачи в контексте первого из перечисленных в предыдущей части факторов. Речь пойдет о файловой системе.
Существует множество способов для того, чтобы повысить скорость выполнения файловых операций. Большинство из тех, которые будут описаны ниже, относятся к категории экстенсивных методов, т.е. основанных на внешних по отношению к веб-приложению средствах. В частности это относится к выбору железа и типа файловой системы, что актуально для систем, работающих на выделенных серверах.
Помимо этого так же будут рассмотрены общие подходы повышения эффективности работы веб-приложений, основанные на оптимизации их кода.
Выбор жестких дисков
В настоящее время распространены четыре основных разновидности HDD: IDE, SATA, SCSI и SAS (Serial Attached SCSI). Учитывая, что IDE уходят с рынка, и все идет к тому, что SAS постепенно заменит SCSI, выбор можно локализовать до двух вариантов — между SATA и SAS. Делать этот выбор стоит опираясь только на масштабы задачи, т.к. жесткие диски этих типов, строго говоря, не являются конкурентами из-за совершенно разного позиционирования.
/2007/12/01wd4000kd-pers.jpg) В качестве примера из жизни, можно привести тот факт, что на недорогие веб-серверы, которые можно арендовать за ~100$ в месяц, обычно ставят SATA. VPS/VDS хостинги тоже зачастую используют именно такие HDD. О той производительности, которую от них можно получить лучше всего основываясь именно на подобных конкретных внедрениях, тем более, что аппаратная конфигурация серверной площадки у большинства провайдеров не является тайной. Только после выполнения такого анализа можно выдать решение, достатона ли производительность SATA или стоит переплатить за SAS.
Существует так же промежуточное решение в виде винчестеров с SATA интерфейсом и повышенной производительностью. Например, WD Raptor с 10,000 rpm работает существенно быстрее обычных SATA дисков, но стоит при этом заметно дешевле SAS.
RAID
Для повышения производительности жестких дисков, их можно объединять в RAID массивы уровня 0 или 0+1 (другие распространенные уровни RAID предназначены только для повышения надежности хранения данных). Увеличение скорости обмена данными с HDD в обоих случаях основано на том, что чтение и запись происходит параллельно на два накопителя. Но в случае с RAID 0+1, дополнительно выполняется так же постоянное дублирование данных, для обеспечения безопасности от сбоев («зеркалирование»).
Для того, чтобы собрать массив RAID 0, понадобится как минимум два винчестера, а для RAID 0+1 — четыре (фактически это два массива RAID 0 — основной и дублирующий). На практике уровень RAID 0 крайне не рекомендуют использовать (в особенности на серверах) из-за отсутствия у него какой-либо отказоустойчивости. Дело даже не в том, что при «смерти» одного из жестких дисков данные со всего массива будут полностью утеряны, а в том, что при работе RAID 0 иногда случаются сбои, после которых какая-то часть данных может быт повреждена. Особенно это касается недорогих RAID контроллеров. Кроме того, массив RAID 0 менее удобен в обслуживании. Заменить жесткий диск в нем — не такая тривиальная операция, как может показаться.
Поэтому, если жестких бюджетных ограничений нет, гораздо лучше использовать массив RAID 0+1 из четырех HDD. Но если финансы не позволяют установить более двух винчестеров, все равно не стоит гнаться за скорость в ущерб надежности. Вместо RAID 0 лучше объединить их в RAID 1 (зеркальный дисковый массив), либо просто использовать по-отдельности.
/2007/12/02promise.thumbnail.jpg) Стоит так же учесть, что в большинстве случаев быстрые дисковые массивы целесообразно использовать для данных веб-сервера (т.е. для статических веб-документов, баз данных, файловых архивов, почты и т.п.), но операционную систему вообще лучше ставить не на RAID, а на отдельный диск. На RAID можно перенести только swap, файловый кэш (если он для чего-то используется) и прочие данные, требующие активного взаимодействия. И конечно же никакой RAID не отменяет необходимости в регулярном резервном копировании, но это уже совсем другая тема.
На фотографии — RAID контроллер средней ценовой категории Promise FastTrak TX4310 с возможностью объединения до 4 SATA жестких дисков в RAID уровней 0, 1, 0+1.
Файловая система
Как известно, идеальной файловой системы, одинакого пригодной на все случаи жизни, не существует. Но есть файловый системы, которые лучше других подходят для конкретных задач. И для того, чтобы выяснить, какую выбрать именно вам, необходимо четко осознавать потребности.
В том случае, если веб-сервер работает под Windows, особо выбирать не придется: альтернатив NTFS просто нет. Но если сервер работает на *nix, при первом взгляде на возможные варианты файловых систем разбегаются глаза: ext2, ext3, ReiserFS, XFS, JFS, и т.д. Я не стану углубляться в их сравнение и выделение положительных черт каждой из них, ограничусь лишь двумя, которых будет вполне достаточно для большинства случаев.
ext3 — одна из наиболее развитых и надежных файловых систем с возможностью журналирования. Многие дистрибутивы Linux при установке предлагают форматировать диски именно под нее. ext3 достаточно универсальна (годится для системного раздела, для хранения файлов баз данных, почты и других нужд), но ее отрицательной стороной является снижение производительности при работе с большим количеством файлов в одной директории.
ReiserFS (текущая версия — 4) — считается менее надежной и не обладает возможностью журналирования, но зато очень хорошо показывает себя при работе с большим количеством мелких файлов. Учитывая, что во многих случаях данные веб-сервера представляют ни что иное, как именно большую кучу мелких файлов, зачастую целесообразно выбирать ReiserFS, например, для хранения статического контента или файлового кэша. Ее потенциально-меньшей надежности в отношении ext3 опасаться не стоит (чтобы спокойно спать, достаточно будет просто обеспечить автоматическое регулярное резервное копирование).
Отдельно стоит упомянуть особенности работы баз данных. В принципе, для СУБД большинства малых и средних проектов будет вполне достаточно той же ext3. Но некоторые базы (например, MySQL/InnoDB) имеют возможность вообще обходиться без файловой системы и работать с жесткими дисками напрямую. Т.н. «raw access method» может повысить производительность, но не во всех случаях.
Использование RAM
Одним из радикальных способов повышения производительности работы с файловой системой является снижение количества запроса к дискам. Добиться этого можно, например, благодаря перманентному хранению активно-используемых данных в оперативную память. Грамотное применение этих методов в некоторых случаях может дать прирост скорости даже больший, чем переход на SAS винчестеры или применение RAID 0/0+1.
Как правило, такие методы сводятся к использованию специального программного модуля (это может быть демон или модуль веб-сервера), который выделит блок оперативной памяти заданного размера для временного хранения данных, и предоставит API для доступа к этой памяти. Такая память может быть использована, например, для хранения данных пользовательских сессий, кэша баз данных, копий сильно-фрагментированного статического контента с жестких дисков и других данных, которые в случае чего «не страшно» потерять (не стоит забывать о том, что оперативная память все-таки энергозависима).
В качестве конкретных примеров можно привести memcached и eAccelerator, но тема каждого из них стоит отдельного поста, поэтому я отложу более подробное описание на ближайшее будущее.
Оптимизация кода
Все перечисленные выше экстенсивные методы повышений производительности, остаются недоступными в условиях виртуального хостинга (будь то VPS/VDS или простой shared сервер). Поэтому должное внимание стоит уделить интенсивным методам оптимизации работы с файлами. Это не значит, что при наличии возможности самому конфигурировать сервер, об оптимизации кода можно вообще забыть: еще не придумали такого железа, которое при должном «таланте» нельзя было бы программно затормозить. Поэтому оптимизация программного обеспечния всегда бует оставаться одним из важднейших моментов в задаче поышения общей производительности.
Как не сложно догадаться, оптимизация работы с файловой системой сводится к снижению объема считываемых и записываемых данных, а так же минимизации количества отдельных обращений к жестким дискам. Чаще всего на практике эти задачи тем или иным образом будут связаны с базами данных.
Один из наиболее часто возникающих вопросов: стоит ли в принципе использовать СУБД для хранения тех или иных данных, или ограничиться хранением использованием файлов? Как правило, основной причиной выбора между этими подходами является то, как предполагается работать с данными. Если это часто-обновляемый контент, или взаимодействие с данными предполагает относительно сложную логику (например, использование многопараметрических выборок или необходимость обеспечения многопользовательскую поддержку), имеет смысл использовать готовую СУБД. В противном случае, придется самостоятельно реализовывать множество функций, которые выполнялись бы средствами БД, и тратить на это дополнительное время.
Непосредственно файловую систему разумно использовать для хранения статического контента. Хороший тому пример — графические файлы, которые многие CMS хранят отдельно от текстов статей. Сами же статьи при этом размещаются в таблицах БД, где их легче редактировать и индексировать — это разумно обоснованный выбор между двумя крайностями.
Резюме
Для повышения производительности полезно:
- разумно подходить к выбору жестких дисков;
- объединять винчестеры в RAID массивы уровня 0+1;
- осмысленно делать выбор файловой системы;
- использовать оперативную память для перманентного хранения активно-используемых данных;
- сводить к минимуму количество обращений к HDD из CMS, а так же по возможности сокращать объем записываемых и считываемых данных.
В следующих постах будут рассмотрены другие факторы, влияющие напроизводительность веб-приложений. Приветствуется конструктивная критика, дополнения, а так же пожелания относительно вопросов, которые стоит дополнительно осветить.
Ссылки по теме:
Написать комментарий
| 
/2007/12/02promise.jpg)
# LitoX: (6 января, 2008 @ 01:58)
замечательно ))
# Кирилл Плитов Иванович: (15 октября, 2008 @ 13:05)
Плитка kerama и керамогранит Китай в широком ассортименте со склада Санкт-Петербурга.В ассортименте самые разнообразные наборы керамогранита Китай и фасады – фасадные материалы, такие как минерит и полированный керамогранит.Керамический гранит служит для промышленных помещений – повышенной прочности и кислотоустойчивости..