هل يجب أن أتصل مباشرة بمقبس CouchDB وأمر طلبات HTTP أو استخدام Node.js كبديل؟

Question

أولا هنا سؤالي الأصلي الذي ولدت كل هذا.

أنا أستخدم AppCelerator Titanium لتطوير تطبيق iPhone (في النهاية Android أيضًا). أنا أتصل بمنفذ Couchdb مباشرة باستخدام Titanium Titanium.network.tcpsocket كائن. أنا يصدق يستخدم فئة Apple SDK CFSocket/NSStream.

بمجرد الاتصال ، أكتب ببساطة:

'GET /mydb/_changes?filter=app/myfilter&feed=continuous&gameid=4&heartbeat=30000 HTTP/1.1\r\n\r\n'

مباشرة إلى المقبس. إنه يبقيه مفتوحًا "إلى الأبد" ويعيد بيانات JSON كلما تم تحديث DB ويطابق طلب المرشح وتغيير الطلب. رائع.

أنا أتساءل ، هل من المقبول الاتصال مباشرة بمقبس Couchdb مثل هذا ، أو هل سأكون أفضل من فتح المقبس إلى Node.js بدلاً من ذلك ، وربما استخدام هذا Couchdb Node.js وحدة للتعامل مع وكيل CouchDB من خلال node.js؟

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

Answer 1

أنا مرة أخرى. :-)

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

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

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

الكتابة مباشرة إلى الأريكة عبر TCPSOCKE هي A-OK طالما أن تكتب طلب HTTP الذي تم تشكيله جيدًا والذي يتبع المواصفات. (أنت لا تمرر طلب فو ... هذا طلب حقيقي HTTP الذي ترسله تمامًا مثل أي شيء آخر.)

ملاحظة: يتطلب منك HTTP 1.1 تضمين رأس مضيف في الطلب ، لذلك ستحتاج إلى تصحيح التعليمات البرمجية الخاصة بك لتعكس ذلك أو فقط استخدام HTTP 1.0 الذي لا يتطلب الأمر للحفاظ على الأمور بسيطة. (أنا فضولي لماذا لا تستخدم titanium.network.httpclient. هل يمنحك فقط جسم الطلب بعد انتهاء الطلب أو شيء من هذا القبيل؟)

على أي حال ، يمكن لـ CouchDB التعامل مع الاتصالات المباشرة تمامًا-وما لم تبذل الكثير من الجهد في وكيل العقدة الخاص بك-من المحتمل أن يمنح المستخدمين تجربة أفضل عندما يكون لديك 100 ألف منهم يلعبون اللعبة في وقت واحد.

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

ألقِ نظرة أيضًا على كيفية عمل "multinode":http://www.sitepen.com/blog/2010/07/14/multi-node-concurrent-nodejs-http-server/