Nhờ tư vấn cấu hình nginx cho static files để tốc độ phản hồi nhanh

, cal của nó không cho quá 100% storage nên chắc phải dùng mới biết, bác dùng rồi và nó tính bw nếu quá 100% phải không?

 

Thế này cũng căng nhỉ.

 

Wasabi tính BW theo dung lượng nha
Disk 1tb thì BW 1tb , nếu BW vượt 1TB thì nhân tiền lên theo disk thôi , với điều kiện là có gắn tự động thanh toán, còn ko sẽ bị nhắn nhở thanh toán nếu ko sẽ khóa acc
Vd :
Disk 2tb mà sử dụng 4tb BW thì sẽ bị tính tiền như sử dụng disk 4TB
Disk 4tb mà sử dụng 10tb BW thì sẽ bị tính tiền như sử dụng disk 10TB

 

Dĩ nhiên phải dùng custom domain của mình để test rồi, lấy url của wasabi thì ko thể làm proxy Cloudflare và cache static files được.

@money e nghĩ là free hoặc sẽ bị charge thêm khi vượt bandwidth, trong tài khoản e ko thấy hiển thị gì về price cho bandwidth cả, có bạn bảo khóa tài khoản wasabi khi vượt quá bandwidth = storage thì quá vô lý (chỉ cần suy nghĩ theo business logic thì thấy ko có chuyện đó, cùng lắm là charge thêm thôi). E đang đẩy đóng ảnh lên Wasabi, để xem thử vài ngày hoặc đến cuối tháng là biết kết quả vụ vượt bandwidth liền. Và e dùng giải pháp cache static files ở Cloudflare nữa, nên bandwidth sẽ được chuyển 1 phần sang Cloudflare.

 

Anh làm site ảnh, có cache (free) ở CF thì CF chỉ cache được chưa đến 10%. Chủ yếu vì traffic của anh không tập trung vào URL nào cả, quá phân mảnh nên cache CF không lưu lâu --> cache traffic khá thấp.

--- Double Post Merged, Jun 7, 2022, Original Post Date: Jun 7, 2022 ---

Thống kê last 30 days của CF. Anh đã xử lý rất nhiều request (bot) để trả về ảnh 1 pixel nên nó giảm bandwidth đi cực nhiều.

Bọn ahrefs, semrusk, yandex, mj12, petal, ... là anh return 1 pixel image hết. Hồi xưa lúc chưa xử lý, bandwidth tốn kinh khủng.

 

cache cf thấp lắm

 

ANh @money xử lý ảnh với requests của Bot xấu hoặc SEO bots thế nào vậy? A xử lý ở mức ở Cloudflare hay web server (như nginx) hay ở mức code?

Nếu Cloudflare còn muốn bán Argo thì chức năng cache static files phải có tỷ lệ thấp thôi, với lại cache static files thì phải cần user requests tại 1 khu vực nhiều (trên 2 requests), trong khi users ở cùng khu vực thì thường đâu thường vào 1 url đâu trừ những popular posts.

 

Anh xử lý trên code php, check user agent thôi. Biết là ko triệt để nhưng chỉ nhiêu đó thôi là giảm bw cực nhiều rồi. Thậm chí bot anh còn ko check hết, chỉ chặn các bot anh list ở trên vì mấy bot đó request quá nhiều. Như ahrefs với semrush chẳng hạn, 1s nó mò vào 5-7 lần (những site rank tốt)

 

Anh @money a xử lý mức code với url có nội dung là html hay image luôn vậy a? E đoán là html, vì nếu xử lý rewrite content cho images ở mức code thì tốn nhiều tài nguyên hơn trong khi hiệu quả chưa chắc nhiều.

 

Xử lý image mới đỡ tốn bw chứ em, html đâu có nhiêu.

Cũng ko tốn resource xử lý đâu em, vì chỉ check nếu là bot muốn chặn thì đọc cái ảnh 1 pixel, ngược lại thì đọc ảnh thật rồi trả về.

 

À thì ra Bot xấu hoặc SEO bots nó có nhiều nguồn lấy image urls, e nghĩ nó lấy image urls từ html của site mình thôi.

 

Có nhiều site nó nhúng đúng cái image url của mình vào site nó, nên bot nó vào đúng image đó thôi em.

 

Thanks anh @money

Về Wasabi, sync images từ remote lên Wasabi hơi căng, Wasabi ko hỗ trợ tính năng giải nén file nên chỉ có cách sync từng file ảnh. Và đây là kết quả upload (sử dụng 4 threads) từ server Hetzner ở Phần Lan đến Wasabi trong 40 giờ đã qua:

Khi upload images vài TB thì bao phê ở góc độ thời gian hoàn thành. Đã test với 01 file vài chục GB thì tốc độ rất ổn (~40-60MB/s), tuy nhiên bài toán upload từng file ảnh thì chua cay.

 

Wasabi giá rẻ thế mà, khi scale lên chắc còn nhiều vấn đề nữa.

 

Có thể dự đoán vấn đề cụ thể nào ko bạn?

Ví dụ đây là speed test của 01 ảnh khi bucket size của mình đã upload được hơn 1,1 triệu file ảnh rồi (mình lấy 10 ảnh test ngẫu nghiên thì speed cũng tương tự). Mình ko đòi hỏi gì hơn với $6/1TB storage size hoặc 1TB bandwidth.

 

Có thể trong quá trình sử dụng: khi bw tăng, khi số lượng request 1 thời điểm lớn => tốc độ bị ảnh hưởng
Làm media (images & videos) thì mình nghĩ tốt nhất vẫn là google (do bản thân google nó có bộ máy render), mà thực tế là chi phí thấp nhất nhưng các bác có vẻ lại không thích nhỉ

Nói chung là với giá của wasabi thì thế là tốt lắm rồi.
Tốc độ của nó thế kia thì đúng là kinh khủng thật, với tốc độ phản hồi thế kia thì nó cũng có khá nhiều location đấy vì cả ở châu âu và US thì tốc độ vẫn đều tốt.

 

Cloud Storage của Google nào thấp đâu bạn? Chỉ cần thử so sánh 1TB storage và 1TB bandwidth.

 

À, giải pháp trước mình đưa ra là drive chứ không phải storage, nhưng tốc độ ở 5 châu không được tốt như của wasabi đâu, kết quả thì ổn định thôi

 

Google Drive thì sao lấy đường dẫn file có dạng tương tự như mydomain/folder/<...>/<ten file> được vậy bạn? Dĩ nhiên folder ở Google Drive tương đồng folder ở remote server chứa files để đồng bộ. Ngoài ra làm sao custom domain để ánh xạ custom domain đó cho toàn bộ files trong folder đó?

--- Double Post Merged, Jun 8, 2022, Original Post Date: Jun 8, 2022 ---

Bác @noenmo có thể nói rõ hơn kỹ thuật để làm phần này ko? Vì số lượng files trong folder và sub-folder hơn vài trăm triệu, nên làm sao ánh xạ đúng file nằm trên Google Drive? Hình như ko xử lý việc này ở Cloudflare được hở bác? Ở các CDN hoặc Cloud storage như Wasabi thì mình chỉ cần chỉnh DNS của custom domain đến đúng địa chỉ của object storage là xong.

--- Double Post Merged, Jun 8, 2022 ---

Trong hình này, speed nhìn chung cũng ổn và tốt hơn so với lưu trữ files tại server, speed này được trả về thông qua mô hình hoạt động thế nào vậy bác? Mình đoán là:
(1) Cloudflare --> Proxy (nginx hoặc...) --> Google Drive à?
(2) Proxy --> Google Drive?

À, có 1 giải pháp thông qua drv.tw (xem video ), có cách nào khác ko thông qua thằng drv.tw này ko?