تفسير مقابل.اللغات المجمعة لمواقع الويب (PHP، ASP، Perl، Python، إلخ.)

Question

أقوم ببناء مواقع ويب تعتمد على قواعد البيانات.لقد استخدمت سابقًا لغة Perl أو PHP مع MySQL.

الآن أبدأ مشروعًا جديدًا كبيرًا، وأريد أن أفعل ذلك بالطريقة التي ستؤدي إلى الموقع الأكثر استجابة ممكن.

لقد رأيت عدة صفحات هنا حيث يتم انتقاد الأسئلة حول كيفية تحسين PHP بإصدارات مختلفة من "لا يستحق بذل جهود كبيرة لتحسين PHP نظرًا لأنها لغة مفسرة ولن تحدث فرقًا كبيرًا".

لقد سمعت أيضًا مناقشات مختلفة (خاصة في بودكاست SO) حول فوائد مجمعة مقابلاللغات المترجمة, ويبدو أنه سيكون من مصلحتي استخدام لغة مجمعة لخدمة الموقع بدلاً من اللغة المترجمة.

هل هذا ممكن حتى في سياق الويب؟ إذا كان الأمر كذلك، ما هو اختيار اللغة المعقول؟

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

Answer 1

ما يمكنك فعله هو ما تفعله العديد من مواقع الويب ذات الزيارات الكثيفة (مثل Facebook أو Twitter)، والمعروف أيضًا بكتابة خوارزمية "استهلاك وحدة المعالجة المركزية" الخاصة بك في مكون إضافي C.

على سبيل المثال، يمكنك كتابة امتداد PHP إذا كنت تخطط لاستخدام PHP، أو تمديد روبي إذا كنت تخطط لاستخدام Ruby / Ruby on Rails، وما إلى ذلك.

بهذه الطريقة، يمكنك الحفاظ على التعليمات البرمجية المبسطة الخاصة بك بسيطة وسهلة الصيانة (قد يكون من الصعب جدًا التعامل مع الطلب من C بدلاً من PHP)، مع وجود نواة خلفية قوية ومتينة (لأنها مجمعة، والمترجم يخبرك بما القضايا في وقت الترجمة)

Answer 2

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

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

وقد قلت ذلك...هذا لا يعني بالضرورة أن موقعك سيعمل بشكل أسرع بنسبة 100% على لغة مجمعة مقابل لغة مترجمة.يوجد مترجمون فوريون سريعون جدًا في الوقت الحاضر لمختلف اللغات (على سبيل المثال.PHP)، كما أن هناك أدوات تحسين للغات المفسرة تجعلها أسرع حتى من ذلك.

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

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

Answer 3

IMHO، من غير المنطقي تمامًا كتابة تطبيق ويب معقد باستخدام لغة مجمعة، لأنها لا توفر فوائد ضد عدد من مشكلات الإدارة.

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

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

Answer 4

لغة Perl ليست لغة مترجمة:يتم تجميعه إلى bytecode، لذلك تدفع ثمن الترجمة الفورية فقط عند بدء تشغيل الملف القابل للتنفيذ Perl.لذلك عند استخدامه مع Apache، لا تستخدم CGI بل mod_perl.

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

Answer 5

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

1. زمن وصول الشبكة
2. الوسائط الثابتة، وخاصة الصور
3. استعلامات قاعدة البيانات
4. رمز المعالجة من جانب الخادم
5. رمز المعالجة من جانب العميل

1 و 5 ليس لهما علاقة كبيرة بهذا السؤال.

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

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

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

Answer 6

هناك الكثير من الأجزاء التي تدخل في تطبيق الويب.لا يلزم أن يكون الوقت الذي تستغرقه طبقة التطبيق كبيرًا.بالنسبة لتطبيق نموذجي، ستكون أكبر الخسائر في خادم الويب وفي قاعدة البيانات.لن يؤدي استبدال PHP بـ cgi الثنائي إلى تغيير هذا.

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

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

Answer 7

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