俄文网站引擎,WordPress主题设置保存,wordpress 一小时建站,网站建设开票多少个点jee过滤器应用场景我扮演的关键角色之一是在本地社区中传播Akka。 作为讨论的一部分#xff0c;人们通常会想到的问题/疑问是Akka如何针对编写良好的Java / JEE应用程序提供更好的可伸缩性和并发性。 由于底层硬件/ JVM保持不变#xff0c;因此参与者模型如何比传统的JEE应用… jee过滤器应用场景 我扮演的关键角色之一是在本地社区中传播Akka。 作为讨论的一部分人们通常会想到的问题/疑问是Akka如何针对编写良好的Java / JEE应用程序提供更好的可伸缩性和并发性。 由于底层硬件/ JVM保持不变因此参与者模型如何比传统的JEE应用程序散发更多功能 为了展示怀疑者我们决定在现有的JEE Web应用程序中进行小型测试对业务逻辑进行重新建模以利用参与者模型并对该模型进行测试。 日交易者应用 DayTrader是围绕在线股票交易系统范例构建的基准应用程序。 该应用程序允许用户登录查看其投资组合查找股票报价以及买卖股票。 DayTrader不仅是功能测试的出色应用程序而且还提供了一组标准的工作负载用于表征和衡量应用程序服务器和组件级别的性能。 DayTrader建立在一组Java EE技术的核心之上这些技术包括用于表示层和Java数据库连接JDBC的Java Servlet和JavaServer PageJSPJava消息服务JMS企业JavaBeansEJB和消息驱动的Bean。 MDB用于后端业务逻辑和持久层。 有关DayTrader的更多信息请点击这里 。 DayTrader似乎是测试我们理论的应用的合适之选。 我们决定使用JSP- JDBC模型来使事情保持简单和可比。 我们采用了2个用例并对业务逻辑进行了重新建模以使用TypedActors。 场景1 –报价/交易屏幕–获取报价 在DayTrader应用程序的“报价/交易者”屏幕中有一个工具可通过单击“报价”按钮来选择报价列表的详细信息。 股票的报价将被检索并显示给用户。 在标准流程中获取报价请求由专用的TradeAction处理该TradeAction在内部调用TradeDirectJEEE对象的getQuote接口。 对于每个请求都会创建一个TradeAction对象。 在更新的流程中创建了一组工作人员这些工作人员侦听来自各个模块的请求以获取报价详细信息。 TradeActionManager将在开始时创建Typed actor池并且还将具有将传入请求路由到Typed actor的操作Typeed actor包含TradeAction对象以调用getQuote函数。 由于使用了类型化角色因此相同的TradeActionManager可以在现有应用程序中进行最少的更改的情况下满足其他TradeAction调用。 原始的和修改后的DayTrader应用程序都由20个50个75个和100个Typed actor以及许多Trade Action对象执行。 该图显示了每种测试方案的相对吞吐量深红色的条表示原始应用程序的吞吐量值其他条表示不同的参与者池大小使用Akka的应用程序的吞吐量。 Akka Typed Actors的每秒吞吐量比原始DayTrader应用程序对于更大的actor池大小要好并且具有较少的内存使用尤其是700和300个用户*每个请求2个。 原始应用程序需要额外的168 MB来处理1400个请求700个用户每个请求2个请求而对于类型化参与者池大小为50个参与者的修改后的应用程序用于服务相同类型请求量的额外内存被观察为104 MB 提高了38 。 对于75和100个类型的actor观察到额外的内存使用量在126MB-136MB之间。 该图显示了每种测试方案的相对吞吐量深红色的条表示原始应用程序的吞吐量值其他条表示不同的参与者池大小使用Akka的应用程序的吞吐量。 使用Jmeter对获取报价的呼叫模拟是在相同的高负载条件下分别针对300个用户分别针对100个和200个演员的不同系统和Akka设置进行的大约需要45分钟。 观察到在相同条件下相对于原始应用程序将Typed Actor的数量从100增加到200相对可以将吞吐量提高约15和18。 还可以观察到将堆大小增加到1024 MB并将垃圾回收方法更改为并发标记清除有助于提高高负载条件下的吞吐量。 方案2 – 4个屏幕–登录主页获取报价购买 尝试了一个由4个用户屏幕组成的更复杂的用例其中用户将使用四个步骤来完成用例场景。 四个步骤是 用户通过登录页面登录 提交登录凭据后向用户显示主页。 获取股票的报价其符号由用户在主页屏幕上输入。 在每个符号下方提交要购买的数量后购买股票。 所有请求都使用TradeAction对象为请求提供服务。 TradeAction对象实现TradeService接口。 因此在这种情况下也应用了为报价/交易屏幕实现的相同TypedActor模型–在上一案例中确定的“获取报价”业务情景并且在TradeAction模块中几乎没有或没有任何更改。 使用Jmeter对300个具有不同Typed Actor池大小的用户进行了由四个屏幕组成的用例仿真。 用户数量设置为在60秒内增加到最多300个用户并且测试运行了15分钟。 可以看到将actor的数量从0增加到300可以将吞吐量提高大约8。 超过300个Typed actor的任何增加都显示出较小的改进。 与原始应用程序的内存使用率相比使用相同类型的actor的应用程序的峰值内存使用率在相同吞吐量100个类型化的actor的情况下提高了约30-40。 结论 即使进行了简单的更改在标准笔记本电脑上运行的应用程序仍能够提供更高的吞吐量 8 并且整体内存使用率下降了38 这表明actor模型的效率以及Akka对内存和线程的处理效率。 测试环境详情 处理器– Intel Core i5-2410M CPU 2.30 GHz 内存– 4 GB 操作系统– Windows 7 Enterprise 应用程序服务器– Apache Geronimo v2.2.1 编译器和构建工具– Apache Maven v2.2.1 Java版本– 1.7.0_03 Akka版本– Akka 2.0.2 数据库– Apache Derby 我们可以做的其他优化 基于请求模式进行分组的Akka未类型化参与者池。 说一个小池仅满足不那么频繁使用的请求而一个大池或多个池满足更频繁使用的请求例如“获取报价”或“获取帐户”。 可以基于请求模式更改池大小的比率以获得更好的吞吐量。 使用actor的PreStart和PostStart函数为数据库添加初始化任务例如获得连接和关闭连接或任何其他初始化任务。 Akka无类型演员用于并发处理持股同一帐户和会话的多个报价。 使用Akka actor层次结构以便有多个级别的actor而更高级别的supervisor actor将一个任务划分为多个较小的子任务并委派给下一级别的子actor。 优化actor系统的Akka调度程序线程池大小。 我想对我的同事Chintu Vijay表示感谢他进行并运行了测试。 参考 Akka Essentials博客上的JCG合作伙伴 Munish K Gupta 向JEE Apps添加了涡轮增压器 。 翻译自: https://www.javacodegeeks.com/2013/01/adding-turbochargers-to-jee-apps.htmljee过滤器应用场景
