Giá proxy theo yêu cầu

Bạn trả tiền cho điều gì

Bạn trả theo số yêu cầu nhà cung cấp đếm. Họ có thể bán gói cố định hoặc tính khi dùng. Giá thường ghi theo nghìn hoặc triệu yêu cầu. Điều này giúp so biểu giá nhưng không cho biết số phải trả lúc mua: gói nhỏ nhất có thể chứa nhiều yêu cầu hơn.

Cùng từ “yêu cầu” có thể mô tả dịch vụ khác nhau. Proxy thường chuyển yêu cầu ứng dụng đến trang web rồi trả phản hồi. Ứng dụng tự tải trang và trích dữ liệu. Với API thu thập dữ liệu, giá còn có thể gồm chạy trình duyệt, xử lý hạn chế truy cập và chuẩn bị kết quả. Vì vậy chỉ so giá yêu cầu là chưa đủ; cần biết dịch vụ làm gì với giá đó.

Cách tính này thuận tiện cho công việc theo lịch. Bạn có thể đã biết số trang cần kiểm tra và tần suất. Tiếp theo, tìm mỗi lần kiểm tra dùng bao nhiêu yêu cầu. Khi đó có thể ước tính gói cho một tháng và mức dùng tăng thế nào nếu thêm trang.

Kích thước phản hồi không nhất thiết ảnh hưởng giá. Nếu mỗi yêu cầu cùng giá, lấy nhiều dữ liệu trong một phản hồi có thể bằng giá lấy phản hồi nhỏ. Tuy nhiên hãy kiểm tra nội dung biểu giá: có thể có giới hạn băng thông, kích thước phản hồi hoặc thời gian thực thi. Xử lý dữ liệu bổ sung cũng có thể tính riêng.

Gói yêu cầu không quyết định số IP bạn nhận. Ví dụ, dịch vụ xoay có thể cho truy cập nhóm IP qua điểm kết nối chung. Đổi IP và giữ địa chỉ trong phiên phụ thuộc thiết lập dịch vụ. Chỉ một lần đổi IP không cho biết bao nhiêu yêu cầu bị tính phí.

Dịch vụ tính điều gì là một yêu cầu

Trước tiên phân biệt yêu cầu với kết nối. Yêu cầu HTTP đề nghị trang web làm việc gì, như trả trang hoặc cung cấp dữ liệu. Trang web gửi phản hồi. Dữ liệu truyền hai chiều tự nó không có nghĩa phải trừ hai yêu cầu. Muốn vậy phải có quy tắc tính phí riêng.

Kết nối là kênh ứng dụng dùng để liên lạc với máy chủ. Nhiều yêu cầu có thể dùng cùng kết nối. HTTP/1.1 cho tái sử dụng kết nối, còn HTTP/2 cho nhiều lượt trao đổi chạy cùng lúc trên đó. Vì vậy số yêu cầu, kết nối đã mở và kết nối hoạt động cùng lúc là các đại lượng khác nhau.

HTTPS thêm một chi tiết. Khi qua proxy HTTP, ứng dụng thường gửi lệnh CONNECT để tạo đường hầm đến trang web. Các yêu cầu sau đi trong đường hầm ở dạng mã hóa. Proxy chuyển dữ liệu nhưng trong cách dùng thông thường không đọc được từng yêu cầu HTTP. Proxy SOCKS cũng cung cấp kết nối đến đích; mỗi hành động ứng dụng không nhất thiết cần kết nối mới.

Vì vậy, có dịch vụ dùng “yêu cầu” để chỉ kết nối hoặc sự kiện khác mà máy chủ proxy đếm được. Dịch vụ khác đếm từng yêu cầu HTTP hay lượt gọi API. Số yêu cầu trong công cụ phát triển trình duyệt có thể khác mức dùng trên bảng điều khiển nhà cung cấp. Chỉ hỗ trợ HTTP, HTTPS hoặc SOCKS5 không xác định quy tắc đếm.

Trước khi mua gói lớn, thử nhỏ. Ghi số tác vụ ứng dụng hoàn thành và số yêu cầu dịch vụ trừ. Dùng đúng ứng dụng, giao thức và thiết lập dự định dùng sau. Thử bằng máy khách HTTP đơn giản không thể hiện mức dùng của trình duyệt còn tải tập lệnh và tài nguyên trang khác.

Vì sao một trang có thể dùng nhiều yêu cầu

Mở trang thường cần nhiều hơn tài liệu chính. Trình duyệt tải riêng định dạng, tập lệnh, hình ảnh và dữ liệu. Trang đang mở có thể tiếp tục liên hệ máy chủ để cập nhật. Một số yêu cầu cũng qua proxy, tùy thiết lập ứng dụng. Cách tính phí phụ thuộc biểu giá.

Theo chuyển hướng thêm một yêu cầu. Nếu trang web trả lời trang nằm ở địa chỉ khác, ứng dụng được đặt theo chuyển hướng sẽ gửi thêm yêu cầu HTTP đến đó. Vì vậy, lấy một tài liệu bằng máy khách đơn giản và mở cả trang trong trình duyệt có thể dùng số yêu cầu khác nhau. Số URL trong danh sách chưa cho biết xử lý chúng cần bao nhiêu yêu cầu.

API có thể hoạt động theo hướng ngược lại: một yêu cầu lấy nhiều bản ghi. Trong ví dụ, trình duyệt gửi năm yêu cầu để tải trang tai nghe kèm giá. Ứng dụng dùng cùng proxy gọi API danh mục của nhà bán lẻ và lấy năm giá sản phẩm bằng một yêu cầu. Đây là API của nhà bán lẻ cung cấp dữ liệu sản phẩm. Nếu nó trả danh mục theo trang, mỗi trang cần thêm yêu cầu. Đôi khi có thể tăng số sản phẩm mỗi phản hồi nếu API hỗ trợ thiết lập đó và trả đủ dữ liệu bạn cần.

Cách này giúp làm thêm việc hữu ích từ gói. Tải lại trang đầy đủ, lấy dữ liệu đã lưu và kiểm tra giá quá thường xuyên có thể nhanh chóng hết hạn mức. Lấy nhiều sản phẩm mỗi lượt gọi, lưu kết quả và chọn tần suất phù hợp giảm số yêu cầu cho cùng công việc. Với cùng tải, hạn mức dùng lâu hơn trong thời hạn gói; hoặc có thể dùng để kiểm tra thêm sản phẩm.

Đo mức dùng cho mỗi tác vụ hoàn thành rất hữu ích. Đó có thể là kiểm tra một trang, lấy danh sách đầy đủ hoặc kiểm tra thành phần xuất hiện sau khi tập lệnh chạy. Đo toàn bộ chuỗi cần để có kết quả, gồm những lượt tải thêm dễ bỏ sót nếu chỉ đếm URL ban đầu.

Khi nào mô hình giá này hữu ích

Giám sát theo lịch

Mức dùng yêu cầu có thể gắn với kiểm tra định kỳ. Ứng dụng có thể theo dõi khả năng truy cập của trang, thay đổi danh sách công khai hoặc kết quả tìm kiếm ở vùng cần. Bạn biết trước số mục tiêu và tần suất. Thử nghiệm cho biết mỗi kiểm tra dùng bao nhiêu yêu cầu và giúp ước tính tiêu thụ tháng.

Không cần kiểm tra các trang khác nhau cùng tần suất. Nếu thông tin đổi mỗi ngày một lần, kiểm tra mỗi phút thường trả cùng dữ liệu. Có thể dành kiểm tra thường xuyên cho trang cần phát hiện thay đổi nhanh. Điều này giữ gói cho những quan sát bạn cần.

Thu thập dữ liệu qua API và thư mục

Mức dùng phụ thuộc cách trang cung cấp thông tin. Nếu danh sách đã chứa đủ dữ liệu, không cần mở từng trang chi tiết. Có thể dành yêu cầu thêm cho mục thiếu dữ liệu hoặc bản ghi đổi từ lượt trước. Mỗi lượt gọi lấy càng nhiều dữ liệu cần thiết, toàn bộ quá trình thu thập càng cần ít yêu cầu.

Cũng cần tính dịch vụ thực hiện gì. API tìm kiếm có thể trả kết quả đã phân tích, còn proxy thường để ứng dụng tải và xử lý. Đây là những lượng công việc khác nhau. Khi so giá, kiểm tra phản hồi chứa gì và bạn còn phải tự làm gì.

Kiểm tra trang và trình duyệt

Kiểm tra kỹ thuật thường có chuỗi rõ ràng: mở địa chỉ, kiểm tra phản hồi, theo chuyển hướng nếu cần và lưu phát hiện. Nếu phần lớn địa chỉ được xử lý tương tự, thử nghiệm giúp ước tính mức dùng. Kiểm tra bằng trình duyệt có thể cần thêm yêu cầu vì phụ thuộc tập lệnh, ảnh và thành phần trang hoạt động.

Chọn cách kiểm tra theo mục đích. Máy khách đơn giản thường đủ để biết trang có phản hồi. Thử biểu mẫu thanh toán phải tải những gì biểu mẫu cần để hoạt động. Tắt tệp cần thiết sẽ giảm yêu cầu nhưng thử nghiệm không còn thể hiện trải nghiệm người dùng.

Lỗi và thử lại ảnh hưởng mức dùng thế nào

Yêu cầu đã gửi không phải luôn trả dữ liệu bạn cần. Trang có thể trả lỗi, bước xác minh truy cập hoặc trang khác. Ngay cả HTTP 200 cũng không đảm bảo ứng dụng nhận đúng thứ muốn: trạng thái báo thành công ở tầng HTTP, còn nội dung cần kiểm tra riêng.

Quy tắc tính phí các yêu cầu này khác nhau. Có dịch vụ đếm yêu cầu đã gửi. Có bên chỉ tính phản hồi đáp ứng định nghĩa hoàn thành thành công của mình. API được quản lý có thể gồm nhiều lần thử nội bộ trong giá một phản hồi. Chế độ hoặc tính năng thêm đôi khi đổi quy tắc. Vì vậy, “trả theo yêu cầu” không tự động là “chỉ trả cho dữ liệu đã lấy”.

Ứng dụng thử lại khác với dịch vụ thử lại nội bộ. Khi ứng dụng gửi lại, nó tạo yêu cầu mới. Khi dịch vụ lặp công việc bạn đã gửi, những lần thử đó có thể nằm trong giá. Hãy xác định lần thử nào bị trừ vào gói.

Khi thử, ghi ba số: tác vụ bắt đầu, yêu cầu tính phí và tác vụ hoàn thành. Hoàn thành phụ thuộc mục đích. Với thu thập dữ liệu, phản hồi cần đúng trường và thông tin đủ mới. Với giám sát khả dụng, phát hiện đúng trang không truy cập được cũng là một lần kiểm tra hoàn thành.

Những số này cho thấy chi phí thực. Yêu cầu rẻ có thể không đáng nếu phản hồi luôn cần thử lại hoặc bị loại. Dịch vụ đắt hơn có thể làm một phần việc thay bạn. So khoản chi để đạt kết quả cần thiết, gồm phần ứng dụng còn phải làm.

Cách tính gói cần thiết

Trước hết tính công việc dự kiến: số mục tiêu cần xử lý và tần suất. Sau đó cộng yêu cầu ngoài lượt lấy bình thường, như thử lại thấy trong kiểm tra. Tính riêng nhóm trang nếu cách hoạt động khác nhau. Tách cả dự phòng tăng tải để không cộng cùng yêu cầu bổ sung hai lần.

Ví dụ minh họa: ứng dụng kiểm tra 150 URL mỗi 30 phút trong 30 ngày. Giả định kiểm tra bình thường dùng một yêu cầu theo biểu giá chọn, và thử thêm tăng mức dùng 5%. Mọi số và giá trong ví dụ đều giả định, không phải kết quả thử của nhà cung cấp hay biểu giá ProxyCompass.

Gói chọn để lại dự phòng 23,200 yêu cầu. Phần này có thể đáp ứng tăng tải khi gói còn hiệu lực. Thử lại dự kiến đã nằm trong 10,800 lần thử bổ sung; không được tính dự phòng này lần nữa thành tiêu thụ cho cùng các lần thử lại.

Giả sử gói giá $10. Nó chứa 250 nghìn yêu cầu, nên giá danh nghĩa mỗi nghìn là $0.04. Bạn trả $10 cho toàn gói. Nhân mức dùng dự kiến 226,800 yêu cầu với giá đó được $9.072. Đây là giá trị phần đã dùng, không phải số tiền thanh toán cho gói: gói cố định vẫn giá $10.

Giờ giả định sau các lần thử thêm, ứng dụng hoàn thành đủ 216,000 lượt kiểm tra theo lịch. Một nghìn lượt hoàn thành tốn khoảng $0.0463: $10 ÷ 216,000 × 1,000. Số này đã tính cả yêu cầu thêm và dự phòng đã mua. Nếu ít lượt hoàn thành hơn, chia khoản chi cho số thực tế.

Phép tính tương tự với tác vụ khác. Khi tính theo mức dùng, nhân yêu cầu tính phí với đơn giá, có xét đơn giá đó bao phủ bao nhiêu yêu cầu. Với gói, dùng toàn giá mua. Sau đó chia khoản chi cho số tác vụ hoàn thành. Nếu nhiều dự án chung gói, quyết định cách phân bổ chi phí giữa chúng.

Cũng kiểm tra ứng dụng có xong đúng hạn không. Ví dụ cần 7,200 lượt kiểm tra mỗi ngày, trung bình năm lượt bắt đầu mỗi phút. Có thể khởi chạy cả 150 lượt mỗi nửa giờ hoặc dàn đều trong khoảng đó. Tiêu thụ gói như nhau nếu mỗi lượt dùng số lần thử giả định, nhưng tải lúc khởi chạy khác. Giới hạn kết nối hoặc tần suất yêu cầu có thể ngăn lịch thứ nhất chạy như dự kiến.

Cách giảm yêu cầu không cần thiết

Bỏ địa chỉ trùng và lưu kết quả trong lúc làm. Sau lỗi, ứng dụng nên tiếp tục từ điểm dừng. Nếu mỗi lần chạy lại cả danh sách, các trang đã xử lý lại tiêu thụ gói. Ghi tác vụ đã xong và tác vụ còn cần xử lý.

Dùng cách tải cần thiết để lấy dữ liệu. Nếu văn bản đã nằm trong phản hồi máy chủ, có thể không cần trình duyệt. Nếu dữ liệu chỉ xuất hiện sau khi chạy tập lệnh, tải đơn giản có thể chưa đủ. Với dịch vụ thu thập dữ liệu, chế độ trình duyệt và tính năng thêm đôi khi dùng nhiều tín dụng hoặc đơn giá khác. Vì vậy một tín dụng không luôn bằng một yêu cầu.

Giảm kích thước phản hồi không luôn tiết kiệm yêu cầu. Nếu nhà cung cấp đếm lượt gọi HTTP, phản hồi ngắn có thể dùng bằng số yêu cầu của phản hồi dài. Để giảm số, có thể kiểm tra dữ liệu không đổi ít thường xuyên hơn, dùng lại kết quả lưu hoặc lấy nhiều bản ghi trong một lượt gọi API. Thông tin vẫn phải đủ mới cho tác vụ.

Giới hạn thử lại và xét nguyên nhân lỗi. Nếu trang tạm không khả dụng hoặc yêu cầu chậm lại, thử ngay có thể trả cùng phản hồi và mất thêm một yêu cầu. Tạm dừng hoặc giảm tần suất có thể hữu ích hơn. Đặc biệt thận trọng với hành động tạo hoặc đổi dữ liệu: kiểm tra kết quả lần đầu trước khi gửi lại. Mất phản hồi không có nghĩa máy chủ chưa làm gì.

Sau khi thay đổi, kiểm tra cả kết quả lẫn mức dùng. Số yêu cầu có thể giảm vì ứng dụng ngừng làm một phần việc. Giảm chỉ hữu ích khi vẫn lấy đúng dữ liệu, đủ mức hoàn chỉnh và kịp thời như cũ bằng ít yêu cầu hơn.

Cần kiểm tra gì khi chọn biểu giá

Trước tiên đảm bảo dịch vụ hoạt động với trang và ứng dụng của bạn. Loại proxy, quốc gia có sẵn, cách phiên hoạt động và quyền vào trang cần qua IP được cấp đều quan trọng. Sau đó so công việc bao gồm: ai tải trang, chạy trình duyệt, trích dữ liệu và thử lại khi lỗi? Điều này giúp giải thích vì sao hai dịch vụ có giá mỗi yêu cầu khác nhau.

Kiểm tra thời hạn gói, quy tắc nạp thêm và cách xử lý yêu cầu chưa dùng. Gói lớn có giá yêu cầu thấp hơn đáng mua nếu dùng kịp cho công việc cần. Nếu một phần đã mua bị bỏ phí, chi phí mỗi tác vụ hoàn thành có thể cao hơn gói nhỏ.

Để so sánh, chọn trang điển hình trong dự án, kể cả trang thường khó xử lý. Ghi thời gian, yêu cầu tiêu thụ, kết quả và thiết lập ứng dụng. Phép thử cho biết kích thước gói cần, chi phí gần đúng và khả năng xong đúng hạn.