同的负载类型和通信协议的大型机。
这样的外部系统调用意味着客户端的Java EE应用程序触发创建或重用套接字链接从外部系统中读写数据。根据业务流程的实施和实现可以配置成同步调用或异步调用。需要注意的是,响应时间会根据外部系统的稳定状况进行改变,所以通过适当的使用超时来保护Java EE应用程序和中间件也是非常重要的。
下面这3种情况是经常出现问题和性能降低的地方:
同步和相继调用太多的外部系统。
在Java EE客户端应用程序和外部系统之间链接超时,使数据丢失或者值太高导致客户端线程被卡住,从而导致多米拉效应。
超时,但程序仍正常执行,可是中间件不处理这种奇怪的路径。
最后,建议多进行负面测试,这意味着需要“人为”创造产生这些问题的条件,用来测试应用程序和中间件之间是如何处理外部系统错误。
5.缺乏适当的数据库SQL调优和容量规划
大家可能会对这一个感到惊奇:数据库问题。大多数Java EE企业系统是依赖关系型数据库处理复杂的业务流程。一个基础扎实稳固的数据库环境可以确保IT环境有规模的增长,来支持日益不断扩大的业务。
在实际中,与数据库相关的性能问题是很常见的。由于多数数据库事务处理都是由JDBC数据源执行的(包括关系持久化API,例如Hibernate)。而性能问题最初都会表现为线程阻塞。
以下是我在10年的工作中,经常出现的关于数据库方面的问题(以Oracle数据库为例):
孤立的,长时间运行的SQL。主要表现为线程阻塞、SQL没有进行优化、缺少索引、非最佳的执行计划、返回大量数据集等等。
表或行级数据锁定。当提交一个双阶段事务模型时(例如,臭名昭著的Oracle可疑事务)。Java EE容器可能会留下一些未处理的事务等待最后的提交或回滚,留下的数据锁能触发性能问题,直到最后的锁被移除。例如中间件断电或者服务器崩溃都可能引起这些情况发生。
缺乏合理规范的数据库管理工具。例如Oracle里面的REDO logs,数据库数据文件等。磁盘空间不足,日志文件不旋转等都会触发较大的性能问题和断电情况。
建议:
合理的容量规划,包括负载和性能测试都是必不可少的,优化数据环境和及时发现问题。
如果是使用Oracle数据库,确保DBA团队定期审查AWR报告,尤其是在上下关联的事件和根源分析过程中。
使用JVM线程存储和AWR报告查明SQL运行缓慢的原因或者使用监控工具来做。
加强“操作”方面的数据库环境(磁盘空间、数据文件、重做日志、表空间等)以适当的监视和报警。如果不这么做,会让客户端IT环境出现较多的断电情况和花许多时