bạn có thể sử dụng rider của jetbrain nhé. mình chạy nó lên xong attach vào process muốn debug và debug thôi

thanks anh nhiều

Cảm ơn anh đã viết bài này và cung cấp nguồn uy tín. Bài viết rất hữu ích, đã giúp mở rộng mindset khi code của em thêm 1 bậc!

Cám ơn bạn về bài viết đủ ngắn gọn, súc tích và vừa hay giải quyết được đúng chỗ mình đang bị missed về MVC!

Bài viết rời rạc

Về phần nhược điểm ở đây, tác giả nói như vậy theo cảm nhận của mình thì chưa đúng lắm Nhược điểm:

• Độ bao phủ hạn chế vì chỉ có một phần nhỏ trong số các kịch bản thử nghiệm được thực hiện
• Kiểm tra không hiệu quả do người thử nghiệm không hiểu biết gì về cấu trúc bên trong phần mềm.
• Tester có hạn chế về hiểu biết về ứng dụng

• Đúng là độ bao phủ hạn chế, nhưng cũng sẽ phủ đc đa số case đến từ người dùng,
• Kiểm tra vẫn sẽ hiệu quả, vì đứng ở góc độ User, khi user họ có thể sự dụng đc, đạt được phần lớn trải nghiệm thì nó ko thể nói là ko hiệu quả được. Có chăng thì nó sẽ chỉ gom về ý đầu là ko phủ được những case thuộc về code hệ thống
• Thực tế, tester blackbox có hạn chế về code, chứ ko phải về ứng dụng. Vì họ vẫn sẽ hiểu ứng dụng theo tài liệu đặc tả dưới góc nhìn của manual test

E có đang làm theo bài của a từ đầu tới cuối ko? Hay là e có project của riêng e đó?

Anh ơi cái này anh Debug bằng dnspy ạ em có thử làm lại case này nhưng không debug được anh có thể chia sẻ cách để debug không ạ

@bao281010 có vẻ như giá trị "background-position" của bạn có vấn đề á, bạn thử thay 100% 100% bằng center thử

thêm ảnh này nữa

bạn ơi sao mình nó không hiện vậy bạn

Một câu hỏi hay. Overhead là chi phí hoặc tài nguyên mà postgres phải bỏ thêm đễ xử lý, lưu trữ. gồm:

• Không gian lưu trữ: update sẽ tạo ra thêm record gây tốn thêm không gian lưu trữ. cách giải quyết thì nằm chính trong câu hỏi của bạn là postgres dùng VACUUM
• Thời gian xử lý: để giải quyết vấn đề này thì postgres có cơ chế MVCC cho nhiều tác vụ chạy đồng thời á.
• Tài nguyên hệ thống: việc chạy VACUUM để dọn dẹp không gian lưu trữ chẳng hạn, thì lại gây tốn tài nguyên hệ thống. Thường postgres sẽ lập lịch để xử lý định kỳ dữ liệu chứ không phải lúc nào cũng có dư thừa là đi dọn dẹp. Ngoài ra, ví dụ trong trường hợp của bạn (2 query update gọi cùng 1 lúc, ko sai 1 milisecond nào), mình sẽ vẽ thêm 2 case như này:
• 2 record update cùng lúc nhưng dữ liệu update khác nhau. Như trường hợp bạn nói.
• 2 record update gọi cùng lúc nhưng dữ liệu update là như nhau: query đầu tiên tạo ra record mới, query thứ 2 thấy dữ liệu giống với cái nó định update nên ko update lại nữa. Lúc này chỉ còn 1 record dư thừa thôi (record gốc hết hiệu lực). Đó cũng là 1 cách để postgres cố gắng giảm thiểu overhead

Ngoài ra còn có HOT (Heap-Only Tuples) Updates: việc tạo bản ghi mới có thể ảnh hưởng đến index gây overhead. Nhưng nếu việc udpate không ảnh hưởng tới cột mà mình đánh index thì postgres có thể sẽ tạo một bản ghi mới ngay trong cùng "page" với bản ghi cũ. Lúc này sẽ không cần cập nhật lại index vì nó vẫn trỏ đến vị trí cũ đc.

Có thể còn nhiều cách thức khác để giảm overhead, nếu bạn biết có thể giới thiệu thêm với mình nhé.

Đừng dùng AI Viết bài nữa

"postgres không thực chất update lên record cũ mà nó insert 1 record mới vào database, record cũ được đánh dấu là không còn hiệu lực, rồi sử dụng VACUUM để dọn dẹp định kì những dữ liệu dư thừa." Vậy chỗ này có case 1 record được update 1 lúc bởi 2 query, theo lý thuyết thì nó sẽ insert 2 record vào db đúng không ạ? Vậy postgres xử lý overhead như nào anh nhỉ?

A ơi, em có một vấn đề là khi mà ghi đè /api/broadcasting/auth như vậy thì ở trong code khi em truy cập auth()->user() thì nó trả về null chứ k lấy được user đang login ạ

Very interesting!!!!

ừa, mình đang viết bài expose application trong EKS với aws load balancer controller nhé, rồi autoscaling nữa. đợt vừa rồi mình bận nên ko có thời gian viết tiếp.

Cảm ơn bạn nhé.

Nhanh nhất thì bác mua khoá học, chẳng hạn của wecommit, thấy chú đó giảng sâu về database lắm. Mình thì ko có xèng nên tìm kiếm mỗi nơi một ít rồi góp nhặt về thôi.

Qúa dữ, bài viết bổ ích

.