أداء الصابون مقابل.XML-RPC أو REST

Question

من السهل فهم الحجج حول بساطة الحلول التي تستخدم XML-RPC أو REST، ويصعب الجدال معها.

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

Answer 1

هناك عدد قليل من الدراسات التي تم إجراؤها بخصوص هذا والتي قد تجدها مفيدة.يرجى الاطلاع على ما يلي:

• لذا:الراحة مقابل أداء الصابون
• سؤال وجواب:الصابون والراحة 101
• خدمات بيانات SQL Server المحدثة:تحميلات Northwind REST وSOAP

هناك أيضًا محادثة أداء مثيرة للاهتمام (قديمة إلى حد ما) حول الموضوع في منتديات MSDN.

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

Answer 2

التأثير الرئيسي في سرعة SOAP مقابل.REST لا يتعلق بسرعة السلك، بل يتعلق بقابلية التخزين المؤقت.يقترح REST استخدام دلالات الويب بدلاً من محاولة المرور عبر XML، لذلك تم تصميم خدمات الويب RESTful بشكل عام لاستخدام رؤوس ذاكرة التخزين المؤقت بشكل صحيح، بحيث تعمل بشكل جيد مع البنية التحتية القياسية للويب مثل وكلاء التخزين المؤقت وحتى ذاكرات التخزين المؤقت للمتصفح المحلي.كما أن استخدام دلالات الويب يعني أن أشياء مثل ETags وضغط الرمز البريدي التلقائي هي طرق مفهومة جيدًا لزيادة الكفاءة.

.. والآن أنت تقول أنك تريد المعايير.حسنًا، بمساعدة جوجل، وجدت شخص واحد الذي أظهر اختباره أن REST أسرع بمقدار 4-6 مرات من SOAP وغيره ورق الذي يفضل أيضًا REST.

Answer 3

REST كبروتوكول لا يحدد أي شكل من أشكال مغلف الرسائل، في حين أن SOAP لديه هذا المعيار.

لذلك، من التبسيط إلى حد ما محاولة المقارنة بين الاثنين، فهما تفاح وبرتقال.

ومع ذلك، يبلغ حجم مغلف SOAP (مطروحًا منه البيانات) بضعة كيلو بايت فقط، لذلك لا ينبغي أن يكون هناك أي فرق ملحوظ في السرعة بشرط استرجاع كائن متسلسل عبر كل من SOAP وREST.

Answer 4

يعمل SOAP وأي بروتوكول آخر يستخدم XML بشكل عام على تضخيم رسائلك قليلاً - قد يكون هذا مشكلة أو لا يكون اعتمادًا على السياق.

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

أي شيء يستخدم HTTP عادةً (ما لم يتم إعادة استخدام اتصال HTTP 1.1 Keepalive، وهو ما لا تفعله العديد من التطبيقات) يبدأ اتصال TCP جديد لكل طلب؛وهذا أمر سيء للغاية، خاصة فيما يتعلق بالروابط ذات زمن الاستجابة العالي.HTTPS أسوأ بكثير.إذا كان لديك الكثير من الطلبات القصيرة من مرسل واحد إلى مستلم واحد، فكر في كيفية التخلص من هذه النفقات العامة.

إن استخدام HTTP لأي نوع من RPC (سواء كان SOAP أو أي شيء آخر) سيؤدي دائمًا إلى تحمل هذه النفقات العامة.تسمح لك بروتوكولات RPC الأخرى بشكل عام بإبقاء الاتصال مفتوحًا.

Answer 5

التوسع في إجابة "pjz".

إذا كنت تحصل على الكثير من المعلومات (الحصول على نوع المكالمات) المستندة إلى عمليات SOAP، فلا توجد حاليًا طريقة يمكنك من خلالها تخزينها مؤقتًا.ولكن إذا كنت ستقوم بتنفيذ هذه العمليات نفسها باستخدام REST، فهناك احتمال أن يتم تخزين البيانات مؤقتًا (يعتمد على سياق عملك)، كما هو مذكور أعلاه.نظرًا لأن SOAP يستخدم POST لعملياته، فلا يمكنه تخزين المعلومات مؤقتًا على جانب الخادم.

Answer 6

الصابون أبطأ بالتأكيد.تكون الحمولات أكبر بكثير مما يجعلها أبطأ في التجميع والنقل والتحليل والتحقق من الصحة والمعالجة.

Answer 7

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

إذا التزمت بتدفقات قصيرة وقابلة للتكرار من البيانات (على سبيل المثال، 500 عنصر)، فيجب أن تكون السرعة مقبولة.

Answer 8

أعتقد أن السؤال الرئيسي هنا هو كيفية مقارنة RPC مع SOAP.

كلاهما يخدم نفس النهج في تجريد الاتصالات من خلال وجود كائنات أساسية تعمل بها وأنواع بيانات بدائية/معقدة يمكنك استعادتها دون معرفة كيفية التعامل مع كل هذا تحتها.

أفضّل دائمًا (JSON-)RPC لأنه

• انها خفيفة الوزن
• هناك العديد من التطبيقات الرائعة لجميع لغات البرمجة
• من السهل التعلم/الاستخدام/الإنشاء
• إنه سريع (خاصة مع JSON)

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

بعض التفاصيل الإضافية التي تحصل عليها من تدفق المكدس هذا سؤال