تحذير: أي وكل المحتوى المنشور يهدف إلى تذكير معرفتي أو الحفاظ عليها، وآمل أن يساعدك ذلك في رحلتك للتعلم أيضًا.
هذه المشاركة حية وسيتم تحديثها بشكل دوري.
إذا وجدت أي عيوب أو لاحظت أن هناك شيئًا مفقودًا، ساعدني على التحسين :)

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

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

LLRT Javascript (جافا سكريبت بوقت تشغيل منخفض)

يتم تطوير وقت تشغيل Javascript جديد بواسطة فريق aws.
إنه تجريبي حاليًا وهناك جهود لمحاولة إصدار نسخة مستقرة بحلول نهاية عام 2024.

راجع الوصف الذي تقدمه AWS:

LLRT (وقت تشغيل منخفض الكمون) هو وقت تشغيل جافا سكريبت خفيف الوزن مصمم لتلبية الطلب المتزايد على التطبيقات السريعة والفعالة بدون خادم. يوفر LLRT بدء تشغيل أسرع بما يصل إلى 10 مرات وتكلفة إجمالية أقل بما يصل إلى 2x مقارنة بأوقات تشغيل JavaScript الأخرى التي تعمل على AWS Lambda
إنه مدمج في Rust، ويستخدم QuickJS كمحرك JavaScript، مما يضمن الاستخدام الفعال للذاكرة وبدء التشغيل السريع.

لاحظ أنهم يهدفون إلى تقديم شيء أسرع بما يصل إلى 10 مرات من أوقات تشغيل JS الأخرى.

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

لكن لا تقلق، ليس كل شيء ورديًا، إنها مقايضات (تورية فظيعة، أعرف ذلك).
لذلك، هناك بعض النقاط المهمة التي يجب مراعاتها قبل التفكير في اعتماد LLRT JS. شاهد ما تقوله AWS:

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

علاوة على ذلك، الفكرة هي أن LLRT JS ليس بديلاً لـnode.js ولن يكون كذلك أبدًا.

ينظر:

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

الاختبارات التقييمية

مع الأخذ في الاعتبار قابلية التطبيق التي ذكرتها AWS نفسها، سنجري اختبارين لتقييم ومقارنة LLRT مع NodeJS. سيكون أحد الاختبارين مخصصًا لحساب الأعداد الأولية والآخر سيكون لاستدعاء API بسيط.

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

التدريب العملي إذن...

إنشاء دالة لامدا الأولى باستخدام العقدة:

الآن، لنقم بإنشاء الدالة باستخدام LLRT JS. اخترت استخدام خيار الطبقة.

إنشاء الطبقة:

ثم أنشئ الدالة:

وأضف هذه الطبقة إلى وظيفة LLRT JS التي تم إنشاؤها:

لإختبار الأعداد الأولية سنستخدم الكود التالي:

let isLambdaWarm = false
export async function handler(event)  {

    const limit = event.limit || 100000;  // Defina um limite alto para aumentar a complexidade
    const primes = [];
    const startTime = Date.now()
    const isPrime = (num) => {
        if (num 



ولأجل اختبار واجهة برمجة التطبيقات، سنستخدم الكود أدناه:


let isLambdaWarm = false
export async function handler(event) {

  const url = event.url || 'https://jsonplaceholder.typicode.com/posts/1'
  console.log('starting fetch url', { url })
  const startTime = Date.now()

  let resp;
  try {
    const response = await fetch(url)
    const data = await response.json()
    const endTime = Date.now() - startTime
    resp = {
      statusCode: 200,
      body: JSON.stringify({
        executionTime: `${endTime} ms`,
        isLambdaWarm: `${isLambdaWarm}`
      }),
    }
  }
  catch (error) {
    resp = {
      statusCode: 500,
      body: JSON.stringify({
        message: 'Error fetching data',
        error: error.message,
      }),
    }
  }

  if (!isLambdaWarm) {
    isLambdaWarm = true
  }

  return resp;
};






  
  
  نتائج الاختبار


الهدف هنا تعليمي أكثر، لذا تتكون العينة الخاصة بنا لكل اختبار من 15 بيانات بداية دافئة وبيانات بداية باردة واحدة.

استهلاك الذاكرة

LLRT JS - تم استهلاك نفس مقدار الذاكرة لكلا الاختبارين: 23 ميجابايت.

NodeJS - بالنسبة لاختبار الأعداد الأولية، بدأت الـNodejs في استهلاك 69 ميجابايت وارتفعت إلى 106 ميجابايت. 

بالنسبة لاختبار API، كان الحد الأدنى 86 ميجابايت والحد الأقصى 106 ميجابايت. 

مدة التنفيذ

وبعد إزالة القيم المتطرفة، كانت هذه النتيجة:





التقرير النهائي

استهلاك الذاكرة - بالنسبة لاستهلاك الذاكرة، لوحظ أن LLRT استخدم الموارد المتاحة بشكل أفضل مقارنةً بـnodejs.

الأداء - لاحظنا أنه في سيناريو المعالجة العالية، حافظت العقدة على أداء أفضل بكثير من LLRT، سواء في البداية الباردة أو الدافئة.

بالنسبة لسيناريو المعالجة الأقل، كان لدى LLRT ميزة معينة، خاصة في البداية الباردة.

 دعونا ننتظر النتائج النهائية ونأمل أن نتمكن من إجراء تحسينات أكثر أهمية، ولكن من الرائع أن نرى مرونة JS ونرى مقدار ما يمكنها وما زال يتعين عليها تقديمه لنا. 


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