سؤال

يدعم Google App Engine حاليًا كلاً من Python وJava.دعم Java أقل نضجًا.ومع ذلك، يبدو أن Java لديها قائمة أطول من المكتبات وخاصة دعم Java bytecode بغض النظر عن اللغات المستخدمة لكتابة هذا الرمز.ما هي اللغة التي ستوفر أداءً أفضل وقوة أكبر؟يرجى تقديم النصيحة.شكرًا لك!

يحرر: http://groups.google.com/group/google-appengine-java/web/will-it-play-in-app-engine?pli=1

يحرر:أعني بكلمة "القوة" إمكانية توسيع أفضل وإدراج المكتبات المتاحة خارج الإطار.لكن بايثون تسمح فقط بمكتبات بايثون الخالصة.

هل كانت مفيدة؟

المحلول

أنا متحيز (لكوني خبير في Python ولكني صدئ جدًا في Java) ولكن أعتقد أن وقت تشغيل Python لـ GAE حاليًا أكثر تقدمًا وأفضل تطورًا من وقت تشغيل Java - كان لدى الأول عام إضافي واحد للتطوير والنضج، بعد كل شيء .

من الصعب بالطبع التنبؤ بكيفية المضي قدمًا - ربما يكون الطلب أقوى على جانب Java (خاصة وأن الأمر لا يتعلق بـ Java فحسب، بل باللغات الأخرى الموجودة أعلى JVM أيضًا، لذا فهذه هي الطريقة للتشغيل على سبيل المثال.كود PHP أو Ruby على App Engine)؛ومع ذلك، يتمتع فريق Python App Engine بميزة وجود Guido van Rossum، مخترع Python ومهندس قوي بشكل مثير للدهشة.

فيما يتعلق بالمرونة، فإن محرك Java، كما ذكرنا سابقًا، يوفر إمكانية تشغيل كود JVM الثانوي المصنوع بلغات مختلفة، وليس Java فقط - إذا كنت في متجر متعدد اللغات، فهذا أمر إيجابي كبير جدًا.والعكس صحيح، إذا كنت تكره Javascript ولكن يجب عليك تنفيذ بعض التعليمات البرمجية في متصفح المستخدم، فإن Java's GWT (إنشاء Javascript لك من ترميز مستوى Java الخاص بك) أكثر ثراءً وتقدمًا من البدائل من جانب Python (في الممارسة العملية، إذا اخترت Python، ستكتب بعض JS بنفسك لهذا الغرض، بينما إذا اخترت Java فإن GWT هو بديل قابل للاستخدام إذا كنت تكره كتابة JS).

فيما يتعلق بالمكتبات، فهي إلى حد كبير عملية غسيل - JVM مقيدة بدرجة كافية (لا توجد سلاسل رسائل، ولا محمل فئة مخصصة، ولا JNI، ولا قاعدة بيانات علائقية) لعرقلة إعادة الاستخدام البسيط لمكتبات Java الموجودة بنفس القدر، أو أكثر، من Python الموجودة يتم إعاقة المكتبات بالمثل بسبب القيود المماثلة المفروضة على وقت تشغيل Python.

فيما يتعلق بالأداء، أعتقد أنه مجرد غسيل، على الرغم من أنه يجب عليك قياس أداء المهام الخاصة بك - لا تعتمد على أداء تطبيقات JVM المحسّنة للغاية المستندة إلى JIT، مع خصم أوقات بدء التشغيل الكبيرة وآثار الذاكرة، لأن محرك التطبيق البيئة مختلفة تمامًا (سيتم دفع تكاليف بدء التشغيل في كثير من الأحيان، حيث يتم تشغيل مثيلات تطبيقك، وإيقافها، ونقلها إلى مضيفين مختلفين، وما إلى ذلك، وكل ذلك بشكل واضح لك - عادةً ما تكون مثل هذه الأحداث أرخص بكثير مع بيئات تشغيل Python مقارنة بأجهزة JVM).

إن موقف XPath/XSLT (لأكون ملطفًا...) ليس مثاليًا تمامًا على أي من الجانبين، على الرغم من أنني أعتقد أنه قد يكون أقل سوءًا في JVM (حيث، على ما يبدو، يمكن إنشاء مجموعات فرعية كبيرة من الساكسونية للتشغيل ، مع بعض العناية).أعتقد أن الأمر يستحق فتح القضايا على قضايا أبينجين صفحة تحتوي على XPath وXSLT في عناوينها - في الوقت الحالي لا توجد سوى مشكلات تطلب مكتبات محددة، وهذا قصر النظر:لا أهتم حقًا بكيفية تنفيذ XPath/XSLT الجيد لـ Python و/أو Java، طالما أنني سأستخدمه.(قد تعمل مكتبات معينة على تسهيل ترحيل التعليمات البرمجية الموجودة، ولكن هذا أقل أهمية من القدرة على تنفيذ مهام مثل "تطبيق تحويل XSLT بسرعة" بطريقة ما!-).أعلم أنني سأضع نجمة على مثل هذه المشكلة إذا تمت صياغتها بشكل جيد (خاصة بطريقة مستقلة عن اللغة).

أخيراً وليس آخراً:تذكر أنه يمكن أن يكون لديك إصدار مختلف من تطبيقك (باستخدام مخزن البيانات نفسه) حيث يتم تنفيذ بعضها باستخدام وقت تشغيل Python، وبعضها الآخر باستخدام وقت تشغيل Java، ويمكنك الوصول إلى الإصدارات التي تختلف عن الإصدار "الافتراضي/النشيط" باستخدام عناوين URL صريحة .لذلك يمكن أن يكون لديك كلا من بايثون و يستخدم كود Java (في إصدارات مختلفة من تطبيقك) نفس مخزن البيانات ويعدله، مما يمنحك المزيد من المرونة (على الرغم من أن واحدًا فقط سيكون لديه عنوان URL "اللطيف" مثل foobar.appspot.com - والذي ربما يكون مهمًا فقط للوصول من قبل المستخدمين التفاعليين على المتصفحات، أتصور؛-).

نصائح أخرى

شاهد هذا التطبيق للتغييرات في Python وأداء Java:

http://gaejava.appspot.com/(تحرير: الاعتذار، الرابط مكسور الآن. ولكن بعد الفقرة لا يزال تطبيقها عندما رأيت ذلك يعمل آخر)

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

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

فيما يتعلق بالمكتبات المتوفرة، ستجد أن الكثير من مكتبة وقت تشغيل Python واسعة النطاق تعمل من الصندوق (كما يفعل Java). إطار ويب django الشهير (http://www.djangoproject.com/) مدعوم أيضا على Appengine.

فيما يتعلق ب "السلطة"، من الصعب معرفة ما تعنيه، ولكن يتم استخدام Python في العديد من المجالات المختلفة، وخاصة الويب: YouTube مكتوب في بيثون، كما هو الحال بالنسبة للمصدر (اعتبارا من الأسبوع الماضي).

يونيو 2013: هذا الفيديو هو إجابة جيدة جدا بواسطة مهندس جوجل:

http://www.youtube.com/watch؟v=tlrim2krw2e.

TLDR؛ يكون:

  • اختر اللغة التي أنت وفريقك أكثر إنتاجية
  • إذا كنت ترغب في بناء شيء للإنتاج: جافا أو بيثون (لا تذهب)
  • إذا كان لديك فريق كبير وقاعدة رمز معقدة: Java (بسبب تحليل الرمز الثابت وإعادة تكوينه)
  • فرق صغيرة تتكرر بسرعة: بيثون (على الرغم من أن جافا بخير أيضا)

سؤال مهم للنظر في اتخاذ قرار بين بيثون وجافا كيف ستستخدم DataStore في كل لغة (ومعظم الزوايا الأخرى بالسؤال الأصلي قد تم بالفعل تغطية جيدة في هذا الموضوع).

ل Java., ، الطريقة القياسية هي استخدام JDO أو JPA. هذه رائعة لسهولة النقل ولكنها ليست مناسبة تماما إلى Datastore.

تتوفر واجهة برمجة تطبيقات منخفضة المستوى ولكن هذا منخفض للغاية للاستخدام اليومي - إنه أكثر ملاءمة لبناء مكتبات الطرف الثالث.

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

لحسن الحظ، هناك حلول يتم تطويرها للضعف المدرجة لكلتا اللغتين.

ل Java., ، يتم استخدام واجهة برمجة التطبيقات ذات المستوى المنخفض لتطوير مكتبات الاستمرار التي هي أكثر ملاءمة بكثير إلى Datastore ثم JDO / JPA (IMO). ومن الأمثلة على ذلك مشروع سيينا, ، و اعترض.

لقد بدأت مؤخرا في استخدام اعتراض وإيجاد أنه من السهل جدا استخدامه وملائما جيدا إلى قاعدة البيانات، وقد ترجمت شعبيتها المتنامية إلى دعم جيد. على سبيل المثال، يعترض تعريفه رسميا من قبل خدمة Google New Cloud Qualpoints. من ناحية أخرى، يعترض أن يعمل فقط مع DataStore، في حين أن Siena "مستوحاة" من قبل DataStore ولكن تم تصميمه للعمل مع مجموعة متنوعة من قواعد بيانات SQL و NOSQL DataStores.

لبثون, ، هناك جهود تبذل للسماح باستخدام Python Gae Patastore API من GAE. مثال واحد هو SQLite Backend أن Google التي تم إصدارها للاستخدام مع SDK، لكنني أشك في أنها تنوي أن تنمو إلى شيء جاهز. ال typhoonae. ربما يحتوي المشروع على إمكانات أكبر، لكنني لا أعتقد أنه من الإنتاج جاهز بعد (صحيحني إذا كنت مخطئا).

إذا كان أي شخص لديه خبرة مع أي من هذه البدائل أو يعرف الآخرين، يرجى إضافتها في تعليق. أنا شخصيا، أنا حقا أحب GAE Batastore - أجد أنه تحسن كبيرا على AWS SimpleDB - لذلك أتمنى لنجاح هذه الجهود لتخفيف بعض القضايا في استخدامه.

أنا أوصي بشدة جافا ل GAE وهنا لماذا:

  1. الأداء: جافا يحتمل أن يكون أسرع ثم بيثون.
  2. تطوير بيثون تحت ضغط نقص مكتبات الطرف الثالث. على سبيل المثال، لا يوجد XSLT ل Python / GAE على الإطلاق. تقريبا جميع مكتبات Python هي ربط C (وتلك ليست غير مدعومة من GAE).
  3. Whacache API: Java SDK لديها قدرات أكثر إثارة للاهتمام من Python SDK.
  4. DATASTORE API: jdo بطيء جدا، ولكن API Java Datastore الأصلي سريع للغاية وسهل.

أنا أستخدم Java / GAE في التنمية الآن.

كما حددت، فإن استخدام JVM لا يقيدك باستخدام لغة Java. يمكن العثور على قائمة لغات JVM والروابط هنا. ومع ذلك, ، يقوم محرك تطبيق Google بتقييد مجموعة الطبقات التي يمكنك استخدامها من مجموعة Java SE العادية، وسوف ترغب في التحقيق في ما إذا كان يمكن استخدام أي من هذه التطبيقات في محرك التطبيق.

تحرير: أرى أنك قد وجدت هذه القائمة

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

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

لقد دهشت بكيفية نظيفة ومباشرة، والمشكلة خالية من Python / django SDK. ومع ذلك، بدأت في الركض في المواقف التي كنت بحاجة للبدء في القيام بمزيد من جافا سكريبت وفكرت في أنني قد أرغب في الاستفادة من GWT وغيرها من أدوات Java Utilities. لقد حصلت في منتصف الطريق فقط من خلال برنامج GAE Java التعليمي، وكانت مشكلة واحدة تلو الأخرى: مشكلات تكوين الكسوف، والتهاب الإصدار JRE، تعقيد العقل الذي يتم تخدير جافا، ومربكة وربما تعليمي مكسور. تحقق من هذا الموقع والآخرين المرتبطون من هنا سأعود إلى بايثون، وسأنظر إلى منامة للمساعدة في تحديات JavaScript الخاصة بي.

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

عندما أفعل عادة في هذا النوع من المعضلات، أبحث عن أرقام لدعم قراري. قررت أن أذهب مع ثعبان لأسباب عديدة، ولكن في حالتي، كان هناك مؤامرة واحدة كانت نقطة التحول. إذا كنت تبحث عن "Google App Engine" في Github اعتبارا من سبتمبر 2014., ، سوف تجد الرقم التالي:

GAE Language Stats

يمكن أن يكون هناك العديد من التحيزات في هذه الأرقام، ولكن بشكل عام، هناك ثلاث مرات مستودعات GAE Python أكثر من مستودعات GAE Java. ليس ذلك فحسب، ولكن إذا قمت بإدراج المشروعات من خلال "عدد النجوم"، سترى أن غالبية مشاريع الثعبان تظهر في الأعلى (عليك أن تأخذ في الاعتبار أن بيثون كان حول أطول). بالنسبة لي، هذا يجعل حالة قوية لبثون لأنني آخذ في الاعتبار اعتماد المجتمع ودعمه والوثائق وتوافر مشاريع مفتوحة المصدر.

إنه سؤال جيد، وأعتقد أن العديد من الاستجابات قد منحت نقاط عرض جيدة للإيجابيات والسلبيات على جانبي السياج. لقد جربت كل من Appengine Python و JVM (في حالتي كنت أستخدمها Gaelyk. وهو إطار تطبيق Groovy الذي تم بناؤه ل Appengine). عندما يتعلق الأمر بالأداء على النظام الأساسي، فإن الشيء الوحيد الذي لم أفكر فيه حتى كان يحدقني في الوجه هو ضمان "طلبات التحميل" التي تحدث على جانب جافا من السياج. عند استخدام Groovy هذه الطلبات التحميل هي قاتل.

أنا وضعت وظيفة معا على الموضوع (http://distractable.net/coding/google-appengine-java-vs-python-performance-complison/) وأنا آمل أن أجد طريقة للعمل حول المشكلة، ولكن إذا لم أكن أعتقد أنني سأعود إلى مزيج ثعبان + Django حتى تطلب طلبات Java البداية الباردة أقل من تأثير.

استنادا إلى مقدار ما أسمع شعب Java يشكو من Appengine مقارنة بمستخدمي Python، أود أن أقول بيثون أقل إرهاقا للاستخدام.

هناك أيضا مشروع UnlaMaten ابتلاع, ، والتي تبدو بتمويل من Google إذا لم تكن مملوكة من Google. إنهم يحاولون تنفيذ الخلفية القائمة على LLVM للحصول على Python 2.6.1 ByTecode، حتى يتمكنوا من استخدام JIT ومختلف التعيينات الأصلية لطيفة / GC / متعددة النواة. (اقتباس لطيفة: "نطمح إلى عدم القيام بعمل أصلي، بدلا من ذلك باستخدام أكبر قدر ممكن من الثلاثين عاما من البحث قدر الإمكان.") يبحثون عن سرعة 5x إلى CpeThon.

بالطبع هذا لا يجيب على سؤالك الفوري، ولكن يشير نحو "إغلاق الفجوة" (إن وجد) في المستقبل (نأمل).

جمال Python NewDays هو مدى توصيله بلغات أخرى. على سبيل المثال، يمكنك الحصول على كل من Python و Java على نفس الجدول مع Jython. بالطبع Jython على الرغم من أنه يدعم بالكامل مكتبات Java، فإنه لا يدعم مكتبات بيثون بالكامل. ولكن إنه حل مثالي إذا كنت ترغب في الفوضى مع مكتبات Java. حتى يسمح لك بمزجها مع رمز Java بدون ترميز إضافي.

ولكن حتى بيثون نفسها جعلت بعض الخطوات forwared. انظر CTTYPES على سبيل المثال، بالقرب من سرعة C، accees المباشرة إلى مكتبات C جميعا دون ترك راحة ترميز الثعبان. سايلون يذهب خطوة واحدة، مما يسمح بمزج كود C مع رمز بيثون بكل سهولة، أو حتى إذا كنت لا ترغب في الفوضى مع C أو C ++، فلا يزال بإمكانك الترميز في Python ولكن استخدام متغيرات من النوع الثابت يجعل برامج Python الخاصة بك بأسرع تطبيقات C وبعد يستخدم سيليثون ودعمه من قبل Google بالمناسبة.

أمس حتى وجدت أدوات لبثون لتضمين ج أو حتى التجميع (انظر Corepy)، لا يمكنك الحصول على أي أقوى من ذلك.

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

مع Python، يمكنك الحصول على Acess to C / C ++، Java، .NET والعديد من المكتبات الأخرى ذات الترميز الإضافي الصفر تقريبا مما يمنحك لغة تقلل، يبسط وتجميل الترميز. انها لغة إغراء جدا.

ذهبت مع بيثون على الرغم من أن GWT يبدو مباراة مثالية لنوع التطبيق الذي أتطور فيه. JPA افسدت جدا على GAE (على سبيل المثال لا @ embeddable وغيرها من القيود غير الموثقة الغامضة). بعد أن أمضيت أسبوعا، يمكنني معرفة أن جافا فقط لا تشعر بالحق في GAE في الوقت الحالي.

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

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

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

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

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

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

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top