Ngày đầu tiên trực tuyến: làm thế nào để không giết trang web của bạn

Giả sử bạn có trang web mới lạ mắt này, với rất nhiều dữ liệu (như hình ảnh lớn) và bạn sắp đưa nó lên mạng. Nếu bạn công khai "quá nhiều", trong những ngày đầu tiên, trang web sẽ tràn ngập các yêu cầu.

Làm thế nào tôi có thể giảm thiểu rủi ro này?

Tôi đã nghĩ về

• sẽ phát triển dần dần, như SO và SF: beta "riêng tư", beta công khai, công khai
• cho phép X kết nối phiên đồng thời, vì vậy người dùng được kết nối vẫn có trải nghiệm tốt về trang web và những người khác có thông báo xin lỗi tốt đẹp

Tôi không thể:

• mua nhiều máy chủ hơn, vì sau những ngày đầu tiên, trang web sẽ có lưu lượng truy cập ít hơn rất nhiều :)

1. Cache càng nhiều càng tốt. Bất kỳ trang nào được tạo động nên được lưu vào bộ đệm để người dùng sẽ có được phiên bản tĩnh. Trong các thành phần trang truy vấn db cũng nên được lưu trữ.
2. Hãy thử sử dụng một dịch vụ bên ngoài như Amazon S3 để phục vụ hình ảnh và đa phương tiện (hoặc sẵn sàng sử dụng nếu trang web đột nhiên bị tấn công với hàng tấn lưu lượng truy cập).

Phát trực tiếp dần dần có thể làm việc cho SOF và SF vì họ đã tích hợp sẵn công khai và nhu cầu, do sự phổ biến của blog của Jeff và Joel. Nếu bạn không có một cơ sở người dùng gần như được bảo đảm như họ đã làm, thì việc phát trực tiếp dần dần có thể gây tử vong.

Tôi sẽ tránh giới hạn bởi các phiên đồng thời, vì khó xác định kết thúc phiên gây ra bởi không hoạt động. Nếu người dùng rời khỏi trong 15 phút và cố gắng tải lại trang của họ, chỉ để nhận thông báo lỗi - bạn vừa mất một người dùng.

Có bao nhiêu kế hoạch đi vào mô hình dữ liệu của bạn? Bạn đã thiết kế một lược đồ cho phép bạn tăng cường khối lượng truy vấn của mình mà không cần các loại, cột nhị phân hoặc các phép nối phức tạp đắt tiền chưa? Bạn đã điều chỉnh phụ trợ cơ sở dữ liệu của bạn (giả sử bạn có một)?

Làm thế nào bạn phục vụ 'hình ảnh lớn' của bạn? Bạn có thể tách nó ra thành một quy trình máy chủ web riêng biệt, thậm chí là một tên miền riêng không?

Bạn đã tải thử nghiệm hệ thống của bạn? Các công cụ như ApacheBench và Siege là vô giá.

Là tất cả cấu hình của bạn trong svn? Là triển khai của bạn tự động? Bạn sẽ rất vui vì điều đó khi bạn phải đưa ứng dụng của chúng tôi ra máy chủ thứ 2.

Một hệ thống thư mời đôi khi có thể là một cách tốt để kiểm soát sự hấp thụ của người dùng đối với một trang web. Bỏ qua một số lời mời nhất định lúc đầu, để trang web không bị quá tải. Sau đó cung cấp cho mỗi người dùng một vài lời mời để chuyển xung quanh cho người khác, từ từ xây dựng số lượng người dùng trên trang web. Bằng cách đó, bạn sẽ không có quá nhiều người truy cập vào trang web ngay từ đầu và bạn không có được lưu lượng truy cập lớn.

Nhược điểm của khóa học là bạn có thể từ chối rất nhiều người dùng ngay từ đầu, những người không có lời mời và những người không thể quay lại sau này. Trừ khi bạn có một trang web thực sự tốt mà mọi người rất hào hứng sử dụng, thì đây có thể là một động thái xấu. Nó phụ thuộc vào trang web thực sự. Ngoài ra, bạn thực sự phải có thêm thời gian phát triển để thêm hệ thống thư mời.

Tôi chắc chắn rằng bạn đã có một cơ sở hạ tầng giám sát mạnh mẽ trước khi ra mắt. Bạn cần có dữ liệu để đưa ra quyết định của mình - điều này có nghĩa là đo tải CPU trên các máy chủ, kiểm tra xem tải của bạn có trải đều trên các hộp không và nếu có thứ gì đó tan chảy, bạn sẽ biết đó là cái gì.

Biết được vấn đề ở đâu sẽ giảm đáng kể thời gian cần thiết để trả lời. Tôi đã thấy quá nhiều trang web khởi chạy mà không theo dõi bất kỳ loại nào, với ý định rằng nó sẽ được thiết lập sau đó ... sau khi đám cháy đã tắt. Điều này là sai lầm sâu sắc.

Bạn có thể muốn xem xét việc lưu trữ nội dung tĩnh của bên thứ 3 như Amazon S3. Nó có thể xứng đáng tùy thuộc vào ứng dụng của bạn để đám mây một số (nhiều như tôi ghét từ thông dụng) bằng cách sử dụng Amazon EC2.

Một số nhà cung cấp dịch vụ lưu trữ cho phép bạn kiểm tra các máy chủ riêng với dung lượng tối đa trong một thời gian và sau đó giải quyết dung lượng hợp lý sau thời gian dùng thử.

Dreamhost là một ví dụ:
http://www.dreamhost.com/hosting-vps.html