تسعير الوكلاء حسب الطلب

مقابل ماذا تدفع

تدفع مقابل عدد الطلبات التي يحتسبها المزود. وقد يبيع باقات ثابتة أو يحاسبك حسب استخدام الخدمة. وتُذكر الأسعار غالبًا لكل ألف أو مليون طلب. ويسهّل ذلك مقارنة التعريفات، لكنه لا يخبرك بما يجب دفعه عند الشراء: فقد تتضمن أصغر باقة طلبات أكثر.

قد تصف الكلمة نفسها، «طلب»، خدمات مختلفة. فالوكيل العادي يمرّر طلبات تطبيقك إلى المواقع ويعيد استجاباتها. ويتولى تطبيقك تحميل الصفحات واستخراج البيانات. ومع API لجمع البيانات، قد يشمل السعر أيضًا تشغيل متصفح ومعالجة قيود الوصول وإعداد النتائج. لذلك لا تكفي مقارنة سعر الطلب وحده؛ بل تحتاج إلى معرفة ما تؤديه الخدمة مقابل السعر.

يلائم هذا التسعير العمل المجدول. فقد تعرف بالفعل عدد الصفحات المطلوب فحصها ومعدل الفحص. ثم اعرف عدد الطلبات التي يستخدمها كل فحص. ويمكنك عندها تقدير الباقة اللازمة لشهر ومقدار نمو الاستخدام عند إضافة صفحات.

لا يؤثر حجم الاستجابة في السعر بالضرورة. فإذا فرضت التعريفة المبلغ نفسه لكل طلب، فقد يكلف جلب بيانات أكثر في استجابة واحدة بقدر استجابة صغيرة. لكن تحقق مما تشمله التعريفة: فقد توجد حدود لعرض النطاق أو حجم الاستجابة أو وقت التنفيذ. وقد تكون لمعالجة البيانات الإضافية رسوم مستقلة أيضًا.

لا تحدد باقة الطلبات عدد عناوين IP التي تتلقاها. فمثلًا يمكن لخدمة متناوبة إتاحة مجموعة IP عبر نقطة اتصال مشتركة. وتعتمد تغييرات IP والاحتفاظ بعنوان لجلسة على إعدادات الخدمة. ولا يخبرك تغيير IP وحده بعدد الطلبات التي ستُفوتر.

ما الذي تحتسبه الخدمة طلبًا واحدًا

ابدأ بتمييز الطلب عن الاتصال. فطلب HTTP يطلب من الموقع فعل شيء، مثل إعادة صفحة أو توفير بيانات. ويرسل الموقع استجابة. ولا تعني حركة البيانات في الاتجاهين بذاتها خصم طلبين. فذلك يحتاج إلى قاعدة فوترة مستقلة.

الاتصال قناة يتواصل التطبيق عبرها مع الخادم. ويمكن لعدة طلبات استخدام الاتصال نفسه. ويتيح HTTP/1.1 إعادة استخدام الاتصال، بينما يتيح HTTP/2 عدة تبادلات متزامنة عليه. لذلك فإن عدد الطلبات والاتصالات المفتوحة والاتصالات النشطة في الوقت نفسه قياسات مختلفة.

يضيف HTTPS تفصيلًا آخر. فعند الاتصال عبر وكيل HTTP، يرسل التطبيق عادة أمر CONNECT لإنشاء نفق إلى الموقع. ثم تنتقل الطلبات اللاحقة مشفّرة داخله. ويمرّر الوكيل البيانات، لكنه لا يستطيع في الاستخدام العادي قراءة طلبات HTTP الفردية. كما يوفر وكيل SOCKS اتصالًا بالوجهة؛ ولا يحتاج كل إجراء في التطبيق بالضرورة إلى اتصال جديد.

لهذا تستخدم بعض الخدمات كلمة «طلب» بمعنى اتصال أو حدث آخر يستطيع خادم الوكيل عده. وتحتسب أخرى طلبات HTTP منفردة أو استدعاءات API. لذلك قد يختلف عدد الطلبات في أدوات المطور للمتصفح عن الاستخدام في لوحة المزود. ولا يحدد دعم HTTP أو HTTPS أو SOCKS5 وحده قاعدة الاحتساب.

قبل شراء باقة كبيرة، نفّذ اختبارًا صغيرًا. وسجّل عدد المهام التي يكملها التطبيق وعدد الطلبات التي تخصمها الخدمة. واستخدم التطبيق والبروتوكول والإعدادات التي تنوي استخدامها لاحقًا. فلن يوضح اختبار بعميل HTTP بسيط استخدام متصفح يحمّل أيضًا البرامج النصية وموارد الصفحة الأخرى.

لماذا قد تستخدم صفحة واحدة عدة طلبات

يتطلب فتح صفحة غالبًا أكثر من مستندها الرئيسي. فالمتصفح يحمّل الأنماط والبرامج النصية والصور والبيانات منفصلة. وقد تستمر صفحة مفتوحة في الاتصال بالخادم للتحديثات. وتمر بعض هذه الطلبات أيضًا عبر الوكيل بحسب إعدادات التطبيق. وتعتمد طريقة فوترة ذلك على التعريفة.

يضيف اتباع إعادة توجيه طلبًا. فإذا أجاب الموقع بأن الصفحة في عنوان آخر، يرسل التطبيق المضبوط لاتباع التوجيه طلب HTTP آخر إلى ذلك العنوان. لذلك قد يستهلك جلب مستند بعميل بسيط وفتح الصفحة كاملة بمتصفح عددين مختلفين من الطلبات. ولا يخبرك عدد عناوين URL في قائمتك بعد بعدد الطلبات اللازمة لمعالجتها.

قد تعمل API بالعكس: فقد يجلب طلب واحد سجلات كثيرة. وفي المثال، يرسل متصفح خمسة طلبات لتحميل صفحة سماعات وسعرها. ويستخدم تطبيق الوكيل نفسه لاستدعاء API كتالوج المتجر ويجلب أسعار خمسة منتجات بطلب واحد. وهذه API المتجر التي تقدم بيانات المنتجات. وإذا أعادت الكتالوج في صفحات، احتاجت كل صفحة إلى طلب آخر. وأحيانًا يمكنك زيادة المنتجات لكل استجابة إذا دعمت API هذا الإعداد وأعادت كل البيانات اللازمة.

يساعدك هذا النهج على إنجاز عمل مفيد أكثر من الباقة. فتكرار تحميل صفحات كاملة وجلب بيانات حفظتها بالفعل وفحص الأسعار أكثر من اللازم قد يستنفد الحصة سريعًا. ويقلل جلب عدة منتجات بكل استدعاء وحفظ النتائج واختيار تكرار فحص مناسب الطلبات اللازمة للمهمة نفسها. وبالحمل نفسه، قد تدوم الحصة أطول ضمن صلاحية الباقة؛ أو يمكنك استخدامها لفحص منتجات أكثر.

يفيد قياس الاستخدام لكل مهمة مكتملة. وقد يعني ذلك فحص صفحة أو جلب قائمة كاملة أو فحص عنصر يظهر بعد تنفيذ البرامج النصية. قس التسلسل الكامل للوصول إلى النتيجة. ويشمل ذلك تحميلات صفحات إضافية يسهل إغفالها عند عد عناوين البداية فقط.

أين يفيد نموذج التسعير هذا

المراقبة المجدولة

يمكن ربط استخدام الطلبات بفحوص دورية. فقد يراقب تطبيق توافر صفحة أو تغير القوائم العامة أو نتائج البحث لمنطقة مطلوبة. وتعرف عدد الأهداف وتكرار الفحص مسبقًا. ويوضح اختبار عدد الطلبات لكل فحص ويساعد في تقدير الاستهلاك الشهري.

لا يلزم فحص الصفحات المختلفة بالتكرار نفسه. فإذا تغيرت المعلومات مرة يوميًا، فسيعيد الفحص كل دقيقة البيانات نفسها غالبًا. ويمكن تخصيص فحوص أكثر تكرارًا لصفحات يهم اكتشاف تغيرها سريعًا. ويحافظ هذا على الباقة للملاحظات التي تحتاج إليها.

جمع البيانات عبر واجهات API والأدلة

يعتمد الاستخدام هنا على طريقة تقديم الموقع للمعلومات. فإذا احتوت القائمة بالفعل كل ما تحتاج إليه، فلا سبب لفتح كل صفحة تفاصيل. ويمكن تخصيص الطلبات الإضافية للعناصر ذات البيانات الناقصة أو السجلات التي تغيرت منذ التشغيل السابق. وكلما جلبت بيانات مطلوبة أكثر في استدعاء واحد، قلّت طلبات الجمع الكامل.

تحتاج أيضًا إلى مراعاة ما تؤديه الخدمة. فقد تعيد API بحث نتائج محللة، بينما يترك وكيل عادي التنزيل والمعالجة لتطبيقك. وهذان مقداران مختلفان من العمل. وعند مقارنة الأسعار، تحقق مما تحتويه الاستجابة وما يظل عليك تنفيذه بنفسك.

تدقيق المواقع وفحوص المتصفح

للتدقيق التقني تسلسل واضح غالبًا: فتح عنوان وفحص الاستجابة واتباع إعادة التوجيه إن لزمت وحفظ النتيجة. وإذا عولجت معظم العناوين بالطريقة نفسها، سهّل الاختبار تقدير الاستخدام. وقد يحتاج فحص المتصفح طلبات أكثر لاعتماده على البرامج النصية والصور وعناصر الصفحة العاملة.

اختر طريقة الفحص حسب الغرض. فغالبًا يكفي عميل بسيط لمعرفة استجابة صفحة. أما اختبار نموذج إتمام شراء فيتطلب تحميل ما يحتاجه ليعمل. وسيقلل تعطيل ملفات مطلوبة الطلبات، لكن الاختبار لن يعود ممثلًا لتجربة المستخدم.

كيف تؤثر الأخطاء وإعادة المحاولة في الاستخدام

لا يعيد طلب مرسل البيانات اللازمة دائمًا. فقد يعيد الموقع خطأ أو تحدي وصول أو صفحة مختلفة. وحتى HTTP 200 لا يضمن تلقي التطبيق ما أراد: فالحالة تبلغ عن نجاح على مستوى HTTP، بينما يحتاج محتوى الاستجابة إلى فحص منفصل.

تختلف قواعد فوترة هذه الطلبات. فتحتسب خدمات الطلبات المرسلة. ولا تفرض أخرى رسومًا إلا على استجابات تحقق تعريفها للإتمام الناجح. وقد تشمل API مُدارة عدة محاولات داخلية لجلب البيانات في سعر استجابة واحدة. وقد تغير أوضاع أو ميزات إضافية قواعد الفوترة. لذلك لا يعني «الدفع لكل طلب» تلقائيًا «الدفع فقط مقابل البيانات المجلوبة».

إعادة المحاولة من تطبيقك تختلف عن المحاولة داخل الخدمة. فعندما يعيد التطبيق إرسال الطلب، ينشئ طلبًا جديدًا. وعندما تعيد الخدمة محاولة عمل قدمته بالفعل، فقد تدخل المحاولات ضمن سعره. اعرف المحاولات التي تُخصم من باقتك.

أثناء الاختبار، سجّل ثلاثة أعداد: المهام المبدوءة والطلبات المفوترة والمهام المكتملة. ويعتمد الإتمام على الغرض. فلجمع البيانات، يجب أن تحتوي الاستجابة الحقول المطلوبة ومعلومات حديثة بما يكفي. ولمراقبة التوافر، يُعد اكتشاف عدم توافر موقع بصورة صحيحة فحصًا مكتملًا أيضًا.

تساعد الأعداد على إظهار تكلفة العمل الحقيقية. فقد تكون الطلبات الرخيصة ضعيفة القيمة إذا احتاجت الاستجابات دائمًا إلى محاولة أخرى أو وجب استبعادها. وقد تؤدي خدمة أغلى بعض العمل نيابة عنك. قارن الإنفاق اللازم للنتيجة المطلوبة، بما يشمل العمل المتبقي لتطبيقك.

كيف تحسب الباقة اللازمة

احسب العمل المخطط أولًا: عدد الأهداف وتكرار معالجتها. ثم أضف الطلبات اللازمة فوق الجلب المعتاد، مثل المحاولات المعادة المرصودة أثناء الاختبار. واحسب مجموعات الصفحات منفصلة إن اختلف سلوكها. وأبق احتياطي نمو الحمل منفصلًا أيضًا، حتى لا تضيف الطلبات الإضافية نفسها مرتين.

لنأخذ مثالًا توضيحيًا. يفحص تطبيق 150 عنوان URL كل 30 دقيقة لمدة 30 يومًا. وافترض أن الفحص العادي يستهلك طلبًا واحدًا وفق التعريفة المختارة، وأن المحاولات الإضافية تزيد الاستخدام بنسبة 5%. وكل الأرقام والأسعار هنا افتراضية؛ وليست نتائج اختبار مزود أو تعريفة ProxyCompass.

تترك الباقة المختارة احتياطيًا قدره 23,200 طلبًا. ويمكنه تغطية نمو الحمل ما دامت الباقة صالحة. وقد أُدرجت المحاولات المعادة المتوقعة بالفعل في المحاولات الإضافية البالغ عددها 10,800؛ فلا ينبغي احتساب الاحتياطي مجددًا استخدامًا للمحاولات نفسها.

افترض أن الباقة تكلف $10. وتحتوي 250 ألف طلب، فيكون السعر الاسمي لكل ألف $0.04. وتدفع $10 للباقة كلها. وضرب الاستخدام المتوقع البالغ 226,800 طلبًا بذلك المعدل يعطي $9.072. وهذه قيمة الجزء المستخدم، لا مبلغ الشراء: فقد ظلت تكلفة الباقة الثابتة $10.

افترض الآن أن التطبيق، بعد المحاولات الإضافية، يكمل كل الفحوص المجدولة وعددها 216,000. وتكلف ألف عملية فحص مكتملة نحو $0.0463: $10 ÷ 216,000 × 1,000. ويأخذ هذا المبلغ في الحسبان الطلبات الإضافية والاحتياطي المشترى معًا. وإذا اكتملت فحوص أقل، فاقسم الإنفاق على عددها الفعلي.

يعمل الحساب بالطريقة نفسها للمهام الأخرى. ففي الفوترة حسب الاستخدام، اضرب الطلبات القابلة للفوترة بمعدل التعريفة مع مراعاة عدد الطلبات التي يغطيها المعدل. وفي الباقة، استخدم سعر شرائها كاملًا. ثم اقسم الإنفاق على عدد المهام المكتملة. وإذا تشاركت عدة مشاريع باقة، فحدد كيفية توزيع تكلفتها بينها.

تحقق أيضًا من قدرة التطبيق على إتمام العمل في الوقت المحدد. يتطلب مثالنا 7,200 فحصًا يوميًا، بمتوسط خمس بدايات في الدقيقة. ويمكنك بدء كل الفحوص البالغ عددها 150 فحصًا معًا كل نصف ساعة أو توزيعها على الفترة. وسيكون استهلاك الباقة نفسه إن استغرق كل فحص العدد المفترض من المحاولات، لكن حمل البدء سيختلف. وقد يمنع حد اتصالات أو معدل طلبات تنفيذ الجدول الأول كما خُطط له.

كيف تقلل الطلبات غير الضرورية

أزل العناوين المكررة واحفظ النتائج مع تقدم العمل. وبعد فشل، ينبغي أن يواصل التطبيق من موضع توقفه. وإذا أعاد القائمة كلها كل مرة، استهلكت الصفحات المعالجة الباقة مجددًا. واحتفظ بسجل للمهام المكتملة والتي ما زالت تحتاج إلى معالجة.

استخدم طريقة التحميل اللازمة لجلب البيانات. فإذا وجد النص المطلوب بالفعل في استجابة الخادم، فقد لا يلزم تشغيل متصفح. وإذا لم تظهر البيانات إلا بعد تنفيذ البرامج النصية، فقد لا يكفي تنزيل بسيط. وفي خدمات جمع البيانات، قد يستهلك وضع المتصفح والميزات الإضافية أرصدة أكثر أو يخضعان لتعريفة أخرى. لذلك لا تساوي وحدة رصيد واحدة طلبًا واحدًا دائمًا.

لا يوفر تقليل حجم الاستجابة طلبات دائمًا. فإذا احتسب المزود استدعاءات HTTP، فقد تستهلك استجابة قصيرة عدد الطلبات نفسه لاستجابة طويلة. ولتقليل العدد، يمكنك تقليل فحص البيانات غير المتغيرة أو إعادة استخدام نتيجة محفوظة أو جلب عدة سجلات باستدعاء API واحد. ويجب أن تظل المعلومات حديثة بما يكفي لمهمتك.

حدّ إعادة المحاولة وانظر في سبب الفشل. فإذا تعذر الموقع مؤقتًا أو طلب الإبطاء، فقد تعيد المحاولة الفورية الاستجابة نفسها وتستهلك طلبًا آخر. وقد يفيد الانتظار أو تقليل التكرار أكثر. واحذر خصوصًا مع الإجراءات التي تنشئ بيانات أو تغيرها: تحقق من نتيجة المحاولة الأولى قبل إعادة الإرسال. ولا يعني فقدان استجابة أن الخادم لم يفعل شيئًا.

بعد التغييرات، تحقق من النتائج إلى جانب الاستخدام. فقد ينخفض العدد لأن التطبيق توقف عن أداء جزء من المهمة. ويكون التخفيض مفيدًا عندما تظل تحصل على البيانات المطلوبة بالاكتمال والحداثة نفسيهما باستخدام طلبات أقل.

ما الذي تتحقق منه عند اختيار التعريفة

تأكد أولًا من عمل الخدمة مع مواقعك وتطبيقك. فنوع الوكيل والبلدان المتاحة وسلوك الجلسة والوصول إلى الصفحات المطلوبة عبر IP المقدمة كلها مهمة. ثم قارن العمل المشمول: من يحمّل الصفحة ويشغّل المتصفح ويستخرج البيانات ويعيد المحاولات الفاشلة؟ ويساعد هذا في تفسير اختلاف سعر الطلب بين خدمتين.

تحقق من مدة صلاحية الباقة وقواعد الإضافة ومعالجة الطلبات غير المستخدمة. وتكون الباقة الكبيرة بسعر طلب أقل جيدة القيمة إن استطعت استخدامها للعمل اللازم في الوقت المناسب. وإذا لم يُستخدم بعض الطلبات المشتراة، فقد ترتفع تكلفة المهمة المكتملة عما في باقة أصغر.

للمقارنة، اختر صفحات نموذجية من مشروعك، بما فيها الصفحات التي تسبب صعوبة عادة. وسجّل الوقت والطلبات المستخدمة والنتائج والإعدادات. وسيدل الاختبار على حجم الباقة اللازم وتكلفة العمل التقريبية وإمكان إتمامه في الموعد.