Logo    
Деловая газета CitCity.ru CITKIT.ru - все об Open Source Форумы Все публикации Учебный центр Курилка
CitForum    CITForum на CD    Подписка на новости портала Море(!) аналитической информации! :: CITFORUM.RU
IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

29.04.2017

Google
WWW CITForum.ru
С Новым годом!
2004 г.

.NET vs. Java

Олег Ремизов, "Комиздат"

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

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

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

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

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

Но существуют, как минимум, три недостатка реализации логики с помощью хранимых процедур.

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

Вторая причина: каким бы мощным ни был диалект SQL, реализованная на нем логика все равно будет работать в десятки, а то и в сотни раз медленнее, чем логика, реализованная на Java, C++ или C#.

Еще одна причина: слабая переносимость нестандартного SQL-кода. Написанием бизнес-логики на северной стороне вы фактически отрезаете себе путь к использованию других баз данных или делаете его очень дорогостоящим. Гораздо проще потом убедить клиента в том, что СУБД, которая используется в вашем приложении, лучше той, которая у него уже есть (хорошо, если у него вообще ничего нет), чем переписывать вашу логику для другого сервера баз данных. Иногда это просто невозможно.

То есть, говоря проще, приложение, построенное по современной архитектуре, должно использовать базу данных в режиме ANSI SELECT/UPDATE и не иметь значительной логики на стороне клиента. Вся логика должна быть реализована в промежуточном слое, называемом сервером приложений.

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

Естественно, если существует жесткая привязка к платформе UNIX, то выбор сервера приложений или платформы для его реализации на сегодняшний день можно считать уже предопределенным - это Java2. В случае принятия решения об использовании готового сервера приложений будет выбран сервер стандарта J2EE - очевидно, что реализация компонентов внутренней бизнес-логики будет выполнена с использованием Java2.

Если вы собираетесь развернуть ваш сервер приложений на платформе Windows, то у вас есть альтернатива в виде C# и COM+. То, что COM+ работает в 2-4 раза быстрее, чем его аналоги, реализованные в соответствии с J2EE-стандартом, подтверждают многочисленные тесты, проделанные как сторонними фирмами, так и самой Microsoft. Объясняется это соотношением нейтив- и интерпретируемого кода: сервера приложений стандарта J2EE сами реализованы с использованием Java2, в то время как С#, напротив, служит только диспетчером, главная задача которого - вызов сравнительно быстродействующего исполнимого нейтив-кода COM+.

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

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

Описание тестового приложения и условий тестирования

Для сравнения двух основных платформ для создания серверных приложений автор создал идентичные тестовые приложения на C# и Java. Для компиляции и запуска C# приложения использовалась майкрософтовская реализация DOT.NET машины Rotor версии 1.0. Для компиляции и запуска Java2-приложения использовалась Java-машина и компилятор, входящие в состав JDK 1.3.

Основные характеристики компьютера, на котором происходило тестирование: Pentium II 366, 256 RAM. Операционная система - Windows 2000 SP2 Workstation.

Тестирование проводилось для ста тысяч объектов. Бизнес-класс Man имеет в своем составе три поля: Name, Sex и Age. Два из них имеют тип String, а последнее - тип Integer. Инициализация всех трех полей происходит в конструкторе объекта.

Также определены две функции сравнения объекта - по имени и возрасту.

В первом цикле приложения происходит создание всех бизнес-объектов и их сохранение внутри коллекции ArrayList. Во втором цикле происходят итерации по этой коллекции с вызовом функции сравнения объекта по имени. Когда пятидесятитысячный объект найден, происходит выход из цикла. Третий цикл делает то же, что и второй,- с той лишь разницей, что сравнение проводится по возрасту. В общей сложности происходит сто тысяч итераций по коллекции. Затем - запись всех объектов на диск. ArrayList очищается посредством вызова метода Clear (), после чего происходит чтение всех объектов с диска и сохранение их в ArrayList.

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

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

Особенности сериализации объектов в C# и Java2

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

Для того чтобы сделать объект записываемым в Java2, необходимо пометить его как объект, реализующий интерфейс implements Serializable. Это указывает компилятору, что необходимо встроить в байт-код объекта байт-код, отвечающий за сохранение объекта этого типа на диск. В C# код сохраняемого объекта должен быть помечен с помощью атрибута [Serializable] перед определением класса - то есть принцип остается тем же, но сам механизм сохранения выглядит немного иначе. Дело в том, что в C# вы сами можете определить свой форматер - класс, который отвечает за формат хранения данных на диске. Так, кроме стандартного бинарного форматера, в C# также предусмотрен форматер, сохраняющий данные в XML-формате, что может быть весьма наглядным, но далеко не быстрым способом представления данных. По умолчанию, в Java2 данные сохраняются в бинарном виде - других форматов хранения данных не предусмотрено.

Результаты тестирования

Для ста тысяч объектов были получены следующие результаты.

Для работы с объектами в памяти мы получили приблизительно 700 мс для C# приложения и 2400 мс - для Java2-приложения. Получается, что DOT.NET-машина при данном количестве объектов работает с объектами в памяти втрое быстрее, чем Java-машина. Возможно, если бы бизнес-класс в C# был описан как структура, мы получили бы еще большую разницу в скорости.

Тестирование скорости при сохранении/чтении данных на диск, напротив, дало не лучшие результаты для C#-приложения. Оно записывало на диск и читало с диска 100000 объектов в течение приблизительно 42-х секунд. Java-приложение справилось с этой же задачей за промежуток времени, равный всего 18-ти секундам,- то есть более чем вдвое быстрей.

Также имеет смысл отметить разницу в размере файлов, созданных приложениями. Для приложения Java2 этот показатель составил 2688961 байт, а для приложения C# - 16188890 байт. Компания Sun Microsystems очень хорошо оптимизировала эту часть своей технологии. Хотя надо отметить, что эти результаты нельзя считать вполне корректными, поскольку в наших объектах было очень много повторяющихся данных. В реальных объектах вашего приложения степень корреляции межу ними будет гораздо ниже - тем не менее, она не исчезнет совсем. Поэтому можно предположить, что весьма значительная разница в скорости все равно останется. Для иллюстрации сказанного ниже приводится диаграмма временных соотношений (см. рисунок).

Выводы

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

Если учесть, что затраты времени на поиск данных в коллекции можно сократить, используя связку "сортировка - бинарный поиск", а также то, что затраты времени при сохранении данных на диск значительно выше затрат времени при осуществлении работы с объектами в памяти,- то для большинства серверных приложений более предпочтительным выбором будет использование платформы Java2.

Однако автор при этом не исключает возможности реализации своих собственных механизмов сохранения данных на диск для приложений, реализованных с использованием C#. В конечном счете, все зависит от бюджета вашего проекта. Если вам нужно построить real-time приложение, где необходима, прежде всего, скорость реакции на сигналы, а устойчивость данных не имеет большого значения, то тут лучшим выбором будет использование C#. Конечно, в этом случае разработка приложения на C++ даст лучшие результаты, если у вас достаточно денег и времени. Еще один плюс в пользу C# - это то, что в месте, где у вас возникают проблемы с быстродействием системы C#, код может быть с легкостью заменен кодом С++. Конечно, это возможно и в Java, однако при этом трудозатраты будут неизмеримо выше.

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

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

Недавно Microsoft выпустила новую версию DOT.NET-машины 1.1 - возможно, при тестировании приложения с ее помощью мы бы получили лучшие результаты. Кроме того, сегодня существует JDK 1.4, включающий более оптимальную версию Java2-машины. Вы можете произвести дополнительное тестирование самостоятельно, воспользовавшись кодом приложений, приведенных на диске. Проекты тестовых приложений выполнены с использованием сред разработки JBuilder7 и Visual Studio.NET соответственно.

Размещение рекламы — тел. +7 495 4119920, ICQ 232284597

Подписка на новости IT-портала CITForum.ru
(библиотека, CITKIT.ru, CitCity)

Новые публикации:

24 декабря

CITKIT.ru:

  • Новогодние поздравления
  • Сергей Кузнецов. Цикл Операционные системы: Ностальгия по будущему:

  • Алексей Федорчук. OpenSolaris 2008.11 Release

  • Сергей Голубев:

  • Евгений Чайкин aka StraNNik (Блогометки):

    17 декабря

  • С.Д.Кузнецов. Базы данных. Вводный курс

    10 декабря

    CITKIT.ru:

  • OpenSolaris 2008.11 Release

  • Альтернативные ОС: две грустные истории (С.Кузнецов)
  • Nokia N810 — доведение до ума
  • CitCity:

  • Платформа 2009: заоблачные перспективы Microsoft

    4 декабря

  • Лекция С.Д.Кузнецова Понятие модели данных. Обзор разновидностей моделей данных

    CITKIT.ru:

  • OpenSolaris 2008.11 Release. Первые впечатления

  • Linux vs FreeBSD: продолжим "Священные войны"?

  • Nokia N810 as is

  • Индульгенция для FOSS

  • Друзья СПО'2008

    26 ноября

  • Нечеткое сравнение коллекций: семантический и алгоритмический аспекты

    CitCity:

    CITKIT.ru:

  • Глава из книги А.Федорчука
    Сага о FreeBSD:
  • 19 ноября

  • Проблемы экономики производства крупных программных продуктов

  • Язык модификации данных формата XML функциональными методами

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

    Заметки к книге:

  • FreeBSD: монтирование сменных устройств и механизм HAL
  • Текстовый редактор ee

    12 ноября

  • Правило пяти минут двадцать лет спустя, и как флэш-память изменяет правила (Гоц Грейф, перевод: Сергей Кузнецов)

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:
  • OSS в России: взгляд правоведа (В.Житомирский)

  • Новая статья из цикла С.Голубева "Железный марш":

    29 октября

  • О некоторых задачах обратной инженерии

  • Веб-сервисы и Ruby

  • Тестирование web-приложений с помощью Ruby

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

  • PuppyRus Linux - беседа с разработчиком (С.Голубев)

  • Сергей Кузнецов. Заметка не про Linux

    22 октября

  • Обзор методов описания встраиваемой аппаратуры и построения инструментария кросс-разработки

    CITKIT.ru:

  • Сергей Кузнецов. Почему я равнодушен к Linux

  • Глава из книги А.Федорчука
    Сага о FreeBSD:
  • Что надо иметь
    3. Базовые познания

    CitCity:

  • Управление IT-инфраструктурой на основе продуктов Microsoft

    15 октября

  • Методы бикластеризации для анализа интернет-данных

    CitCity:

  • Разъемы на ноутбуках: что они дают и зачем их так много?
  • AMD Puma и Intel Centrino 2: кто лучше?

    CITKIT.ru:

  • Новый цикл статей С.Голубева
    Железный марш:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

    8 октября

  • Автоматизация тестирования web-приложений, основанных на скриптовых языках
  • Опыт применения технологии Azov для тестирования библиотеки Qt3

    Обзоры журнала Computer:

  • SOA с гарантией качества
  • Пикоджоуль ватт бережет
  • ICT и всемирное развитие

    CitCity:

  • Пиррова победа корпорации Microsoft

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

    Статья из архива:

  • Я живу в FreeBSD (Вадим Колонцов)

    Новые Блогометки:

  • Перекройка шаблона Blogger или N шагов к настоящему
  • Blogger. Comment style
  • Screenie или глянцевый снимок экрана

    2 октября

    CITKIT.ru:

  • Сага о FreeBSD (А. Федорчук)

    Zenwalk: пакет недели

  • Банинг — интеллектуальное развлечение (С.Голубев)

    CitCity:

    25 сентября

  • Клермонтский отчет об исследованиях в области баз данных

    CITKIT.ru:

  • Пользователям просьба не беспокоиться... (В.Попов)

  • Снова про ZFS: диск хорошо, а два лучше
  • Командная оболочка tcsh (А.Федорчук)

    Zenwalk: пакет недели

    17 сентября

  • T2C: технология автоматизированной разработки тестов базовой функциональности программных интерфейсов
  • Технология Azov автоматизации массового создания тестов работоспособности

    CITKIT.ru:

  • FreeBSD: ZFS vs UFS, и обе-две — против всех (А.Федорчук)

    Zenwalk: пакет недели

  • Дачнет — практика без теории (С.Голубев)

    10 сентября

  • За чем следить и чем управлять при работе приложений с Oracle
  • Планировщик заданий в Oracle
    (В.Пржиялковский)

    CITKIT.ru:

  • Microsoft: ответный "боян" (С.Голубев)

  • Причуды симбиоза, или снова "сделай сам" (В.Попов)

  • Файловые системы современного Linux'а: последнее тестирование
  • Zsh. Введение и обзор возможностей
    (А.Федорчук)

    Описания пакетов Zenwalk: Zsh, Thunar, Thunar-bulk-rename, Xfce4-places-plugin, Xfce4-fsguard-plugin

    Блогометки:

  • Google Chrome
  • Лончер для ASUS Eee PC 701

    3 сентября

    CITKIT.ru:

  • Заметки о ядре (А.Федорчук):

    Добавлены описания пакетов Zenwalk: Galculator, Screenshot, Gnumeric, Pidgin

    В дискуссинном клубе:

  • И еще о Википедии и Google Knol

  • Лекция для начинающего линуксоида (С.Голубев)

    26 августа

  • Транзакционная память (Пересказ: С. Кузнецов)

    CITKIT.ru:

  • Открыт новый проект Zenwalk: пакет недели

  • Статья Текстовые процессоры и их быстродействие: конец еще одной легенды?

    21 августа

    CITKIT.ru:

  • Почему школам следует использовать только свободные программы (Ричард Столлман)
  • Беседа Сергея Голубева с учителем В.В.Михайловым

  • Википедия или Гуглезнание? Приглашение к обсуждению (Алексей Федорчук)
  • Народная энциклопедия от Google (StraNNik)

  • Обзор Mandriva 2009.0 Beta 1 Thornicrofti
  • Новичок в Линукс: Оптимизируем Mandriva 2008.1

  • Книга Zenwalk. Приобщение к Linux:

    13 августа

    CitCity:

  • Мирный Atom на службе человеку. Обзор платы Intel D945GCLF с интегрированным процессором
  • Обзор процессоров Intel Atom 230 на ядре Diamondville

  • iPhone - год спустя. Скоро и в России?

    CITKIT.ru:

  • Интермедия 3.4. GRUB: установка и настройка (из книги Zenwalk. Приобщение к Linux)

    6 августа

  • СУБД с хранением данных по столбцами и по строкам: насколько они отличаются в действительности? (Пересказ: С. Кузнецов)

    CITKIT.ru:

  • Интермедия 2.2. Что неплохо знать для начала (из книги Zenwalk. Приобщение к Linux)

  • И снова про шрифты в Иксах (А.Федорчук)

  • 20 самых быстрых и простых оконных менеджеров для Linux

  • Дело о трех миллиардах (С.Голубев)

    30 июля

  • OLTP в Зазеркалье (Пересказ: С. Кузнецов)

    CitCity:

  • Будущее BI в облаках?
  • Тиражные приложения и заказная разработка. Преимущества для заказчика
  • Дискуссия со сторонниками заказной разработки

    CITKIT.ru:

  • Новые главы книги Zenwalk. Приобщение к Linux:
  • Глава 8. Пакеты: средства установки, системы управления, системы построения
  • Глава 9. Zenwalk: репозитории, пакеты, методы установки

    23 июля

    CITKIT.ru:

  • Все против всех. 64 vs 32, Intel vs AMD, tmpfs vs ext3
  • Две головы от Intel

  • Zenwalk: обзор штатных приложений (глава из книги "Zenwalk. Приобщение к Linux")

  • Нормально, Григорий...

    16 июля

    Обзоры журнала Computer:

  • Перспективы и проблемы программной инженерии в XXI веке
  • Большие хлопоты с большими объемами данных
  • Перспективы наноэлектроники

    CITKIT.ru:

  • Интермедия о лицензиях (А.Федорчук. "Zenwalk. Приобщение к Linux")

  • Есть ли будущее у KDE?

  • Linux в школе: альтернативный вариант в задачах

  • Шифр (приключения агента Никодима)

    10 июля

    CITKIT.ru:

  • Новые разделы книги А. Федорчука Zenwalk. Приобщение к Linux:
  • Интермедия вступительная. Linux или GNU/Linux? Как вас теперь называть?
  • Глава 5. Среда Xfce
  • Глава 6. Xfce: приложения и плагины

  • ZUR (Zenwalk User Repository) FAQ

    2 июля

  • Персистентность данных в объектно-ориентированных приложениях (С. Кузнецов)

    CITKIT.ru:

  • Новые разделы книги А. Федорчука Zenwalk. Приобщение к Linux:
  • Интермедия 1.2. Дорога к Zenwalk'у. Период бури и натиска
  • Интермедия 3.3. Немного о Linux'е и "железе"
  • Глава 4. Настройка: инструментами и руками
  • Интермедия 4.1. Zenpanel и конфиги: поиски корреляции

  • Интервью с Жан-Филиппом Гийоменом, создателем дистрибутива Zenwalk

  • Linux в школе: первые итоги (С. Голубев)

    25 июня

    CITKIT.ru:

  • Zenwalk. Приобщение к Linux (А. Федорчук)

  • Логика и риторика (С.Голубев)

  • Технология Tru64 AdvFS

  • Ханс Райзер предлагает отвести полицейских к телу Нины

    18 июня

  • Проекты по управлению данными в Google (Пересказ: С. Кузнецов)

    CITKIT.ru:

  • ОС и поддержка "железа": мифы и реальность (А. Федорчук)

  • Linux в школе: другие дистрибутивы

  • Пинок (С. Голубев)

    4 июня

  • Ландшафт области управления данными: аналитический обзор (С. Кузнецов)

    CITKIT.ru:

  • Linux в школе: слово заинтересованным лицам

  • SlackBuild: пакеты своими руками

  • Linux от компании Novell. Установка и обзор openSUSE Linux

    Все публикации >>>




  • IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

    Информация для рекламодателей PR-акции, размещение рекламы — тел. +7 495 4119920, ICQ 232284597 Пресс-релизы — pr@citcity.ru
    Послать комментарий
    Информация для авторов
    Rambler's Top100 TopList liveinternet.ru: показано число просмотров за 24 часа, посетителей за 24 часа и за сегодня This Web server launched on February 24, 1997
    Copyright © 1997-2000 CIT, © 2001-2007 CIT Forum
    Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...