@Truong23523 Cũng không hẳn. Nhưng xét bài toán bạn đề cập mình hiểu là giảm độ trễ API thì không phù hợp thật. Kafka nó phù hợp hơn khi bạn muốn phát triển software theo hướng Event Driven Design hoặc muốn có khả năng lưu trữ trong thời gian dài thì hơn.
Với cả "Xử lý gọn gàng, sạch sẽ các bạn ạ. Sức mạnh của ThreadPoolExecutor phát huy rõ rệt hơn. Tận dụng được 10 thread và queue vẫn còn chỗ nên rất nhanh, khác biệt trong một hệ thống có thể đc tính bằng milliseconds như vậy đó. nếu mỗi request cách nhau 100 milliseconds thì nó chỉ cần sử dụng 5 thread thôi." Sao anh có thể phát biểu được câu này ạ, ý em là em đang thắc mắc tại sao cách nhau 100ms thì chỉ cần 5 thread, hoặc anh dựa vào đâu để tính toán corePoolSize: 5
maxPoolSize: 15
queueCapacity: 100
như đây anh.
Có cách nào để test k anh Nam (em thấy trên tài khoản git của anh ạ), em chạy trên Mac dù chỉ mới chạy ví dụ 1 của anh là 500ms thì đã nhảy lỗi rejected from java.util.concurrent.ThreadPoolExecutor@52cc8049 giảm xuống 50ms thì cũng như thế, kết quả trả ra y chagn, em cũng mở tương đối nhiều tab, k rõ có phải mỗi 1 Thread nó được tạo ra từ ThreadExecutorService đó là nó sẽ chiếm 1 core đúng k anh Nam, anh giải thích đoạn chiếm core cho em với, em cứ thắc mắc mãi ở chỗ này, day dứt k chạy được demo của anh!!! Em Fan cứng anh ạ
Bạn ơi mình hỏi chút các cache này có hỗ trợ cho những trường hợp mà lần đầu tiên vào website của mình load nhanh hơn ko?
Hay là phải qua lần đầu mới bắt đầu load nhanh?
@hieult0603 Mình nghĩ với các document mà bạn có thể phân tách thành cấu trúc rõ ràng thì nên sử dụng hybrid search. Các dịch vụ như Azure AI Search hỗ trợ rất tốt việc này. Ngoài ra bạn nên đào sâu hơn vào data đê tìm cách chia chunk cho hợp lý tuỳ thuộc vào loại dữ liệu. Dữ liệu đầu vào sẽ ảnh hưởng rất nhiều đến cách bạn retrieval ra thông tin trong pipeline RAG.
@huukimit thế nó dùng chủ yếu trong mấy mô hình microservice hàng triệu người dùng thôi , chứ với kiểu dự án 1 source fe + 1 source be + 1 db thì chắt không cần thiết bạn nhỉ
Bạn có thể hiểu là nháp bằng FE rồi paste
Do trước đó lập trình viên BE đã có giao diện FE (tự code hoặc được lập trình viên FE đưa), họ đã biết cần truyền dữ liệu gì vào vị trí nào rồi nên có thể build html chính xác
Cơ bản thì useQuery đã là 1 hook rồi bạn. nên theo quy tắc thì không thể gọi useQuery trong 1 hook khác. ngoài ra thì key nếu nói dễ hiểu chính là dependencies của call back mà bạn truyền vào useQuery.
THẢO LUẬN
Bác viết tiếp các phần sau đi bác @Minh Monmen ơi
@Truong23523 Cũng không hẳn. Nhưng xét bài toán bạn đề cập mình hiểu là giảm độ trễ API thì không phù hợp thật. Kafka nó phù hợp hơn khi bạn muốn phát triển software theo hướng Event Driven Design hoặc muốn có khả năng lưu trữ trong thời gian dài thì hơn.
Em vừa thử Thread.sleep từ 10 -> 40 ms thì cũng k dc, đúng 50ms thì mới chạy được anh Nam ạ, sao anh có thể biết dc hay quá v ạ.
Với cả "Xử lý gọn gàng, sạch sẽ các bạn ạ. Sức mạnh của ThreadPoolExecutor phát huy rõ rệt hơn. Tận dụng được 10 thread và queue vẫn còn chỗ nên rất nhanh, khác biệt trong một hệ thống có thể đc tính bằng milliseconds như vậy đó. nếu mỗi request cách nhau 100 milliseconds thì nó chỉ cần sử dụng 5 thread thôi." Sao anh có thể phát biểu được câu này ạ, ý em là em đang thắc mắc tại sao cách nhau 100ms thì chỉ cần 5 thread, hoặc anh dựa vào đâu để tính toán corePoolSize: 5 maxPoolSize: 15 queueCapacity: 100 như đây anh.
Có cách nào để test k anh Nam (em thấy trên tài khoản git của anh ạ), em chạy trên Mac dù chỉ mới chạy ví dụ 1 của anh là 500ms thì đã nhảy lỗi rejected from java.util.concurrent.ThreadPoolExecutor@52cc8049 giảm xuống 50ms thì cũng như thế, kết quả trả ra y chagn, em cũng mở tương đối nhiều tab, k rõ có phải mỗi 1 Thread nó được tạo ra từ ThreadExecutorService đó là nó sẽ chiếm 1 core đúng k anh Nam, anh giải thích đoạn chiếm core cho em với, em cứ thắc mắc mãi ở chỗ này, day dứt k chạy được demo của anh!!! Em Fan cứng anh ạ
dùng cái này để show ra trang detail bài viết đc ko bạn ?
ko làm tiếp à a
Đối với request đầu tiên thì sex không nhanh hơn vì server vẫn render trang như bình thường.
Mặc dù mình dùng macOS nhưng bài viết chỉ đưa ra công cụ chạy trên 1 OS thì ko hay lắm. Mình dùng nvm.
Bạn ơi mình hỏi chút các cache này có hỗ trợ cho những trường hợp mà lần đầu tiên vào website của mình load nhanh hơn ko? Hay là phải qua lần đầu mới bắt đầu load nhanh?
@hieult0603 Mình nghĩ với các document mà bạn có thể phân tách thành cấu trúc rõ ràng thì nên sử dụng hybrid search. Các dịch vụ như Azure AI Search hỗ trợ rất tốt việc này. Ngoài ra bạn nên đào sâu hơn vào data đê tìm cách chia chunk cho hợp lý tuỳ thuộc vào loại dữ liệu. Dữ liệu đầu vào sẽ ảnh hưởng rất nhiều đến cách bạn retrieval ra thông tin trong pipeline RAG.
@huukimit thế nó dùng chủ yếu trong mấy mô hình microservice hàng triệu người dùng thôi , chứ với kiểu dự án 1 source fe + 1 source be + 1 db thì chắt không cần thiết bạn nhỉ
👍️
ServBay chỉ support MacOS, mình thì đang dùng nvm cũng khá là ổn
Bạn có thể hiểu là nháp bằng FE rồi paste Do trước đó lập trình viên BE đã có giao diện FE (tự code hoặc được lập trình viên FE đưa), họ đã biết cần truyền dữ liệu gì vào vị trí nào rồi nên có thể build html chính xác
Có QueryCache. Class này chứa toàn bộ cache của react-query. Cơ bản thì nó sẽ cung cấp các phương thức CRUD để giúp thao tác với cache.
Cơ bản thì useQuery đã là 1 hook rồi bạn. nên theo quy tắc thì không thể gọi useQuery trong 1 hook khác. ngoài ra thì key nếu nói dễ hiểu chính là dependencies của call back mà bạn truyền vào useQuery.
Mình có đoạn mã như thế này thì áp dụng deltatime ở đâu vậy ad?
let position = 0 let velocity = 10
function loop() { velocity *= 0.95 position += velocity
requestAnimationFrame(loop) }
Nếu mình làm như này thì lại rất chậm: position += velocity * deltatime
Vì trong repo có chứa cả thông tin nhạy cảm nên anh chưa tạo repo mẫu. Em copy code mẫu theo hướng dẫn trong bài chắc chắn sẽ thực hiện được nhé.
@refacore Mình hiểu rồi, cám ơn bạn đã đóng góp cho cộng đồng, mình tin là bài viết này sẽ còn có giá trị cho nhiều người khác sau này nữa.