Сегодня вопрос экономической эффективности и стоимости владения систем на основе Windows и Linux является одним из наиболее спорных и важных. Сегодня существует целый ряд различных исследований, которые, в зависимости от того кто их спонсировал, показывают то более низкую стоимость владения для Windows, то для Linux. Анализ этих работ(1) показывает, что наиболее убедительно выглядят исследования, показывающие более низкую стоимость владения Windows, выглядит более убедительно. Поэтому с большим интересом компьютерная общественность отнеслась к очень профессиональному исследованию аналитической компании Robert Frances Group "TCO for Application Servers: Comparing Linux with Windows and Solaris"(2), опубликованному в августе 2005 года. Здесь мы проводим тщательный анализ исследования Robert Frances Group, а также попытаемся воспроизвести их методику оценки ТСО и проверить их данные.
Результаты исследования Robert Frances Group
Выводы, сделанные в исследовании Robert Frances Group "TCO for Application Servers: Comparing Linux with Windows and Solaris"2, достаточно радикальны: ТСО Linux для систем на процессорах х86 на 40% процентов ниже, чем у Windows-систем, и на 54% меньше, чем у систем на SPARC Solaris. Согласно Robert Frances Group стоимость оборудования для Linux и Windows, которое обеспечивает одинаковую производительность различается очень значительно - 13 191 долл. для Linux-системы и 23 242 долл. для Windows-системы. И здесь возникает основной вопрос, послуживший толчком для проведения собственного исследования ситуации. Такое колоссальное различие в стоимости оборудования не может быть вызвано только разницей в операционной системе, поверх которой тестируется приложения. И Windows и Linux являются достаточно зрелыми операционными системами, чтобы так кардинально влиять на результаты тестов.
Проблемы методики Robert Frances Group
На наш взгляд, методика исследования, предложенная в работе, содержит много спорных моментов и некорректных обобщений. Компания Robert Frances Group разработала собственную методику сравнения стоимости аппаратной части ТСО. В ее основе лежит идея рассмотрения сравнимых между собой по задачам и производительности приложений. Поскольку найти такие приложения, работающие одновременно на Linux, Windows и Solaris, весьма затруднительно, то в качестве сравнительной характеристики используются результаты независимого, объективного и широко известного теста серверов приложений, разработанного международной организацией SPEC (Standard Performance Evaluation Corporation). В исследовании Robert Frances Group в качестве тестового примера был использован тест SPECjbb(3). Это развитие идеи тестов TPC-C в трехуровневой архитектуре (клиент - сервер приложений - СУБД). Основная модификация связана с тем, что обращений к СУБД не производится, вместо таблиц базы данных используются классы Java. Таким образом, этот тест выполняет транзакции и запросы практически того же типа, что тест ТРС-С, но вся нагрузка ложится на сервер приложений и JVM, а обращений к дисковой системе, столь характерных для тестов TPC-C, не производится.
Использование результатов универсальных интегральных тестов для сравнения различных систем в тех случаях, когда прямые данные недоступны, с нашей точки зрения является оптимальным. Наша компания использует этот метод уже несколько лет. Однако такое сравнение должно выполняться крайне аккуратно, с пониманием сути происходящих процессов и особенностей аппаратной архитектуры рассматриваемых систем. К сожалению, авторы исследования из Robert Frances Group не дали подробного описания своей методики с примерами. Приведено только общее описание методики: например, для расчета стоимости оборудования выбирались системы на основе ОС Linux, Windows и Solaris с производительностью близкой к 100 тыс. операций в секунду. Такой подход, теоретически, снимает проблему масштабирования результатов (зависимость производительности от конфигурации компьютера и его стоимости нелинейная).
Далее в исследовании с Web-сайтов Dell, HP и IBM брались цены на серверы в подобной комплектации и усреднялись. Затем, судя по всему, авторы методики Robert Frances Group нормировали стоимость системы на 100 тыс. операций. Как производилась это масштабирование в методике не сказано, но можно предположить, что все параметры системы, например стоимость, умножались на коэффициент, полученный делением "стандартной" производительности (100 тыс.) на показанную в тесте производительность.
В целом методика выглядит очень основательно, но содержит ряд очень спорных моментов. На мой взгляд, выбор систем с характеристиками, максимально близкими некоему фиксированному значению, является принципиальной ошибкой, компрометирующей всю методику и приводящей к неправильным выводам.
Дело в том, что процесс тестирования производительности в тестах TPC и SPEC достаточно сложен и далеко не всегда достигнутые в тестах результаты являются финальными характеристиками максимально возможной производительности. В процессе работы над тестами сами группы тестировщиков постоянно улучшают свои результаты. И реальная производительность системы, показавшей результат теста достаточно близкий к 100 тыс. операций в секунду, может быть гораздо выше.
Второе слабое место методики Robert Frances Group в том, что в качестве точки отсчета выбрано значение 100 тыс. операций в секунду. Дело в том, что эта производительность может быть достигнута как на серверах с двумя процессорами, так и на серверах с четырьмя процессорами. При этом стоимость 2- и 4-процессорных серверов может отличаться очень значительно. Если в качестве модели сервера с необходимой производительностью будут взяты серверы с разным числом процессоров для разных операционных систем, то та система, для которой выбрана четырехпроцессорная модель, несомненно, окажется существенно дороже.
Таким образом, подход Robert Frances Group не учитывает особенности тестирования производительности систем и их архитектуры. Так как стоимость сервера является значительной частью ТСО всей системы, то если она не верна, весь расчет ТСО можно считать некорректным.
Кроме того, в начале исследования "TCO for Application Servers: Comparing Linux with Windows and Solaris" авторы ссылаются на опрос 20 компаний с более чем 250 сотрудниками. Очевидно, что некоторые из этих данных используются в дальнейшем для расчетов стоимости администрирования систем. Однако ни методика такого исследования, ни результаты не приводятся. Субъективность таких исследований очень хорошо показана в работе Forrester Research(4). Кроме того, выборка из 20 компаний ни в коем случае не является репрезентативной. Но для доказательства некорректности всего исследования достаточно показать ошибку хотя бы в одном компоненте расчета ТСО, в то время как для доказательства корректности необходимо доказать корректность каждого слагаемого.
Правила сравнения
Корректное сравнение свойств систем, участвующих в тестах производительности, возможно только там, где результаты тестов пропорционально зависят от параметров оборудования. Например, такая зависимость наблюдается при повышении частоты процессора в случаях, когда именно процессор является узким местом системы, а память, шина, системы ввода/вывода имеют запас производительности. Это возможно только в случае очень похожей архитектуры серверов. В общем, для того, чтобы полученные результаты можно было корректно сравнить между собой должны выполняться три основных условия.
Условие 1. Необходимое условие для того, чтобы результаты можно было сравнивать между собой, - одинаковая архитектура тестируемых систем. Так как в нашем случае это условие соблюдается (поскольку можно выбрать для исследования только системы архитектуры х86), то следует детально рассматривать число процессоров и их тип (AMD или Intel). Таким образом, установив планку производительности в некоторой окрестности 100.000 операций, мы будем рассматривать отдельно 2- и 4-процессорные сервера.
Условие 2. Необходимо убедиться в том, что достигнутые в тестах результаты являются максимально возможной на сегодня производительностью такой системы. Только в этом случае в некотором приближении их можно считать значимой оценкой этой системы.
Условие 3. Использованные для сравнения результаты должны как можно меньше отличаться от выбранного уровня производительности. Это условие необходимо, так как только в этом случае можно ожидать приемлемого уровня интерполяции результатов тестов на выбранное общее значение производительности. Реально линейная масштабируемость практически никогда не достигается, но в некоторой окрестности реперной точки зависимость производительности от прироста параметров достаточно близка к линейной. Это требование, основное в работе Robert Frances Group, является только третьим в нашем списке приоритетов. И его следует применять лишь после того, как соблюдены первые два условия нашей методики.
Методика анализа стоимости и производительности
Так как авторы исследования Robert Frances Group не раскрыли подробностей своей методики - выбранные примеры из jbb2000, конфигурации серверов, принципы оценки стоимости администрирования и так далее, - то мы не можем полностью воспроизвести их расчеты. Для наших целей достаточно ограничиться проверкой данных по стоимости аппаратного обеспечения (серверов).
В таблице 1 приведены результаты тестов jbb2000(5) на 7 сентября 2005 года, удовлетворяющие условию 2. Чтобы выполнялось условие 1, эти данные разведены по двум таблицам - для 2-процессорных конфигураций и для 4-процессорных.
Таблица 1. Официальные результаты тестов jbb2000
Производитель | JBB2000 | ОС | JVM | Процессор |
Результаты для серверов с 2 процессорами
|
||||
Dell |
105296 | Microsoft Windows 2003 Server, Standard Edition | BEA WebLogic JRockit 32-bit |
Intel Xeon DP |
Tyan Computer Corporation |
103377 | Microsoft Windows Server 2003 Enterprise Edition | BEA WebLogic JRockit 32-bit |
AMD Opteron 252 |
Tyan Computer Corporation |
88211 | SuSE Linux Enterprise Server 9 | BEA WebLogic JRockit 32-bit |
AMD Opteron 252 |
Sun Microsystems |
65840 | Solaris 10 | Java HotSpot(TM) 64-Bit | AMD Opteron 252 |
Результаты для серверов с 4 процессорами
|
||||
Tyan Computer Corporation | 181496 | Microsoft Windows Server 2003 Enterprise Edition | BEA WebLogic JRockit 32-bit |
AMD Opteron 852 |
IBM | 167515 | Microsoft Windows Server 2003 Enterprise Edition | J2RE 1.4.2 Windows 32 |
Intel Xeon MP |
Tyan Computer Corporation | 144638 | SuSE Linux Enterprise Server 9 | BEA WebLogic JRockit 32-bit |
AMD Opteron 850 |
Sun Microsystems | 116142 | Solaris 10 | Java HotSpot(TM) 64-Bit | AMD Opteron 852 |
Очевидно, что граница 100 000 операций слишком велика для Linux и Solaris на 2-процессорных машинах и слишком низка для 4-процессорных. Найти сравнимые по производительности машины не удается. Поэтому мы решили применить подход, который использовался в исследовании Robert Frances Group, и нормировать производительность машин на 100 000 операций.
Так как в наших данных выполняются условия 1 и 2, то мы будем стараться выполнять условие 3, насколько это возможно, предполагая, что зависимость производительности в некоторой небольшой окрестности 100.000 операций в секунду линейна.
В первую очередь очевидно, что системы на основе Solaris существенно проигрывают по производительности Windows и Linux. Не случайно Robert Frances Group не включает в свое рассмотрение результаты тестов Solaris на машинах с процессорами AMD. Такую низкую производительность в этих тестах можно объяснить только тем, что, в отличие от Linux и Windows на платформе х86, для Solaris используется 64-битная JVM производства Sun, которая, возможно, пока недостаточно доработана. Поэтому, хотя мы и приводим данные по Solaris в наших таблицах, но основное сравнение будем вести для Windows и Linux(6).
Для введения стоимостной характеристики в расчете ТСО мы использовали подход, аналогичный Robert Frances Group, - использование цен с официальных сайтов компаний. Но для упрощения задачи мы использовали не "некоторую средневзвешенную" цену, а цены на компьютеры НР, предполагая, что их цены дают достаточно точную оценку. Мы выбрали HP как типичного производителя x86-серверов, в линейке которого присутствуют все необходимые для расчетов модели. При этом стоимость модели больше всего зависит именно от использованных процессоров и памяти, так как все остальные компоненты одинаковы или очень близки, а цены сбалансированы именно с учетом вычислительной мощности(7).
При использовании автоматических конфигураторов на сайте www.hp.com мы ориентировались на то, чтобы все возможные конфигурации серверов из полных описаний тестов jbb2000 присутствовали в выбранной линейке. Оптимальный выбор в этой случае - линейка rack-серверов ProLiant DL, в которой присутствуют серверы на основе Xeon DP и AMD с различными тактовыми частотами и размерами памяти. Выбиралась минимальная конфигурация - не использовались резервные блоки питания, дополнительные сетевые адаптеры и другие опции. В результате для всех серверов использовалась "голая" конфигурация по умолчанию, одинаковая в пределах линейки. Так как в тестах jbb операции ввода/вывода на дисковые носители и диски никак не влияют на производительность, то мы рассчитывали все цены на использование минимального одинакового для всех систем диска SCSI 15.000 rppm 36 Гб.
Такая "минималистическая" конфигурация позволяет точнее выделить именно особенности применяемой техники. Если в реальных системах будут использованы дополнительные опции, то разница в стоимости систем уменьшится.
В таблице 2 приведены сводные данные по всем системам и "нормированные на 100.000" цены на соответствующие серверы. В соответствии с условием 1 мы выделили две группы результатов: 2- и 4-процессорные серверы. Мы также привели результат на процессорах Xeon DP, которые по производительности на двухпроцессорных машинах даже превосходят процессоры AMD, но нарушают условие 1. Так как разница в производительности невелика, а условие 2 требует выбора лучших результатов (в данном случае по критерию цена/производительность), то мы не будем их использовать. В результате у нас получаются две группы очень похожих компьютеров, которые в линейках HP можно представить как ProLiant DL385 и ProLiant DL585. Таким образом, мы считаем, что такое сравнение наиболее корректно и позволяет строить по настоящему обоснованные выводы.
Таблица 2. Сводные данные по стоимости при нормировании производительности на 100.000 операций в секунду
Процессор | Память (MB) |
Модель сервера |
ОС | jbb2000 | Цена (долл.) |
Цена на 100.000 операций (долл.) |
2 х Intel Xeon DP 3600 MHz |
8192 | НР ProLiant DL380 |
Windows | 105296 | 8,698 | 8,260 |
2 х AMD Opteron 252 2600 MHz |
4096 | НР ProLiant DL385 |
Windows | 103377 | 6,346 | 6,138 |
2 x AMD Opteron 252 2600 MHz |
4096 | НР ProLiant DL385 |
Linux | 88211 | 6,346 | 7,194 |
2 x AMD Opteron 252 2600 MHz |
8192 | Sun Fire V20z |
Solaris | 65840 | 7,595 | 11,535 |
4 x AMD Opteron 850 2400 MHz |
4096 | НР ProLiant DL585 |
Linux | 144638 | 16,595 | 11,809 |
4 x AMD Opteron 852 2600 MHz |
8192 | НР ProLiant DL585 |
Windows | 181496 | 22,340 | 12,144 |
4 x AMD Opteron 852 2600 MHz |
16384 | Sun Fire V40z |
Solaris | 116142 | 24,995 | 21,521 |
Сравнение результатов Robert Frances Group и Elashkin Research
Анализ результатов "нормированных" цен на равные по производительности сервера показывает, что в группе 2-процессорных машин стоимость "железа" для Windows серверов на 17% дешевле, чем для Linux. В группе 4-процессорных машин наблюдается обратная картина: Linux-сервер стоит на 7% дешевле Windows сервера 18. Полученные нами результаты разительно отличаются от заявленных Robert Frances Group 13,191 долларов за Linux-систему и 23,242 за систему на Windows.
Какие образом могли получиться такие цифры в исследование Robert Frances Group? Можно предположить, что стоимость серверов несколько изменилась за прошедшее время, но это никак не объясняет кардинальное различие в стоимости серверов для Linux и Windows, полученную в исследовании. Такая разница возможна только за счет нарушения условий 1 и 2. Если взять для Windows систем не лучшие результаты для 4-процессорного сервера, а для Linux лучшие результаты для двухпроцессорного и нормировать их на 100 000, то можно получить такое соотношение. Мы не можем оценить, является это следствием методологической ошибки или подгонкой результатов под заранее заданный результат, но совершенно очевидно, что все данные, полученные в этом исследовании, некорректны. Данные по стоимости аппаратного обеспечения содержат грубую ошибку в десятки процентов. А так как все расчеты всех остальных компонентов ТСО опираются на эту же методику и набор результатов тестов jbb, то они также являются неверными.
Анализ стоимости аппаратной платформы для выполнения приложений Java в трехуровневой архитектуре не показал абсолютного преимущества операционных систем Windows или Linux при выборе аппаратной платформы для исполнения приложений. В зависимости от необходимой производительности преимущество принадлежит то одной, то другой операционной системе.
1 "Бизнес модель Open Source. Перспективы и угрозы",
Elashkin Research, 2005
2 http://www-1.ibm.com/linux/whitepapers/robertFrancesGroupLinuxTCOAnalysis05.pdf
3 http://www.spec.org/jbb2000/docs/faq.html
4 "The Costs And Risks Of Open Source", Julie Giera, April 12, 2004.
Forrester Research
5 http://www.spec.org/jbb2000/results/jbb2000.html
6 Для соблюдения объективности отметим, что серверы на основе Solaris и SPARC
- рекордсмены в абсолютной производительности тестов jbb2000 и опережают серверы
с Linux на процессорах Power5 более чем в два раза, конкурируя только с серверами
IBM Power5 и AIX.
7 Для серверов Sun мы, тем не менее, выбрали цены именно с сайта www.sun.com,
так как модельный ряд, использовавшийся в тестах Sun jbb2000, плохо совместим
с модельным рядом HP - приходится добавлять память, а такие "заказные конфигурации"
всегда дороже, чем стандартные. В результате стоимость серверов Sun v40 и v20
получается меньше, чем аналогичных моделей HP. При этом дисковая система v20
и v40 содержит более дорогие диски, и в стоимость входит операционная система
Solaris. Но так как мы приводим Solaris в нашем исследовании только для примера,
то это отступление от правил не влияет на результат.