Làm cách nào để tính toán yêu cầu máy chủ cho ứng dụng web

Tôi đang phát triển phần phụ trợ, trong đó tôi sẽ hiển thị API cho ứng dụng di động của mình. Người dùng có thể đăng ký, thêm sản phẩm, chia sẻ liên kết của sản phẩm thông qua email / sms / bất cứ nơi nào và những người khác có thể nhấp vào nó và mua sản phẩm. Đây là quy trình làm việc đơn giản của ứng dụng di động. Ứng dụng này là một ứng dụng chuyên sâu về hình ảnh sẽ có các hình ảnh tải lên và truy xuất sẽ được thực hiện bởi dịch vụ đám mây của bên thứ ba. Vì phần hình ảnh không được xử lý bởi phần phụ trợ của tôi.

Bây giờ tôi đến từ nhóm phát triển và có ít kinh nghiệm về phía máy chủ phần cứng. Khi tôi đưa ra yêu cầu về cơ sở hạ tầng, họ đã hỏi tôi những câu hỏi sau.

1. Thông lượng ứng dụng / lưu trữ
2. Thông lượng ứng dụng (Số kết nối đồng thời trong 3 tháng, 6 tháng và 1 năm)
3. Thông lượng lưu trữ (Tăng trưởng dữ liệu trong 3 tháng, 6 tháng và 1 năm)
4. Yêu cầu HA
5. Yêu cầu DR

Tôi không chắc làm thế nào để tôi dự báo 3 điểm trên. Làm thế nào thông qua đặt được tính toán? Tôi ước tính sẽ có 10000 người dùng đăng ký trên ứng dụng của tôi trong tháng đầu tiên, trong đó 5000 người dùng sẽ hoạt động. Trên một lần đăng nhập trung bình vào ứng dụng, sẽ có 10 lần truy cập API cho mỗi người dùng, điều này sẽ dẫn đến 5000 * 10 = 50.000 lượt truy cập mỗi tháng, sẽ là 1 lần truy cập API mỗi phút, tức là ~ 2 kết nối đồng thời trong tháng đầu tiên.

Là tính toán đi như thế này? và làm thế nào để tôi tính toán sự tăng trưởng dữ liệu? Có nghĩa là, một người dùng đăng ký, tạo ra sản phẩm và nếu tôi tổng kích thước cơ sở dữ liệu được tiêu thụ cho điều đó, đó có phải là cái được gọi là tăng trưởng dữ liệu không?

Câu hỏi này có vẻ thảm hại, nhưng tôi thực sự cần sự giúp đỡ trong việc tìm ra cách tính thông lượng cho các yêu cầu máy chủ.

Ba điểm đầu tiên là lập kế hoạch năng lực. Tổ chức đang cố gắng lập ngân sách và dự đoán cho tương lai. Than ôi, không có cách đơn giản hoặc được chấp nhận để dự đoán hiệu suất và khả năng mở rộng. Mỗi ứng dụng và môi trường là khác nhau. Do đó, cách tốt nhất để trả lời điều này là đo lường.

Đặc biệt:

1. Thảo luận với quản lý hoặc chủ sở hữu sản phẩm của bạn về khả năng tăng trưởng của người dùng và các loại người dùng khác nhau. Nếu họ không biết, hãy đoán nhưng tài liệu cho rằng đây là những phỏng đoán.
2. Tạo tự động chạy qua các đường dẫn chung của ứng dụng của bạn. Bạn có thể ghi lại hoạt động hoặc nhập chính bạn vào các ứng dụng kiểm tra tải như JMeter .
3. Tạo một môi trường thử nghiệm phù hợp với phần cứng hiện tại hoặc dự kiến ​​của bạn. Hãy chú ý đến những thứ như băng thông, lưu trữ, SSL, ghi nhật ký hoặc các khía cạnh thường bị lãng quên khác có thể ảnh hưởng đến hiệu suất. Giả sử dịch vụ hình ảnh của bên thứ ba nếu bạn có thể, sử dụng hình ảnh nhỏ hơn hoặc đại diện.
4. Sử dụng ứng dụng kiểm tra tải để tạo đề xuất cho số lượng người dùng dự kiến ​​tại các thời điểm khác nhau.
5. Sử dụng một công cụ quản lý hiệu suất ứng dụng, như AppDOUNDics hoặc DynaTrace , để đo lường hiệu suất và xác định các tắc nghẽn.

Ngoài các yêu cầu trên, điều này có thể giúp bạn:

1. Xác nhận môi trường của bạn hỗ trợ tải yêu cầu.
2. Tìm tải tối đa mà môi trường của bạn hỗ trợ.
3. Tìm (các) nút cổ chai giới hạn hiệu suất hoặc khả năng mở rộng của bạn.
4. Thử nghiệm với các cấu hình khác nhau để xem cách thực hiện hoặc tỷ lệ.
5. Quan sát cách hệ thống đối phó khi bạn kích hoạt thất bại.

Hai điểm cuối cùng, yêu cầu HA (tính sẵn sàng cao) và DR (khắc phục thảm họa, có lẽ là RPO (mục tiêu điểm khôi phục) và RTO (mục tiêu thời gian phục hồi) ), khó dự đoán hơn vì đây thực sự là những yêu cầu kinh doanh. Thảo luận với quản lý hoặc chủ sở hữu sản phẩm của bạn về các lỗi có thể xảy ra và chi phí cho chúng để giảm thiểu hoặc khắc phục . Nếu cả hai bạn đều chưa quen với điều này, hãy mong đợi nhiều điều đoán và đêm muộn về phía bạn.

Tôi sẽ đề xuất một cơ sở khách quan hơn. Chuyển đến nhật ký HTTP hiện có của bạn. Giả sử đây là bản cập nhật cho một ứng dụng đã có trong ứng dụng hiện trường, chỉ cần kéo nhật ký và kiểm tra các yêu cầu HTTP được bao gồm. Điều này cung cấp một cơ sở khách quan tuyệt đối trước mô hình tải của bạn thay vì một ngón tay ướt trong không khí để kiểm tra gió.

Ngoài ra, hãy ghi nhớ từ góc độ QA. Bạn không thể sở hữu cả hai yêu cầu và xác nhận. Vì vậy, bạn có thể sử dụng dữ liệu khách quan từ nhật ký để giúp xây dựng mô hình tải thông tin, nhưng ai đó trong doanh nghiệp cần phải đăng xuất theo định nghĩa thực tế. Tại sao? Bởi vì bạn đang đưa ra một yêu cầu trong luồng mà trước đây không có sẵn cho các nhà phát triển, kiến ​​trúc sư, người quản lý nền tảng, v.v ... nếu bạn thất bại trong ứng dụng, bạn muốn doanh nghiệp đứng sau bạn rằng các con số là chính xác.

Những gì bạn có thể kéo các bản ghi?

• Tốc độ giao dịch cao nhất mỗi giờ (đếm yêu cầu bị chặn theo giờ)
• Người dùng cao nhất mỗi giờ (đếm địa chỉ IP bị chặn theo giờ)
• Luồng dữ liệu người dùng (Xem thẻ tham chiếu về các yêu cầu để xây dựng một cây các yêu cầu trước đó)
• Thời gian phản hồi hiện tại (nếu bạn đã bật trường thời gian w3c cho các cuộc gọi dịch vụ web của bạn). Điều này có thể được sử dụng để đặt kỳ vọng cho các bản phát hành trong tương lai trên cơ sở khách quan để đạt hoặc vượt quá mô hình hiện tại
• Suy nghĩ thời gian từ sự chậm trễ giữa các yêu cầu bằng IP. Bạn có thể mô hình thực tế các điểm mẫu vào thời gian giữa hai yêu cầu bằng cách lấy thẻ tham chiếu và chặn theo địa chỉ IP để xây dựng một tập hợp mẫu. Sau đó, bạn có thể kéo các số liệu thống kê về các mẫu đó trong thời gian suy nghĩ tối thiểu, tối đa, trung bình, 90 phần trăm. Heck, một số gói thống kê thậm chí sẽ cung cấp cho bạn một chức năng mà bạn có thể chèn một số ngẫu nhiên vào để có được phân phối phù hợp với sản xuất
• Nếu bạn có nhật ký cho các khoảng thời gian trước đó, bạn có thể dự kiến ​​các mô hình tăng trưởng để quan sát so với mong muốn (bán hàng hoặc sử dụng dự báo)

Tôi thích Splunk cho loại công việc này. Đối với hầu hết các tổ chức, bạn sẽ có thể kéo nhật ký trị giá 30 ngày vào tầng miễn phí mà không phải lo lắng về việc thiết lập một nửa tá ứng dụng khác nhau giống như bạn làm với ngăn xếp ELK.

Nhận sai các yêu cầu và bạn cũng có thể đuổi theo những bóng ma kỹ thuật sẽ không bao giờ xảy ra trong sản xuất và không thực sự làm giảm bất kỳ rủi ro nào. Hãy chắc chắn rằng ai đó ở phía doanh nghiệp ký tắt các yêu cầu của bạn hoặc bạn cũng có thể sở hữu các khoản vượt quá ngân sách cá nhân để theo đuổi các khuyết điểm.

Tôi thực sự thích câu hỏi của bạn. Đó là một điều tốt. Tôi không nghĩ rằng có một câu trả lời thực sự cho điều này nhưng tôi sẽ cố gắng. Khi tạo / thiết kế một Máy chủ mới, điều quan trọng nhất là phải chọn đúng
Môi trường và Phương thức. Không phải tất cả các môi trường là quy mô, hầu hết chỉ trong một cách hạn chế. Nhóm Phần cứng đang cố gắng tính toán là gì, loại hệ thống tập tin và Giao diện nào họ có thể sử dụng. Một số hệ thống tập tin dễ cài đặt nhưng khó mở rộng. Những người khác khó thiết lập nhưng dễ quản lý và mở rộng.

Điều tốt nhất theo ý kiến ​​của tôi là, để liên lạc với những người hỏi bạn những Câu hỏi này và giải thích chúng tại sao bạn không thể trả lời những câu hỏi này ngay bây giờ. Khi khởi chạy một Ứng dụng hoặc Hệ thống mới, không ai có thể nói tất cả điều này phát triển như thế nào, đặc biệt là khi không có Hệ thống nào khác mà bạn có thể so sánh. Nhưng bạn có kiến ​​thức về API mà bạn thiết kế và "Người đàn ông phần cứng" có kiến ​​thức về cách thức Môi trường / Máy chủ của anh ấy hoạt động. Cùng nhau bạn có thể tìm ra câu hỏi này cho chắc chắn.

Hy vọng điều này sẽ giúp bạn.