优化Java持久层性能：High-Performance Java Persistence精髓

需积分: 50 38 浏览量更新于2024-07-16 收藏 16.39MB PDF 举报

"High-Performance Java Persistence 是一本由Vlad Mihalcea编写的关于优化Java持久层性能的书籍，旨在帮助读者充分利用持久化层的潜力。本书涵盖了数据库服务器、连接性层、应用数据访问层（包括ORM框架和原生查询构建器）以及性能和扩展性的关键概念。" 在Java性能优化领域，这本书深入探讨了以下知识点： 1. **响应时间和吞吐量**：性能优化的主要关注点是响应时间（应用程序对请求的处理速度）和吞吐量（系统在单位时间内处理的请求量）。优化这两个指标对于提供高效服务至关重要。 2. **数据库连接边界**：数据库连接是应用性能的关键因素。了解和管理连接池的大小限制可以防止资源耗尽和性能瓶颈。 3. **扩展性策略**：包括垂直扩展（Scaling Up，通过增强单个服务器的能力来提高性能）和水平扩展（Scaling Out，通过增加服务器数量来分散负载）。书中还提到了主从复制、多主复制和分片等不同的扩展模式。 4. **JDBC连接管理**： - **DriverManager**：Java标准API，用于建立和管理数据库连接，但效率较低，不适合高并发环境。 - **DataSource**：推荐的连接管理方式，尤其是连接池，如C3P0、HikariCP等，可以显著提高性能和资源利用率。 - **连接池原理**：通过复用已建立的数据库连接，减少创建和关闭连接的开销，提高系统效率。 - **容量规划**：基于队列理论进行数据库连接的容量规划，确保在预期负载下系统的稳定运行。 - **实际应用示例**：书中可能包含监控连接池并分析关键指标（如并发连接请求计数、并发连接计数和最大连接数）的实际案例。 5. **ORM框架**：例如Hibernate，是Java开发中常用的对象关系映射工具，它简化了数据库操作，但也可能引入性能问题。书中可能探讨如何有效地使用ORM，避免N+1查询、懒加载等问题。 6. **原生查询构建器**：作为ORM的补充，允许开发者编写更高效的SQL查询，以绕过ORM可能带来的性能损失。此外，作者Vlad Mihalcea鼓励读者分享这本书，以推动Java持久化性能优化的知识传播。书中内容深入浅出，对于希望提升Java应用数据库性能的开发者来说，是一本宝贵的参考资料。

Performance and Scaling 6

Ideally, if the system was scaling linearly, adding more database connections would yield a pro-

portional throughput increase. Due to contention on database resources and the cost of maintaining

coherency across multiple concurrent database sessions, the relative throughput gain follows a curve

instead of a straight line.

USL (Universal Scalability Law)¹ can approximate the maximum relative throughput (system

capacity) in relation to the number of load generators (database connections).

C (N) =

1 + α (N − 1) + βN (N − 1)

• C - the relative throughput gain for the given concurrency level

• α - the contention coefficient (the serializable portion of the data processing routine)

• β - the coherency coefficient (the cost for maintaining consistency across all concurrent

database sessions).

When the coherency coefficient is zero, USL overlaps with Amdahl’s Law². Contention has the

effect of leveling up scalability. On the other hand, coherency is responsible for the inflection point

in the scalability curve, and its effect becomes more significant as the number of concurrent sessions

increases.

The following graph depicts the relative throughput gain when the USL coefficients (α, β) are set to

the following values (0.1, 0.0001). The x-axis represents the number of concurrent sessions (N) and

the y-axis shows the relative capacity gain (C).

Figure 2.1: Universal Scalability Law

¹http://www.perfdynamics.com/Manifesto/USLscalability.html

²http://en.wikipedia.org/wiki/Amdahl%27s_law

Performance and Scaling 7

The number of load generators (database connections), for which the system hits its maximum

capacity, depends on the USL coefficients solely.

Nmax =

√

(1 − α)

The resulting capacity gain is relative to the minimum throughput, so the absolute system capacity

is obtained as follows:

Xmax = X (1) × C (Nmax)

2.2 Database connections boundaries

Every connection requires a TCP socket from the client (application) to the server (database).

The total number of connections offered by a database server depends on the underlying hardware

resources, and finding how many connections a server can handle is possible through measurements

and proven scalability models.

SQL Server 2016 and MySQL 5.7 use thread-based connection handling.

PostgreSQL 9.5 uses one operating system process for each individual connection.

On Windows systems, Oracle uses threads, while on Linux, it uses process-based connections.

Oracle 12c comes with a thread-based connection model for Linux systems too.

https://msdn.microsoft.com/en-us/library/ms190219.aspx

https://dev.mysql.com/doc/refman/5.7/en/connection-threads.html

http://www.postgresql.org/docs/9.5/static/connect-estab.html

http://docs.oracle.com/database/121/CNCPT/process.htm

A look into database system internals reveals the tight dependency on CPU, Memory and Disk

resources. Because I/O operations are costly, the database uses a buffer pool to map into memory

the underlying data and index pages. Changes are first applied in memory, and flushed to disk in

batches to achieve better write performance.

Even if all indexes are entirely cached in memory, disk access might still occur (to fetch the associated

data pages into the memory buffer pool). To provide data consistency, locks (shared and exclusive)

are used to protect data blocks (rows and indexes) from being concurrently updated.

Using covering indexes, that fit into memory, can eliminate disk access because the

querying data can be fetched without accessing the disk.

Performance and Scaling 8

This means that high-throughput database applications will experience contention on CPU, Memory,

Disk and Locks. When all the database server resources are in use, adding more work load will only

increase contention, therefore lowering throughput.

Resources might get saturated due to improper system configuration, so the first step to improving

a system throughput is to tune it according to the current data access patterns.

Lowering response time not only makes the application more responsive, but it can also

increase throughput.

But response time alone is not sufficient in a highly concurrent environment. To maintain

a fixed upper-bound response time, the system capacity must increase, relative to the

incoming request throughput. Adding more resources can improve scalability up to a

certain point, beyond which the capacity gain starts dropping.

At the Velocity conference, both Google Search and Microsoft Bing teams have concluded that

higher response times can escalate and even impact the business metrics.

Capacity planning is a feedback-driven mechanism, and it requires constant application monitor-

ing, and so, any optimization must be reinforced by application performance metrics.

http://radar.oreilly.com/2009/06/bing-and-google-agree-slow-pag.html

2.3 Scaling up and scaling out

Scaling is the effect of increasing capacity by adding more resources. Scaling vertically (scaling up)

means adding resources to a single machine. Increasing the number of available machines is called

horizontal scaling (scaling out).

Traditionally, adding more hardware resources to a database server has been the preferred way of

increasing database capacity. Relational databases have emerged in the late seventies, and, for two

and a half decades, the database vendors took advantage of the hardware advancements following

the trends in Moore’s Law.

Distributed systems are much more complex to manage than centralized ones, and that’s why

horizontal scaling is more challenging than scaling vertically. On the other hand, for the same price

of a dedicated high-performance server, one could buy multiple commodity machines whose sum

of available resources (CPU, Memory, Disk Storage) is greater than of the single dedicated server.

When deciding which scaling method is better suited for a given enterprise system, one must take

into account both the price (hardware and licenses) and the inherent developing and operational

costs.

Performance and Scaling 10

The asynchronous replication topology is also referred as warm standby because the election process

doesn’t happen instantaneously.

Most database systems allow one synchronous Slave node, at the price of increasing transaction

response time (the Master has to block waiting for the synchronous Slave node to acknowledge

the update). In case of Master node failure, the automatic failover mechanism can promote the

synchronous Slave node to become the new Master.

Having one synchronous Slave allows the system to ensure data consistency in case of Master node

failures since the synchronous Slave is an exact copy of the Master. The synchronous Master-Slave

replication is also called a hot standby topology because the synchronous Slave is readily available

for replacing the Master node.

When only asynchronous Slave are available, the new elected Slave node might lag behind the

failed Master, in which case consistency and durability are traded for lower latencies and higher

throughput.

Aside from eliminating the single point of failure, database replication can also increase transaction

throughput. In a Master-Slave topology, the Slave nodes can accept read-only transactions, therefore

routing read traffic away from the Master node.

The Slave nodes increase the available read-only connections and reduce Master node resource

contention, which, in turn, can also lower read-write transaction response time. If the Master node

can no longer keep up with the ever increasing read-write traffic, a Multi-Master replication might

be a better alternative.

2.3.2 Multi-Master replication

In a Multi-Master replication scheme, all nodes are equal and can accept both read-only and read-

write transactions. Splitting the load among multiple nodes can only increase transaction throughput

and reduce response time as well.

But because distributed systems are all about trade-offs, ensuring data consistency is challenging in

a Multi-Master replication scheme because there is no longer a single source of truth. The same data

can be modified concurrently on separate nodes, so there is a possibility of conflicting updates. The

replication scheme can either avoid conflicts or it can detect them and apply an automatic conflict

resolution algorithm.

剩余244页未读，继续阅读

weixin_41708713

粉丝: 0
资源: 2

优化Java持久层性能：High-Performance Java Persistence精髓

High Performance Java Persistence 无水印pdf

Java 9 High Performance 无水印pdf转化版

High-Performance.Java.Persistence

high-performance-java-persistence:高性能Java持久性书和视频课程代码示例

vladmihalcea.wordpress.com:vladmihalcea.com的某些源代码。 hibernate-master-class和high-performance-java-persistence也用作博客源代码存储库-java source code

ejb-3_0-fr-spec-ejbcore.pdf,ejb-3_0-fr-spec-persistence.pdf,ejb-3_0-fr-spec-simplified.pdf

Pro.EJB.3.Java.Persistence.API.pdf

Rest-Approach-to-Data-Persistence-R.A.D.A-

Apress.Pro.EJB.3.Java.Persistence.API.pdf

Manning-Java.Persistence.with.Hibernate 英文版

最新资源