Сравнительное тестирование программных комплексов

ТЕСТИРОВАНИЕ

Стеки Open source и .NET демонстрируют хорошую производительность, но и смешанные стеки показали прекрасные результаты в лабораторных тестах

Может ли ИТ-стек вашей организации выдержать возлагаемую на него нагрузку? Обеспечивают ли компоненты вашего ИТ-стека наивысшую достижимую производительность? Есть ли у вас возможность выбора? Пришло время дать ответы на эти вопросы.

Существуют самые различные виды стеков - от сетевых до стеков программного кода. Но в последние годы наибольшее внимание привлекают те стеки, которые называют - несколько расширительно - ИТ-стеками. В сущности, ИТ-стек состоит из серверной операционной системы, Web-сервера, СУБД и скриптового языка или языка разработки.

Конечно, ИТ-стеки вполне заслуживают уделяемого им внимания. В конце концов, этот набор приложений составляет базовое ядро, на нем работает большинство приложений предприятия, использующих Web-технологии: от порталов до корпоративных систем управления контентом, систем управления взаимоотношениями с клиентами (Customer Relationship Management, CRM) и планирования ресурсов предприятия (Enterprise Resource Planning, ERP).

Кроме того, по мере все более активного перехода компаний к сервисно-ориентированным архитектурам (Service-Oriented Architecture, SOA) и другим основанным на сервисах системам их ИТ-стеки будут играть огромную роль в определении стратегии развития сервисов.

Наверное, двумя самыми известными стеками являются Microsoft .Net и LAMP с открытым исходным кодом.

Стек .Net обычно состоит из операционной системы Windows Server, Web-сервера IIS (Internet Information Services), СУБД SQL Server и скриптового языка Active Server Pages. Стек LAMP включает серверную ОС Linux, Web-сервер Apache, СУБД MySQL и один из трех начинающихся на букву “P” скриптовых языков (PHP, Python или Perl).

Кроме этих двух стеков наиболее широко применяется - особенно на предприятиях - J2EE (Java 2 Platform, Enterprise Edition). Данный стек достаточно гибок с точки зрения набора компонентов, но один из них обязателен: языком разработки должен служить JSP (JavaServer Pages).

Разумеется, существуют не только эти три ИТ-стека. Когда вы начинаете использовать различные приложения и согласовывать их друг с другом, в том числе приложения, которые мы даже не упомянули, возможности выбора становятся практически беспредельными.

Тем не менее ИТ-стек выбирается исходя не из качества входящих в него приложений, а на основе накопленного опыта (“Мы всегда использовали Linux, Unix или Windows”), имеющихся навыков работы (“Наши программисты знают только ASP, JSP или PHP”) или ориентации на конечные продукты (“Мы хотим применить продукт “Х”, который требует .Net, Linux или Java”).

Но что можно сказать о самих стеках? В какой мере выбор стека влияет на производительность? Должны ли стеки быть однородными или предприятия могут добиться высокой производительности, используя компоненты, заимствованные из различных стеков?

Такова лишь часть вопросов, на которые лаборатория eWeek Labs стремилась дать ответ, начав несколько месяцев назад тестирование состава, производительности и масштабируемости корпоративных ИТ-стеков.

Мы провели серию испытаний восьми различных ИТ-стеков для определения предельной нагрузки (правда, при этом мы использовали лишь малую толику возможностей составления стеков). Наш набор состоял из стеков “чистого” LAMP, “чистого” .Net, J2EE в сочетании с Windows и Linux, а также стека, который мы назвали WAMP, - в сущности это компоненты с открытым исходным кодом под управлением серверной ОС Windows. (Протестированные нами стеки и входящие в их состав приложения приведены в таблице.)

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

Но отдельные итоги могут вызвать удивление. Смешанные стеки довольно хорошо показали себя в ходе тестирования, особенно те, в которых используется нестандартная СУБД.

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

Это не означает, что использование только продуктов Microsoft будет плохим решением: стек Microsoft .Net показал очень хорошую производительность в наших тестах, ярко продемонстрировав преимущества тесной интеграции всех компонентов стека.

Мы надеемся, что наши испытания дадут определенное представление, но более всего мы надеемся, что они побудят ИТ-менеджеров самостоятельно провести аналогичные тесты. Никакие испытания, проведенные сторонней лабораторией, не скажут вам, как будет работать определенная комбинация серверов и приложений именно с вашими системами и в конкретных условиях вашего бизнеса.

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

Тестирование ИТ-стеков

Приступая к испытаниям ИТ-стеков, лаборатория eWeek Labs преследовала несколько целей.

Во-первых, нас не интересовали тесты с нереалистичной нагрузкой, предназначенные для выяснения, какой из ИТ-стеков рухнет первым. Мы хотели, чтобы каждый стек работал с объемным, но реалистичным и устойчивым трафиком, дабы получить имеющие практическое значение результаты, которые можно было бы использовать применительно к вычислительным средам большинства организаций.

Среднее число транзакций в секунду

Для испытания платформы с выходом в Интернет, такой, как ИТ-стек, нам требовалось испытательное приложение (subject application). Мы хотели избежать создания условий, напоминающих “чистую комнату”, в которых часто проводятся тесты такого рода. Поэтому вместо того чтобы создавать тестовое приложение, а затем портировать его на используемые в испытаниях языки, мы решили применить реальные приложения. Если говорить конкретно, мы выбрали портальные приложения, поскольку они написаны чуть ли не на всех скриптовых языках и на каждом из них мы могли создавать почти идентичный тестовый сценарий.

Мы воспользовались теми порталами, которые сочли достаточно популярными: Microsoft SharePoint Portal Server 2003 (использует ASP), XOOPS (PHP), Plone (Python), а также Liferay и JBoss Portal (JSP).

Что касается серверов, то наши тестовые системы были построены на базе процессоров AMD Opteron, имели дисковые RAID-массивы с интерфейсом SATA (Serial ATA) и 2 Гб RAM. Для каждой СУБД выделялся отдельный компьютер.

Нагрузка, создаваемая виртуальными клиентами, генерировалась рабочей станцией с процессором AMD Athlon 64 под управлением Windows XP. Во всех тестах использовалась имеющаяся в лаборатории eWeek Labs сеть Gigabit Ethernet. Каждый тест проводился несколько раз, чтобы нивелировать условия испытаний и избежать случайных результатов.

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

В конечном счете мы решили воспользоваться инструментом Borland SilkPerformer (ранее он выпускался компанией Segue Software) как непосредственно для тестирования, так и для подготовки отчетов. При выполнении каждого теста продолжительностью около часа SilkPerformer создавал нагрузку на стек приложений в виде 1 тыс. виртуальных клиентов.

При тестировании ИТ-стеков мы написали сценарий для выполнения простых задач, которые можно воспроизвести на любом портале. Эти задачи включали загрузку идентичной страницы с каждого портала, загрузку страниц пользователей и просто навигацию по порталу. Мы предпочли свободно доступные страницы вместо тех, которые требуют аутентификации пользователей, поскольку не хотели, чтобы наши испытания превратились в тестирование систем аутентификации.

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

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

Как и любое масштабное сравнительное тестирование, наши испытания ИТ-стеков не лишены слабых мест.

Могут сказать, что мы тестировали испытательные приложения - порталы, а не сами стеки. Конечно, можно было бы возразить, что тесты с использованием самостоятельно разработанных приложений предметной области были бы проверкой не столько стеков, сколько навыков программистов по переносу приложений на другие платформы.

Кроме того, многие протестированные нами платформы не предназначены для конечных пользователей. Например, Plone рекомендуется применять в промышленных условиях на кластерах или прокси-серверах Apache.

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

Как мы ожидаем, наибольшую критику вызовет то обстоятельство, что мы не протестировали некоторые стеки, в том числе коммерческие платформы J2EE вроде тех, что выпускают BEA Systems, IBM, Oracle и Sun Microsystems, а также многие иные сочетания СУБД и серверных платформ.

Надеемся, что со временем мы, а также читатели, которые проведут эти тесты и поделятся своими результатами, сможем ответить на подобную критику. Мы планируем опубликовать итоги наших новых тестов по адресу blog.eweek. com/blogs/eweek_labs и приглашаем вас также поделиться здесь своими данными.

LAMP

Среди проведенных нами тестов наиболее близким к “чистому” стеку LAMP был тест с использованием SUSE Enterprise Linux, Apache, MySQL и системы управления порталом и контентом XOOPS. Мы выбрали XOOPS ввиду ее широкой популярности и высокого ранга, присвоенного ей на сайте sourceforge.net среди порталов на базе PHP.

Среднее число обращений в секунду

Почти в любом из проведенных нами тестов такая конфигурация LAMP на основе PHP демонстрировала достойную производительность, занимая место в середине списка.

Средняя пропускная способность, Кбит/с

Например, средняя пропускная способность составила 120,59 Кбит/с, а среднее число обращений - 24,15 в секунду. Если учесть, что конфигурация была совершенно стандартной, без какой-либо подстройки параметров, эти цифры производят более сильное впечатление, чем может показаться на первый взгляд. Даже самые горячие сторонники PHP согласятся, что этот язык разрабатывался не в расчете на достижение высокой производительности. Обычно они рекомендуют использовать кластеры или внешние ускорители вроде тех, что выпускает вендор PHP - компания Zend Technologies.

Показатели производительности этого стека позволяют сделать вывод, в правильности которого убедились все, кто уже поработал с PHP (включая авторов некоторых наиболее активно используемых интернет-блогов), - PHP-система на базе “чистого” LAMP способна легко справиться с трафиком и нагрузкой в масштабе предприятия.

Linux J2EE

Мы запускали портал Liferay на стеке Linux J2EE ввиду его популярности как портальной системы на основе Java и несколько необычной базовой конфигурации. Liferay использует СУБД Hypersonic SQL (ныне называется H2 Database), написанную на Java и специально предназначенную для очень быстрой работы с Web-приложениями. Мы запускали Liferay на компьютерах, и работавших под управлением CentOS Linux, где были установлены серверы Apache и Tomcat.

Возможно, это вызовет некоторое удивление, но в наших тестах данная конфигурация оказалась одной из самых производительных, показав прекрасную среднюю пропускную способность на уровне 1,56 Мбит/с и наибольшее среднее число обращений в секунду - 234,81.

Мы в значительной мере относим эту выдающуюся производительность на счет легкой СУБД Hypersonic SQL. Небольшие, узко ориентированные СУБД на протяжении многих лет показывают очень хорошие результаты в стандартных транзакционных тестах, сходных с нашими тестами производительности. Интересным дополнением таких тестов могло бы стать применение этих систем для решения задач, требующих более интенсивного обращения к базе данных.

Как бы то ни было, эти результаты выглядят весьма многообещающе для всех, кто заинтересован в работе с неоднородными стеками. Компании, изучающие ИТ-стеки, особенно предназначенные для простых транзакционных приложений, определенно должны обратить внимание на стек, в котором используется нестандартная, но потенциально высокопроизводительная СУБД.

Linux JBoss

Для испытания этого стека мы решили включить в его состав JBoss Portal. Компания JBoss - один из главных производителей серверных Java-приложений с открытым кодом, но JBoss Portal еще не достиг зрелости, если сравнивать его с другими рассматриваемыми нами портальными приложениями. Последние существуют уже на протяжении нескольких лет, многократно тестировались в реальных условиях и соответствующим образом дорабатывались.

Вероятно, эта незрелость и стала причиной того, что данный стек показал сравнительно невысокую производительность. Мы запускали JBoss в сочетании с MySQL под управлением ОС CentOS. И хотя производительность такого стека во всех тестах была не худшей, он неизменно оказывался в нижней части списка. (В защиту JBoss нужно сказать, что производительность JBoss Portal под управлением Windows была значительно выше, чем у JBoss в сочетании с CentOS Linux.)

Мы считаем, что со временем большинство присущих JBoss Portal недочетов будет устранено на всех платформах, как это произошло с родственным ему продуктом - сервером приложений.

Состав стеков

Заслуживает рассмотрения вариант использования JBoss в указанной комбинации с дополнительной подстройкой параметров, а также в сочетании с другими СУБД, включая Hypersonic SQL, так хорошо показавшей себя при тестировании стека на базе Liferay.

Linux Python

В одном из возможных вариантов стека LAMP буква “P” означает Python.

Наиболее популярным приложениям, входящим в стек с языком Python, а именно серверу приложений Zope и системе управления порталом и контентом Plone, не только безразлично, какие компоненты включены в стек, но они еще и стремятся заменить эти компоненты своими собственными. В наших тестах мы использовали Zope и Plone практически в “чистом” виде. Plone работал под управлением системы SUSE Enterprise Linux.

В некоторых случаях Plone показал среднюю производительность, занимая позиции ближе к середине списка. В действительности это значительно лучше, чем мы ожидали. Особенно, если учесть, что в документации по Plone усиленно подчеркивается, что в производственной среде Plone не следует применять как самостоятельный продукт, что для повышения производительности его необходимо использовать в сочетании с другими серверами.

Ответ на вопрос “Почему?” дают такие показатели, как среднее количество транзакций в секунду и среднее время загрузки, по которым Plone под управлением SUSE оказался среди наиболее медленных из протестированных нами систем (среднее время загрузки страницы составило 156,22 с, а среднее время загрузки документа - 75,94 с).

Наиболее часто такие значения стали появляться к концу теста, когда Plone начал испытывать стресс под воздействием высоких нагрузок, с которыми ему приходилось справляться. Тем не менее, основываясь на полученных нами результатах, можно предположить, что в качестве внутреннего сервера стек на базе “чистого” Python с использованием Plone скорее всего будет работать хорошо.

.Net

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

Для тестирования стека .Net мы взяли Windows Server 2003 R2, SQL Server 2005 и SharePoint Portal Server 2003. Вся эта конфигурация в целом показала очень хорошую производительность, достигнув наивысшей средней пропускной способности (с большим отрывом) в 4,59 Мбит/с.

Этот прекрасный результат мы в значительной мере относим на счет высокого уровня интеграции всех компонентов данного стека. Если системы с открытым кодом и системы на базе Java, как правило, разрабатываются независимо друг от друга, то все компоненты .Net целенаправленно создаются с учетом требований интеграции и согласованной совместной работы.

Даже если бы стек .Net потерпел полный провал в наших тестах, он, вероятно, все равно сохранил бы популярность во многих организациях. Но продемонстрированные им прекрасные результаты должны придать компаниям уверенность, что .Net удовлетворит большинство их самых сложных требований.

Среднее время загрузки страница (в с)

Windows и системы с открытым кодом

Поговорим о наших Ромео и Джульетте: ни сторонники открытого ПО, ни приверженцы Windows не готовы согласиться на брак серверных компонентов с открытым исходным кодом и ОС Windows.

ИТ-менеджеров, которые пытаются использовать бесплатные приложения в Windows-системах, часто считают скрягами и советуют им перейти на “настоящие” продукты для Windows. А многие из сторонников открытого ПО рассматривают WAMP как прекрасную конфигурацию для разработки или тестирования, но не подходящую для реальных производственных сред и требующую перехода на новую ступень, чтобы создать “настоящие” системы под управлением Linux и Unix.

Однако времена, видимо, меняются

Основываясь на наших посещениях конференций пользователей по многим наиболее важным корпоративным приложениям с открытым исходным кодом, можно сделать вывод, что нередко ИТ-менеджеры пытаются применять открытое ПО на серверах Windows. Несомненно, их привлекает возможность воспользоваться всеми преимуществами открытого ПО и его высокой производительностью без необходимости переквалифицироваться в администраторов Linux.

Результаты нашего тестирования стека WAMP показывают, что эти менеджеры, вполне вероятно, попали в струю. Наши стеки WAMP включали Windows Server 2003, Apache, MySQL и XOOPS (на базе PHP); Plone под управлением Windows Server 2003 R2; JBoss и MySQL с сочетании с Windows Server 2003.

Все эти три системы оказались в числе лидеров по числу транзакций в секунду. При этом JBoss под Windows значительно опередил своих собратьев под Linux, производя в среднем 16,79 транзакций в секунду. Эти конфигурации очень хорошо показали себя и в тестах на скорость загрузки. Средних результатов они достигли по усредненному количеству обращений в секунду и по средней пропускной способности.

Тем не менее на всем протяжении каждого теста ни одна из этих систем не оказалась перегруженной. Подобно черепахе из басни, они начинали работать несколько медленнее, но всегда устойчиво. Они никогда не выделялись, но и никогда не рушились.

Среднее время загрузки документа (в с)

Результаты, полученные нами при тестировании стеков WAMP, являются, возможно, самым большим сюрпризом за все время испытаний. Корпоративные ИТ-менеджеры не должны отказываться от рассмотрения варианта с развертыванием стеков с открытым исходным кодом на платформе Windows Server.

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

Пишите директору лаборатории Джиму Рапозе по адресу: jim_rapoza@ziffdavis.com.

Версия для печати