- Crawl Budget Management For Large Sites | Google Search Central | Documentation | Google for Developers
- Learn what crawl budget is and how you can optimize Google's crawling of large and frequently updated websites.
Bài viết được dịch bởi AI.
두루미스 기술 블로그
Sử dụng Cloud Run để phục vụ Tệp tĩnh - 1
- Ngôn ngữ viết: Tiếng Hàn Quốc
- Quốc gia tiêu chuẩn: Tất cả các quốc gia
Bài viết được tóm tắt bởi durumis AI
- Để sử dụng hiệu quả ngân sách thu thập dữ liệu của Google Search, chúng tôi đã tiến hành cải thiện tốc độ truyền tải trang web và triển khai dịch vụ Chuyển hướng dựa trên Cloud Run.
- Các tệp tĩnh như robots.txt, favicon.ico và logic chuyển hướng đã được di chuyển sang Cloud Run, giúp cải thiện tốc độ phản hồi từ 200ms xuống còn 20ms so với GKE Autopilot hiện tại.
- Triển khai Cloud Run trên nhiều vùng khác nhau trên toàn cầu để cung cấp dịch vụ từ máy chủ gần với vị trí người dùng nhất, qua đó tăng tốc độ và tiết kiệm chi phí.
Tất cả các dịch vụ dựa trên nội dung đều mong muốn được hiển thị nhiều trên tìm kiếm của Google.
Tuy nhiên, để được hiển thị trên tìm kiếm của Google, cần phải có crawler truy cập thường xuyên để thu thập dữ liệu mới nhất và phản ánh chính xác điều đó.
Lúc này, để crawler truy cập vào trang web thường xuyên hơn, người ta sử dụng " Ngân sách thu thập dữ liệu (Crawl Budget)" để tăng ngân sách, từ đó tăng tần suất truy cập. Và để làm được điều này, trang web cần phải có một lượng lưu lượng truy cập nhất định.
Vậy làm cách nào để sử dụng hiệu quả "ngân sách thu thập dữ liệu" hạn chế này để crawler truy cập thường xuyên hơn với cùng một ngân sách?
Đó là tốc độ tải trang web phải nhanh. Ví dụ, một trang web có thời gian tải xuống trang là 20ms sẽ được crawler truy cập thường xuyên hơn so với một trang web có thời gian tải xuống trang là 200ms.
Về cơ bản, dịch vụ của Durumis hướng đến "dịch vụ toàn cầu", vì vậy chúng tôi đang cung cấp lưu lượng truy cập cơ bản từ 8 vùng trên toàn thế giới.
Vùng máy chủ GCP
Hiện tại, dịch vụ của chúng tôi đang sử dụng 40 vùng của Google bao gồm các vùng ở Châu Á như Seoul, Singapore, Mumbai, Châu Âu như Bỉ, Bắc Mỹ như Los Angeles và South Carolina. Điều này giúp đảm bảo người dùng có thể truy cập nhanh chóng từ bất cứ đâu trên thế giới.
- Global Locations - Regions & Zones | Google Cloud
- Google Cloud offers regions across the world to provide customers with global coverage, low cost, low latency, and application availability.
Tuy nhiên, vì lý do đã đề cập ở trên, chúng tôi quyết định tinh chỉnh thêm để đạt được tốc độ tối ưu hơn.
Hiện tại, dịch vụ của chúng tôi đang trong quá trình chuyển đổi từ phương thức URL ban đầu sang phương thức tên miền phụ mới, do đó có một số chuyển hướng (Redirect) và Google Crawler đang truy cập vào phần này nhiều. Chúng ta cần phải giúp Google nhận biết nhanh chóng URL mới từ URL cũ.
Vì vậy, để tận dụng tối đa ngân sách thu thập dữ liệu được cung cấp, lưu lượng truy cập cho chuyển hướng cần phải duy trì tốc độ nhanh nhất có thể.
Trước đây, GKE được triển khai ở 8 vùng đã đề cập ở trên và mỗi GKE sử dụng GKE Autopilot của Google để thực hiện chuyển hướng bằng dữ liệu không liên quan đến cơ sở dữ liệu.
- Autopilot overview | Google Kubernetes Engine (GKE) | Google Cloud
- Plan, set up, and have GKE Autopilot mode manage your clusters, including node management, security, and scaling.
Do đó, chúng tôi quyết định di chuyển một số logic hiện có trên GKE và Cloud Run sang Cloud Run mới. Danh sách các thành phần cần di chuyển như sau:
- robots.txt: Mặc dù là tệp tĩnh, nhưng nó đang phục vụ các nội dung được tạo ra bằng một số logic nhất định trên nhiều tên miền phụ.
- favicon.ico: Tệp tĩnh thuần túy.
- durumis.com/[lang]/@userId/postID: Chuyển hướng đến URL mới -> userId.durumis.com/[lang]/postID
Trước đây, khi sử dụng một framework hơi nặng trên GKE Autopilot để phục vụ, thời gian phản hồi là khoảng 200ms.
Phương pháp mới sử dụng Cloud Run, do logic rất đơn giản nên chúng tôi không sử dụng framework và thay vào đó sử dụng node:http mà không cần thư viện, chỉ dùng mã cơ bản.
const http = require("http"); const fs = require("fs"); const path = require("path"); let cachedFavicon = null; function loadFavicon() { const faviconPath = path.join(__dirname, "favicon.ico"); try { cachedFavicon = fs.readFileSync(faviconPath); console.log("Favicon loaded into memory"); } catch (err) { console.error("Error loading favicon:", err); } } --- 생략 --- const server = http.createServer((req, res) => { if (req.url === "/favicon.ico") { res.writeHead(200, { "Content-Type": "image/x-icon", "Cache-Control": "public,max-age=2419200" } res.end(cachedFavicon); }); server.listen(port, () => { console.log(Server running at http://localhost:${port}/); });
( Không nên sao chép và chạy mã trên trực tiếp. Chỉ nên hiểu ý tưởng cơ bản ).
Đối với favicon.ico, vì đây là tệp ảnh nên chúng tôi đã chọn cách tải từ tệp, lưu trữ trong bộ nhớ và sử dụng để truyền tải.
Sử dụng shell script và gcloud để triển khai đồng thời vào nhiều vùng.
Và...
Kết quả triển khai như sau:
Màn hình Cloud Run
Chúng tôi đã triển khai đến "tất cả các vùng" ở Mỹ, cùng với 2 vùng ở Châu Âu, 2 vùng ở Châu Á, 1 vùng ở Châu Phi và 2 vùng ở Nam Mỹ. Thực ra, đây là một trong những ưu điểm của Serverless, việc triển khai như vậy không làm tăng chi phí. (Thậm chí, nếu phục vụ lưu lượng truy cập từ các vị trí gần hơn, chi phí có thể giảm).
Vậy, tốc độ đã được cải thiện bao nhiêu?
Tốc độ phản hồi của máy chủ trước đây như sau:
GKE Autopilot
Tốc độ sau khi cải thiện như sau:
Sử dụng Cloud Run cho Tệp tĩnh
Chắc hẳn bạn sẽ nghĩ rằng, vì Cloud Run là Serverless nên sẽ có thời gian khởi động lạnh (Cold Start). Nhưng trong trường hợp này, crawler liên tục truy cập theo chu kỳ nên vấn đề này không đáng kể. Đây là một trong những đặc điểm của Serverless trên GCP, nó chuyển đổi giữa trạng thái chờ (Standby) và nhàn rỗi (Idle) để chờ sẵn. (Và tất nhiên là không làm tăng chi phí).
Trong bài đăng tiếp theo, chúng tôi sẽ giải thích về các tệp khác, không phải là tệp tĩnh hoặc chuyển hướng 301 như trên, ví dụ như tệp ảnh hoặc các loại tệp khác.
