Hi ạ ! Cho em hỏi là khi nào web public trên hosting có nhiều người sử dụng cùng lúc mới cần tới connection Pool còn nếu e làm project môn học thì không cần phải đụng đến connection Pool đúng ạ ? nếu ở localhost chỉ có 1 user mà thực nhiều thao tác database ( thêm, sửa, xoá,…) cùng lúc thì có bị ảnh hưởng gì không ? Em cảm ơn
Connection và Connection Pool
Sai, vì bạn không nói rõ project môn học đang cần giải quyết vấn đề gì. Nếu nhỡ project đó đang làm về connection pool mà bạn là không đụng đến nó => rớt cái tạch vì lạc đề.
Ở localhost thường thì không vấn đề gì nếu người viết mã không làm những việc ngớ ngẩn như vòng lặp while do không có điều kiện dừng, đệ quy cài đặt sai.
Với những thao tác thông thường, localhost không quá yếu (cài được Netbeans) thì dư sức chạy được mấy cái bài tập về Java ở trường. Localhost cài được Visual Studio thì cũng thực hành tốt C Sharp.
Sinh viên không nên lăn tăn hoặc hoang tưởng về những điều không xảy ra vì theo định luật nào đó nếu điều xảy ra nó sẽ xảy ra, điều không xảy ra sẽ không xảy ra 
. Lăn tăn chẳng có ích gì.
7 Likes
Hi there,
Tớ đoán cậu đang nói tới database connection pool 
Như @superthin có đề cập ở trên, tùy thuộc vào vấn đề mà cậu đang giải quyết, cậu có thể quan tâm tới connection pool hay không. Thường, với các project môn học, trừ khi cậu học môn nào liên quan tới cách manage resource khi xây dựng hệ thống, cậu mới phải quan tâm tới cách sử dụng connection pool và cách config connection pool. Còn không, mở database connection mới mỗi khi gọi tới database cũng không vấn đề gì.
Tuy nhiên, khi cậu cần xây dựng hệ thống chịu tải tốt, cậu buộc phải sử dụng database connection pool. Việc khởi tạo DB connection mới luôn đắt đỏ, nên đó là động cơ chính để cậu sử dụng pattern này. Lý do tớ sẽ đề cập ở phần dưới.
Tớ đoán cậu đang muốn đề cập tới việc trong 1 transaction, 1 user có thực hiện 1 thao tác, trong đó phải retrieve, thêm, sửa, xóa dữ liệu (hiển nhiên là nó sẽ phải thực hiện tuần tự, không cùng lúc được ).
Tùy theo cách implement của cậu, cậu sẽ có vấn đề khác nhau.
- Mỗi database query sử dụng 1 database connection khác nhau. Cậu sẽ gặp vấn đề lớn về:
- Resource, khi phải tạo ra rất nhiều database connection cho 1 transaction
- Khó có thể sử dụng database transaction, khi mỗi thao tác cậu cần phải commit và đóng database connection lại. Cậu có thể gặp vấn đề toàn vẹn dữ liệu, khi thao tác delete nào đó bị lỗi, mà cậu không revert lại toàn bộ các thao tác insert đã làm.
- Một transaction tạo và sử dụng 1 database connection duy nhất (không sử dụng connection pool patter). Cậu sẽ chủ yếu gặp vấn đề khi có nhiều request tới app của cậu:
- Resource, khi cậu xử lý 100 QPS (query-per-second), 100 threads ở server của cậu (trong TH cậu đã có ít nhất 100 threads ở pool) sẽ phải tự tạo ra 100 database connection đắt đỏ. Huge waste!
- Phần lớn các connection này sẽ idle trong phần lớn xử lý, khi cậu cần tính toán trên dữ liệu của cậu (trừ khi cậu chỉ CRUD). Cậu không thể tái sử dụng các object nặng nề đó.
- Khổ thân garbage collector
- Bên phía database, cậu cũng sẽ nhận thấy rất nhiều thread được tạo ra để phục vụ app khi có nhiều QPS tới app của cậu. Điều này tương đối nghiêm trọng, vì:
- Nó đồng nghĩa với việc cậu không thể tính toán bao nhiêu app instance có thể được scale lên, dẫn tới việc không thể manage resource cho phù hợp. Nếu cậu biết chắc mỗi application có bao nhiêu database connection tới, cậu có thể tính ra lượng app instance tối đa một cách dễ dàng.
- Nếu database có nhiều thread, tải tới DB sẽ cao hơn -> nhiều query sẽ bị kéo dài thời gian chờ đợi trong hàng đợi.
Spoiler nếu như cậu chưa từng làm việc này, nếu cậu theo dõi resource của app của cậu khi cậu implement theo 2 cách trên, cậu sẽ thấy lượng heap bị chiếm tương đối rõ rệt bị sử dụng khi có nhiều QPS tới app của cậu, và thời gian response cũng lâu hơn xíu - khoảng vài phần trăm (đặc biệt với cách 1).
Đó là lý do sao cậu cần database connection pool khi cậu phải xây dựng hệ thống chịu tải tốt.
8 Likes
@superthin @library Cảm ơn 2 anh đã hỗ trợ nhưng em còn 2 thắc mắc nữa mong được giải đáp ạ
- 1 Web chỉ có 1 Connection Pool ( toàn bộ user sử dụng connection này ) hay mỗi user hệ thống sẽ tạo ra 1 connection pool ( web sẽ có nhiều pool vì có nhiều user)
- Connection pool có nhược điểm không ? Vì mỗi pool sẽ có giới hạn số lượng kết nối tối đa, nếu pool đã đã đạt đến số lượng kết nối tối đa VD 1000 thì các user khác sẽ không truy cập được ( pool hết kết nối nên user không thể truy cấn database )
Em cảm ơn !
1 Like
Cảm ơn cậu về câu hỏi nhé!
Về câu hỏi đầu tiên:
1 Web chỉ có 1 Connection Pool ( toàn bộ user sử dụng connection này ) hay mỗi user hệ thống sẽ tạo ra 1 connection pool ( web sẽ có nhiều pool vì có nhiều user)
Để tớ giải thích trước về 1 website cơ bản trước nhé!
Sau khi cậu code xong, cậu cần deploy website của cậu lên 1 server nào đó. Lúc đó, cậu cần 1 phần mềm gọi là web server. Ví dụ, trong TH cậu dùng Java, cậu thường sử dụng Apache Tomcat; PHP thường đi với Nginx hoặc Apache chẳng hạn.
Khi cậu deploy code của cậu lên web server, mỗi web server được gọi là 1 instance của website của cậu. Website của cậu chỉ cần 1 instance là có thể live rồi, nhưng thường sẽ cần nhiều hơn 1 instance để phục vụ lượng traffic lớn.
Mỗi instance có 1 resource giới hạn, và connection pool là 1 giới hạn đó. Connection pool được tạo ra từ lúc start web server, và giữ nguyên cho tới khi web server bị tắt.
Từ kiến thức ở trên, cậu đã có thể suy luận 2 điều dưới đây:
- Connection pool liên quan tới từng instance của website (tức web server), chứ không phải liên quan tới từng user.
- Vì 1 website có thể có nhiều instance, 1 website sẽ có nhiều connection pool, mỗi cái gắn với 1 instance.
Liên quan tới câu hỏi thứ 2 của cậu:
Connection pool có nhược điểm không ? Vì mỗi pool sẽ có giới hạn số lượng kết nối tối đa, nếu pool đã đã đạt đến số lượng kết nối tối đa VD 1000 thì các user khác sẽ không truy cập được ( pool hết kết nối nên user không thể truy cấn database )
Connection pool có nhược điểm chứ! 
Tuy nhiên không phải như cậu suy luận.
Trước tiên, tớ sẽ đề cập tới các kịch bản xảy ra khi 1 request tới server của cậu, mà mọi DB connection trong pool đều busy:
- Kịch bản 1: Thread xử lý của cậu sẽ chờ connection pool đưa cho nó DB connection, trong 1 khoảng thời gian nhất định. Hết thời gian (timeout), thread đó sẽ dừng lại và gửi response lỗi về client.
Cậu có thể config được thời gian này. - Kịch bản 2: Thread xử lý của cậu sẽ chờ connection pool đưa cho nó DB connection, trong 1 khoảng thời gian nhất định. Sau 1 thời gian (chưa timeout), 1 thread khác dùng xong DB connection, nhả lại và Thread của của cậu được đưa cho connection đó.
Thread của cậu sẽ gọi tới DB dùng connection kia, và trả về kết quả như bình thường.
Cậu có thể thấy khi pool hết tài nguyên, cậu vẫn có khả năng nhận được kết quả như thường.
Về mặt nhược điểm của Connection pool, điểm lớn nhất đó là việc tìm ra 1 instance sẽ có bao nhiêu connection trong connection pool.
Bởi vì:
- Nếu cậu set 1 số quá thấp so với traffic thực tế của website, có nhiều request sẽ thường xuyên rơi vào tình trạng chờ. Thời gian respond của website cậu sẽ bị kéo dài đáng kể.
- Nếu cậu set 1 số quá cao so với traffic thực tế của website, DB của cậu sẽ luôn luôn có 1 số lượng thread được tạo ra lớn, phục vụ cho các connection này.
Nếu cậu có n instance trong website, mỗi instance có m connection trong pool, DB của cậu sẽ có (n x m) thread được tạo ra. Đa số những thread này lại thường xuyên không được dùng (vì cậu set quá cao) => tốn resource của DB 1 cách không cần thiết.
Việc cân đối resource không bao giờ dễ dàng đối với kỹ sư Đó là nhược điểm lớn nhất của pattern này.
Hope it helps!
8 Likes
83% thành viên diễn đàn không hỏi bài tập, còn bạn thì sao?