Есть у нас некое программное обеспечение, занимающееся пакетной обработкой документов в разных форматах, с СУБД в качестве backend – MS Access или MS SQL. Это самое некое ПО планируется запускать на “облаке” Amazon EC2. Постольку поскольку в стране кризис, а документов очень много, процесс необходимо оптимизировать таким образом, чтобы уменьшить затраченное машинное время, и, следовательно, и количество долларов, перетекшее из нашего кармана в карман Amazon.
К концу этих безответственных экспериментов из окна офиса я начал видеть сумасшедший дом. За каждым изменением следовал прогон шестисотмегабайтного набора тестовых данных с секундомером и занесение цифирей в таблицу. Итак:
Первое, и самое очевидное – пробуем разные конфигурации EC2. Они различаются количеством доступной памяти и вычислительных ядер (виртуальных, как и всё прочее). Прирост есть, но более мощные конфигурации стоят дороже, поэтому смысл эксперимента несколько портится. Однако, сравниваем цифры, выбираем лучший тип машины для наших целей, в прицелом на то, что этот метод “оптимизации” можно скомбинировать с чем-то из нижеследующего.
Второе – создаём RAID, т.е. striped drive встроенными средствами Windows. В основе лежит здравое предположение, что диски, пусть и виртуальные, в группе должны работать быстрее. Как позже выяснилось, ненамного. Что на этот диск поместить? Разумеется, файл подкачки, папку %TEMP% и собственно исходные и конечные данные. Потом пробуем туда же положить базы СУБД
Далее – чрез более быстрые диски – к звездам! Если RAID быстрее обычного диска, то диск виртуальный должен быть вообще на высоте. Создаём, кладем всё то же, что и в предыдущем примере. Быстро, блин! Виртуальный диск, понятно, не бесплатен, однако соотечественники в этом отношении не подкачали, создав не хуже и дешевле.
А как насчет того, чтобы создать несколько виртуальных дисков? Пробуем. Конечно, RAID из них не сделаешь, но зато можно положить все ключевые компоненты (как называлось – %TEMP%, своп, данные БД и данные) на разные диски и попробовать. Бодрячком, как говаривал Сява.
Пятое – пробуем заменить MS Access, использовавшийся до этого, на MS SQL. Это был офигенный рывок в производительности, особенно если разместить базы на виртуальном диске.
До этого мы пользовали SQL Express. Он бесплатный, поэтому не вполне enterprise-grade. Пробуем поменять его на Standard. ПРОФИТа в нашем клиническом случае [почти] нет.
Замечаем, что наше ПО написано без учёта многопоточности, соответственно, использует только одно ядро. Ну и ладно, у нас будет своя параллелизация – с блекджеком и шлюхами. Пробуем запустить несколько копий. Не работает – проверяет наличие имиджа себя в памяти. Переименовываем *.exe файлы в четыре разных (по числу ядер) – работает, но глючит. Тьфу, неинтересно.
Пробуем запустить те же самые экзешники в окружении Terminal Server. TS использует какой-то хитрый механизм, предоставляя каждому приложению свою виртуальную копию реестра, окружения, и всего прочего, т.о. копии становятся более изолированными друг от друга и чудесно работают даже безо всяких переименований. Читаем заклинания: change user /install, потом change user /execute, стало быстрее.
Так как программка использует Ms Office, пробуем даунгрейдить 2007 до 2003. Стало быстрее раза в полтора.
Ну и под конец дня, люто ненавидя всех, пробуем вообще унести SQL сервер на другую виртуальную машину. В нашем случае оказалось не принципиально.
Когда писался этот текст, стало известно, что мы не будем использовать сие супер-ПО из-за каких-то непоняток с лицензированием, а будем использовать софт от другой фирмы, изначально написанный для параллельной обработки. Завтра будет ещё один весёлый день…
