чт, 23/05/2013 - 23:02
В этой статье я поделюсь своим опытом использования CMS/CMF Drupal на локальной машине. Речь пойдет о случае, когда все программные средства разработки будут находиться на виртуальном диске компьютера. Будут приведены результаты тестов, показывающих - есть ли прирост скорости в административном интерфейсе Drupal на стадии веб-разработки. Статья ориентирована на начинающего веб-мастера.
Я использую RAM-диск чуть меньше года. На нем "крутятся": браузер, виртуальный сервер, Drupal и кеши некоторых графических программ.
В целом, я доволен. И несмотря на неожиданные тесты, о которых я скажу ниже, вернуться на жесткий носитель, пусть даже SSD, я все-же не захочу. Во всяком случае сейчас, если только завтра не произойдет какой-нибудь очередной прорыв в компьютерных нано-технологиях:)
Поэтому меня иногда спрашивают: - а действительно ли есть эффект от использования виртуальной памяти в качестве диска?
Обычно отвечаю: - да, субъективно все вышеуказанные программы и браузер с десятком открытых вкладок реагируют на нажатие мышки достаточно быстро, можно сказать - мгновенно. Все открывается и закрывается "без тормозов", но!
МИФ
Все знают, что скорость считывания и записи в оперативной памяти на порядок выше, чем даже у самых быстрых SSD. Кажется, что все должно просто "летать". Однако - это не совсем так. Это утверждение имеет отношение лишь только к тем процессам, которые требуют чтения и записи больших объемов данных, например растровой графики.
Если таковых нет, то в конечном итоге все упирается в процессорную мощность компьютера и даже самые быстрые устройства хранения данных, к сожалению, уходят на второй план. И, именно по-этому (в нашем случае я имею ввиду веб-разработку) все выглядит несколько иначе.
РЕАЛЬНОСТЬ
Я хотел показать комфортные условия работы на RAM-диске, но не знаю как это сделать (хоть видео с экрана пиши:). И вот решил сделать несколько различных тестов, чтобы хотя-бы для самого себя ответить на вопрос - есть эффект или нет? Посмотреть на скупые цифры, так сказать.
И то, что я увидел, в конечном итоге, - меня несколько озадачило... Но об этом чуть позже.
1. О каких программных средствах идет речь
В моем случае - это браузер FireFox Portable, локальный сервер XAMPP Portable Lite для Windows и CMS/CMF Drupal. Все это, как вы догадываетесь, позволяет развернуть и настроить свой сайт локально, т.е. на персональном компьютере.
Как это все "забросить" в оперативную память?
Для этого нужно предварительно на своем компьютере создать RAM-диск и инсталлировать на него в первую очередь вышеуказанные браузер, далее набор программ локального сервера и в завершение - саму систему управления контентом Drupal.
Так же я ниже приведу:
- конфигурацию "подопытного" ноутбука и краткое описание повторяющихся операций (сценариев) при работе с сайтом. Последние будут в роли тестов;
- скорость отработки программного обеспечения на базе пяти различных устройств: USB FlashDrive (обычная флешка Kingston), USB HDD (внешний жесткий диск WD), HDD (внутренний штатный жесткий диск Toshiba), SSD (внутренний твердотельный накопитель Corsair), SO-DIMM (модули оперативной памяти Samsung);
- некоторые детали настройки программного обеспечения.
2. Важная особенность RAM-диска
RAM-диск - это в принципе такой же диск, как и все остальные на вашем компьютере, с той лишь разницей, что он энергозависимый и забирает часть оперативной памяти компьютера. Соответственно, нужно исключить ситуацию неожиданного отключения питания компьютера. Это либо источник бесперебойного питания, либо, как в моем случае - это ноутбук.
3. Проблематика
Спросите - зачем все размещать в энергозависимой оперативной памяти с риском потери данных в то время, когда скоростные SSD уже достаточно распространены и привлекательны по цене?
Ответ в общем-то прост.
Да, SSD действительно быстрее HDD, но все же не на столько, что бы сравниться с оперативной памятью. На сегодняшний день оперативная память является самым быстрым носителем данных, в разы превышающая скорости записи и чтения на SSD, и так же с каждым годом доступнее по цене.
Вот, к примеру, данные по тестируемым устройствам:
(в полном размере)
А так, как при разработке сайта на Drupal приходится делать массу операций таких как: включения/выключения различных модулей и их настроек, создавать структуры блоков, словарей таксономии, меню, представлений (Views) и много чего еще - хотелось бы, чтобы процесс генерации страниц в административном интерфейсе Drupal происходил максимально быстро и не приходилось "долгими" секундами ждать окончания вращения всем знакомых индикаторов:
4. Как обычно решается проблема
Обычно, когда разработчик (в моем случае - это веб-мастер, или иначе site-builder) ставит своей целью повысить производительность своего компьютера, а это средство производства и работать оно должно максимально надежно и быстро, он добавляет оперативной памяти.
Позже, через некоторое время, меняет HDD (как слабое звено) на SSD.
Потом приходит к мысли поменять процессор на более производительный или, чего уж там, сам компьютер на более современный.
Но всегда, как правило, установка рабочего комплекта программ происходит на жесткий энергонезависымый носитель, к примеру на тот же SSD. И если обратить внимание на момент разработки какого либо сайта, сколько запросов происходит к базе данных или другим рабочим файлам на том же носителе и сколько на это уходит времени, то возникает мысль - а почему бы эти данные не разместить на более быстром носителе?
Поэтому, проделав в некоторой степени выше описанный путь пользователя, я решил пока воздержаться от покупки более современного компьютера и попытаться сделать из своей "печатной машинки" ну, скажем... что-то вроде ракеты:) Что из этого получилось и стоит ли игра свеч - смотрите сами!
5. Итак - что имеем. Конфигурация на момент тестирования
Аппаратная часть:
Ноутбук с процессором Intel Core i3 2,2Ghz/4Gb DDR3/320Gb HDD (не самые современные контроллеры SATA II и USB 2.0).
Со временем сделал апгрейд: увеличил оперативную память SO-DIMM до 8Gb (две планки по 4Gb) и поменял штатный 320Gb HDD на более быстрый 60Gb SSD.
Примечание. Чтобы навскидку понять, какого размера можно будет создать RAM-диск на существующей оперативной памяти, обычно рекомендуют следующее соотношение "системная память/RAM-disk": 3Gb/0.5Gb, 4Gb/1Gb, 6Gb/2Gb, 8Gb/4Gb, 10Gb/6Gb. Вот, к примеру, один из источников. Забегая вперед, скажу, что я сделал диск размером 2Gb, которого мне с лихвой хватает для текущих рабочих задач. Как это выглядит в проводнике Windows (скриншот).
Периферия для сравнительных тестов:
- Внешний жесткий USB-диск 500Gb HDD;
- USB флешка FlashDrive 8Gb. Её использовал только для сравнения. Понятно, что на ней не возможно комфортно работать с сайтом.
Программное обеспечение:
- Система: Microsoft Windows 7 Home Basic x64.
Для информации, если кто не знает: максимальный размер оперативной памяти для редакций Starter - 2Gb, Home Basic - 8Gb, Home Premium - 16Gb и для остальных - 192 Gb, подробнее);
- Программы для создания RAM-диска. В качестве примера привел только две - платную и бесплатную. На самом деле их великое множество.
Итак: Primo Ramdisk Ultimate Edition 5.5.0. Она платная и одна из самых быстрых. Я ей и пользуюсь. Либо QSoft Ramdisk driver 5.3.2.13 (т.к. на официальном сайте так и не разобрался - где скачать нужную мне версию, нашел неофициальный источник для скачивания. Устанавливал - все работает). Программа бесплатная. Устанавливается как драйвер устройства и настраивается несколько сложнее. В моем случае работала примерно на тех же скоростях (скриншот), как и Primo Ramdisk - также стабильно и без нареканий;
- Браузер: FireFox Portable 20.0.1;
- Локальный сервер: программный комплекс XAMPP Portable Lite 1.8.1 (Apache 2.4.2, MySQL 5.5.27, PHP 5.4.7);
- Система управления контентом (CMS/CMF): Drupal 7.22.
6. Какие тесты использовались
Синтетические для замера скорости чтения/записи самих носителей информации:
- Программа CrystalDiskMark 3.0.2 x64 (сайт разработчика)
- Программа AIDA64 2.85.24 (сайт компании)
Собственные три сценария в административном интерфейсе Drupal такие, как:
- Обновление страницы модулей
Время генерации страницы модулей по адресу "ваш-сайт/admin/modules" для ситуации, когда установлено 165 неких модулей, из которых 92 включено. Замер времени осуществлялся счетчиком времени модуля Devel 7.x-1.3; - Создание 300 страниц
Время создания, к примеру, 300 страниц одного и того же типа материала со встроенной картинкой 200х200px в формате JPG. Для автоматического создания контента использовался тот же модуль Devel и его подмодуль Generate. Замер осуществлялся банально - секундомером; - Отображение 300 страниц
Время отрисовки представления (вывод тех же трехсот созданных страниц) уже с помощью модуля Views 7.x-3.7. Содержимое выводилось сплошным списком без навигатора в формате анонсов. Выводились поля: заголовки, картинки и тизеры (анонсы). Замер времени осуществлялся средствами Views в режиме автоматического предпросмотра.
Этот же замер был продублирован утилитой ApacheBench 2.3. (файл ab.exe), входящей в комплект вышеупомянутого программного комплекса XAMPP.
Так же, как вариант, проверялось время генерации этого же представления (списка созданных страниц) в браузере уже по адресу этой страницы "ваш-сайт/test" (скриншот). Замечу, что кроме самого списка выводились небольшое меню сайта и несколько блоков в футере. Время замерялось счетчиком модуля Devel.
Примечание. Собственный кеш Drupal и кеш Views были отключены. PHP кеш (eAccelerator) для чистоты эксперимента был тоже отключен. Настройки MySQL сервера брались по рекомендациям разработчиков Drupal.
Все однотипные замеры, за исключением создания трехсот страниц, повторялись по 5-10 раз. Для конечного результата вычислялось среднее значение.
7. Результаты тестирования
Первичный замер скорости чтения/записи устройств хранения данных. От медленных (слева) до самых быстрых (справа).
(в полном размере с альтернативными тестами от AIDA64. Обратите внимание на время доступа Average Read Access в самом низу полноразмерной картинки)
Собственные сценарии:
1. Обновление страницы модулей
2. Автоматическое создание трехсот страниц
3. Отображение трехсот страниц
Результаты тестов в табличном виде
ВЫВОДЫ
Судя по последним трем тестам, использование RAM-диска не приводит к сокращению времязатрат в пользовательском интерфейсе CMS даже, если на нем (на диске) разместить и браузер, и локальный сервер и CMS. В некоторых случаях (см. сценарий 1 и 3) "старый-добрый" винчестер (HDD) оказывается по-проворнее.
Последний факт меня и озадачил. Я ожидал, что не будет существенной разницы от применения RAM-диска по сравнению с SSD, но что-бы не было разницы по сравнению с HDD...
Отсюда напрашивается вывод, что слабым звеном в моей конфигурации является не носитель информации (HDD или SSD), а именно сам процессор. Получается, что от его уровня производительности зависит время генерации страниц в пользовательском интерфейсе.
Но не все так печально. Ведь субъективно апгрейд компьютера с HDD на SSD пользователем ощущается сразу - все просто "летает". И тут важно вспомнить, что причиной этому является не только скорость чтения, но и время доступа к данным - у SSD оно составляет 0,22 ms против 16,76 у HDD (см. гл.7).
Следующий шаг к ускорению - перенос некоторых профессиональных программ или их кешей с SSD на RAM-диск. Он менее заметен в случае веб-разработки, но все-же весьма ощутим, если приходится работать, к примеру, с графикой. И вот в этом случае время доступа (у RAM-диска 0,01 ms против 0,22 у SSD) отступает уже на второй план по сравнению со скоростью, к примеру, чтения у RAM-диска 4500 MB/s против 190 у SSD.
А так, как мне в работе приходится использовать несколько программ одновременно, да плюс браузер с десятком открытых вкладок, и между программами приходится постоянно переключаться, то последний вариант ускорения моей "печатной машинки" для меня достаточно существенен и ощутим. Жаль только, что выше приведенные тесты не в состоянии этого показать:)
Ну и в заключение.
В моем видении - "ракета" для веб-разработчика - это прежде всего (1) компьютер с максимально производительным процессором + (2) RAM диск для временных файлов, кешей и возможно баз данных + (3) SSD для системы и рабочих программ + (4) HDD для емких файлов наподобие архивов, бекапов, фото, видео и т.п.
Возможно, что такой дифференцированный подход к решению задач и привел к тому, что сейчас достаточно популярны ноутбуки с двумя носителями - быстрым небольшим SSD под систему и емким HDD для данных. А если у кого сейчас есть оптический CD/DVD привод в ноутбуке, то можно попробовать использовать его для второго (HDD) винчестера с помощью специального адаптера-переходника (предложения и варианты в сети имеются).
Для тех, кто хочет создать RAM-диск и посмотреть эффект для своей конфигурации. Некоторая последовательность действий и нюансов настройки ПО.
Внимание! Все, что описано ниже не является инструкцией или обязательным руководством. Это только один из вариантов установки программного обеспечения в виртуальную память (RAM-диск) из моего личного опыта. Все, что вы примените из нижеописанного - вы делаете на свой страх и риск!
Если вас не испугало такое "грозное" предупреждение, то тогда - вперед!
1.ПОДГОТОВКА КОМПЬЮТЕРА
Итак, прежде всего убедитесь, что у вас все в порядке с аппаратной частью (с железом) и программной (с Windows). Вы наверно догадываетесь, что синие экраны смерти нам совершенно ни к чему. Все текущие данные в виртуальной памяти, а следовательно на RAM-диске, в этом случае будут утеряны.
Чтобы этого избежать, или в лучшем случае, минимизировать эту неприятность, желательно:
- Обновить все BIOS (прошивки: системной платы, видеокарты, жестких дисков и др.). После этого обновить все драйверы, возможно установить не самые последние, а именно стабильные, которые не вызывают конфликтов с другими устройствами.
- Проверить оперативную память и жесткие диски. Для начала - встроенными средствами Windows: памяти и дисков для Win 7. И в завершение, даже если все нормально, - нагрузочными тестами, которые позволяют определить стабильность функционирования устройств компьютера - памяти, процессора и дисков при повышении их температуры. К примеру, можно воспользоваться AIDA64 Меню->Сервис->Тест стабильности системы.
Если все в порядке, можно проверить программную часть.
- Убедиться, что Windows имеет последние обновления.
Еще, как вариант, можно запустить встроенную утилиту sfc.exe, которая проверит целостность системных файлов и исправит их, если с ними что-то не так. Но тут сразу оговорюсь - пользоваться ею можно с уверенностью только в том случае, если у вас стандартная установка системы и нет никаких специальных изменений в системных файлах. Иначе она может просто перезатереть некоторые нужные вам файлы на стандартные.
Запускается утилита из командной строки: кнопка Пуск->Выполнить->cmd->sfc /scannow. Программе потребуется инсталляционный диск с операционной системой. Подробнее об этой процедуре можно нагуглить набрав "sfc /scannow".
- Проверьте журналы Windows. Кнопка Пуск->Администрирование->Просмотр событий->Журналы Windows. Если там обилие красных и желтых пунктов, то нужно разбираться, насколько они критические для работы системы и попытаться исправить источники этих конфликтов. Имеется неплохое описание терминов и процедур в самой справке журнала.
2.СОЗДАНИЕ RAM-ДИСКА
Установка Primo Ramdisk не представляет трудностей. Все достаточно подробно и со скриншотами представлено на странице компании-разработчика.
Букву для диска я выбрал Z. Тип диска Direct-IO. Он несколько быстрее SCSI (скриншот). Файловая сиситема FAT32. Ассоциированный файл-образ: загрузка и сохранение. Сохранение файла-образа: сжатый образ, скоростное. Время сохранения: при выключении ПК. При желании можно сохранять образ вручную через интерфейс самого приложения (обычно при использовании гибернации).
3.УСТАНОВКА БРАУЗЕРА
Скачиваем любой portable браузер. Я предпочитаю Mozilla Firefox Portable (на русском). Кому-то, возможно, удобнее работать в Google Chrome Portable.
Установка не представляет затруднений. При запуске дистрибутива, мастер установки спросит, в какую папку устанавливать. Указывайте смело корень RAM-диска. Должно быть что-то вроде Z:\FirefoxPortable. Все файлы браузера, будущих расширений и кеша будут в этой папке. На начальном этапе на диске потребуется, как сообщает мастер, 47Mb. По факту 62Mb (для Google Chrome Portable 105Mb. По факту 119Mb).
Тут нужно иметь ввиду ограничение по кешу и размеру расширений, т.к. место на RAM-диске приходится отслеживать. Я ограничиваю кеш в пределах 50Mb. В Firefox-е - это Меню->Настройки->Дополнительные->Сеть картинка. В Google Chrome иначе. Один из способов - это создать ярлык и прописать в поле Объект Z:\GoogleChromePortable\GoogleChromePortable.exe --disk-cache-dir="Z:\GoogleChromePortable" --disk-cache-size=51238400 картинка. Запускать браузер двойным кликом по ярлыку. Но лучше погуглить, т.к. есть нюансы с кешированием, к примеру, медиаконтента (одна из веток про это).
В конечном итоге, после установки десятка необходимых расширений, размер папки с учетом кеша 50Mb, у меня составил 150Mb, что на мой взгляд - очень неплохо для Firefox Portable. Для Google Chrome Portable получалось несколько больше, да и с кешем не все было так просто; наровил разростись больше, чем я его ограничивал.
Небольшое пояснение.
Конечно можно поставить и обычный (не potable) браузер на жесткий носитель, к примеру на тот же HDD, а профиль пользователя и кеш перенести на RAM-диск для ускорения работы. Эффет будет тот-же. И возможно это будет актуально тем, у кого относительно не много (3-4Gb) оперативной памяти или в случае, когда используется невидимая память в 32-битных системах (подробнее о последнем). Но я от этого варианта отказался, т.к. теряется целостность хранимых данных; что-то на жестком носителе, что-то на виртуальном. Не удобно для архивирования или переноса на другие носители.
4.УСТАНОВКА XAMPP
Находим и скачиваем ZIP архив именно(!) XAMPP Portable Lite. Распаковываем его на диск Z. Все файлы локального сервера должны находиться по адресу Z:\xampp. Инсталлятор нам не потребуется.
Если у вас установлен Skype, то необходимо отключить в нем использование 80 порта. Заходим в его меню: Инструменты->Настройки->Дополнительно->Соединение и убираем галочку с "Использовать порты 80 и 443 в качестве входящих альтернативных".
Запускаем в папке Z:\xampp\xampp-control.exe для дальнейшей настройки. Нас будут интересовать только Apache и MySQL. Достаточно подробное описание настройки этих приложений я нашел на этом сайте http://i--gu.ru/urok-1. Найдите там главу "Настройка XAMPP" и действуйте дальше.
5.УСТАНОВКА DRUPAL
По установке CMS Drupal написано достаточно много. В нашем случае нас интересует седьмая версия. Вот одна из статей, которую можно применить в качестве инструкции. Только не забудьте, что мы устанавливаем CMS не на диск С, как в ней, а на наш виртуальный диск Z.
В качестве дополнения не лишним будет еще просмотреть несколько устаревшую (для шестой версии), но еще актуальную статью "Начинаем работать с Drupal: полное практическое руководство" http://www.drupal.ru/quickstart.
В итоге, после всех установок и настроек, у вас на диске Z будут две папки - FirefoxPortable и xampp. Внутри папки xampp по адресу Z:\xampp\htdocs\имя_сайта будет находиться ваш сайт на Drupal. А его база данных - в папке Z:\xampp\mysql\data\имя_базы_данных.
Все программы - и браузер, и контрольная панель XAMPP в дальнейшем запускаются с этого виртуального диска.
Комментарии
Я дочитал :) Спасибо за
Я дочитал :) Спасибо за статью.
Кто бы мог подумать, что статья про RAM может вызвать во мне непреодолимое желание приобрести SSD :)
+1. Даже уже присмотрел бухту
+1. Даже уже присмотрел бухту для второго диска вместо сидирома для своего ноута.
Спасибо! Надеюсь, добавил
Спасибо! Надеюсь, добавил уверенности для апгрейда)
Изумительная статья. Лучшее
Изумительная статья. Лучшее из того, что мне встречалось про ram.
Сам с этой технологией познакомился 7 лет назад в ходе настройки LTSP (linux terminal server project) - там в RAM по сети грузится вся ОС. Увы, для xml-разработчика линух пока не слишком актуален - там нет XML Spy. А на винде однозначно нужно чудо типа Primo Ramdisk для ускорения баз данных и всякого рода кэшей. Попутно спасаем ресурс SSD.
Касаемо баз данных... Автор зачислил их во вторую очередь переезда на RAM ("...и возможно баз данных"). Но это для SQL-баз данных. А для noSQL? Когда разрабатываешь файловую СУБД, первая опасность - потеря скорости. И значит тут RAM критично важна. Является ли это панацеей для файловых БД пока не знаю. Кто-нибудь подскажет?
зы. Подтверждаю важность процессора для работы web-сервера. Попытка поднять xammp на конфигурации atom+SSD полностью провалилась, при том, что атомы признают идеальным решением для, например, файловых хранилищ.
Автору статьи респект, я
Автору статьи респект, я раньше как то не задумывался над таким вариантом. Дошел до SSD, а оказывается можно еще быстрее :).
ru7701:
Немного непонятен вопрос про noSQL - вы случайно не спутали понятия RAM и RAM Disk ?
Для работы как MySQL, так и MongoDB (как пример) действительно важно выделять оптимальное количество оперативной памяти RAM из доступной, чтобы и работало быстро и другим приложениям не мешало.
При этом и MySQL и MongoDB ведь также в конечном счете хранят данные в виде файлов на диске. А значит производительность дисковой системы тоже критична в подавляющем количестве случаях. Переход на RAM Disk будет и в этом случае выгоден.
Другой вопрос, что хранить в БД файлы - это достаточно большой размер самой БД, соответственно RAM Disk небольшого размера просто может не хватить для полноценной работы. А выделять большой объем из RAM чревато ограничением уже работы самого сервиса, соответственно да, возможны потери производительности.
Тут немаловажно вспомнить, что файлы в БД с точки зрения MongoDB почти ничем не отличаются от остальных данных и при работе с ними, он не берет их целиком, а работает по частям (chunk) - соответственно требования к свободной RAM может быть даже ниже, чем в случае MySQL.
P.S.: или я не понял вопрос, тогда нужно подробнее описание проблемы.
Спасибо за некоторые
Спасибо за некоторые разъяснения и ссылки на MongoDB. Как я понял, вы к тому, что базы данных в любом случае имеет смысл держать на RAM-диске, и проблемой тут могут стать лишь размеры баз. Просто у меня-то в голове мысль, что в "крутых" СУБД (каковыми являются все реляционные) есть внутренние механизмы кэширования, которые обеспечивают дополнительное ускорение, в том числе за счет использования ОЗУ. Т.е. для них RAM-диск не так нужен как для интересных мне "совсем не крутых" СУБД держащих все данные исключительно в виде файлов.
Чуток конкретизирую свой интерес...
Волей судьбы несколько лет разрабатываю простейшую semantic-web noSQL-СУБД. Поступаемые данные (для semantic-web они всегда идут в виде новых триплетов) perl-скриптом записываются в xml-файлы на RAM-диск. Причем скрипт тут же готовит индексы: специальную систему папок и xml-файлов позволяющую через, допустим, xslt-запросы быстро находить любую нужную информацию. Отдельный специальный блок следит за целостностью всех связей, отслеживает конфликты и т.д.
...И вот у меня беспокойство, будет ли это так же быстро как у конкурирующих СУБД?
(опустим проблему размера БД).
Спасибо за позитивные отзывы
Спасибо за позитивные отзывы ru7701 и Softovick) Всегда приятно, когда из статьи каждый находит что-то полезное для себя.
ru7701: к сожалению, по noSQL ничего сказать не могу, не пробовал.