Aws-lambda-dotnet: أداء C # Lambda مقابل Node مقابل Python

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

هذا الاختبار يقيس فقط وقت بدء تشغيل اللغة وهو شيء لطالما كانت اللغات الديناميكية مثل Node.js و Python سريعة مقارنة باللغات الثابتة مثل C # و Java بسبب نقص التحقق من النوع والتحميل البطيء للتبعيات.

آسف لم أقصد إغلاقها. لا تتردد في مواصلة المحادثة.

شكرا لإبقاء هذا مفتوحا. ليس المقصود منه النقد ، ولكن كأساس لنقاش مفتوح.

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

فقط لتأكيد فهمي ، أعدت قراءة كيفية عمل حاوية Lambda هنا: http://docs.aws.amazon.com/lambda/latest/dg/lambda-introduction.html

bjorgnormj وثائق غامضة جدا في هذا الصدد :(
لقد قدمت ملاحظات أدناه وآمل أن يتم توضيحها

• 'كيف يمكننا أن نجعلها أفضل؟
  كن دقيقًا في المكان الذي يمكن فيه البحث عن الوقت الفعلي لـ "بعض الوقت" للبيان: "تحتفظ AWS Lambda بالحاوية لبعض الوقت تحسباً لاستدعاء وظيفة Lambda أخرى."
• ماذا تحاول أن تفعل؟
  فهم مقدار الوقت الذي يُحتمل أن تحدث فيه إعادة استخدام الحاوية فعليًا من أجل التنبؤ بالأداء

bjorg ما نشرته هنا ليس وقت بدء تشغيل Lambda _cold. لكن _وقت الاستجابة الدافئ_.

عندما تبدأ وظيفة C # لأول مرة من البرد ، يمكن أن تستغرق ما يصل إلى بضع أجزاء من الألف من الثانية (في حالتي تبلغ 500 مللي ثانية). بمجرد أن يتم تسخينه ، سيبقى على قيد الحياة ويقدم الطلبات بمعدل أسرع مشابه لما نشرته (في حالتي كان حوالي 0.9 إلى 1 مللي ثانية). في نهاية المطاف سوف يموت في نهاية حياته ، أو يحدث القياس الذاتي ويبدأ المزيد من لامبدا الباردة. للحصول على وقت بدء التشغيل ، انتظر 15 دقيقة أو نحو ذلك ، ثم انقر فوق اختبار.

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

من حيث التحسين ، بالنسبة لوقت بدء التشغيل البارد ، يمكنك:

1. تأكد من تلقي الطلبات دائمًا ، على مدار الساعة طوال أيام الأسبوع حتى تكون حيوانات لامداك دافئة دائمًا
2. قم بإعداد ping دوري على lambda (إما جداول ساعة السحاب أو newrelic أو شيء من هذا القبيل) ، بحيث تكون حيوانات lambdas الخاصة بك دافئة دائمًا.

بالنسبة لوقت الاستجابة الدافئ ، ليس هناك الكثير من التحسين:

1. وقت الاستجابة البشري المقبول عمومًا هو 200 مللي ثانية
2. أقل من 1 مللي ثانية هو في الواقع جيد جدًا. نادرًا ما تحصل على هذا السعر خارج helloworld أو toUpper .
3. إذا وضعت بوابة API أمام lambda وفضحت مكالمات HTTP للعالم. سيكون متوسط ​​المكالمة المخزنة مؤقتًا من الويب حوالي 50 مللي ثانية.
4. تحصلك AWS على فواصل زمنية تبلغ 100 مللي ثانية على أي حال
5. من المحتمل أن يكون 0.85 مللي ثانية قريبًا من الأداء الأولي لكود peice العادي C #. حاول تشغيل وظيفتك على جهازك من خلال طريقة رئيسية وانظر.

لا تخلط أيضًا بين الأداء ووقت الاستجابة. فقط لأن Node تستجيب في 20 مللي ثانية عندما تنقر يدويًا بالتسلسل ، لا يعني أنها ستتصرف بنفس الطريقة عندما يكون هناك 100 ألف طلب تلقائي فيض في الثانية ، ويزيد كل ثانية. قم ببعض اختبارات التحميل والتزامن الحقيقية. قد تجد أن اللغات متعددة الخيوط مثل Java أو C # قد تتعامل مع طلبات أكثر في الثانية تحت التحميل. لقد رأيت في الواقع إحصائيات لامدا في بعض الأماكن: Python = أسرع بدء تشغيل بارد ، Java = الطلبات الدافئة الأسرع في الثانية ، لكن لا يمكنني العثور عليها الآن.

على أي حال ، يجب أن يجيب هذا على سؤالك بأمل.

وجدت المناقشة التي تحتوي على المعيار https://www.quora.com/Which-language-better-suits-for-AWS-Lambda

yunspace ، شكرًا على الكتابة التفصيلية. لدي فضول في الغالب حول كيفية قيام تطبيق .NET Core الحالي بتنظيم البيانات من الاستدعاء الداخلي الخام إلى معالج C #. نظرًا لأن المعالج يمكن أن يختلف في التوقيع (حسب النوع وعدد الوسائط) ، سأفترض أنه تم استدعاؤه عبر الانعكاس. لذلك كان سؤالي بشكل أساسي هو ما إذا كانت هناك طريقة للاستدعاء دون التأثير على طبقة التنظيم. على سبيل المثال ، يمكن أن يكون التوقيع Foo(Stream, ILambdaContext) نمط معالج معرف مسبقًا يتجاوز أي منطق لتحويل الحمولة إلى مثيل POCO.

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

لإلغاء تنظيم المدخلات الخام JSON في POCO ، تستخدم lambdas بشكل افتراضي Amazon.Lambda.Serialization.Json التي تعتمد على Newtownsoft Json.Net. ولكن يمكنك تبديل هذا التطبيق الافتراضي باستخدام جهاز التسلسل الخاص بك. انظر قسم التعامل مع أنواع البيانات القياسية

أرى ما تعنيه. تستخدم معظم برامج التسلسل (بما في ذلك Json.Net) انعكاسًا بطيئًا. لإثبات هذه النظرية ، أفترض أنه يمكنك معرفة ما إذا كان Foo(Stream, ILambdaContext) يمنحك وقت استجابة أفضل للاستدعاءات الدافئة. وإذا كان الأمر كذلك ، فمن المحتمل أن يكون من المفيد أن تقوم بتدوير مُسلسل العميل الخاص بك للحصول على سلاسل و POCOs.

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

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

بالنسبة لجميع أوقات التشغيل الأخرى ، بما في ذلك Java ، يمكنك الحصول على ما بين 0.22 - 0.30 مللي ثانية على وظيفة دافئة. وهذا يعني أساسًا أن حمل lambda هو أسوأ 3x-4x لـ C #.

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

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

أنا أيضا أتمنى أن نتمكن من المساعدة. أنا على حافة الهاوية فقط في انتظار وضع C # core للعمل بعدد لا يحصى من الطرق. هذا عامل حاسم بين Azure و Amazon. يعتبر نهج الخادم الأقل من C # أفضل بكثير من الاضطرار إلى صيانة العديد من أجهزة EC2 باستخدام تحديثات Windows وفحوصات الأداء وتحديثات SQL وما إلى ذلك. إنها وظيفة بدوام كامل تقريبًا تجعل هذه البيئات محدثة للعملاء.

يعتبر نهج الخادم الأقل من C # أكثر فعالية من حيث التكلفة ، وأقل كثافة لليد العاملة ، وقابل للتطوير وإعادة الاستخدام تلقائيًا.

المشكلة الأخرى المتبقية هي نهج RDC الفعال من حيث التكلفة والقابل للتطوير الآن :-)

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

genifycom ما أفهمه هو أن هذا الخيط يتتبع فرق الأداء البالغ 0.5 مللي ثانية

للتوضيح ، هذا لا يوقف اعتمادنا لـ C # Lambda (أو LambdaSharp ، كما أطلقنا عليها). إنه مصدر فخر أكثر. :)

أفهم تماما!

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

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

normj هل هناك أي تحديثات حول مشاكل الأداء التي نراها؟

SpoonOfDoom هل رأيت النصيحة بضربه كل 10 دقائق أو نحو ذلك؟ هذه ممارسة قياسية جدًا في .Net إلى الأبد ، في التسعينيات من القرن الماضي ، جعلت استضافتي هي الأسرع مع العلم بذلك بينما لم يفعل أي شخص آخر - لكنها شائعة جدًا بعد الآن وحتى الأدوات الشائعة مثل هذه - https://www.iis.net/downloads / microsoft / application-initialization - التي يوصى بها. تقوم Lambda بتغيير نموذج التكلفة ولكن إلى حد ما تواجه نفس التحديات بغض النظر عن كيفية هندستها.

bitshop هذا ما نقوم به حاليا. نسمي كل شيء مرة كل 10 دقائق ، وفي أغلب الأحيان يكون ذلك مفيدًا. ولكن لا يزال لدينا بعض الارتفاعات كل بضع ساعات ، حيث نصل ​​إلى البداية الباردة مرة أخرى - يبدو أن مثيلات AWS قيد التشغيل. تتمتع Net Lambdas بأقصى عمر ثم يتم استخدام واحدة جديدة بغض النظر عن حالة الحرارة / البرودة الحالية؟ لست متأكد.
يبدو أنه قرار غريب من قبل أمازون بعدم منح المطورين الفرصة للحماية الكاملة ضد هذا (مقابل سعر على الأقل). بالتأكيد ، وصلنا إلى الذروة كل بضع ساعات فقط الآن ، ولكن إذا أصابها أحد العملاء بدلاً من البرنامج النصي الخاص بنا ، فسيظل العميل منزعجًا ويرى أن تطبيقنا غير موثوق به و / أو بطيء.

yunspace يبدو أن وظيفة lambda النموذجية ستظل بحاجة إلى وقت بدء تشغيل بارد يزيد عن 2000 مللي ثانية.
REPORT RequestId: d1e5f56c-0ea9-11e7-bb5d-bb039f76a793 Duration: 2120.69 ms Billed Duration: 2200 ms

normj أي شيء أفعله خطأ؟

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

    // 800ms
    public string FunctionHandler(string input, ILambdaContext context)

    // 2000ms, Request being the other object type
    public string FunctionHandler(Request input, ILambdaContext context)

لدي أوقات بدء تشغيل باردة ~ 21 ثانية في 128 ميجابايت لوظيفتين مختلفتين من lamba في C # ، وكلاهما يستقبل SNS. أحصل على نفس الوقت تقريبًا مع S3 put المشغل مقابل SNS. دافئ ، إنها ~ ثانيتان.

إذا قمت بزيادة الذاكرة إلى 256 ميجا ، أرى أن أوقات سمك القد تنخفض إلى حوالي 10 ثوانٍ ، إلخ.

تظهر سجلات Lambda أنني أستخدمها في الذاكرة الإجمالية 40 ميجابايت.

من إحدى الوظائف ، إجمالي وقت التشغيل:

128 ميجا بايت بارد: تقرير المدة: 21775.92 مللي ثانية تمت الفاتورة المدة: 21800 مللي ثانية حجم الذاكرة: 128 ميجا بايت الحد الأقصى للذاكرة المستخدمة: 35 ميجا بايت

128 ميغا بايت دافئ: تقرير المدة: 1326.76 مللي ثانية تمت الفاتورة المدة: 1400 مللي ثانية حجم الذاكرة: 128 ميجا بايت الحد الأقصى للذاكرة المستخدمة: 37 ميجا بايت

256 ميجا بايت بارد: تقرير المدة: 11159.49 مللي ثانية تمت الفاتورة المدة: 11200 مللي ثانية حجم الذاكرة: 256 ميجا بايت الحد الأقصى للذاكرة المستخدمة: 39 ميجا بايت

256 ميجا بايت دافئ: تقرير المدة: 792.37 مللي ثانية تمت الفاتورة المدة: 800 مللي ثانية حجم الذاكرة: 256 ميجا بايت الحد الأقصى للذاكرة المستخدمة: 39 ميجا بايت

384 ميجا بايت بارد: تقرير المدة: 7566.07 مللي ثانية تمت الفواتير: 7600 مللي ثانية حجم الذاكرة: 384 ميجا بايت الحد الأقصى للذاكرة المستخدمة: 43 ميجا بايت

384 ميجا بايت دافئ: تقرير المدة: 850.59 مللي ثانية تمت الفاتورة المدة: 900 مللي ثانية حجم الذاكرة: 384 ميجا بايت الحد الأقصى للذاكرة المستخدمة: 47 ميجا بايت

فقط للضحك:

1024 ميجا بايت بارد: تقرير المدة: 3309.12 مللي ثانية تمت الفاتورة المدة: 3400 مللي ثانية حجم الذاكرة: 1024 ميجا بايت الحد الأقصى للذاكرة المستخدمة: 38 ميجا بايت

1024 ميغا بايت دافئ: تقرير المدة: 677.57 مللي ثانية المدة: 700 مللي ثانية حجم الذاكرة: 1024 ميجا بايت الحد الأقصى للذاكرة المستخدمة: 41 ميجا بايت

هذا كثير من النفقات لبدء التشغيل البارد.

بالمقارنة ، هذه وظيفة nodejs تقوم بحوالي نصف العمل (الإصدار الأقدم قبل المنفذ إلى C #) ، ولكن نفس نوع العمل (أخذ SNS ، كتابة شيء ما إلى قاعدة بيانات ، تخزين شيء ما إلى S3) ولكن هذا يبدو صحيحًا عبر لوحة مع وظائف أخرى لدينا:

128 ميجا بايت بارد: تقرير المدة: 262.58 مللي ثانية تمت الفاتورة المدة: 300 مللي ثانية حجم الذاكرة: 128 ميجا بايت الحد الأقصى للذاكرة المستخدمة: 19 ميجا بايت

128 ميغا بايت دافئ: تقرير المدة: 134.79 مللي ثانية تمت الفاتورة المدة: 200 مللي ثانية حجم الذاكرة: 128 ميجا بايت الحد الأقصى للذاكرة المستخدمة: 19 ميجا بايت

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

أنا أستخدم أدوات Visual Studio AWS لتحميل الحزمة - تم تجميع الكود مسبقًا للنظام الأساسي المستهدف قبل تحميله ، أليس كذلك؟ هل هناك شيء مفقود أم أن هذا طبيعي؟ الأرقام الأخرى المذكورة هنا أصغر ولكني لا أعرف تخصيص الذاكرة.

يعد وقت التمهيد البارد مشكلة عند إنشاء Slack-bots ، حيث تنتهي مهلة Slack بعد 3000 مللي ثانية. أتمنى حقًا أن تكون هناك طريقة لضمان توفر مثيل دائمًا.

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

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

bjorg لضمان توفر المثيلات دائمًا ، ربما من الأفضل مراعاة EC2 أو ECS

InsidiousForce أنا مندهش أنك تبدأ 21 SpoonOfDoom

تضمين التغريدة :)

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

الخلاصة ، لسوء الحظ ، أنه لا يمكنك الوصول إلى هذا الحد إلا من خلال القيام بكل هذا ، وفي مرحلة ما ، يتوقف تخصيص المزيد من الذاكرة عن كونه ممكنًا. ستتمتع دائمًا بأوقات البدء الباردة هذه ، وعلى الرغم من أنك قد تكون قادرًا على تقليلها ، فمن المحتمل أنك لن تتمكن من تقليلها إلى نقطة يكون فيها من المعقول بالنسبة لواجهة API عامة أو شيء من هذا القبيل - يبدو أنك إذا كنت لا يمكنك الانتظار فقط بين الحين والآخر ، إذن C # Lambda ليست مناسبة لك ، ومن الأفضل لك استخدام مثيل EC2 أو ربما (كما نفعل الآن) Elastic Beanstalk ، إذا كنت تريد نشرًا سهلاً وتوسيع نطاق تلقائي .
نقوم الآن بتحويل Lambdas الخاص بنا إلى مشروع واجهة برمجة تطبيقات ويب ASP.NET ، والذي يتيح لنا الاستمرار في نشر مريح من Visual Studio والاحتفاظ ببعض خيارات القياس التلقائي.

TL ؛ DR: لا يبدو أن هناك طريقة موثوقة لحل هذه المشكلة. استخدم EBS أو EC2 بدلاً من ذلك.

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

أهلا بالجميع!
لقد كتبت مقالًا أنني أقارن بين Python و PHP و Java و Ruby و C #.
هل يمكنك التحقق منه وإبداء رأيك فيه؟ (هذه ليست مادة تقنية بحتة ، ولكنها أكثر تعميماً للمبتدئين)
https://www.cleveroad.com/blog/python-vs-other-programming-languages

هذه المقالة لم تكن مفيدة بالنسبة لي.

أولاً ، لم تكن مقارنة. يقول العنوان الموجود على الصفحة "مزايا استخدام PYTHON على لغات أخرى" لذلك من الواضح أنها ليست مقارنة.

ثانيًا ، لا توجد لغة واحدة تناسب جميع المتطلبات!

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

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

تأتي المشاكل بأشكال عديدة.

أنا أتفق مع جينيفيكوم. بالإضافة إلى ذلك ، هناك بعض النقاط التي تبدو مشكوك فيها إن لم تكن خاطئة تمامًا. على سبيل المثال ، القول بأنك لا تستطيع عمل تطبيقات قاعدة الشبكة (أفترض أن هذا يعني الحوسبة الموزعة؟) في Python يبدو غير مطلع ، على نوجيت وحده .
أيضًا ، ليس لدى Python "طريقة واحدة لحل مشكلة" - فهناك دائمًا طرق متعددة لحل المشكلات ، وعادةً لا يكون لذلك أي علاقة باللغة على الإطلاق.
ثم هناك جزء واحد يبدو أنك تتعارض فيه مع نفسك ، حيث تقول في الرسم البياني الخاص بك أن Python لا يمكنها عمل تطبيقات عبر الأنظمة الأساسية (أليس كذلك؟ يبدو هذا خطأ) ثم في النص "Python متوافق مع جميع أنظمة التشغيل الحديثة تقريبًا" .
هناك أيضًا مشكلات أخرى أصغر - على سبيل المثال ، يمكنك نظريًا كتابة التعليمات البرمجية في C # باستخدام Notepad والترجمة عبر سطر الأوامر ، دون الحاجة إلى IDE ، بينما يجعل IDE المناسب مثل IntelliJ أيضًا تطوير Python أسهل بكثير.

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

genifycom و SpoonOfDoom شكرا لك على رأيك ، وسوف آخذ هذا في الاعتبار.

إليك رأي آخر أكثر ملاءمة لـ .Net Core:
https://read.acloud.guru/comparing-aws-lambda-performance-of-node-js-python-java-c-and-go-29c1163c2581

هل من نصائح حول كيفية جعل كود c # أكثر كفاءة من منظور .NET لمعالجات lambda؟
بعض أمثلة الأسئلة التي أحاول معالجتها:
1) هل سيؤدي جعل وظائف لامدا ثابتة إلى زيادة إعادة استخدام سياق لامدا وتحسين الأداء؟
2) إذا صنعت فئة الوظائف (التي تضم جميع معالجات lambda) فئة فردية ، فهل ستعمل على تحسين الأداء؟
3) إذا قمت بعمل متغيرات ثابتة / للقراءة فقط وقمت بمشاركتها عبر وظائف لامدا ، فهل ستعمل على تحسين الأداء؟

إذا كان لدى أي شخص أي معلومات ، من فضلك اقترح

@ niraj-bpsoftware لماذا تجربها وتنشر نتائجك هنا؟ سأكون مهتمًا جدًا بمعرفة ما إذا كان هناك فرق ملحوظ. لأكون صادقًا ، سأكون مندهشًا تمامًا إذا كان لأي من هؤلاء تأثير.

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

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

3) نفس الشيء.