صفحة 2 من 3 الأولىالأولى 123 الأخيرةالأخيرة
النتائج 18 إلى 34 من 43
  1. almosmm:
    • almosmm
    • منضم للمجتمع من: Feb 2004
    • لديه عدد مشاركات: 659
    • عدد متابعيه:
    • قوة ترشيحه: 5.1
    14-04-2009, 09:47 PM

    اقتباس المشاركة الأصلية كتبت بواسطة mr_m مشاهدة المشاركة
    almosmm صراحة لا اقتنع بان CodeIgniter مفيدة في ال caching

    بسبب استهلاكها لموارد النظام الذي تسببه هي بمفردها + الكاش الموجودة بها وطريقة التحكم بدائيتين.
    هل تقصد استهلاك إطار العمل كله لموارد النظام ؟

    اشرح لي عملياً اخي الفاضل! ارجوا ان لا تكون ممن يلقون بكلام " سمعوه " فقط من غيرهم ... لأنه وحتى الآن .. الجميع "وأعني المحترف والمبتدئ " يعلم ان CI هو من أقوى وأسرع إطارات العمل المتواجدة حالياً في الساحة ( يتفوق على CakePHP و Zend Framework وغيرهم )
    انا لا اقول هذا الكلام فقط لأنني اقدم دروس CI هنا
    ولا اريد ان اتطرق إلى الاسباب العلمية لأنني ذكرتها مراراً وتكراراً

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

    كما انني دائماً افضل التعديل على المميزات التي لا تعجبني في CI بنفسي ..
    بالطريقة التي تم بناء CI عليها .. تستطيع ان تشاهد المصدر بوضوح تاااام وسوف تجد ان الموضوع سهل جداً

    ارجوا ان يتشارك الاخوة ويطرحوا النقاط المهمة للكاش لكي يستفيد منها من يريد ان ينصع نظام الكاش الخاص به

    • أعـجـبـك؟ 0
    • لم يعجبك؟ 0
  2. عبد الواحد البشيري:

    عدت
    اقتراحاتكم -> www.elbachiri.com

    14-04-2009, 11:39 PM

    اقتباس المشاركة الأصلية كتبت بواسطة Bibrs Web مشاهدة المشاركة
    شكراً على الشرح المبسط
    ملحوظه بسيطه .. نسيت
    كود PHP:
    fclose($fp); 
    بعد التعديل على ملف الكاش ..
    صحيح نسيتها وهي مهمة جدا
    شكرا لك
    اقتباس المشاركة الأصلية كتبت بواسطة المجروح مشاهدة المشاركة
    لا وقت ولا شئ أخي انت تخزن في الذاكرة بيانات بعد عمل serialize لها لحمايتها من أي تغير فيها
    مثلا جلبت بيانات جروب الأعضاء في الموقع مع كل خياراتها في مصفوفة كبيرة
    اعمل لها serialize وخزنها في الإكس كاش

    الأن حينما تأتي لدالة جلب البيانات اللي تكتبها في أول الصفحة خلي فيها شرط
    لو البيان موجود في الذاكرة ( عندك دالة isset خاصة بالإكس كاش كما تري ) يجلب من الرام
    ولو غير موجود يجلبها بتعليمة سكول ويخزنها في الرام متفقين ؟

    طيب متي نحدث البيانات ؟
    هكذا ستظل في الرام دائماً

    أكتب لنفسك دالة وظيفتها كل ما تناديها تقوم وحدها بعمل تعليمة السكول تلك وتخزين الناتج في الرام ( تعمل unset للبيانات في الذاكرة وتعمل تعليمة السكول وتعيد تخزينها )

    ونادي دالتك هذه في كل مكان فيه تحديث للجروبات

    بمعني حينما تدخل كمشرف عام للوحة التحكم وتقوم بإضافة مجموعة جديدة ضع مناداة الدالة في أخر مكان لتلك ال action وهي الخاصة بتخزين بيانات المجموعة الجديدة

    ايضا ضعها في أخر الأكشن الخاصة بعمل update لمجموعة

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

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

    بإختصار خصص لنفسك صفحة لدوال الكاش ضع فيها دالة خاصة لكل نقطة هامة في برمجيتك تحتاج فيها لكاش وناديها حسب ال action أو حسب الزمن من خلال الكرون

    ============
    ملحوظة أخواني
    ركبت الأكس كاش علي السيرفر وبعده مباشرة قل إستهلاك الذاكرة لدي من 58% تقريبا ل 34% كمتوسط
    وهذا أمر أكثر من رائع
    بما ان المعلومات مخزنة في الذاكرة الا يسبب ذالك ضغط على الذاكرة

    • أعـجـبـك؟ 0
    • لم يعجبك؟ 0
  3. mr_m:
    • mr_m
    • منضم للمجتمع من: Jan 2008
    • لديه عدد مشاركات: 516
    • عدد متابعيه:
    • قوة ترشيحه: 5.4

    محمد حمود.

    15-04-2009, 12:33 AM

    almosmm اهلا بك اخي نعم اعني بالفعل ان اطار العمل الجاهز يستهلك موارد النظام .. بشكل نسبي!

    بمعنى.. انك من الممكن ان تبني صفحاتك بشكل سريع وبمرونة عالية بدون اي اطار عمل ..
    لكن قد يحتم عليك تواجدك في فريق او عملك بشكل عام استعمال واحد خاص بكم أو customized او جاهز تماما ..
    > هذا المفهوم نتج بعد اختبار اساليب عدة مع عدد لا باس به من المحاولات. حقيقة لسنوات عدة ان كان يهمك الزمن.

    وبما اني قد مررت بمثل هذا الحديث من قبل فسوف اختصر الحوار حتى لا اكرره
    كنت اقول لمن يحاورني ان يذهب لموقع يعتمد على ZF او CI -ما تم اختبارهم.
    ثم يأتي بمتوسط اوقات التكوين لصفحات العرض ثم التدرج الى عملية شراء المنتج.
    و كان الحد الادنى 7 ملي ثانية (يعني 0.007) والنتيجة عندي لم تزيد عن 2 ملي وهناك صفحات ظهر فيها 0.9 ملي.
    * طبعا تمت مراعاة تشابه البرنامجين.


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

    • أعـجـبـك؟ 0
    • لم يعجبك؟ 0
  4. mr_m:
    • mr_m
    • منضم للمجتمع من: Jan 2008
    • لديه عدد مشاركات: 516
    • عدد متابعيه:
    • قوة ترشيحه: 5.4

    محمد حمود.

    15-04-2009, 12:47 AM

    ارجوا ان يتشارك الاخوة ويطرحوا النقاط المهمة للكاش لكي يستفيد منها من يريد ان ينصع نظام الكاش الخاص به
    ما رايكم -اذا سمح اخونا عبد الواحد- في ان يحدد احد سكربت مجاني لنتنافس في عمل كاش له

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

    ؟

    • أعـجـبـك؟ 0
    • لم يعجبك؟ 0
  5. عبد الواحد البشيري:

    عدت
    اقتراحاتكم -> www.elbachiri.com

    15-04-2009, 01:29 AM

    اقتباس المشاركة الأصلية كتبت بواسطة mr_m مشاهدة المشاركة
    ما رايكم -اذا سمح اخونا عبد الواحد- في ان يحدد احد سكربت مجاني لنتنافس في عمل كاش له

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

    ؟
    الموضوع موضوعكم

    والله اني استفدت من الردود شكرا لكم

    • أعـجـبـك؟ 0
    • لم يعجبك؟ 0
  6. محب الله ورسوله:
    • محب الله ورسوله
    • منضم للمجتمع من: Aug 2004
    • لديه عدد مشاركات: 6,447
    • عدد متابعيه:
    • قوة ترشيحه: 5.0

    السيف أصدق أنباء من الكتب

    15-04-2009, 05:18 AM

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

    بما ان المعلومات مخزنة في الذاكرة الا يسبب ذالك ضغط على الذاكرة
    بل يقللها
    لأنه تكون مخزنة مرة واحدة فقط
    لكن مع الكويري فيتم جلبها مع كل زائر للذاكرة ( لكن أعتقد الماي سكول تقوم بعدم التكرار لو كانت الداتا نفسها ولا أدري هل ذلك إفتراضياً أم بطرق معينة )

    وكما قلت الطريقة مجربة وخفضت الإستهلاك بشدة للسيرفر
    مع العلم اني لدي موقع واحد علي سيرفر 4 جيجا رام

    • أعـجـبـك؟ 0
    • لم يعجبك؟ 0
  7. mr_m:
    • mr_m
    • منضم للمجتمع من: Jan 2008
    • لديه عدد مشاركات: 516
    • عدد متابعيه:
    • قوة ترشيحه: 5.4

    محمد حمود.

    15-04-2009, 07:13 PM

    هناك شيء قابلني عند عمل serializing لمصفوفات كبيرة لوضعها على الرام:

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

    اما من قاعدة البيانات:
    = البحث في جدول -مؤرشف في الاساس لغرض البحث-
    = ارجاع مصفوفة واحدة فقط او عدم ارجاع شيء.


    لذلك انتقلت لقاعدة البيانات فترة .. ثم انتقلت لوسيلة اراها افضل
    وهي تخزين محتويات المصفوفة على شكل نص بدون serializing - ثم استعمال ال Regular Expressions في التحقق والارجاع.
    نظرا لان التعامل مع النصوص اسرع واخف بمرات عديدة من التعامل مع المصفوفات.
    وايضا يقتصد من المعالجة لدى البروسيسور، و قطعة الذاكرة المؤقتة من الرام والتي تخزن فيها المعلومات للمرة الثانية في كل تنفيذ للصفحة..

    • أعـجـبـك؟ 0
    • لم يعجبك؟ 0
  8. محب الله ورسوله:
    • محب الله ورسوله
    • منضم للمجتمع من: Aug 2004
    • لديه عدد مشاركات: 6,447
    • عدد متابعيه:
    • قوة ترشيحه: 5.0

    السيف أصدق أنباء من الكتب

    15-04-2009, 08:13 PM

    اقتباس المشاركة الأصلية كتبت بواسطة mr_m مشاهدة المشاركة
    هناك شيء قابلني عند عمل serializing لمصفوفات كبيرة لوضعها على الرام:

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

    اما من قاعدة البيانات:
    = البحث في جدول -مؤرشف في الاساس لغرض البحث-
    = ارجاع مصفوفة واحدة فقط او عدم ارجاع شيء.


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

    فأيهما أفضل
    ان يكون البيان في الذاكرة مباشرة وتجلبه وتتعامل معه وهو بيان موجود مرة واحدة
    ام يكون علي الهارد مفركش في قاعدة بيانات ثم ترسل كويري يتم ترجمتها ثم بعد الترجمة يتم تكوين البيان المطلوب في جدول جديد ثم إرساله للذاكرة ( مع كل زائر يتم ذلك أو كل وقت من الزمن حسب قواعد البيانات ) ثم يتم التعامل معها !!

    ثم أنك أفترضت أن تلك الكويري تجلب من جدول حقيقي موجود ولن نستخدم join التي ستجمع البيانات من أكثر من جدول عن طريق جدول إفتراضي تقوم بحمله والتجميع فيه وهذا حمل زائد

    الفرق هنا تفرقه بين دالة serialize فقط
    وبين عمود طويل من العمليات

    • أعـجـبـك؟ 0
    • لم يعجبك؟ 0
  9. mr_m:
    • mr_m
    • منضم للمجتمع من: Jan 2008
    • لديه عدد مشاركات: 516
    • عدد متابعيه:
    • قوة ترشيحه: 5.4

    محمد حمود.

    15-04-2009, 10:13 PM

    = اخي بداية استخدامي للنصوص في التعامل مع الرام تم التوصل اليها + تجميعها على سرفرات حقيقية موجودة على الانترنت وعليها ضغط عالي من الزوار.
    و على مواقع متوسطة لها قواعد بيانات بداخلها 45+ الف عضو و ايضا جداول في بعضها اكثر من 100+ الف record . ان ام تخني الذاكرة


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



    = بخصوص الانتقال كلية لتخزين الكاش على قاعدة البيانات بامكانك ان تسميه "خطأ" وانا معك في ذلك.
    لكن هذا كان سنة 2006 وبامكانك تخيل مدى قلة المعلومات والتجارب في هذا المجال وقتها.

    اذا اردت المقارنة في "التخزين على الرام" فقارن بين استخدام المصفوفات X استخدام النصوص
    الذي اعتمد عليه حاليا عند التخزين على الرام كما ذكرت في ردي السابق.



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

    - هناك صفحات ستاتيك تماما يتم تحويل الزائر لها وتكونها بالكرون.
    - وهناك صفحات تستدعي اجزاء استاتيك من الرام واخرى من صفحات اخرى.
    - وايضا هناك fetching لنتائج استعلامات و اعادة تخزينها في جداول لسهولة جلبها.
    - وهناك خرائط للسكشنز والاكشنز الخاصة بها و طريقة عرضها في الرام.
    - وتخزين بيانات دخول لمستخدمين معينين واعدادات اللغة في الرام على شكل نصوص وترك آخرين.


    * واشكال الاستخدام تتوقف على مجال ومهمة الموقع الذي تعمل له كاش .. او بمعنى اصح optimization
    * يمكنني المناقشة فيما تم ذكره فقط حتى تعم الفائدة .. لكن ليس اكثر.

    • أعـجـبـك؟ 0
    • لم يعجبك؟ 0
  10. محب الله ورسوله:
    • محب الله ورسوله
    • منضم للمجتمع من: Aug 2004
    • لديه عدد مشاركات: 6,447
    • عدد متابعيه:
    • قوة ترشيحه: 5.0

    السيف أصدق أنباء من الكتب

    15-04-2009, 10:26 PM

    اقتباس المشاركة الأصلية كتبت بواسطة mr_m مشاهدة المشاركة
    = اخي بداية استخدامي للنصوص في التعامل مع الرام تم التوصل اليها + تجميعها على سرفرات حقيقية موجودة على الانترنت وعليها ضغط عالي من الزوار.
    و على مواقع متوسطة لها قواعد بيانات بداخلها 45+ الف عضو و ايضا جداول في بعضها اكثر من 100+ الف record . ان ام تخني الذاكرة


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



    = بخصوص الانتقال كلية لتخزين الكاش على قاعدة البيانات بامكانك ان تسميه "خطأ" وانا معك في ذلك.
    لكن هذا كان سنة 2006 وبامكانك تخيل مدى قلة المعلومات والتجارب في هذا المجال وقتها.

    اذا اردت المقارنة في "التخزين على الرام" فقارن بين استخدام المصفوفات X استخدام النصوص
    الذي اعتمد عليه حاليا عند التخزين على الرام كما ذكرت في ردي السابق.



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

    - هناك صفحات ستاتيك تماما يتم تحويل الزائر لها وتكونها بالكرون.
    - وهناك صفحات تستدعي اجزاء استاتيك من الرام واخرى من صفحات اخرى.
    - وايضا هناك fetching لنتائج استعلامات و اعادة تخزينها في جداول لسهولة جلبها.
    - وهناك خرائط للسكشنز والاكشنز الخاصة بها و طريقة عرضها في الرام.
    - وتخزين بيانات دخول لمستخدمين معينين واعدادات اللغة في الرام على شكل نصوص وترك آخرين.


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

    فأنت تقول أن تخزين البيان في الذاكرة كان أبطأ من جلبه من قاعدة البيانات
    كيف ذلك والبيان اصلا حينما تطلبه من قاعدة البيانات يتم نقله للذاكرة ليبدأ التعامل معه !!
    يعني هذه الخطوة ما هي إلا خطوة من خطوات التعليمة التي لا بد أن تمر بها وأنت بذلك وفرت كل الخطوات وأستخدمت خطوة واحدة

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

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

    مع العلم أن نظام التخزين في الذاكرة وتحديد ال address كان مجال دراسة لنا في مادتين أيضا مع معالج 8086 ثم جهاز الماري والمانو وكيفية تحديد الأدريس وتخزين البيانات وأيضا درسنا دراسة بسيطة للأسمبلي ليكون تطبيق عملي مع ما درسناه في الهاردوير

    فإذا كان بإمكانك أن تتحكم أنت بالأمر بتدخل بشري منك في ناتج تعليمة معينة فهذا أمر رائع ولهذا وجدت مسرعات ال php وأوجدت تلك الخاصة لكي تسمح لك بعمل ما لا يمكن لأنظمة الداتا بيز عمله لأنها لا تعلم إن كان ذلك الناتج قابل للتحديث أم لا وما مدي ذلك

    • أعـجـبـك؟ 0
    • لم يعجبك؟ 0
  11. mr_m:
    • mr_m
    • منضم للمجتمع من: Jan 2008
    • لديه عدد مشاركات: 516
    • عدد متابعيه:
    • قوة ترشيحه: 5.4

    محمد حمود.

    15-04-2009, 11:02 PM

    اخي هل تعني انك مثلا لكي تعمل تحقق لل login لزائر مثلا هل سوف تتحقق منه عن طريق جلب 50000 مصفوفة
    من الرام و البحث عن اسمه فيها ثم مقارنة معلوماته ؟ أم سوف تتحقق عنه باستعلام SQL ؟

    وايضا ماذا عن هيئة وشكل تخزين البيانات على الرامة؟

    وهل تفضل تخزين كل بيانات الكاش على الرام بدون استخدام اي شيء اخر؟


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

    • أعـجـبـك؟ 0
    • لم يعجبك؟ 0
  12. محب الله ورسوله:
    • محب الله ورسوله
    • منضم للمجتمع من: Aug 2004
    • لديه عدد مشاركات: 6,447
    • عدد متابعيه:
    • قوة ترشيحه: 5.0

    السيف أصدق أنباء من الكتب

    15-04-2009, 11:42 PM

    اقتباس المشاركة الأصلية كتبت بواسطة mr_m مشاهدة المشاركة
    اخي هل تعني انك مثلا لكي تعمل تحقق لل login لزائر مثلا هل سوف تتحقق منه عن طريق جلب 50000 مصفوفة
    من الرام و البحث عن اسمه فيها ثم مقارنة معلوماته ؟ أم سوف تتحقق عنه باستعلام SQL ؟

    وايضا ماذا عن هيئة وشكل تخزين البيانات على الرامة؟

    وهل تفضل تخزين كل بيانات الكاش على الرام بدون استخدام اي شيء اخر؟


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

    ولتفهم ما قصدته بالكاش اللي شرحته
    لديك مجموعات الأعضاء
    حينما تريد بيانات العضو الفلاني وصلاحيته طبقاً لمجموعته
    تذهب وتجلب مجموعته فقط

    ولكن في حالتي تخزن كل المجموعات في مصفوفة في الرام

    هنا ستقول لي إذا الأفضل جلبها سأخبرك لا
    لأنه في نفس الوقت هناك عشرات الأعضاء من أماكن مختلفة دخلوا وتجلب لهم بيانات مجموعاتهم

    هنا لديك الأن 100 زائر في الموقع من 50 مجموعة مختلفة
    كل عضو منهم جلبت له بيانات مجموعة عضويته وخزنتها في address مختلفة في الذاكرة لتبدأ التعامل مع محتواها بعمليات البرمجة ( المنطقية والحسابية )
    طيب هذا يعني أنك جلب معلومات مجموعة العضوية الفلانية مثلا 80 مرة وخزنتها مكررة 80 مرة وأجريت لها في ذلك الوقت 80 تعليمة سكول لنقلهما للذاكرة

    فتوفر هذا كلاه وتجعل المصفوفة كلها في الذاكرة مرة واحدة فقط فتكون

    1- وفرت مساحة الذاكرة بشدة من تكرار بيانات المجموعات
    2- وفرت عملية الترجمة للسكول


    هل وصلت الفكرة ؟
    ما تنقله للذاكرة هو ما تريده فقط فلما مع كل زائر تنقله للذاكرة
    خليه هناك
    =======================================
    علي الهامش

    بشكل مختصر جدا
    كل ما يقوم به المعالج من عمليات يقوم في أول عمله بنقلها للذاكرة والتعامل معها عن طريق الجسر الشمالي
    ولهذا فالشركات من إنتل ل amd تحاول توفير سرعة نقل أفضل
    ومتحكم الذاكرة اللي كان مدمج في المعالج من أول المعالج athelon ولم يكن مدمج في معالجات إنتل وبدأت بدمجه من أول المعالج core i7 هو المتحكم في أماكن البيانات في الذاكرة ونقلها إلخ

    طيب ماذا يحدث لو كان هناك بيان كثير الإستخدام من قبل المعالج
    يعني بيان طلبت عمل أس له ( عمليات الاس أو الفلوتينج بوينت هي أكثر العمليات إرهاق للمعالج ويتم بها قياس قدرة المقالج والتفرقة بينها )
    يقوم المعالج بنقل البيان من الذاكرة البعيدة لذاكرة الكاش القريبة والتي تكون أسرع بكثير ويختلف حجمها من معالج لأخر بل ويختلف طريقة إستخدامها من شركة لأخري
    في amd يوجد مستويين للكاش l1 و l2
    وتزيد إنتل في المعالجات الجديدة ب l3
    كل مستوي يكون أقرب للذاكرة وأقل حجماً ويكون أكثر سرعة وتكلفته أعلي

    فكرة نقل البيان من الذاكرة للكاش الخاص بالمعالج هي نفسها فكرة نقل البيان من قاعدة البيانات لديك للذاكرة كون الذاكرة أسرع

    لو تريد سرد تفصيلي من أول فتح الحاسوب وما يقوم به البايوس وتحميل كيرنل النظام في الذاكرة إلي الفرق بين الذاكرة وما فيها وما يتم نقله للذاكرة الإحتياطية علي الهارد ( swap في حالة لينوكس ) إلخ فقط أمر أخي

    سأحاول بإذن الله شرح الأمر فهو مفيد جدا للمبرمجين لأنه فيه كلام عن ال DBMS خاصة وأن المتطور منها يمكنه أن يضع بيانات داخل الكاش ميموري للمعالج ويتحكم في كل بيان داخل وخارج من المعالج ويخصص bit لتحديد ما كانت المتغير الفلاني حدث عليه تغيير أم لا

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

    هنا تستخدم ال transaction وكل هذه العمليات تعتمد بشدة علي فهم ما يتم علي الرام وما يتم علي الهارد ديسك

    طيب ماذا لو لم تنقطع الكهرباء ولكن حدث عطب في الهارد ديسك ولم تكن البيانات الخاصة بأخر 5 دقائق نقلت للنظام العام للبنك ؟

    طيب ماذا لو كنت عند شباك وتسحب فلوس وفي نفس اللحظة يقوم موظف اخر بإضافة فلوس لك في الحساب
    فسحب الموظف الأول مبلغك من قاعدة البيانات وهو 2000 جنية ثم سحب الموظف علي الشباك الأخر ال 2000 جنيه أيضا
    ثم قام الموظف الجديد بطرح 1000 جنيه سحبتها فأصبح المبلغ الجديد 1000 جنيه
    لأن صار الموظف الثاني لديه بيان يقوم أن حسابك 2000 جنيه وهذا خطأ
    وبالتالي أي عملية يقوم بها يقوم بها علي رقم خاطئ
    هنا يجب أن موظف الشباك الأول كان يغلق علي بيانك في قاعدة البيانات حينما سحبه وحينما يأتي الموظف الثاني لسحبه يخبره النظام أن المتغير مغلق

    طيب هل يغلقه قراءة وكتابة أم كتابة فقط ؟
    طيب لو الموظف الثاني طلبه وتم الرفض هل يطلبه مرة أخري أم يتم تعليمه علي طابوم طلبات مطلوب للمتغير الفلاني ليتم إعطاءه له أو ما يتم فك الإغلاق ؟

    الداتا بيز أكبر بكثير من ان تكون مجرد تعليمة سكول

    خلاصة القول وبشكل عملي
    طلبت تنفيذ تعليمة ستجلب من 5 جداول بإستخدام ال join
    يتم تنفيذ ما طلبت علي الهارد ديسك وتكوين جدول جديد فيه ما طلبت وذلك عن طريق mysql_query()
    الأن يتم نقل هذا الجدول للذاكرة
    ثم يمكنك أن تتعامل معه طوال الفترة الباقية للصفحة من خلال الذاكرة
    سواء mysql_fetch_assoc() أو عد عدد الصفوف إلخ
    كل هذه تتم علي البيانات التي جلبتها لتوك للذاكرة وهذا لتسريع العمل
    ولكن لو ظلت علي الهارد فسيكون الأمر مرهق جدا في كل تنفيذ علي النتائج

    هل وصلت الفكرة ؟

    • أعـجـبـك؟ 0
    • لم يعجبك؟ 0
  13. mr_m:
    • mr_m
    • منضم للمجتمع من: Jan 2008
    • لديه عدد مشاركات: 516
    • عدد متابعيه:
    • قوة ترشيحه: 5.4

    محمد حمود.

    16-04-2009, 12:41 AM

    اخي لو انك اجبت على اسئلتي على شكل نقط وكل على حدة كنت ستسهل علي عملية الرد..

    لا أخي ما أقصده أنك حينما تطلب مثلاً بيانات العضو رقم 5
    يتم ترجمة تعليمة السكول من خلال المعالج عبر المترجم الخاص بال DBMS والذي يحمل نفسه للذاكرة مع الكيرنل الخاص بالنظام
    بعد الترجمة تذهب للهاد باحثة عن الجدول المطلوب
    بعد إيجاده يتم نقله للذاكرة
    ثم يبدأ المعالج في تنفيذ ما تريده علي بيانات ذلك العضو بينه وبين الذاكرة

    ولتفهم ما قصدته بالكاش اللي شرحته
    لديك مجموعات الأعضاء
    حينما تريد بيانات العضو الفلاني وصلاحيته طبقاً لمجموعته
    تذهب وتجلب مجموعته فقط

    ولكن في حالتي تخزن كل المجموعات في مصفوفة في الرام

    هنا ستقول لي إذا الأفضل جلبها سأخبرك لا
    لأنه في نفس الوقت هناك عشرات الأعضاء من أماكن مختلفة دخلوا وتجلب لهم بيانات مجموعاتهم

    هنا لديك الأن 100 زائر في الموقع من 50 مجموعة مختلفة
    كل عضو منهم جلبت له بيانات مجموعة عضويته وخزنتها في address مختلفة في الذاكرة لتبدأ التعامل مع محتواها بعمليات البرمجة ( المنطقية والحسابية )
    طيب هذا يعني أنك جلب معلومات مجموعة العضوية الفلانية مثلا 80 مرة وخزنتها مكررة 80 مرة وأجريت لها في ذلك الوقت 80 تعليمة سكول لنقلهما للذاكرة

    فتوفر هذا كلاه وتجعل المصفوفة كلها في الذاكرة مرة واحدة فقط فتكون

    1- وفرت مساحة الذاكرة بشدة من تكرار بيانات المجموعات
    2- وفرت عملية الترجمة للسكول


    هل وصلت الفكرة ؟
    ما تنقله للذاكرة هو ما تريده فقط فلما مع كل زائر تنقله للذاكرة
    خليه هناك
    طيب انت ذكرت تعامل الداتابيس مع داتا ولم تذكر تعامل PHP مع ال 50000 مصفوفة المخزنة في الرام
    والتي تقوم بفك ال serializing لها ثم تعمل لها declaring في كل طلب للصفحة -ولا يخزن المسرع الا ال intermediate code للصفحات فقط-
    اي ان المصفوفات سيتم معالجتها ووضعها في جدول المتغيرات في الرام ثم يبحث داخل ال 50000 عنصرر في المصفوفة ليخرج لك مصفوفة تتعامل معها.

    بمعنى انك طالما طلبت المصفوفات سوف يتم تعريفها في PHP و البحث فيها مع كل تنفيذ للكود..
    ترى هل هذه العملية اسرع ام البحث في الداتابيس؟

    وبخصوص طريقة تعامل MySQL مع الداتا وفرزها هل يعقل انه لو عندك جدول 500 ميجا انها تنقله للرام؟ ومع كل يوزر

    لا بالطبع عزيزي ما اعرفه انها تبحث فقط ضمن الحقل المحدد لها وهو هنا ال username ولا اعرف ان كانت تنقله للرام كاملا ام لا.
    و ايضا لا يتم التحقق من كل ال entries الموجودة به -حيث يتم فرزها وترتيبها اثناء عملية التخزين- ثم البحث بداخلها.
    ثم بعد النجاح تحدد الاجزاء التي طلبتها من الجدول وترجعها لك.. لكن لا اعتقد ان الجدول ينقل كاملا للذاكرة.


    * وعلى كل ساقتبس لك سطر من ردي قبل السابق
    - وتخزين بيانات دخول لمستخدمين معينين واعدادات اللغة في الرام على شكل نصوص وترك آخرين.
    ويتم وضع ال rules لهم بناء على تحليل اخر اوقات الدخول.



    * لكنك لم تجب على باقي اسئلتي
    وايضا ماذا عن هيئة وشكل تخزين البيانات على الرامة؟

    وهل تفضل تخزين كل بيانات الكاش على الرام بدون استخدام اي شيء اخر؟
    -------------
    اما ما هو مكتوب على الهامش فسوف اقرأه بتأني لأعلق عليه.

    • أعـجـبـك؟ 0
    • لم يعجبك؟ 0
  14. مهندس مصرى:
    • مهندس مصرى
    • منضم للمجتمع من: May 2007
    • لديه عدد مشاركات: 947
    • عدد متابعيه:
    • قوة ترشيحه: 5.0

    قل اللهم مالك المُلك تؤتي الملك من تشاء وتنزع الملك ممن تشاء وتعز من تشاء وتذل من تشاء بيدك الخير انك على كل شىء قدير

    16-04-2009, 02:03 AM

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

    الأن حينما تأتي لدالة جلب البيانات اللي تكتبها في أول الصفحة خلي فيها شرط
    لو البيان موجود في الذاكرة ( عندك دالة isset خاصة بالإكس كاش كما تري ) يجلب من الرام
    ولو غير موجود يجلبها بتعليمة سكول ويخزنها في الرام متفقين ؟

    طيب متي نحدث البيانات ؟
    هكذا ستظل في الرام دائماً

    أكتب لنفسك دالة وظيفتها كل ما تناديها تقوم وحدها بعمل تعليمة السكول تلك وتخزين الناتج في الرام ( تعمل unset للبيانات في الذاكرة وتعمل تعليمة السكول وتعيد تخزينها )

    ونادي دالتك هذه في كل مكان فيه تحديث للجروبات

    بمعني حينما تدخل كمشرف عام للوحة التحكم وتقوم بإضافة مجموعة جديدة ضع مناداة الدالة في أخر مكان لتلك ال action وهي الخاصة بتخزين بيانات المجموعة الجديدة

    ايضا ضعها في أخر الأكشن الخاصة بعمل update لمجموعة

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

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

    بإختصار خصص لنفسك صفحة لدوال الكاش ضع فيها دالة خاصة لكل نقطة هامة في برمجيتك تحتاج فيها لكاش وناديها حسب ال action أو حسب الزمن من خلال الكرون

    ============
    ملحوظة أخواني
    ركبت الأكس كاش علي السيرفر وبعده مباشرة قل إستهلاك الذاكرة لدي من 58% تقريبا ل 34% كمتوسط
    وهذا أمر أكثر من رائع
    جزاك الله خيرا اخي المجروح ..
    ساقوم بالتطبيق و التجربة

    • أعـجـبـك؟ 0
    • لم يعجبك؟ 0
  15. محب الله ورسوله:
    • محب الله ورسوله
    • منضم للمجتمع من: Aug 2004
    • لديه عدد مشاركات: 6,447
    • عدد متابعيه:
    • قوة ترشيحه: 5.0

    السيف أصدق أنباء من الكتب

    16-04-2009, 02:20 AM

    50000 مصفوفة المخزنة
    !!!!!!!!!!!!!!!
    انا أخبرك عن المعلومات المهمة
    يجعني جروبات الأعضاء ( هذه مصفوفة )
    التصنيفات ومعلوماتها ( هذه مصفوفة )
    ملف اللغة ( هذه مصفوفة )
    خيارات الموقع ( هذه مصفوفة )

    كلهم ما يزيدو عن 9 ويكون حجمهم بالكثير جدا 5 ميجا يوم ما تكون مليان وملف اللغة بالألوف
    خليتهم فجأة 50 ألف !!
    ثم هذا ما يقوم به الهاك الرائع vboptimize لمنتديات الفيبولتن حيث يحول ملف اللغة والخيارات وكله للذاكرة مستخدما ال xcache فمن أين حكمت أنها طريقة خاطئة والكثير من المبرمجين المحترفين صاروا يستخدموها ؟
    هل تعتقد أني جايب شئ من عندي أخي ولا مخترع شئ
    كل هذا جلبته من الفيبولتن وهاكاتها وكلها أفكارة موجودة فعلياً في الفيبولتن التي لها كلاسات للتعامل مع 5 أنواع من الكاش

    xcache
    apc
    eaccelerator
    تخزين مباشر في الذاكرة
    الملفات

    وهو ما يستخدمه أيضا vbseo

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

    وبخصوص طريقة تعامل MySQL مع الداتا وفرزها هل يعقل انه لو عندك جدول 500 ميجا انها تنقله للرام؟ ومع كل يوزر
    شرحت لك 3 مرات وأنت لم تفهم وهذه ليست مشكلتي
    قلت لك أنك حينما تطلب تعليمة لجلب بيانات العضو رقم 5
    يتم البحث في قاعدة البيانات علي الهارد
    ثم نقل جدول العضو رقم 5 فقط للذاكرة
    يعني الجدول الناتج والموجود فيه إسمه وبريده إلخ

    هل فهمت أم أشرها بلغة أخري !!

    لا بالطبع عزيزي ما اعرفه انها تبحث فقط ضمن الحقل المحدد لها وهو هنا ال username ولا اعرف ان كانت تنقله للرام كاملا ام لا.
    ناتج الكويري يتم نقله علي الفور للذاكرة لتبدأ اللغة التي تستخدمها وهي في حالتنا php بالتعامل مع ذلك الناتج بالعمليات المنطقية والحسابية المطلوبة
    ثم بعد الإنتهاء تقوم أليا ( ليس كل ال DBMS ) بتفريغ الذاكرة من ذلك الناتج
    ولهذا فأنت تقوم بعمل free بعدما تنتهي من الكويري لتقوم بتفريغ الذاكرة من المحتوي
    لما تفرغ الذاكرة ما دامت البيانات تأتي من الهارد !!

    لهذا سألت من قبل الأستاذ العزيز عبدالله عيد هنا عن هل أقوم بعمل free أم لا قال لي لا تهتم فكلاس التعامل مع ال mysql في ال php تقوم بذلك ألياً

    لا أدري كيف شئ مبدأي في عالم البرمجة مثل هذا ولا تعرفه رغم أني أعتبرك من أصحاب الخبرة !!

    ثم بعد النجاح تحدد الاجزاء التي طلبتها من الجدول وترجعها لك.. لكن لا اعتقد ان الجدول ينقل كاملا للذاكرة.
    هات لي نص واحد قلت فيه ان الجدول كله ينقل للذاكرة
    قلت لك الجدول الناتج
    يعني جرب تدخل phpmyadmin
    وتنفذ تعليمة فيها join تجلب من أكثر من جدول
    ستجد ال phpmyadmin أظهر لك جدول جديد طويل جدا فيه كل البيانات
    هذا الجدول الظاهر أمامك موجود في الذاكرة الأن ويتم التعامل معه من الذاكرة ويمكنك تحميل محتواه داخل مصفوفة ( هذه المصفوفة ستكون في الذاكرة أيضاً ) ثم تفرغ محتوي الكويري ( والذي سيفرغ المحتوي من ال address القديم ومعه بيانات تلك الكويري والتي يخزنها ال DBMS ) ويصبح لديك مصفوفة واحدة وهي ما حملت فيها الناتج ولا تحمل معها أية بيانات أخري

    هذه المصفوفة يمكنك تخزينها بشكل دائم في الذاكرة لو كانت كثيرة الجلب من قاعدة البيانات
    هذا هو ما قصدته
    فقط المصفوفات كثيرة الجلب مثلما تفعل البرمجيات المتقدمة

    مثل ملف اللغة
    القوالب لو كانت في قواعد البيانات
    المجموعات
    الخيارات
    التصنيفات
    الهووك بأسمائها وارقامها

    إلخ

    كلها ما تزيد عن 10 مصفوفات يتم جلبها بكثرة رغم ان محتواها لا يتغير إلا نادراً فلتوفير تكرار تعليمات السكول كل مرة يتم تركها في الذاكرة بشكل دائم بواسطة المسرعات او تخزينها علي الهارد بواسطة كاش الملفات ( الأولي ستكون أسرع بالطبع )

    وايضا ماذا عن هيئة وشكل تخزين البيانات على الرامة؟

    وهل تفضل تخزين كل بيانات الكاش على الرام بدون استخدام اي شيء اخر؟
    لم أفهم !!
    عموما تعاملي مع الكاش وحسب الخبرة التي اكتسبتها من تلك البرمجيات يكون بنوعين

    النوع الأول وهو المعلومات كثيرة الولوج وقليلة التحديث وهي التي ذكرتها بالأعلي
    هذه أخزنها في الذاكرة بواسطة xcache ثم أكتب لكل واحدة منهم دالة تحديث وأناديها وقتما يحدث عليها تحديث ( هم يفعلون ذلك ولو تريد أسماء الدوال أجلبها لك )

    ثم البيانات متوسطة الولوج مثل الإحصائيات فهيه أخزنها أيضا في الذاكرة كونها لا تتعدي الكيلو بايت في حجمها وأكتب لها دالة أناديها كل زمن محدد وليكن كل ساعه فأوفر عمل تعليمة سكول لجل إحصائيات الموقع تحدث كل زيارة لفقط 24 مرة في اليوم
    فبدلاً من 50000 مرة تكون 24 مرة !!

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

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

    مع العلم أني وجدت نظام أخر تستخدمه البرمجيات الكبيرة
    وهو البعد التام عن تعليمات السكول update وإستخدام جداول إفتراضية
    فبدلاً من تحديث بيانات الموضوع مع كل زائر في كل زيارة
    يتم مع كل زائر يدخل عمل تعليمة insert في جدول إفتراضي
    هذه التعليمة يكون فيها رقم القسم اللي تم زيارته
    ورقم الموضوع
    وإسمه و ال ip إلخ مع الزمن الحالي اللي أدخلت فيه التعليمة لقاعدة البيانات

    وكل ساعه عن طريق المهام يتم جلب البيانات من هذا الجدول
    ومعالجتها بالبرمجة لتحديد كل قسم تم زيارته كم مرة وكل موضوع كم وكل عضو كم فينتج لنا القسم الفلاني تم زيارته الساعه السابقة 15 مرة
    فنزود إحصائيات القسم دفعة واحدة ب 15 في تعليمة واحدة

    هذا النظام موجود في كل البرمجيات الإحترافية ويكون إختياري
    مثلا الفيبولتن موجود فيها ولكنه بخيار من لوحة التحكم ومكتوب في وصفه ( ينصح به للمنتديات الكبيرة )


    فهناك أيضا لتقليل الحقول في الصلاحيات إستخدام الارقام ال binary لما تتمتع به من الثنائية ( إما 0 أو 1 ) فيمكنك إستخدامها في الصلاحيات yes - no
    وهناك الكثير فقط قلب البرمجيات المشهورة والعالمية لتتعلم منهم

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

    • أعـجـبـك؟ 0
    • لم يعجبك؟ 0
  16. PHP Expert:
    • PHP Expert
    • منضم للمجتمع من: Aug 2004
    • لديه عدد مشاركات: 1,976
    • عدد متابعيه:
    • قوة ترشيحه: 5.0

    انا أريد وأنت تريد والله يفعل مايريد!

    16-04-2009, 03:14 AM

    الأخ المجروح،

    اعتقد ان الاخ mr_m كان يقصد شي اخر غير اللي جاوبت عليه

    الاخ mr_m يقصد أيهما اسرع:
    1-استخراج مثلا اسماء المشرفين من مليون سجل عن طريق البي اتش بي بحيث يكون المليون سجل موجوده كمصفوفه في كود البي اتش بي ((طبعا هذا مجرد مثال لان في الواقع مستحيل مليون سجل في كود))
    2- استخراج اسماء المشرفين من مليون سجل عن طريق امر SQL

    طبعا في هذه الحاله واضح ان الاستخراج عن طريق امر SQL اسرع بكثير.

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

    بالمناسبة من اسباب البطء في منتديات vbulletin هو بعض الـ SQL queries والتي وجدت معالجتها تحتاج أكثر من ثانيتين!
    مثلا الأمر هذا

    كود PHP:
    ### 127 Queries 
    ### Total time: 280, Average time: 2.20472440944882
    ### Taking 2  to 5  seconds to complete
    ### Rows analyzed 41617 - 41626
    SELECT threadid,title,postusername,forumid,lastposter  FROM  thread WHERE forumid NOT IN (XXX,XXX,XXX,XXXXXXORDER BY lastpost DESC LIMIT XXX

    • أعـجـبـك؟ 0
    • لم يعجبك؟ 0
  17. mr_m:
    • mr_m
    • منضم للمجتمع من: Jan 2008
    • لديه عدد مشاركات: 516
    • عدد متابعيه:
    • قوة ترشيحه: 5.4

    محمد حمود.

    16-04-2009, 03:46 AM

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

    * عند قراءة النصف الاول من ردك كنت عزمت على ترك النقاش من الاساس نظرا لاني كنت "باتكلم صيني".
    والنصف الاخر يوحي بان هناك امل في القاء بعض النصائح ..

    لكن حصل خير ..

    * هناك فقط نصيحة لمن اراد تعلم الكاشنج بمعناها الحقيقي او سأل نفسه لماذا صفحات مواقع مثل Eacebook سريعة،
    بان يقرأ كتب متخصصة في هذا الغرض -ربما لا تكون حتى لPHP لان ما يهم هو التقنية
    وعندما يتوسع ستتضح حقائق كثيرة منها :

    - ان ما تحتثنا عنه في هذا الموضوع الى الان هي طرق تقليدية جدا جدا لعمل الكاشنج.
    - بعض البرامج التي يطلق عليها العرب احترافية مثل vb فيها كوارث ان صح التعبير في الاوبتمايزنج والكاشنج. والروتين الذي تمت برمجتها فيه.
    - ربما يعرف معنى ال System Analysis لمواقع الويب و خرائط الكاش
    - ربما يفتح نظره على الربط بين السيرفرات وتوزيع المهام.
    - وبالتاكيد سيتضح له بدائية ما تستخدمه 90% من البرمجيات العربية في الكاش.


    شكرا،،

    • أعـجـبـك؟ 0
    • لم يعجبك؟ 0
صفحة 2 من 3 الأولىالأولى 123 الأخيرةالأخيرة