مقارنة خاطفة بين mod_php و mod_perl و mod_python

لكن هل حقاً تعني هذه الفروقات البسيطة شيئاً؟ أتفهم أنه في البرامج التي تعتمد على الحسابات أنها مسألة حساسة. ولكن الويب شئ مختلف تماماً. هذه الفروقات الصغيرة لا شئ بجانب الـnetwork lag الذي يميز تطبيقات الويب. وقد يكون عنق الزجاجة الرئيسي الآخر هو قاعدة البيانات. وفي الغالب حين تصل إلى بك الحالة إلى أن الشئ الوحيد الذي بقي لتعمل له optimization هو لغة البرمجة فستجد أن لغات الـscripting بشكل عام لن تسعفك. خذ كمثال موقع Facebook. بدأ بالـPHP. وبعد سنوات من تطوير البنية التحتية انتهى بتحويل كوده إلى مزيج من ++C وErlang.

يجب ان لا ننسى ان ال lag بطبيعته متراكم -- accumulative

total_lag = network_lag + application_lag

وعندما يأتي للnetwork_lag فهو نادرا مايكون فوق 500ms جزء ثانية..

غالبا يكون 200ms-300ms حتى مع السيرفرات التي هي في امريكا ودول بعيدة

واذا تلاحظ ان mod_python متأخر عن بقية الmod_xxxx في معظم الاحيان بالثواني وليس فقط ms

وسيتبين المزيد في اختبار قاعدة البيانات لاحقا

وهذا مهم... وللعلم السرعة هي احد اسباب تحول Facebook من mod_php إلى HipHop

HipHop يحول كود php الى كود ++c ويترجمه ب++g وهكذا التطبيق اسرع

قضية زيادة السرعة ليست فقط لارضاء المستخدم الطرفي بل أيضا:

* تؤدي إلى تقليل عدد السيرفرات

* مما يؤدي إلى تقليل فاتورة الكهرباء

* وطبعا الtotal_lag ايضا يقل للمستخدم فالخدمة ستكون سريعة بوضوح

الواقع ان network_lag يعتبر مبالغ فيه... فهو غالبا في حدود 200ms-300ms فقط

والجزء الأكبر من التأخير، الذي يأخذ بالثواني، هو ناتج من تاخير التطبيق نفسه

لذا عنصر سرعة تطبيق الويب مهم جدا.. واذا لم يكن مهما لإكتفى الناس بتطبيقات CGI

لكنهم في الواقع حولوا إلى mod_xxxx لأنها اسرع من نظيراتها CGI.... لان سرعة التطبيق مهمة جدا

تذكر أن أوقات التنفيذ الطويلة هذه هي نتيجة لعمليات غير اعتيادية. لن تكون هناك صفحة تنادي عملية فرز لمليون عنصر مثلاً (إلا إذا كان تصميمك من الأساس سيئاً). في العمليات الاعتيادية لن يكون الفرق بين PHP أو Perl أو Python أو حتى الأرستقراطيان .NET و Java كبيراً بالمقارنة بالـNetwork Lag.

نقطة أخرى. الاتجاه بعيداً عن الـCGI ليس مسألة لغة. لأن الـCGI مستقل عن خيار اللغة. هناك تطبيقات CGI مبرمجة بالـ++C. الابتعاد عنها كان بسبب الأسلوب الذي تتبعه في إدارة الذاكرة. لأنها (حسب ما أتذكر) تنشئ process جديد مع كل عملية.

بالنسبة لعمليات التكرار الغير اعتيادية فهذا فقط لخلق الload

صفحات المواقع عمليا لا تنفذ مليون print في طلب واحد

لكنها ربما تحصل على مليون طلب وكل طلب يحتوي على عشرات print مثلا

فالهدف هو heuristic لخلق load قريب بطريقة سهلة في بيئة تجريبية

جميع الbenchmarks هي عبارة عن خلق load بطريقة heuristic.. وهذا الاسلوب بطبيعته ليس دقيق 100%.. ولهذا السبب نقول every benchmark is flawed

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

بالنسبة لCGI. لم اقل انها مبنية على اللغة.. كل مايحدث انه ملف executable ويعاد توجيه stdout الى html body

حتى لو كان C مثلا كما قلت... وقمت قبل هذا الموضوع بتجربة موقع على C حتى اقارن بنظيره وكان mod_php اسرع

لأن الoverhead في الinter-process communication هو المصيبة

العبئ مع CGI ليس انها تتعامل مع الذاكرة بشكل غبي... هذه شكليات غير مباشرة

المشكلة المباشرة ان هذا الاسلوب الغبي أدى إلى بطئ في التطبيق....

فكل الذي يحدث معها ان stdout يعاد توجيهه الى http body...

يعني يوجد عبئ الinter-process communication وهذا يزيد البطئ

فالمشكلة الأساسية مع تطبيقات CGI هي البطئ..

ولو تقرأ في صفحات mod_xxxx ستجد ان الجانب الاكثر اهتماما لديهم هو زيادة السرعة:

* http://perl.apache.org/

* http://www.modpython.org

اقتباس

mod_perl gives you a persistent Perl interpreter embedded in your web server. This lets you avoid the overhead of starting an external interpreter and avoids the penalty of Perl start-up time, giving you super-fast dynamic content.

فالهدف من وراء كل هذا هو الحصول على السرعة

لماذا لا تجرب تغيير أباتشي إلى مخدم nginx و Fastcgi سترى بكل تأكيد الفرق :)

OMLX

فينك يا اعم :D

هذه نقطة مهمة في زيادة السرعة...

ساجرب مستقبلا مقارنة بين apache و nginx ... لكن في موضوع آخر لان هذا الموضوع فقط عن mod_xxxx وهذه حركات apache فقط

لكن وقتها ساضيف اختبار آخر، لان هذا الاختبار على الارجح لن يبرز قوة nginx:

*ساقوم بتثبيت منتدى، مثل phpBB او ماشابه

* وثم اقوم بارسال العديد من الطلبات.. واحسب الوقت المستهلك في خدمة 10000 زبون مثلا

لكن لو اكتفيت بهذا الاختبار فربما لن يعني شيئا على الارجح. لان ميزة nginx هو حذف الوقت الضائع في خلق process جديدة

لانه لديه process شغال مسبقا ويستقبل عليه الطلبات

فكما تعلم nginx يعتبر even driven بينما apache هو process-based

وحينها ساضيف ايضا uWSGI بالاضافة الى fastcgi... حسب علمي uWSGI سيكون اسرع من fastcgi

اليوم كنت اشاهد هذه الفيديو :

و يتحدث به Haiping Zhao كاتب php hiphop عبارة عن compiler او translator يقوم بتحويل php الى c++ يستخدم لتسريع اداء php على سيرفرات موقع الفيس بوك

المهم انه اثناء الموضوع ذكر ان php ابطئ من بايثون و بيرل وعرض benchmark استنادا الى هذه الموقع : http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=all

اقتباس

* عملية قياس الوقت تمت من خارج الخادم لمزيد من الحيادية. الامرين curl و time

admin@hx01 ~ $ time curl -s http://127.0.0.1/test_primeNums.py >> /dev/null 
real    1m4.788s
user    0m0.006s
sys     0m0.003s

الظاهر أنها جائت من داخل الخادم :D.

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

ahmad123 كتب:

....

المهم انه اثناء الموضوع ذكر ان php ابطئ من بايثون و بيرل وعرض benchmark استنادا الى هذه الموقع : http://shootout.alioth.debian.org/u64q/benchmark.php?test=all〈=all

وهذه ايضا معلوماتي القديمة..

كذلك استغربت في المقارنة السابقة عندما كانت php منافسة قوية

قديما جربت php وكان بطيئا جدا في تجارب بسيطة قريبة من هذه التجارب جدا

لكن الغريب انه حاليا يبدو سريعا جدا

ربما قاموا بتطويرات في php مؤخرا

تحدثت سابقا على ايام المقارنة القديمة مع مطورين pypy واستغربوا ايضا..

جربو الكود بأنفسهم ونفس الشيء، جربوا تعديلات ولكن بطيءة ايضا

وثم الخلاصة كانت ان pypy تحتاج اعادة النظر في I/O

SIFE كتب:

admin@hx01 ~ $ time curl -s http://127.0.0.1/test_primeNums.py >> /dev/null 
real    1m4.788s
user    0m0.006s
sys     0m0.003s

الظاهر أنها جائت من داخل الخادم :D.

بالنسبة لداخل الخادم وخارجه فقصدي هو:

* داخل الخادم: داخل apache، كmodules

* خارج الخادم: خارج apache

لذا قصدي خادم = software و ليس hardware

اقتباس

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

مع موقع بسيط ربما حتى تطبيقات CGI تفي بالغرض

واحيانا المبرمج يختار اللغة التي يرتاح معها اكثر

اليوم قمت باختبار بسيط و نتائج جائت غريبة للغاية , لا اعرف اين خطأ :

#include <stdio.h>

int main(void)
{
        int i ;
        for( i=0;i<999999;i++)
        {
                if( i % 2 == 0 )
                printf("Hello World !\n");
        }
        return 0 ;
}

و

<?php
for($i=0;$i<999999;$i++)
{
if($i%2 == 0 )
printf( "Hello World!\n") ;
}

النتائج

Even Number 
ahmad@ahmad-laptop:~/prog_c$ time php ./prog1
real	0m20.383s
user	0m1.820s
sys	0m2.164s
ahmad@ahmad-laptop:~/prog_c$ time ./prog1
real	0m44.460s
user	0m0.868s
sys	0m4.300s

النتائج تشير الى ان كود php اسرع من كود C !!

هل هناك خطأ ما ؟ ان لم يكن فما تفسير هذه النتائج ؟!!

ahmad123 كتب:

اليوم قمت باختبار بسيط و نتائج جائت غريبة للغاية , لا اعرف اين خطأ :

#include <stdio.h>

int main(void)
{
        int i ;
        for( i=0;i<999999;i++)
        {
                if( i % 2 == 0 )
                printf("Hello World !\n");
        }
        return 0 ;
}

و

<?php
for($i=0;$i<999999;$i++)
{
if($i%2 == 0 )
printf( "Hello World!\n") ;
}

النتائج

Even Number 
ahmad@ahmad-laptop:~/prog_c$ time php ./prog1
real	0m20.383s
user	0m1.820s
sys	0m2.164s
ahmad@ahmad-laptop:~/prog_c$ time ./prog1
real	0m44.460s
user	0m0.868s
sys	0m4.300s

النتائج تشير الى ان كود php اسرع من كود C !!

هل هناك خطأ ما ؟ ان لم يكن فما تفسير هذه النتائج ؟!!

قد تكون المشكلة من أمر printf. أزل أمر الطباعة من الكودين وجرب.

System Down كتب:

قد تكون المشكلة من أمر printf. أزل أمر الطباعة من الكودين وجرب.

صحيح , عند ازالة امر الطباعة النتائج مختلفة تماما :

ahmad@ahmad-laptop:~/prog_c$ time php prog1.php 

real	0m0.307s
user	0m0.296s
sys	0m0.008s
ahmad@ahmad-laptop:~/prog_c$ time ./prog1

real	0m0.009s
user	0m0.008s
sys	0m0.000s

انا جربت كودك وفي جميع الاحوال كان C اسرع

وعندما قمت بتحويل stdout على /dev/null (تخطيت التيرمينال) اصبح الفارق ابرز

user@maxtor-laptop:test$ time php test040.php > /dev/null 

real	0m0.389s
user	0m0.320s
sys	0m0.050s
user@maxtor-laptop:test$ time ./test040 > /dev/null 

real	0m0.024s
user	0m0.030s
sys	0m0.000s

ماهو اصدارة المترجم والمكتبات؟

غريب ان c لديك بطيئة هكذا... عندي اسرع بكثير

بينما نتائج الPHP بيننا متقاربة

اضافة: هذا مضحك... السرعة لديك من غير printf تساوي السرعة لدي مع printf المعاد توجيهها الى /dev/null!!

ماهي اصدارات المترجمات والمكتبات ونظام التشغيل لديك؟

النتائج محيرة نوعا ما !

مترجم gcc version 4.4.5

نظام تشغيل اوبنتو 10.10

هنا gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5)‎