Vì không giỏi nên đây là lần này mình lập topic để thảo luận, hỏi đáp về webpush notification. Vậy mà 1 năm sắp qua rồi mà vẫn chưa làm được nưa … toang quá.
Thời gian ghi log: 0.187559s Tổng thời gian: 4.885548s
Rất chậm: Khi gửi liên tục > 2000 endpoint thời gian req fcm.googleapis.com lên 15-20s.
Hiện tại web-push-php sử dụng thư viện GuzzleHttp\Client để request
Sử dụng CPU: mariadbd: 36 đến 80% CPU - 2 core Intel® Xeon® 2200.186 56320 KB Sử dụng RAM: mariadbd: 270 Mb tổng - 4Gb ram Ping fcm.googleapis.com: 1.45 ms PHP Đã thử 7.3, 7.4, 8.0
Vấn đề mình nhận ra thời gian req đến fcm.googleapis.com hiện tại là nguyên nhân gây chậm. Vậy làm thế nào tối ưu thời gian này? .
Nếu chia cùng lúc ra thành 5 cron mỗi cron xử lý 200 endpoint 1 lần thì làm thế nào xử lý việc trùng endpoint.
Webpush notification này là batch à cậu? Vì cậu đang cân nhắc dùng cronjob, nên khả năng cao đây là batch.
Khi nào thì webpush notification được kích hoạt? Định kỳ, hay có 1 event nào đó kích hoạt, hay do cậu chạy thủ công?
2000 endpoint là 1 khối lượng công việc lớn, do 200 endpoint đã mất 4.4s, nên 2000 endpoint có thể sẽ mất tới 40s, nhưng cậu chỉ mất 15-20s. Tại sao đó được gọi là chậm?
Cậu kỳ vọng webpush notification chạy trong bao lâu? Hay, bao lâu được gọi là nhanh? Và có ai chờ webpush notification chạy xong không? Họ bị ảnh hưởng thế nào?
Tại sao DB của cậu có spec thấp vậy? Cậu chạy trên local hay production vậy?
Tại sao cậu lại bỏ mất 1 năm để optimize phần này vậy? Đó là cost rất lớn!
Thường thì nếu như không có hướng giải quyết được trong 1 ngày, cậu nên hỏi người có kinh nghiệm hơn, hoặc từ bỏ rồi.
Nếu cậu muốn scale app/batch webpush notification của cậu, cậu đã thử cân nhắc dùng message broker chưa?
Webpush notification này là batch à cậu? Vâng bạn các thông tin đơn hàng cần được cập nhật + bài viết mới được gửi tự động. Hiện tại dev nên mình truy xuất log để dễ chỉnh sửa trước khi chạy cron file.
Khi nào thì webpush notification được kích hoạt? Lấy từ database có 1 bảng mình đẩy các yêu cầu vào đây và file php sẽ đọc nếu có dữ liệu sẽ gửi.
2000 endpoint là 1 khối lượng công việc lớn? 1 enpoint chỉ mất 0.07s thôi b.
Cậu kỳ vọng webpush notification chạy trong bao lâu? Mình gửi qua onesignal mất 3-5p cho list tầm 10K endpoint
Tại sao DB của cậu có spec? mình tạo DB InnoDB và đánh dấu index các trường quan trọng cần lấy nên việc select rất nhanh. Máy chủ Cloud GG 4Gb ram và 2 Core CPU
Tại sao cậu lại bỏ mất 1 năm để optimize phần này vậy?! Đây là một nhánh công việc nên trước gì vẫn chạy chậm và gửi từng nhóm nhỏ hoặc 1 không gửi ALL nên k bị tình trạng gửi chậm. Dữ liệu này quan trọng nên việc đưa người khác sẽ dễ mất toàn bộ. Nếu có thể thuê DEV để xử lý làm thế nào toàn vẹn dữ liệu! Thật sự mình chưa tìm đc cách!
Message broker? Mình đang tra google từ này, nghĩa là mình chưa có nhiều kiến thức gốc của PHP.
Hiện tại mỗi enpoint đều gửi 1 req CURL đến google. Mình thấy batch request nhưng chưa tìm được tại liệu để gọp 200 endpoint lại thành 1 lần req đến google.
Hm. Nếu nó là batch, cậu không có lý do gì để yêu cầu nó phải gửi nhanh cả (cậu cũng không chỉ được lý do đó cho tới giờ).
Đây không phải hệ thống realtime, và batch của cậu, tớ đoán là được kích hoạt định kỳ để đọc dữ liệu trong DB, nên chỉ cần nó thực hiện nhanh hơn chu kỳ của batch là được.
Oh sorry, tớ đọc lộn
Vậy, với giả thiết thời gian tổng 2000 endpoint bằng 2000 lần thời gian của 1 endpoint, thì 2000 endpoint cậu sẽ mất 140s. Con số thực tế của cậu đã chỉ ra cậu đã gọi 2000 endpoint nhanh hơn thời gian dự tính, phải không?
Câu hỏi của tớ là, có thực sự nó chậm không? Và chậm so với cái gì? Rõ ràng cậu không thể coi thời gian chạy marathon mất 60 phút là chậm (kỷ lục thế giới là hơn 2h), so với thời gian chạy nước rút 100m mất 14s, phải không?
Hm, hình như cậu không phải người cài đặt hệ thống này.
Cậu có 1 cronjob gọi tới DB định kỳ phải không?
Vậy sao cậu không dùng onesignal?
Mặt khác, cậu có thể thấy, 2000 endpoint của cậu mất 20s, tức là trung bình 1 endpoint mất 0.01s để gửi. 10k endpoint sẽ mất 100s = 1.7 phút. Vậy, hệ thống hiện tại đã nhanh hơn gấp 1.7 - 2.9 lần so với onesignal rồi!
Nếu cậu kỳ vọng nó chậm như onesignal thì có thể thêm mấy vòng lặp để chậm đi
Như tớ đoán, database của cậu không nhận nhiều traffic, nên 4GB RAM và 2 core CPU của cậu mới đủ dùng. Tớ hiểu hệ thống của cậu có scale rất nhỏ.
Sorry, tớ không hiểu ý cậu lắm, hình như nó không liên quan tới câu hỏi của tớ. Ý tớ muốn hỏi cậu có đáng để bỏ công ra optimize nó không. Thậm chí tớ không nghĩ vấn đề của cậu tồn tại đâu.
Đó không phải thuật ngữ PHP đâu. Trong article cậu đưa cho tớ, có đề cập tới “job queue”. Ở đây, họ dùng redis làm message queue - chính là message broker mà tớ đang đề cập tới.
Nếu cậu sử dụng message broker, và làm theo article mà cậu đề cập, cậu sẽ tạo ra được các job worker chạy song song (đó là việc scale app/batch mà tớ đề cập ở command trước), từ đó sẽ tăng tốc độ đáng kể.
Hiển nhiên, giá phải trả là cậu phải tốn 1 đống engineer cost để tái cấu trúc hệ thống hiện tại của cậu.
Vì cậu không phải người cài đặt hệ thống, tớ nghĩ sẽ tốt hơn nếu như cậu có thể nhờ dev bên cậu nghiên cứu thêm, nếu như cậu vẫn muốn optimize nữa.
Cá nhân tớ thấy, cậu chưa hiểu rõ “vấn đề” của cậu đâu. Tớ không nghĩ đó là vấn đề, vì không ai thiết kế hệ thống batch với tiêu chí chạy nhanh, và bỏ công để optimize nó. Nó chạy chậm hơn vài giây rẻ hơn nhiều so với cả năm engineering cost cậu bỏ ra để optimize 1 batch.
Đầu tiên cảm ơn cậu đã trả lời giúp mình, thật sự cảm ơn.
không có lý do gì để yêu cầu nó phải gửi nhanh cả
Có những lúc cần gửi số lượng lớn thì không được. Các số lượng lớn như chương trình flashsale của sản phẩm A trong vòng 2h. Hoặc gửi những người theo dõi chuyên mục PHP khi có bài nổi bật trong ngày.
thì 2000 endpoint cậu sẽ mất 140s
14s nhé. Chậm hơn so với các hệ thống như onesignal, so sánh hơi khoai nhưng mà ai lại không muốn code mình chạy nhanh. Hiện tại trong 14s khi file thực thi CPU k load hết nhưng các tác vụ khác máy chủ bị đứng…cái này mình chưa tìm hiểu kỹ xem do đâu.
Hm, hình như cậu không phải người cài đặt hệ thống này.
Mình lên kịch bản cũng như build khá lâu rồi. Code và Thư viện mình kiếm trên mạng rồi ghép lại với nhau.
Vậy sao cậu không dùng onesignal?
Quay lại 1 năm trước thì lúc còn miễn phí và mới mẻ thì mọi thứ đều ổn, lúc đó CTR mình đạt 17-20%. Sau đó thì giảm và onesignal bắt đầu tính phí, CTR cũng giảm còn 2-3% Và hiện tại là 0.7-1%. Nên chi phí trả phí hàng tháng mà CTR thấp dẫn đến lỗ…Nên việc build 1 hệ thống sẽ không bị giới hạn.
Hiện tại onesignal giới hạn ở 10K endpoint/1 tin nhắn.
Thật ra list bên onesignal lớn hơn nhiều, tại con số mình đưa ra chưa đủ chứ nó nhanh dã man luôn.
Như tớ đoán, database của cậu không nhận nhiều traffic, nên 4GB RAM và 2 core CPU của cậu mới đủ dùng. Tớ hiểu hệ thống của cậu có scale rất nhỏ.
Lúc đầu mình sử dụng máy nội bộ, máy bàn thì tôc độ tốt tuy nhiên delay ping đến google là 132ms so với 1.2ms trên cùng cụm máy chủ google sẽ giảm thời gian CURL hơn. Hiện tại mình sử dụng CLOUD google để DEV.
Ý tớ muốn hỏi cậu có đáng để bỏ công ra optimize nó không
Thời gian là gần 1 năm nhưng thời gian Code cũng như chỉnh sửa thì đâu đó 10-15 ngày. Nhưng nó cứ loanh quanh trong đầu, các bước đã xong mà có 1 vấn đề cuối cùng không giải quyết đc…khó chịu lắm. https://whatwebcando.today/
job worker chạy song song & engineer cost để tái cấu trúc hệ thống hiện tại của cậu.
Php 7x cũng có nhưng chưa biết dùng
Tớ không nghĩ đó là vấn đề, vì không ai thiết kế hệ thống batch với tiêu chí chạy nhanh, và bỏ công để optimize nó
Nếu bạn nhìn lại cách đặt title của mình sẽ gây cảm giác tò mò, vì 2 lần trước đăng bài không ai ngó cả. Có vẻ là đụng chạm nhiều vấn đề khác nên mình đã đặt tít như vậy.
Hm, đừng làm vậy nữa nha cậu. Cậu có thể dùng trick này và nghĩ rằng mình đạt được kết quả ở lần này, nhưng không có lần tiếp theo đâu. Tớ nhớ dai lắm
Và trick này cũng không có ích. Lý do tớ reply cậu không phải vì tiêu đề đó đâu, mà vì tớ nghĩ tớ nên giúp những người khác làm rõ các thông tin, do cách diễn đạt của cậu rất lủng củng. Tớ có ngó qua các topic trước của cậu, và vì câu hỏi của cậu không rõ ràng, cùng cách diễn đạt tệ hại, nên như thường lệ, mọi người sẽ skip. Cậu nên cải thiện phần đó, nếu như cậu muốn đi xa hơn.
Đây là reply cuối cùng của tớ cho cậu. Tớ nghĩ cậu đã biết cậu cần làm gì, tất cả đã có trong article mà cậu đề cập.
Chúc cậu may mắn!
Nên có bằng khen cho thím này. Mà diễn đàn có phần thưởng cho ai chăm chỉ trả lời câu hỏi trên diễn đàn không nhỉ. Xin hỏi thêm là thím có đang làm cho công ty nào ở Việt Nam không hay là thím làm cho công ty nước ngoài ở Việt Nam thế ah. Thím này cái gì cũng trả lời được hết đó(hơi quá nhỉ )
Thím đó là con robot AI đó bạn, đến giờ phút này mà bạn vẫn chưa phân biệt được AI với người đang chung sống hòa bình ở Dạy Nhậu Học thì nguy quá. Nhỡ đâu ngày mai con AI đó nó nổi giận thì bạn… tiêu nhé.
)
83% thành viên diễn đàn không hỏi bài tập, còn bạn thì sao?