PlentyOfFish Architecture

Bài tóm tắt PlentyOfFish 2007 1. Khởi đầu Độ khó: Cơ bản

PlentyOfFish · 2007 · 1. Khởi đầu · Độ khó: Cơ bản — bài gốc

Nguồn thứ cấp: HighScalability tóm tắt phỏng vấn và blog của nhà sáng lập Markus Frind; nhiều số liệu tự báo. Các mục Update về sau (2009) kể thêm việc nâng phần cứng.

Bối cảnh

  • Site hẹn hò do một người vận hành: 1,2 tỉ page view/tháng, 500.000 lượt đăng nhập/ngày, 500–600 trang/giây, sống bằng Google Ads. Stack Windows, ASP.NET, IIS, Akamai, ServerIron.
  • Phần cứng: 2 web server cân bằng tải (2 Xeon 4 nhân, 8 GB RAM, dùng khoảng 800 MB), 3 DB server; gần 64.000 kết nối đồng thời, 2 triệu page view/giờ; đường 1 Gbps dùng 200 Mbps; 171 triệu ảnh/ngày (1 TB) qua Akamai.

Thay đổi chính

  • Load balancer phần cứng vì IIS giới hạn 64.000 kết nối; sticky session theo user thay vì lưu session ngoài (máy chết thì user đăng nhập lại; chấp nhận được với site hẹn hò). Không dùng Windows NLB.
  • Mọi thứ động, gzip toàn bộ output (khoảng 30% CPU) để giảm băng thông; không dùng cache của ASP.NET (dữ liệu hết hạn ngay khi vào cache) và không dùng control dựng sẵn.
  • Database: một DB chính và hai DB cho search; tách đọc khỏi ghi, có DB chỉ đọc, denormalize thành bảng chỉ để đọc thay vì đọc 20 bảng. Theo Frind, gọi DB 20 lần mỗi trang là hết cứu; vấn đề hiệu năng gần như luôn là block trong DB.
  • Scale up: "RAM giải quyết mọi vấn đề, sau đó lên máy lớn hơn"; cập nhật 2009: máy DB lõi 512 GB RAM, 32 CPU, chuyển sang RamSan 250.000 IOPS cho 10.000 ảnh/giây.
  • CDN là lý do một người làm được; theo Frind không có site top 100 nào không dùng CDN.

Vì sao

  • Ứng dụng viết từ đầu, rất đơn giản; theo HighScalability (dẫn Jeff Atwood tính chi phí), Frind giữ scale up có thể vì không muốn viết lại phần mềm cho scale out.

Bài học cho SWE

  • Ở quy mô hàng tỉ page view/tháng, một máy DB lớn + CDN + code đơn giản vẫn đủ nếu workload hợp.
  • Giảm số lần gọi DB mỗi trang và tách đọc/ghi là đòn bẩy lớn nhất trước khi nghĩ tới phân tán.

Liên quan