英语原文共 8 页，剩余内容已隐藏，支付完成后下载完整资料
用于Web API开发的Java EE和ASP.NET Core技术的性能比较
Kristiāns Kronis1, Marina Uhanova
Riga Technical University, Riga, Latvia
摘要：本文描述了Java EE和ASP.NET Core的性能测试的实现，用于比较语言运行时的性能特征。性能测试创建为REST服务，以JSON格式处理数据。ASP.NET Core的实现使用Kestrel Web服务器，而Java EE的实现使用基于Apache Tomcat的Apache TomEE。为了调用性能测试并收集其结果，创建了一个分析服务。这个服务使用Express with ES6(用于其异步功能)，Redis和MySQL，还使用Angular 5创建了一个基于Web的界面，利用此服务显示结果。
关键词：性能测试；计算机语言；编程；软件性能。
1 引言
由Oracle开发的Java EE(Java Platform, Enterprise Edition)和Microsoft开发的ASP.NET(Active Server Pages .NET)都提供创建Web应用程序的功能。 但是在过去，Java EE相比ASP.NET具有更好的跨平台支持——可以在Windows和GNU / Linux操作系统上安装Oracle支持的JVM(Java Virtual Machine) H的otSpot实现。 而完整的.NET Framework不能在GNU / Linux上运行，必须使用Mono。Mono最初是一个开源项目，并且在2016年才被Microsoft收购[1] 。它不支持WPF(Windows Presentation Foundation)，WWF(Windows Workflow Foundation)，为WCF(Windows Communication Foundation)和ASP.NET [2]提供有限的支持。
但是，随着2016年.NET Core的发布以及随后的ASP.NET Core [3]，微软公司正在支持更多的操作系统。 现在，由于GNU / Linux上已有CLR(Common Language Runtime)的实现，加上ASP.NET的现代重写版本和新的Web服务器——Kestrel [4]。重新评估哪个技术栈更适合新项目是十分有帮助的。
我们通过检查它们的不同之处来进行评估。比如，Kestrel web服务器或IIS服务器与最流行的Java web服务器，如Apache Tomact，有什么不同，运行在相似而且常见配置下的典型用例的运行时性能有何不同。
本文描述了一个系统的实现，这个系统用于运行组织好的性能测试程序并收集它们的结果，它能为用户提供即时可见的反馈。性能测试的目的是获得两种技术栈在GNU/Linux操作系统上的性能近似值，并突出任何明显的差异。我们为软件架构和实现指定了通用准则，以保证软件有生成数百个并发请求并有效地处理他们，以及处理任何的错误的能力。
使用JSON(JavaScript Object Notation)进行数据传输的REST(Representational State Transfer)API在两种技术中都有描述和实现，且部署在同一个服务器上。另外，实现了一个单独的应用程序，包括Angular 5编写的测试配置的前端，用Express和Node.js编写的后端。后端使用Redis做临时存储和MySQL做日志。系统的设计是模块化的——实现测试API的服务器可在前端界面进行配置，另外可以配置Redis和MySQL日志。
尽管我们没有声明这样的结果是客观的，但是此系统可以作为一个起点进行拓展，比如增加更多的服务器，它们可以在没有代码更改的情况下运行不同的语言和软件和硬件配置；或者扩展将要运行的性能测试。总之应该有必要为将来更多的特定测试做准备。
2 Java EE
Java EE(Java Platform，Enterprise Edition)是Java SE(Java Platform，Standard Edition)的超集，它扩展了通用的Java API，以提供在企业环境下拥有的特性，例如依赖注入(CDI，EJB)，事务管理(JTA)和动态网页功能(JSP，JSF)，以及用于创建web服务的功能(JAX-RS，JAX-WS)，同时缩短了开发时间和软件的复杂性(图1)[6]。此次开发由Java Community Process(JCP)组织，基于Java Specification Requests(JSR)。
本文描述了一个发布于2013年的使用Java EE 7的配置[7]。Java EE 7平台可进一步分为Full Platform和Web Profile，其目的是为了提供更有限的功能集合，因为这样更容易支持。开发的API利用了Servlets、JSON、CDI和JAX-RS，因此使用了Full Platform规范的元素。
之所以选择Java EE 7，是因为在撰写本文时，Java EE 8的使用有限，仅有Glassfish 5.0和Payara 5支持Java EE 8规范，且这两者不如基于Apache TomEE的Apache Tomcat那样受欢迎。
图1 Java EE Full Platform和Web Profile规范图
3 ASP.NET
ASP.NET(Active Server Pages .NET)是微软公司开发的基于CLR的web应用框架[9]。它提供的功能类似Java EE。比如，Web Forms允许创建和JSP和JSF类似风格的动态内容(图2)[10]。组件中的ASP.NET Web API、ASP.NET AJAX、ASP.NET MVC提供了不同的功能[12]。ASP.NET通常运行在IIS(Internet Information Services)上，微软公司不支持在GNU/Linux上的IIS，因此，我们必须使用Kestrel。
图2 包含ASP.NET的.NET Framework Architecture图
4 ASP.NET Core
ASP.NET Core是由微软公司和社区贡献者开发的下一代ASP.NET[12]，可以运行在完整的.NET Framework和.NET Core平台。ASP.NET Core是ASP.NET的重写版，它旨在提供更加纤薄但更现代的功能集，以及一个轻量的web服务器Kestrel(尽管在Windows仍可以使用IIS)。Kestrel服务器支持多个组件－Entity Framework Core、MVC Core和Razor Core[13]等，这些组件可以替代ASP.NET中的那些组件。
5 测试要求
为了确保最佳结果，不受操作系统配置的干扰，我们定义了系统设计的一些指导原则：
1. API的实现应该放在不同的服务器上。在这种情况下，应使用VPS(virtual private server)。
2. 两台服务器应具有相同类型和版本的操作系统。我们选择Ubuntu 16.04.4 LTS。
3. 为了确保服务器表现相同。它们将用综合性能测试。两者都将进行相同类型的性能测试。这里，使用sysbench 0.4.12。
4. 服务器应运行有着相同更新的相同软件，区别仅在于运行程序所需的软件包——Open JDK和.NET Core。
5. 不使用反向代理(如Apache httpd或nginx)测试特定技术栈的服务器的性能(Apache TomEE和Kestrel)。
此外还规定了如何进行测试以防止测试系统自身的实现而导致的内存泄漏和错误：
1. 调用基准测试的服务不应超过系统的负载容量。这是通过顺序测试每个API来避免服务被负载影响，尽管还可以并行地运行单个测试的多次。
2. 使用调度器简单地添加和删除要被运行的测试。调度器是由前端实现的，因此不会将测试服务限制成顺序执行，仅仅允许它以这种方式使用。考虑到未来的效果，应该有一个对多个API并行测试的能力。
3. 应该尽量减少系统各层(API、测试服务、前端)之间无关的数据交换。在这里，测试请求的内容是由测试服务自身生成的，且仅和要测试的API交换，前端只接受结果。
4. 测试结果可以根据前端的请求分块提供。在所有调度的测试完成之前，如果没有检索，测试结果将会过期。
5. Web界面应该是轻量级的。这是通过将结果进行分组并在超过100次测试时显示该组的平均值来实现的，以防止图表框架影响性能。
MySQL数据库可用于更加精确地分析结果。
6 测试系统组件的详细信息
此系统有几个组件组成，每个组件使用通用的技术重新创建配置，这些组件可以在实际使用中找到。
A.Java API实现
Java API的实现使用Java EE特性且在可能的情况下避免使用三方框架，如Spring。此实现运行在Apache TomEE Web Profile 7.0.2， 它通过使用开源组件(OpenEJB，Apache CXF等)[14]提供Java EE 7 Web Profile的功能。它基于Apache Tomcat——一个流行的开源容器[15]，运行在Open JDK 1.8.0_151上。
B.ASP.NET Core API实现
ASP.NET Core API使用ASP.NET Core特性实现，且如果可能，避免使用第三方的框架。
它运行在Kestrel web服务器2.0.1上。这个发行版可以运行在.NET Core 2.1.3.
C. Node.js Express测试服务
测试服务在Node.js 9.2.1上运行，基于Express 4.15.5。它使用cors、redis和request-promise-native包(通过npm安装)等，以提供必要的功能。
D.Angular 5 Web界面
前端由Angular 5、TypeScript 2.5.3和Bootstrap 4创建，Bootstrap 4和JQuery 3.21.组合提供用户界面的样式和行为。此外ng2-charts用作Angular和Chart.js的桥梁，Chart.js是一个提供基于HTML5的图形显示功能的框架[16]。
7 前端的设计
前端部分用作系统其它界面的外观，且允许配置要使用的Redis和MySQL，以及要进行测试的服务器。
应用程序的结构基于一个Angular模块，此模块提供存储与设置测试相关的数据的服务。后者包含测试条目本身——有关测试类型的数据、次数和其他参数——要使用的服务器。每个测试都有一个服务器对象的引用。
应用程序的其他部分由工具类(比如枚举或通知组件)和用于显示数据和组织输入和输出的组件组成。后者包含选项卡、菜单和图表组件。
界面是标签化的，在任何时间仅显示与用户相关的信息，选项卡有用于运行测试和显示其结果的选项卡(图3)，以及配置服务器的选项卡和更改系统设计的选项卡。
图3 列举可提供的测试类型的测试选项卡的web界面图
图4 列举当前服务器的服务器配置选项卡的web界面
最后，性能测试过程还尝试将请求运行时间的图表作为它的组件。这些组件以不同的方式显示请求在网络上花费的时间和花费在处理请求的时间。横轴显示迭代和迭代范围(如果运行超过100次迭代)，竖轴显示执行时间(以ms为单位)
图5 web界面的一部分，显示测试结果和控制更改参数
这些都是通过系统的自行报告获取的，并以柱状图的形式显示。其中柱状图的底栏显示在API上的测试执行时间，而顶栏显示剩余的时间，这段时间为获取测试服务的请求的时间(通过在总时间中减去执行时间来计算)。
8 前后端之间的通信
系统的各层采用HTTP请求进行通信(图6)，此功能由HttpClient类、Angular端的JavaScript Json类和后端body-parser功能的Express路由组合提供。
选择此格式是因为JSON格式将内容用作其他的JavaScript对象，使得层之间能简单地交换信息。
图6 网络请求图，某种可能的配置是redis作为后端的内部部分
测试服务暴露了两条路径：/schedule和/results，前者允许安排新的测试执行，后者可以通过前端轮询，接收和清除存储在Redis中的结果列表，以及检查执行是否完成。两者都因Redis的存储性能使用其作为临时存储，它使用RAM(random access memory)。Redis可以通过express-redis库访问，该库实现了官方API并且允许原子访问[17]。唯一的例外就是设计表的TTL值，这是通过一个单独的调用完成的，如果值在一定时间内不被请求就会到期。
为了调试，所有各层之间的通信在浏览器的控制台或者Node.js的输出中用日志记录下来并重定向至一个文件。
当在测试服务上启动一个测试时，所有执行相关数据必须在第一次请求中传递，这些数据包括：测试的类型，运行的测试，唯一标志符，测试API要使用的信息，以及
剩余内容已隐藏，支付完成后下载完整资料
资料编号：[19816]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
课题毕业论文、外文翻译、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
