المحتوى عن 'cache'.



مزيد من الخيارات

  • ابحث بالكلمات المفتاحية

    أضف وسومًا وافصل بينها بفواصل ","
  • ابحث باسم الكاتب

نوع المُحتوى


التصنيفات

  • التخطيط وسير العمل
  • التمويل
  • فريق العمل
  • دراسة حالات
  • نصائح وإرشادات
  • التعامل مع العملاء
  • التعهيد الخارجي
  • التجارة الإلكترونية
  • مقالات عامة

التصنيفات

  • PHP
    • Laravel
    • ووردبريس
  • جافاسكريبت
    • Node.js
    • jQuery
    • AngularJS
    • Cordova
  • HTML5
  • CSS
    • Sass
    • إطار عمل Bootstrap
  • SQL
  • سي شارب #C
    • منصة Xamarin
  • بايثون
    • Flask
    • Django
  • لغة روبي
    • إطار العمل Ruby on Rails
  • لغة Go
  • لغة جافا
  • لغة Kotlin
  • برمجة أندرويد
  • لغة Swift
  • لغة R
  • سير العمل
    • Git
  • صناعة الألعاب
    • Unity3D
  • مقالات عامّة

التصنيفات

  • تجربة المستخدم
  • الرسوميات
    • إنكسكيب
    • أدوبي إليستريتور
    • كوريل درو
  • التصميم الجرافيكي
    • أدوبي فوتوشوب
    • أدوبي إن ديزاين
    • جيمب
  • التصميم ثلاثي الأبعاد
    • 3Ds Max
    • Blender
  • مقالات عامّة

التصنيفات

  • خواديم
    • الويب HTTP
    • قواعد البيانات
    • البريد الإلكتروني
    • DNS
    • Samba
  • الحوسبة السّحابية
    • Docker
  • إدارة الإعدادات والنّشر
    • Chef
    • Puppet
    • Ansible
  • لينكس
  • FreeBSD
  • حماية
    • الجدران النارية
    • VPN
    • SSH
  • مقالات عامة

التصنيفات

  • التسويق بالأداء
    • أدوات تحليل الزوار
  • تهيئة محركات البحث SEO
  • الشبكات الاجتماعية
  • التسويق بالبريد الالكتروني
  • التسويق الضمني
  • استسراع النمو
  • المبيعات

التصنيفات

  • إدارة مالية
  • الإنتاجية
  • تجارب
  • مشاريع جانبية
  • التعامل مع العملاء
  • الحفاظ على الصحة
  • التسويق الذاتي
  • مقالات عامة

التصنيفات

  • الإنتاجية وسير العمل
    • مايكروسوفت أوفيس
    • ليبر أوفيس
    • جوجل درايف
    • شيربوينت
    • Evernote
    • Trello
  • تطبيقات الويب
    • ووردبريس
    • ماجنتو
  • أندرويد
  • iOS
  • macOS
  • ويندوز

التصنيفات

  • شهادات سيسكو
    • CCNA
  • شهادات مايكروسوفت
  • شهادات Amazon Web Services
  • شهادات ريدهات
    • RHCSA
  • شهادات CompTIA
  • مقالات عامة

أسئلة وأجوبة

  • الأقسام
    • أسئلة ريادة الأعمال
    • أسئلة العمل الحر
    • أسئلة التسويق والمبيعات
    • أسئلة البرمجة
    • أسئلة التصميم
    • أسئلة DevOps
    • أسئلة البرامج والتطبيقات
    • أسئلة الشهادات المتخصصة

التصنيفات

  • ريادة الأعمال
  • العمل الحر
  • التسويق والمبيعات
  • البرمجة
  • التصميم
  • DevOps

تمّ العثور على 6 نتائج

  1. يُستعمل Varnish Cache بكثرة لتخبئة محتوى مواقع الويب لتسريع أداء المواقع وتخفيض الحمولة على الخادوم الأصل (origin-server). لطالما شجعنا على استعمال التّخبئة لتسريع أداء تطبيقات الويب وتسهيل قابلية التوسع (Scalability) وضمان الاستقراريّة إضافة إلى الفوائد الأخرى التي تأتي مع هذه الإجراءات من تحسين لتجربة المُستخدم إلى التوفير في الموارد. لكن رغم ذلك فلا نزال بحاجة إلى التأكيد على أهميّة التّخبئة. وفي بعض الأحيان، قد يعني الأمر شرح كيفيّة استعمال Varnish Cache وما يُميّزه عن بقيّة التقنيات الأخرى. الأمور الغريبة التي تُميّز Varnish Cache Varnish Cache عبارة عن خادوم HTTP بنظام HTTP خلفي له قدرة على تقديم الملفّات. يعتمد على هندسة سلسليّة (threaded architecture)، دون حلقة أحداث (event loop). ولأن شيفرة الكتابة قادرة على استعمال استدعاءات النظام الحاصرة (blocking system calls)، فذلك يجعله أسهل استعمالا من Apache أو NGINX، التي يتطلّب استعمالها التعامل مع حلقة أحداث. يقوم Varnish Cache بالتسجيل (logging) على الذاكرة عوضا عن القرص الصلب، تم تصميمه بهذه الطّريقة لأن تسجيل 10000 من عمليات HTTP كل ثانية على القرص الصلب أمر يتطلب الكثير من الموارد. يقوم Varnish بتسجيل جميع التّفاصيل (حوالي 200 سطر لكل طلب) على الذاكرة مُباشرة. إن لم يتم طلب التفاصيل المُسجّلة فستتم الكتابة فوقها (overwrite). يعتبر Varnish التطبيق الوحيد الذي يتخذ هذا المسلك. المرونة: استعمال VCL الميّزة الكبرى لـ Varnish Cashe هي لغة الضّبط الخاصّة به. تمّ إنشاء لغةVCL (Varnish Configuration Language) منذ أكثر من 11 عاما لتدعم النسخة الأولى من Varnish Cache. على عكس Apache أو بقيّة البرمجيّات، فـVarnish Cache لا يعتمد على إعداد تقليدي.بل يعتمد عوضا عن ذلك على مجموعة من السّياسات التي تُكتب بهذه اللغة. تتم ترجمة هذه السيّاسات إلى شيفرة ثنائية، تُحمّل هذه الشيفرة ويتمّ تشغيلها بعد ذلك. يقول مهندس Varnish Cache Poul-Henning Kamp بأنVCL أُنشأت لتكون مجموعة أدوات يمكن استعمالها حسب الحاجة، وليس قطعة موحدة يُمكن إضافتها إلى بيئة العمل. في يومنا الحالي، هناك أكثر من 100 وحدة (modules) لـ VCL يمكن استعمالها ببساطة. في الحقيقة، ففي ملتقيات Varnish Summits هناك دائما ورشة عمل لتعليم الأشخاص كيفيّة كتابة وحدات خاصّة. تعتبر لغة VCL من أكبر الأسباب التي تجعل النّاس تستعمل وتتعلّق بـVarnish Cache. إذ تفتح المرونة التي توفرها اللغة الأبواب للقيام بأي شيء قد يرغب أحدهم بفعله، ما يمحو القيود التي عادة ما تأتي مع البرمجيّات التقليديّة. إذا، ما هي أهم الأدوات التي توفّرها VCL وكيف يُمكننا الاستفادة منها؟ التنطيف Purging لا يدعم Varnish تنظيف المحتوى عند إعداده لأول مرّة، إذ لا يُمكنك تنزيله وتنصيبه ثمّ استعمال نظام تنظيف دون أية خطوات إضافيّة. عوضا عن تمكين إعدادات افتراضيّة، يتوجب على مستخدمي Varnish Cache العمل على تفعيل الميزات المرغوبة كل على حدة، لكن إعداد نظام تنظيف أمر بسيط، ويمكنك الحصول على النتيجة التي ترغبها. sub vcl_recv { if (req.method == "PURGE") { return (purge); } } إن لم ترغب بتمكين الأشخاص على الأنترنت من تنظيف المحتوى على نظام تخبئتك، فسيتوجب عليك ضبط حدّ الوصول ACL كما يلي: acl purge { "localhost"; "192.168.55.0"/24; } sub vcl_recv { if (req.method == "PURGE") { if (!client.ip ~ purge) { return(synth(405,"Not allowed.")); } return (purge); } } إضافة ميزة لـVarnish Cache: خنق الرّبط السّاخن (Hot linking) يسمح إطار العمل الخاص بـVarnish للمستخدمين بإضافة أية ميزة يحتاجون إليها. أول ميّزة أضيفت هي استعمال VCL للحد من الرّبط السّاخن. الرّبط السّاخن هو عمليّة سرقة موارد أحدهم على الويب وكتابة مقال يستخدم صورا مرفوعة على خادوم الضّحية ليدفع تكاليف استخدام الموارد. يسمح Varnish للخوادم بإيقاف هذه العملية عند استعمال الرّبط السّاخن للموارد الخاصة بالخادم دون إذن. على سبيل المثال، يمكن لـVarnish وضع سقف لعدد مرّات حدوث هذا الأمر كل ثانيّة عبر استخدام وحدة من وحدات Varnish (VMOD) باسم vsthrottle لإضافة الخنق (throttling). يمكن القيام بالأمر عبر استيراد وتحميل الوحدة. شيفرة VCL أسفله تُوضّح كيفيّة الحدّ من الرّبط السّاخن. في هذا المثال، نقوم بتطبيق ثلاثة قواعد. القاعدة الأولى تتحقّق من أن عنوان URL المطلوب يبدأ بـ/assets/. القاعدتان الثانيّة والثّالثة تحميان مجلّد الملفات السّاكنة من الرّبط السّاخن. يتمّ هذا عبر التحقق ممّا إذا كان المُحيل referrer طرفا غير مُتوقّع، وما إن طلبت أسماء نطاق أخرى ملفّاتك لأكثر من 10 مرّات خلال 60 ثانيّة. ما سبق عبارة عن دالّة الخنق، يُستعمل رابط URL كمفتاح للخنق.الحدّ المسموح به هو 10 مرّات كلّ 60 ثانيّة. يُمكن تقديم الملفات السّاكنة غير المُشار إليها، وعندما يحصل ذلك، فسيتم إرسال خطأ 403 مع منع الربط السّاخن. يُمكن كذلك توسيع الخنق لاستعمال memcache، وذلك ليحصل المستخدم على المُحاسبة الرّئيسيّة (central accounting) في العنقود (cluster). import vsthrottle; (..) if (req.url ~ "^/assets/" && (req.http.referer !~ "^http://www.example.com/") && vsthrottle.is_denied(req.url, 10, 60s) { return(error(403,"Hotlinking prohibited"); } التّعامل مع ملفات تعريف الارتباط (cookies) لن يقوم Varnish بتخبئة المحتوى الذي يُطلَبُ باستعمال ملفّات تعريف الارتباط. ولن يستجيب إلى طلب محتوى مخبّأ إن كان الطّلب متعلّقا بملف تعريف ارتباط. عوضا عن هذا، يُمكن استعمال وحدة VMOD لحذف ملفّ تعريف الارتباط. المحترفون يستعملون تعبيرا نمطيّا (regular expression) لترشيح ملفات تعريف الارتباط. ولأنّنا لسنا محترفين، فـVarnish يوفّر وحدة باسم cookie تبدو كما يلي: import cookie; sub vcl_recv { cookie.parse ("cookie1: value1; cookie2: value2"); cookie.filter_except("cookie1"); // get_string() will now yield // "cookie1: cookie2: value2;"; } لا يقوم Varnish بإنشاء ترويسة (header) ملف تعريف ارتباط. وإن رأى بأن النظام الخلفي قد أرسل شيفرة إنشاء ملفّ تعريف ارتباط، فلن يقوم بتخبئته. الحل أن تحذف ترويسة Set-Cookie أو إصلاح الخادوم الخلفي. ترويسات Set-Cookie تقوم بتعطيل ملفّات تعريف الارتباط. الحلّ: احذف ترويسة Set-Cookie أو أصلح النّظام الخلفيّ. نمط الإمهال Grace Mode يُمكن نمط الإمهال Varnish من تقديم محتوى قديم إن لم يكن المحتوى الجديد جاهزا أو مُتوفّرا. يساهم هذا في تحسين الأداء عبر إعادة تحميل المحتوى من النظام الخلفيّ بشكل غير متزامن (asynchronous). في الوقت الذي تم فيه تقديم Varnish 1.0 كحل لنظام تخبئة لموقع الجريدة النرويجيّة Verdens Gang، كانت هناك مشاكل كبرى بسبب التكتّلات السلسليّة (threading pileups). كانت الصفحة الرّئيسيّة للموقع تُقدّم 3000 مرّة كلّ ثانيّة، لكن نظام إدارة المُحتوى (CMS) كان بطيئا، إذ كان يأخذ 3 ثوان لإعادة توليد الصّفحة الرّئيسيّة. في بعض المواقع، إن اتّبعت طلبات التّعليقات (RFC)، فسيقوم وسيط (proxy) التّخبئة بإلغاء الصّفحة الرّئيسيّة أو سيحدث انقضاء وقت (time out). عندها سيأتي مُستخدم آخر وسيتوجب جلب نسخة جديدة من الصّفحة الرّئيسيّة. يقوم Varnish بهذا عبر عمليّة التئام التّخبئة (coalescing). إذ يتم وضع المستخدمين الجدد عند وصولهم على قائمة انتظار. (أنظمة التّخبئة الأخرى تُرسل المُستخدمين إلى النظام الخلفيّ ما يقتل الخادم). إن تّمت إضافة 3000 مُستخدم إلى قائمة الانتظار كلّ ثانيّة، فبعد ثلاثة ثوان، سيكون الطابور عبارة عن 9000 مستخدم ينتظرون النظام الخلفي لجلب المحتوى. في البداية، كان Varnish يأخذ المحتوى المطلوب، ويقوم بالتواصل مع السّلاسل (Thread) الـ9000 التي تمّ إنشاؤها، ويُحاول دفع كل شيء دفعة واحدة. سمّي هذا الحدث بالقطيع الصّاخب (thundering herd). وكانت النّتيجة موت الخادوم فورا. لحلّ هذه المُشكلة، قرّر Varnish استعمال الصفحة الرّئيسيّة القديمة عوضا عن انتظار الخادوم لإعادة توليد المحتوى. لن يهتم أحد إن كان المحتوى قديما بـ20 ثانيّة، إلا في حالة كانت البيانات التي تقدّمها متعلّقة بمعلومات ماليّة وترغب عرضها في الوقت الفعلي. تغيّرت التّفاصيل المتعلّقة بـGrace خلال السنوات الماضيّة. في Varnish 4.0 (إن تمّ تفعيله) فستبدو كما يلي: sub vcl_backend_response { set beresp.grace = 2m; } يتم ربط Grace مع كائن الإجابة الخلفيّة (backend response object). إن تم تحديد القيمة في دقيقتين (2m) فسيُبقي Grace على الكائن لدقيقتين بعد انقضاء الـTPL. إن تم طلب الكائن خلال هذا الوقت، فسيتم تفضيل تقديم ما هو مُخبّأ عوضا عن إرسال طلب جديد إلى النظام الخلفيّ. سيتم استعمال الكائن وإعادة تحميله بعدها بشكل غير متزامن. تفاصيل Grace لا يتطلب فهم Varnish Cache النظر إلى الشّيفرة المصدريّة، عوضا عن ذلك، يتم توفير VCL افتراضيّ يُمكن الاعتماد عليه لإضافة أية تفاصيل أخرى حسب الحاجة. فبِميّزة مثل Grace يُمكن للمُستخدمين قراءة شيفرة VCL والنظر إلى التفاصيل: Insert code sub vcl_hit { if (obj.ttl >= 0s) { // A pure unadulterated hit, deliver it return (deliver); } if (obj.ttl + obj.grace > 0s) { // Object is in grace, deliver it // Automatically triggers a background fetch return (deliver); } // fetch & deliver once we get the result return (fetch); } إن كان الكائن VCL يحمل قيمة أكبر من 0 ثوان، هذا يعني بأنّ الـTTL موجب، سيتمّ الرجوع والتّقديم. إن كانتا كل من قيمتي TTL وGrace أكبر من 0 ثوان، فهذا يعني بأنّها ضمن Grace وسيقوم Varnish بتقديمها. إن كانتا كل من قيمتي TTL وGrace أصغر من 0 ثوان، فسيتّم طلب الصّفحة من النّظام الخلفيّ. تعديل كيفيّة عمل Grace يُمكن للمؤسّسات التي تكون بحاجة إلى تقديم معلومات ماليّة وتأبى عرض معلومات قديمة للمُستخدم أن تُغيّر من كيفيّة عمل Grace. في المثال التّالي، لم يتغيّر الجزء الأول، في الجزء الثّاني نقوم بالتقديم في حالة لم يكن الخادوم الخلفيّ على ما يرام وكانت كلا من قيمتي TTL و Grace أكبر من 0 ثانيّة. sub vcl_hit { if (obj.ttl >= 0s) { // A pure unadulterated hit, deliver it return (deliver); } if (!std.healthy(req.backend_hint) && (obj.ttl + obj.grace > 0s)) { return (deliver); } // fetch & deliver once we get the result return (fetch); } *بضعة معلومات إضافيّة: beresp: كائن الطّلب الخلفّي backend request object. req: كائن الطّلب request object. يُستعمل في vcl_recv. bereq: كائن الطّلب الخلفي backend request object. يُستعمل في vcl_backed_fetch. beresp: كائن الإجابة الخلفيّة. يُستعمل في vcl_backend_response. resp: كائن الإجابة response object. يُستعمل في vcl_deliver. obj: الكائن الأصلي في الذّاكرة. يُستعمل في vcl_hit. للمزيد من التّفاصيل استعمل man(7) vcl. آلة الحالة (state machine) يمرّ كل طلب عبر عدّة حالات. يُمكن تشغيل شيفرة مخصّصة في كل حالة لتعديل كائنات الطّلب. بعد تنفيذ الشّيفرة المخصّصة، يقوم Varnish باتّخاذ قرار ما إذا كان نجاحا (Hit) أو إخفاقا (Miss) بعدها يتم تشغيل إمّا VCL hit أو VCL Miss. في حالة النّجاح سيقوم Varnish بتقديم المحتوى. والإخفاقات تُعيد الطّلب من النظام الخلفي. 90% من التّغييرات التي يُحدثها المُستخدمون تحدث هنا. كيفيّة التّضبيط (Tuning) على Linux يتم تحديد الانضباطيات (Tunables) على Linux بشكل محافظ، ونجد SOMAXCONN و TCP_MAX_SYN_Backlog أكثرها مشقّة. عند الانصات (listen) إلى المقابس (socket)، يأخذ Varnish بضعة ثوان للانصات للنّداء. إن كانت السّلاسل مشغولة، فستبدأ النّواة (kernel) بالتّكتّل (queue). لا يُسمَحُ لهذا التّكتّل بأن ينمو إلى ما وراء قيمة SOMAXCONN. سيطلب Varnish 1024 اتّصالا على تكتّل عمق الانصات (listen depth queue)، لكنّ النواة تقوم بإبطال ذلك لتحصل على 928 فقط. ولأنّ Varnish يعمل بصلاحيات الجذر (root)، فمن الممكن تقرير عمق انصات خاصّ، لكنّ Linux أدرى بما هو أفضل. قد يرغب المُستخدمون بالرّفع من هذا الحدّ إن أرادوا تخفيض خطر رفض الاتّصالات عند انقضاء عمق الانصات. سيتوجّب على المستخدم اتخاذ قرار ما إذا كان عدم التّقديم وتقديم صفحة خطأ أفضل أو لا. يقوم TCP_MAX_SYN_Backlog بتعريف عدد الاتّصالات البارزة التي يُمكن لها أن تكون بداخل إقامة الاتّصال (handshake) الثّلاثي الأطراف قبل أن تقرّر النواة بأنّها تحت الهجوم. القيمة الافتراضيّة هي 128. لكن في حالة دخل جمع كبير من النّاس إلى موقعك دفعة واحدة فقد تحصل على أكثر من 128 اتّصال TCP كلّ ثانيّة. لا تقم بتعديل tcp_tw_recycle. تأكّد بأنّك تعرف ما تفعله قبل لمس الإعدادات وابحث على الويب قبل ذلك. إذ أنّ الكثير من العفاريت (demons) تعتمد على هذه القيّم. مساحات العمل (Work spaces) في Linux في Varnish، الذاكرة المحليّة متواجدة في كلّ سلسلة. ولأنّ التّراجع (rollback) يستنزف الموارد، فإنّنا لا نتراجع كلّما احتجنا إلى قليل من المساحة في الذّاكرة. عوضا عن ذلك، نقوم بتعيين مُسبق للذّاكرة على كلّ سلسلة إن كان للمستخدم العديد من سياسات VCL التي قد تستنزف مساحة العمل بأكملها. لا يقوم Varnish بتتبّع الاتّصال، وحدة التّعاقد (contract module) بطيئة للغاية. يتمّ افتراضيّا تشغيل خمسة سلاسل. يُمكن إنشاء سلاسل جديدة بسرعة نسبيّا، لكن إن كنت تخطّط لفتح ألف اتّصال كلّ ثانيّة أي ألف سلسلة، ففي هذه الحالة لديك مُعطى (parameter) لتخصيص سلاسل مُسبقا. خلاصة: احذر عند التّعامل مع مساحات العمل. لا تقم بتتبّع الاتّصالات (connection tracking). ارفع معدّل السّلاسل إلى طلب واحد في الثانيّة لكل سلسلة. الموازنة بين ما هو غريب وما هو رائع في Varnish Cache المرونة القويّة والمميّزات التّي يتمتّع بهاVarnish Cache لا تأتي في حزمة جاهزة (ما قد يجده البعض غريبا)، لذا فقد لا يكون الحلّ الأنسب للجميع. لكنّ المرونة التي يتمتّع بها قد تُغيّر من مجريات الأمور عند الرغبة في تخصيص والتّحكم بأداء المواقع وقابليّة توسيعها. ترجمة -بتصرّف- للمقال Getting started with web app accelerator Varnish Cache لصاحبه Per Buer.
  2. يعدّ المعالج Processor ويُسمى وحدة المعالجة المركزية CPU ‏(Central Processing Unit) أو المعالج المصغَّر Microprocessor أهمَّ مكونات الحاسوب فبدونه لا يوجد حاسوب، وهو دارة إلكترونية تنفِّذ التعليمات وتعالج البيانات باستخدام عمليات الحساب والمنطق. معالج Intel 80486DX2. نشرت الصورة في ويكيبيديا برخصة المشاع الإبداعي BY-SA تغيَّر تصميم المعالج وشكله كثيرًا عبر العقود الأخيرة ولكنّ عمله الأساسي بقي ثابتًا. المعالجات الحديثة هذه الأيام هي معالجات مصغَّرة أي أنّ جميع مكونات وعناصر المعالج تتواجد في دارة متكاملة IC واحدة وقد تحتوي هذه الدارة على عناصر إضافية كذاكرة ومُتحكمات Microcontrollers وغيرها. يُصنع المعالج من عناصر إلكترونيَّة تدعى أشباه نواقل وهي الترانزستورات حيث يحتوي على الملايين منها، والمزايا التي تضيفها الترانزستورات للمعالج هي الدقة والاستهلاك الأقل للطاقة والسرعة العالية. مكونات المعالج يتألف المعالج من مكونات عدَّة أهمها هي: وحدة التحكم Control Unit هي دارة رقمية تتحكم بتوجيه جميع الأوامر والبيانات لمعالجتها فهي لا تنفِّذ أو تعالج البيانات وإنما تتخاطب مع الذاكرة ووحدة الحساب والمنطق وأجهزة الإدخال والإخراج وتنسِّق فيما بينها لتنفيذ الأوامر لذا نجد أن وحدة التحكم تدير وتنظِّم أغلب أجهزة الحاسوب. وتتحكم أيضا بكمية البيانات المنتقلة بين المعالج وجميع العناصر والأجهزة، وبتدفق البيانات داخل المعالج، وبتنظيم عمل الوحدات الأخرى الموجودة داخله. وحدة الحساب والمنطق ALU ‏(Arithmetic Logic Unit) هي دارة رقمية مسؤولة عن تنفيذ ومعالجة البيانات عبر إجراء العمليات الحسابية والمنطقية، والعملية الحسابية المستخدمة هي الجمع فقط أما بقية العمليات يمكن مكافأتها وتحويلها إلى عملية الجمع. تأتي البيانات من الذاكرة إلى المعالج لتعالج ضمن هذه الوحدة ثم تعاد إلى الذاكرة أو تخزَّن مؤقتًا في السجلّات Registers وهي ذاكرة سريعة جدًا. وحدة التحكم بالذاكرة MMC ‏(Memory Management Unit) تحوي المعالجات غالية الثمن وحدة التحكم بالذاكرة التي وظيفتها تحويل العناوين المنطقية إلى عناوين الذاكرة الفيزيائية RAM، وتأمين حماية الذاكرة، ونقل البيانات إلى جهاز تخزين ثانوي (كالقرص الصلب) وإحضارها منه، ولها فائدة كبيرة عند استخدام الذاكرة الافتراضية Virtual memory. قد لا تحتوي المعالجات البسيطة أو المكتبية على هذه الوحدة. عامل الشكل يصف عامل الشكل Form factor شكل المعالج الخارجي ونوع المقبس الذي يركَّب عليه، وأشهر عوامل الشكل هي: LGA هي تقنية لتعليب المعالج والدارات وتدعىLGA‏ (Land Grid Array) حيث يزوَّد أسفل المعالج بشبكة من تماسات صغيرة تتصل مع اللوحة الأم، ويركَّب هذا النوع على المقبس أو يُلحم مباشرة على اللوحة. ومن المعالجات التي تستخدم هذا العامل هي “Intel Pentium 4” و “Intel Xeon” و “Intel Core 2” و “Intel Core” و “AMD Opteron” إذ تستخدمه معالجات Intel الحديثة خلافًا لمعالجات AMD التي تستخدم التصميم PGA بكثرة. المعالج Pentium 4 بتعليب LGA 775. نشرت الصورة برخصة المشاع الإبداعيBY-SA لصاحبها Eric Gaba أشهر المقابس التي تدعم عامل الشكل LGA هي مقبس “LGA 775”، الذي تستخدمه جميع المعالجات من نوع “Intel Pentium D” و “Core 2”، والمقبس “LGA 1150”، ويشير الرقم 775 والرقم 1150 إلى عدد الأرجل الموجودة على المقبس. PGA المعالج Pentium 4 بتعليب PGA. نشرت هذه الصورة برخصة المشاع الإبداعي BY-SA لصاحبها Liam McSherry هي تقنية لتعليب المعالج والدارات وتسمى PGA ‏(Pin Grid Array) ويكون شكل المعالج مربعًا أو مستطيلًا وتوزَّع الأرجل أسفل المعالج بانتظام ولا تغطي كامل مساحته، ويركب هذا النوع على اللوحة عبر ثقوبٍ موجودةٍ عليها أو عبر مقبس، وله أنواع كثيرة وهي: FC-PGA ‏(Flip-Chip PGA): صمَّمت شركة Intel هذا النوع مع معالجات “Pentium III” و “Celeron” و “Pentium 4” التي تستخدم المقابس: “Socket 370 Socket 478 SPGA‏ (Staggered PGA): يُستخدم مع معالجات Intel والمقابس التي تدعمه هي: Socket 5 Socket 7 Socket 8 CPGA‏ (Ceramic PGA): تستخدم الدارات المتكاملة هذا التصميم بكثرة، وبعض المعالجات التي تستخدمه هي معالجات “AMD Athlon” و “AMD Buron” والمقابس هي: Socket A Socket AM2 Socket AM2+‎ OPGA‏ (Organic PGA): يُستعمل مع الدارات المتكاملة والمعالجات، وابتكرته بدايةً شركة AMD مع المعالج “Athlon XP”، والمقابس المستخدمة هي: Socket A Socket 754 Socket 939 Socket 940 Socket FM1 Socket FM2 Socket AM2 Socket AM2+‎ Socket AM3 Socket AM3+‎ Socket AM4 SECC تدعى هذه التقنية Single Edge Contact Cartridge وتعرف أيضًا Slot 1 واستخدمت مع المعالج “Intel Pentium II” والمعالج “Intel Pentium III”. ذاكرة التخبئة Cache memory هي ذاكرة سريعة وصغيرة جدًا من نوع SRAM تتموضع داخل المعالج أو على اللوحة الأم. تُستخدَم لتقليل الزمن والطاقة اللازميْن للوصول إلى البيانات الموجودة في الذاكرة الرئيسية (ذاكرة الوصول العشوائي RAM) إذ تُخزَّن عليها البيانات متكررة الاستخدام بدلًا من إعادتها إلى الذاكرة ثم إحضارها من جديد. سرعة المعالج عالية جدًا بالمقارنة مع الذاكرة الرئيسية لذا سيحصل الكثير من الهدر في الوقت اللازم لانتقال المعلومات الموجودة في الذاكرة إلى المعالج حال عدم وجود ذاكرة التخبئة. نموذج توضيحي يبين الفرق بين سرعة معالجة البيانات عند استخدام ذاكرة التخبئة وسرعتها بدونها. المصدر: extremetech.com تحوي المعالجات أنواعًا متعددةً من هذه الذاكرة منها ذاكرة تخبئة للتعليمات وأخرى للبيانات التي تُقسم إلى مستويات عدَّة. أنواع ذاكرة التخبئة تحوي الحواسيب الحديثة والخواديم ثلاثة أنواع من ذاكرة التخبئة وهي: ذاكرة تخبئة التعليمات Instruction cache: تزيد من سرعة جلب التعليمات وتنفيذها. ذاكرة تخبئة البيانات Data cache: تزيد من سرعة الحصول على البيانات من الذاكرة الرئيسية أو كتابة البيانات عليها لإعادتها إلى الذاكرة الرئيسية، وتقسم إلى مستويات وهي: المستوى الأول L1: هي ذاكرة سريعة جدًا مع سعة تخزينية صغيرة (8 – 128 كيلوبايت) تُدمج مع المعالج، وغالبًا يكون لكل نواة ذاكرة L1 منفصلة. المستوى الثاني L2: هي أبطأ سرعةً من L1 ولكن سعتها أكبر (64 كيلوبايت – 16 ميغابايت) وتُدمج مع المعالج وقد يكون لكل نواة ذاكرة منفصلة أو تشترك جميع النوى في المعالج بذاكرة L2 واحدة. المستوى الثالث L3: أبطأ من سابقتها (تكون سرعتها من مضاعفات سرعة الذاكرة الرئيسية) وأكبر سعةً (4 – 128 ميغابايت) وغالبًا تشترك جميع النوى بذاكرة L3 واحدة. المستوى الرابع L4: يندر استخدامها وتوجد على رقاقة منفصلة وسعتها أكبر من 512 ميغابايت. ذاكرة التخبئة من نوع TLB‏ (Translation Look-aside buffer): وظيفتها تسريع عملية تحويل العناوين الافتراضية إلى عناوين فيزيائية للتعليمات والبيانات. يمكن أن توجد ذاكرة منفصلة للتعليمات وتدعى ITLB‏ (Instruction TLB) وذاكرة منفصلة للبيانات أيضًا وتدعى DTLB‏ (Data TLB)، وتكون هذه الذاكرة جزءًا من وحدة التحكم بالذاكرة MMC. آلية العمل مع المعالج تنتقل البيانات المراد معالجتها بين الذاكرة الرئيسية وذاكرة التخبئة ككتل ثابتة الحجم Cache blocks وعندما يريد المعالج القراءة من الذاكرة الرئيسية أو الكتابة عليها يتحقق أولًا من وجود نسخة من البيانات في ذاكرة التخبئة. إن وجد المعالج تلك البيانات فإنه يقرأها مباشرةً من ذاكرة التخبئة ثم يخزِّن الناتج فيها وهذه العملية أسرع بكثير من القراءة من الذاكرة الرئيسية. عندما يطلب المعالج البيانات من ذاكرة التخبئة فإنه يطلبها أولًا من الذاكرة L1 فإن لم يجدها يطلبها من الذاكرة L2 فإن لم يجدها يبحث عنها في الذاكرة L3 فإن وجدها أخذها للمعالجة وإن لم يجدها يُرسِلُ إلى الذاكرة لإحضار تلك البيانات. إن لم يجد المعالج البيانات في ذاكرة التخبئة فإن هذه الذاكرة تطلب نسخةً من البيانات من الذاكرة الرئيسية التي بدورها ترسل نسخة من البيانات إليها وحينئذ يقرأ المعالج تلك البيانات. تُرسَلُ البيانات بعد الانتهاء من معالجتها إلى ذاكرة التخبئة ومنها تعاد إلى الذاكرة الرئيسية؛ أمَّا إن كان المعالج يحتاج تلك البيانات مرارًا وتكرارًا فإنها تبقى فيها ريثما ينتهي المعالج منها. المعالجات متعدِّدة النوى المعالج متعدِّد النوى هو معالج واحد يحتوى على وحدات معالجة مستقلة تدعى كل واحدة منها “نواة” Core. يمكن للمعالج متعدد النوى معالجة العديد من التعليمات في الوقت نفسه ممَّا يزيد من سرعته. قد تتشارك النوى ذاكرة تخبئة مع بعضها و قد تنفرد كل نواة بمستوى واحد أو أكثر من ذاكرة التخبئة، توضح الصورة بنية معالج ثنائي النوى تنفرد كل نواة فيه بذاكرة L1 وتشترك النواتان بذاكرة L2. تستطيع بعض المعالجات محاكاة عمل نواتين من نواة واحدة فيزيائيَّة وتدعى هذه التقنية HT‏ (Hyper Threading) التي طورتها شركة Intel على معالجاتها. هذا يعني أنَّه إذا كان المعالج رباعي النوى ويدعم هذه التقنية فإنه يعمل وكأنه ثماني النوى، وبالتأكيد لا يتساوى هذا المعالج مع نظيره الذي يحوي ثماني نوى فيزيائيَّة في الأداء. المصدر: GetHow.org سرعة النبضات Clock speed يشير هذا المصطلح إلى التردد Frequency أو سرعة المعالج وتقاس بالهيرتز Hz (عدد النبضات بالثانية)، أي عدد التعليمات التي تعالج بالثانية، وتقاس سرعة المعالج حاليًا بواحدة غيغاهيرتز GHz. فالمعالج الذي سرعته 1 هيرتز مثلًا يستطيع معالجة أمر واحد في الثانية، والمعالج الذي سرعته 3 غيغاهيرتز يستطيع معالجة 3 بليون أمر في الثانية. بنية المعالج 32 بت و64 بت تؤثِّر البنية المعمارية للمعالج فيما إذا كانت 32 بت أو 64 بت على أدائه وتحدِّد نوع نظام التشغيل والبرامج المستخدمة معه، ولكن ما هو الفرق بينهما؟ الفرق بين المعالج 32 بت والمعالج 64 هو: حجم الكلمة المعالجة كلَّ نبضة: يستطيع المعالج 32 بت معالجة البيانات ذات الحجم 32 بت والمعالج 64 بت يعالج البيانات ذات الحجم 64 بت في كلِّ نبضة ولذلك تأثيرٌ على كمية البيانات المعالجة. عرض ناقل العناوين Address bus: (شرحناه في درس اللوحة الأم) إذ يحدِّد حجم الذاكرة الأعظمي الذي يستطيع المعالج التعامل معها فالمعالجات 32 بت يكون عرض ناقل العناوين 32 بت وتستطيع التعامل مع ذاكرة سعتها 4 غيغابايت كأقصى حد، أمَّا معالجات64 بت يكون عرض الناقل 64 بت وسعة الذاكرة التي تستطيع التعامل معها كبيرة. انتبه إلى التوافق بين نظام التشغيل والبرامج وبين بنية المعالج فإن استخدمت نظام تشغيل أو برامج ذات 32 بت مع معالج 64 بت لن تستثمر كامل كفاءة المعالج وخصوصًا إن كان البرنامج المستخدم هو للرسم والتصميم ثلاثي الأبعاد. ملاحظة: نظام تشغيل 64 بت لا يعمل مطلقًا مع معالج من نوع 32 بت. الشركات المصنِّعة توجد في مجال تصنيع معالجات الحواسيب شركتان متنافستان وهما Intel و AMD وتطرح كل شركةٍ إصدارات عديدة من المعالجات. تقسَّم معالجات Intel إلى أجيال (الجيل الأول والثاني والثالث …إلخ.) ومعالج Core i7-7700K ذو الجيل السابع هو الأحدث إلى الآن أمَّا أحدث معالج منAMD هو معالج Ryzen 7 1800X. قد تسأل هل معالجات Intel أفضل أم معالجات AMD وماذا اختار عند شراء حاسوب جديد؟ الجواب على هذا السؤال يحتاج إلى مقالة أخرى للبحث والتمحيص عن الفروق والاختلافات بين معالجات الشركتين، وباختصار يمكن أن تكون معالجات AMD أرخص أو أكثر مرونة لكسر سرعتها من معالجات Intel أو قد تكون معالجات Intel أفضل للألعاب ولا تُصدر الكثير من الحرارة ولكن ذلك لا ينطبق على جميع المعالجات. نقطة أخيرة أحببت أن أوضحها وهي أنَّك قد تجد خلال بحثك عن الفرق بين المعالجات أولئك المتعصبين لشركة Intel أو AMD الذين يرون محاسن ومزايا معالج تلك الشركة دون الأخرى وإذا سألتهم ماذا أختار فيرشدونك مباشرة لشركتهم المفضلة. ابحث بنفسك واقرأ جميع المواصفات والمزايا ثم قرر بناءً على ذلك أي نوع من المعالجات هو الأفضل والأنسب. شراء وتركيب المعالج على اللوحة الأم يجب قبل شراء معالج جديد مراعاة جميع الأمور السابقة وليس التركيز على السرعة فقط، ولا تنسَ أيضًا التوافق مع اللوحة الأم (تردد الناقل الأمامي FSB ومعامل الضرب ونوع المقبس) لاستثمار كامل ثمن المعالج الذي دفعته. انتبه عند تركيب المعالج إلى وجود بعض العلامات التي تساعد على تركيبه منها وجود سهمٍ في أحد زوايا المعالج يقابله سهمٌ يشبهه على المقبس أو وجود بعض النتوءات على المقبس التي تدلك على الطريقة الصحيحة لتركيب المعالج. وحذار من استخدام العنف أثناء تركيب المعالج خصوصًا مع معالجات من نوع PGA فأي حركة خاطئة تؤدي إلى كسر أحد أرجله وتعطل المعالج أو المقبس. تبريد بالسائل. المصدر asetek.com تُركَّب فوق المعالج أداة التبريد المناسبة له بعد تركيبه على المقبس وإمَّا أن يكون نظام التبريد مروحة مع مشتتٍ حراريٍ، ولا تنسَ في هذه الحالة إضافة القليل من معجونة التبريد التي تحسِّن من انتقال الحرارة من سطح المعالج إلى المشتت، أو التبريد عبر السوائل أو التبريد الغازي. الخلاصة تعلمنا في هذا الدرس أشياء كثيرة حول المعالج وهي غيض من فيض ولكنها كافية لفهم مبدأ المعالج ومكوناته ومواصفاته. المصادر Control unit، ويكيبيديا. SECC،‏ Computer Hope. Pin Grid Array، ويكيبيديا. Land Grid Array، ويكيبيديا وحدة الحساب والمنطق، ويكيبيديا. ALU،‏ Computer Hope. Central processing unit، ويكيبيديا. وحدة معالجة مركزية، ويكيبيديا. Cache memory، ويكيبيديا. CPU cache، ويكيبيديا. Multi-core processor، ويكيبيديا. What Is a CPU?‎،‏ Lifewire. What is the difference between a 32-bit and 64-bit CPU?‎،‏ Computer Hope.
  3. يوفّر Laravel واجهة تطبيقات برمجية موّحدة للتعامل مع أنظمة تخبئة Cache مختلفة مثل Memcached وRedis. سنعرض في هذا المقال لكيفية إعداد التخبئة في Laravel ومبدأ عملها ثم نتطرق للدالة المساعدة cache التي أضيفت إلى إطار العمل بداية من الإصدار 5.3. تهيئة بيئة التطوير يُحدَّد اسم النظام المستخدَم في التعليمة CACHE_DRIVER ضمن ملف env.. تأخذ التعليمة CACHE_DRIVER مبدئيا القيمة file التي تعني أن الكائنات Objects المخبَّأة ستخزن ضمن ملف ضمن نظام التشغيل. تُضبَط إعدادات نظام التخبئة المستخدَم في الملف config/cache.php، بعد تعيينه بالتعليمة السابقة. نفترض أنك لديك مشروع Laravel بالإصدار 5.3 للتطبيق عليه. ننفذ الخطوات التالية لتهيئة مثال نعتمد عليه في ما بعد للشرح. إنشاء نموذج والتهجير المصاحب له وبذره نستخدم artisan لإنشاء نموذج Eloquent مع التهجير المصاحب له على النحو التالي: php artisan make:model Post -m نفتح ملف التهجير لضبط الحقول في جدول البيانات بإضافة حقل جديد يُسمّىtitle (العنوان): public function up() { Schema::create('posts', function (Blueprint $table) { $table->increments('id'); $table->string("title"); $table->timestamps(); }); } يمكننا الآن تنفيذ التهجير: php artisan migrate الخطوة التالية هي بذر الجدول الحصول على بيانات للتطبيق عليها. ننشئ ملف البذر: php artisan make:seeder PostsTableSeeder ثم نعدل عليه: class PostsTableSeeder extends Seeder { public function run() { Model::unguard(); // نستورد faker لبذر الجدول $faker = Faker\Factory::create(); // ننشئ 10 تسجيلات في الجدول foreach(range(1, 10) as $index) { Post::create([ 'title' => $faker->sentence(5), ]); } Model::reguard(); } } نعدّل ملف بذر قاعدة البيانات لإضافة ملف بذر الجدول posts إليه: public function run() { $this->call(PostsTableSeeder::class); } ثم ننفذ البذر: php artisan db:seed --class=PostsTableSeeder لدينا الآن جدول بيانات بـ10 تسجيلات. أكملنا إعداد النموذج الذي نريد العمل عليه، الخطوة الموالية هي إعداد المتحكم والمسارات. المتحكم والمسارات نستعين بأداة artisan لإنشاء متحكم على النحو التالي: php artisan make:controller PostsController ننشئ في المتحكم PostsController دالة باسم index نستخدمها للحصول على جميع المنشورات الموجودة في جدول البيانات posts بصيغة JSON: public function index() { $posts = Post::all(); return response()->json($posts); } لا تنس استيراد النموذج Post: use App\Post; ثم ننتقل إلى إعداد المسارات. سنضيف مسارا باسم posts/ إلى ملف مسارات واجهةالوب routes/web.php: Route::get('/posts', 'PostsController@index'); يمكننا الآن تنفيذ الأمر php artisan serve من مجلد المشروع لتشغيل الخادوم الخاص ببيئة التطوير ثم الذهاب إلى الرابط http://localhost:8000/posts لرؤية جميع المنشورات المحفوظة في الجدول. إعداد التخبئة واستخدامها تُضبَط التخبئة - كما أسلفنا - في الملفين env. وconfig/cache.php. يحوي الصنف Illuminate\Support\Facades\Cache الكثير من الدوال الثابتة Static التي تتعامل مع التخبئة. إضافة قيمة إلى التخبئة تُستخدَم الدالة Cache::put لإضافة قيمة إلى التخبئة. تأخذ الدالة ثلاثة معطيات: Cache::put('key', 'value', 10); مفتاح key يمثل اسم المتغير. لا يمكن أن تحمل قيمتان في النظام نفس المفتاح. قيمة المفتاح value. مدة زمنية معبَّر عنها بالدقائق (10 في المثال أعلاه)، وتمثل المدة التي سيحتفظ النظام فيها بقيمة المفتاح ضمن التخبئة. تمكن أتمتة إضافة المفاتيح إلى التخبئة بالدالة remember. تبحث هذه الدالة أولا عن قيمة المفتاح في التخبئة، وترجعها إن وجدته؛ فإن لم تجده تنشئ المفتاح وتعطيه القيمة التي ترجعها دالة الإغلاق Closure الممررة في المعطى الثالث. سنستخدم الدالة remember في دالة index التي أضفناها سابقا إلى المتحكم. نعدّل الدالة index على النحو التالي: public function index() { $posts = Cache::remember('posts', 5, function() { return Post::all(); }); return response()->json($posts); } لا ننسى استدعاء الصنف Cache: use Illuminate\Support\Facades\Cache; تعني الشفرة أعلاه أننا عند طلب الدالة index فإنها ستبحث عن المنشورات الموجودة في التخبئة، فإن وجدتها ترجعها وإلا فإنها تنشئها باستدعاء الدالة all من النموذج Post؛ وتحتفظ بها في التخبئة لمدة خمس دقائق؛ ثم ترجع النتيجة. بهذا تكون جميع الطلبات التي ترد إلى المسار posts/ تمر عبر التخبئة؛ سنضيف لأغراض التوضيح مسارا جديدا (ضمن routes/web.php) لنعدل عن طريقه على إحدى التسجيلات الموجودة في جدول المنشورات: Route::get('/edit/post/{id}', 'PostsController@edit'); ونعدّل المتحكم بإضافة الدالة edit التالية: public function edit($id) { $post = Post::find($id); $post->title = "New title for ".$id; $post->save(); $posts = Post::all(); return response()->json($posts); } ما يحدث هو التالي: تظهر عند زيارة الرابط posts/ المنشورات مع المرور على نظام التخبئة؛ أما عند زيارة المسار edit/post/id/ فسنعدّل على المنشور ذي المعرف id، ثم نعرض المنشورات المخزنة في الجدول مباشرة، دون البحث عنها في التخبئة. يظهر في الصورة المتحركة التالية الفرق بين استخدام التخبئة وطلب المنشورات مباشرة من الجدول: تكون التخبئة فارغة عند زيارة المسار posts/ لأول مرة. في هذه الحالة يطلب Laravel المنشورات مباشرة من جدول البيانات، يعرضها ثم يضيفها إلى التخبئة. نطلب الرابط edit/post/1/ الذي يغيّر عنوان المنشور ذي المعرف 1 ليصبح New title for 1؛ ثم يعرض المنشورات بطلبها مباشرة من جدول قاعدة البيانات. لاحظ تغير عنوان المنشور. نعود للرابط posts/ قبل انقضاء المدة المحددة في دالة التخبئة (5 دقائق)، نلاحظ أن التعديل الذي أجريناه لا يظهر في المنشورات المعروضة. ملحوظة: يجب التأكد في التطبيقات الموجهة لبيئة الإنتاج من تناسق عمليات التعديل على قاعدة البيانات والتخبئة. بمعنى أنه يجب أن ينعكس التعديل على قيمة في جدول البيانات مباشرة على القيمة المحفوظة في التخبئة. العمليات على التخبئة الحصول على قيمة من التخبئة: Cache::get('key'); يمكن إرجاع قيمة مبدئية في حال عدم وجود المفتاح في التخبئة: Cache::get('key', 'default'); تبحث الدالة أعلاه عن قيمة المفتاح key في التخبئة، فإن لم تجدها ترجع القيمة المبدئية default. التحقق من وجود مفتاح في التخبئة: if (Cache::has('key')){ Cache::get('key'); } else { Cache::put('key', $values, 10); } نتحقق في الشفرة أعلاه من وجود قيمة للمفتاح key ونرجعها إن وجدت؛ وإلا نضيف قيمة جديدة للمفتاح في التخبئة. نزع مفتاح من التخبئة: Cache::forget('key'); كما يمكن استخدام الدالة pull التي تبحث عن قيمة في التخبئة، ثم تحذفها بعد الحصول عليها: Cache::pull('key'); يشبه الأمر تنفيذ الدالتين get وforget بالتتالي. توجد طريقة أخرى لحذف محتوى التخبئة قبل انتهاء المدة المحددة له بتنفيذ أمر artisan التالي: php artisan cache:clear الدالة المساعدة cache يحتوي إطار العمل Laravel على الكثير من دوال PHP المساعدة؛ بعضها مستخدَم في وظائف إطار العمل نفسه. تعمل الدوال المساعدة Helper functions على الرفع من الإنتاجية والابتعاد عن تكرار الشفرات البرمجية بتجميع وظائف اعتيادية وإتاحة الوصول إليها حيث دعت الحاجة. يضيف الإصدار 5.3 دالة مساعدة جديدة باسم cache يمكن استخدامها في أي جزء من المشروع من أجل تسهيل التخاطب مع نظام التخبئة، بدلا من الصّنف Illuminate\Support\Facades\Cache. نحصل على قيمة المتغير key (المفتاح) باستخدام الدالة المساعدة cache على النحو التالي: cache('key'); تكافئ التعليمة أعلاه استخدام الصنف Cache على النحو التالي: Cache::get('key'); يمكن أيضا تمرير مصفوفة بالمفاتيح وقيمها إلى الدالة cache؛ ونحدّد المدة الزمنية التي نريد أن تستغرقها التخبئة: cache(['title' => 'Hsoub Academy'], 5); إن طلبنا في الخمس دقائق القادمة قيمة المفتاح title في الدالة cache فسنجد القيمة Hsoub Academy. نستخدم الدوال الموجودة في الصنف Cache في الدالة المساعدة cache بنفس الطريقة: إضافة مفتاح إلى التخبئة: cache()->put('key', 'value', 10); أو cache(['key' => 'value'],10); البحث عن قيمة المفتاح في التخبئة، وإضافته إليها إن لم يوجد بها: cache()->remember('key', 5, function() { // }); الحصول على قيمة مفتاح من التخبئة ثم حذفه منها بعد ذلك: cache()->pull('key'); حذف مفتاح من التخبئة: cache()->forget('key'); نعيد كتابة الدالة index في المتحكم PostsController بالدالة المساعدة cache بدلا من الصنف Cache: public function index() { $posts = cache()->remember('posts', 5, function() { return Post::all(); }); return response()->json($posts); } يمكن ملاحظة أنك لا تحتاج لاستيرد صنف جديد؛ فالدالة المساعدة متوفرة في جميع المشروع.
  4. ما هو OPcache؟ يحتاج كلّ طلب Request في PHP إلى أن يُحلَّل Parsed، يُترجَم Compiled ثمّ يُنفَّذ Executed؛ لكن في حالات عديدة تؤدّي الطّلبات دائمًا إلى نفس النّتائج، وهو ما يعني أن الخادوم يكرّر في كلّ مرة الخطوات الثّلاث المذكورة دون حاجة لذلك. هنا يأتي دور أدوات التّخزين المؤقَّت للشّيفرة العمليّة Opcode (اختصار ل Operation code، وهو ناتج التّحليل ثمّ التّرجمة أي الصّيغة الّتي يُنفَّذ بها الطّلب)، ومن بينها OPcache. يتلخَّص عمل OPcache في الاحتفاظ بالشيفرة العمليّة في ذاكرة الوصول العشوائي RAM وتنفيذها - عند إعادة الطّلب - من الذّاكرة مباشرةً دون الحاجة للمرور بخطوتَيْ التّحليل والتّرجمة؛ وهو ما يعني اختصار الخطوات والتّقليل من حِمل العمل، غير الضّروريّ، على الخادوم. نفترض في هذا الدّرس وجود حزم LAMP مثبَّتة ومضبوطة على خادومك. تفعيل OPcache تأتي أداة OPcache مضمَّنةً في الإصدار 5.5 من PHP. الأمر التّالي يُظهر إصدار PHP المستخدَم: php -v عندي مثلًا: PHP 5.5.9-1ubuntu4.9 (cli) (built: Apr 17 2015 11:44:57) Copyright (c) 1997-2014 The PHP Group Zend Engine v2.5.0, Copyright (c) 1998-2014 Zend Technologies with Zend OPcache v7.0.3, Copyright (c) 1999-2014, by Zend Technologies لاحظ السّطر الأخير: with Zend OPcache v7.0.3, Copyright (c) 1999-2014, by Zend Technologies يخبرنا هذا السّطر أن OPache مُثبَّت؛ وأنّ الإصدار المستخدَم هو 7.0.3. إذا اتّبعت خطوات كيف تُثبِّت وتؤمِّن phpMyAdmin على Ubuntu 14.04 فستجد أنّ OPcache مُفعَّل. للتّأكّد ننشئ ملفّ info.php (راجِع الدّرس السّابق) ثمّ ندخل إلى العنوان http://domain_or_ip/info.php حيث domain_or_ip نطاق أو عنوان IP الخادوم. في صفحة معلومات الخادوم نبحث عن بعض التّفاصيل. يُمكن ملاحظة أنّ ملفّ إعداد خادوم الويب المستخدَم هو etc/php5/apache2/php.ini/ وأنّ خادوم الويب يبحث عن ملفّات إعداد إضافيّة في المجلَّد etc/php5/apache2/conf.d/؛ تظهر ملفّات الإعداد الموجودة في هذا المجلّد ضمن خانة Additional .ini files parsed، ومن بينها الملفّ etc/php5/apache2/conf.d/05-opcache.ini/. يتحكّم هذا الملفّ في إعداد OPcache كما سنرى. إذا نزلنا أسفل الصّفحة فسنجد فقرات خاصّة ب OPcache: ما يهمّنا الآن من هذه الفقرة هو السّطر الأوّل: Opcode Caching Up and Running أي أنّ التّخزين المؤقَّت مُفعَّل ويعمل. إعداد OPcache توجد خيّارات عديدة لضبط آليّة عمل OPcache. سنتعرّض في هذه الفقرة لأهمّها. يقدّم توثيق PHP قائمة بجميع الخيّارات الموجودة. 1- حجم ذاكرة التّخزين المؤقّت تُحدّد تعليمة opcache.memory_consumption حجم الذّاكرة المخصَّصة لاستخدام OPcache، حيثُ تُخزّن الشيفرة العمليّة لسكربتات PHP. تُضاف هذه التّعليمة إلى ملفّ إعداد OPcache الموجد على المسار etc/php5/apache2/conf.d/05-opcache.ini/. نفتح الملفّ للتّحرير: sudo nano /etc/php5/apache2/conf.d/05-opcache.ini محتوى الملفّ: ; configuration for php ZendOpcache module ; priority=05 zend_extension=opcache.so ملحوظة: لتعطيل OPcache أضف علامة ; أما سطر zend_extension=opcache.so؛ ثمّ أعد تشغيل خادوم ويب Apache. ستلاحظ أنّ صفحة المعلومات لم تعد تظهر البيانات المتعلّقة ب Zend OPcache. نُضيف تعليمة opcache.memory_consumption ونحدّد قيمتها، علمًا أنّ القيمة الافتراضيّة هي 64MB. مثلًا، التّعليمة التّاليّة تحدّد حجم ذاكرة التّخزين المؤقّت ب128 ميغا بايت: opcache.memory_consumption=128 ينصح التّوثيق الرّسمي لOPcache بإعطاء قيمة 128 لهذه التّعليمة، إلّا أنّ الأمر يعتمد على قدرات خادومك ونوعيّة وعدد التّطبيقات والخدمات العاملة عليه. 2- الحدّ الأقصى لعدد الملفّات المُخزّنة تُتيح تعليمة opcache.max_accelerated_file تحديد عدد أقصى للملفّات المحتفظ بها في ذاكرة التّخزين المؤقَّت. القيمة المنصوح بها هي 4000: opcache.max_accelerated_files=4000 3- المدّة اللّازمة للتّحقّق من وجود تغيير على برنامج مُخزَّن في الذّاكرة تُحدّد تعليمة opcache.revalidate_freq مدّة زمنيّة (بالثّانيّة) يُتحقّق بعد انقضائها من وجود تغييرات على الملفّ المخزّن في ذاكرة الوصول العشوائيّ؛ إذا كان الاختبار إيجابيًّا، أي حدث تغيير، فإنّ الملفّ يُعاد تحليله وترجمته قبل أن يُخزّن من جديد. يُنصَح بقيمة 60 لهذه التّعليمة: opcache.revalidate_freq=60 ملحوظة: إضافة علامة ; في بداية سطر يعني تجاهلَه. في هذه الحالة، إذا كان السّطر يحوي تعليمة فلن تؤخَذ في الحسبان. يظهر الملفّ الآن بالمحتوى التّالي: ; configuration for php ZendOpcache module ; priority=05 zend_extension=opcache.so opcache.memory_consumption=128 opcache.max_accelerated_files=4000 opcache.revalidate_freq=60 لم يتبقّ إلا إعادة تشغيل خادوم الويب لتفعيل الخيّارات: sudo service apache2 restart ملحوظة: يمكن التّأكّد من عبر صفحة info.php حيث تظهر قيمة الخيّارات أعلاه في خانات بنفس أسماء الخيّارات. خاتمة يُساعد استخدام أداة OPcache في تحسين أداء الخادوم بشكل ملحوظ والاستفادة القصوى من موارد الجهاز. حاول - بحذر - تجربة إعدادات مختلفة وتفحّص تأثيراتها على الأداء حتى تجد الإعداد الأكثر مناسبةً لبيئة عملك. إذا أردت مواصلة التّحسين فدرس كيفيّة تثبيت وإعداد الذّاكرة المُخبّئة (Memcache) على Ubuntu خطوة جيّدة في هذا المجال.
  5. Redis عبارة عن نظام تخزين مؤقّت cache بنمط مفتاح-قيمة key-value مفتوح المصدر. إن كنت ترغب في استخدام Redis على بيئة الإنتاج الخاصة بك، فإن نسخ بياناتك على خادومين على الأقل يُعتبر من بين أفضل الممارسات (best practices)، تتيح الوفرة الاسترداد في حالة فشل البيئة، ما يُعتبر مهمّا عند نمو قاعدة مستخدمي تطبيقك. بنهاية هذا الدرس، سنضبط خادومي Redis كالتالي: خادوم Redis للمتبوع/السيد (master server) خادوم Redis للتّابع (slave server) سنشرح كذلك كيفيّة الانتقال إلى خادوم التّابع وضبطه كسيّدِِ مؤقّت. لك كامل الحريّة في ضبط أكثر من خادوم واحد خاص بالتابع. هذا الدرس يركز على ضبط عنقود تابع ومتبوع خاص بـredis، لتعلم المزيد عن Redis بشكل عام واستخدامه الأساسي كقاعدة بيانات، ألق نظرة على هذا الدرس. المتطلبات في حين سيعمل هذا على إصدارات أقدم وتوزيعات لينكس أخرى، لكن ننصح باستعمال نظام أوبنتو 14.04. سنعتمد على: نظام أوبنتو Ubuntu 14.04 LTS. خادومين، بأي حجم تريد، واحد متبوع وآخر أو أكثر للتّوابع. ادخل إلى خواديمك عبر SSH مع مستخدم غير جدري مع صلاحيّات sudo كما هو مبيّن في الإعداد الابتدائي لخادوم أوبنتو 14.04 . الخطوة الأولى: تثبيت Redis سنبدأ مع الخادوم الذي سيستضيف المتبوع/السّيّد، وأول خطوة هي تثبيت Redis. أولا نحتاج إلى إضافة مستودع Redis الخاص بـ Chris Lea (كما جرت عليه العادة، توخ الحذر عند إضافة مستودعات طرف ثالث، نستخدم هذا المستودع لأن صاحبه حسنُ السمعة): sudo add-apt-repository ppa:chris-lea/redis-server اضغط ENTER لقبول المستودع. شغل الأمر التالي لتحديث الحزم: sudo apt-get update ثبت خادوم Redis: sudo apt-get update تأكد أنّ Redis مُشغل وقيد التنفيذ: redis-benchmark -q -n 1000 -c 10 -P 5 الأمر أعلاه يخبر بأننا نريد تشغيل الأمر redis-benchmark في وضع صامت، مع 1000 طلبات إجماليّة، 10 اتصالات موازية، و 5 طلبات أنابيب. للمزيد من المعلومات عن هذا الأمر، شغّل الأمر redis-benchmark –help على الطرفيّة لتظهر لك معلومات وأمثلة حول الأمر. بعد انتهاء العمليّة، يجب أن ترى مُخرجات تبدو كالتالي: PING_INLINE: 166666.67 requests per second PING_BULK: 249999.98 requests per second SET: 249999.98 requests per second GET: 499999.97 requests per second INCR: 333333.34 requests per second LPUSH: 499999.97 requests per second LPOP: 499999.97 requests per second SADD: 499999.97 requests per second SPOP: 499999.97 requests per second LPUSH (needed to benchmark LRANGE): 499999.97 requests per second LRANGE_100 (first 100 elements): 111111.12 requests per second LRANGE_300 (first 300 elements): 27777.78 requests per second LRANGE_500 (first 450 elements): 8333.33 requests per second LRANGE_600 (first 600 elements): 6369.43 requests per second MSET (10 keys): 142857.14 requests per second الخطوة الثانية: ضبط Redis المتبوع الآن بما أن Redis قيد التنفيذ على العنقود المتكون من الخادومين، يجب علينا تعديل ملفات الإعدادات. كما سنرى، هناك اختلافات طفيفة بين ضبط الخادوم المتبوع والتابع. لنبدأ أولا مع المتبوع master. افتح الملف etc/redis/redis.conf/ باستخدام محرر النصوص المُفضّل لديك: sudo nano /etc/redis/redis.conf وعدّل الأسطر التّالية: ضع قيمة معقولة لمؤقّت الإبقاء على قيد الحياة KeepAlive للـTCP: tcp-keepalive 60 اجعل الخادوم متاحا للجميع على الويب بجعل هذا السّطر كتعليق (أو بحذفه): #bind 127.0.0.1 بحكم طبيعة Redis وسرعاتها العاليّة قد ينفذ مهاجم هجوم القوة الغاشمة Brute force على كلمة المرور. لذلك ننصح إزالة تعليق سطر requirepass وإضافة كلمة مرور معقّدة (أو من الأفضل أن تكون جملة مرور معقدة): requirepass your_redis_master_password على حسب سيناريو استخدامك، قد ترغب في تعديل السّطر التالي أو لا. لغرض هذا الدرس ، نفترض أن حذف أي مفتاح key deletion ممنوع. قم بإزالة التعليق عن هذا السّطر واضبطه كالتالي: maxmemory-policy noeviction أخيرا، سنقوم بالتعديلات التاليّة، وهي مطلوبة للنسخ الاحتياطي للبيانات. أزل التعليق/أو اضبط هذه الأسطر كالتالي: appendonly yes appendfilename redis-staging-ao.aof احفظ التغييرات. أعد تشغيل خدمة Redis لإعادة تحميل تعديلات الضبط التي قمنا بها. sudo service redis-server restart إذا أردت، يُمكنك إضافة بعض المحتوى إلى قاعدة بيانات المتبوع من خلال اتباع قسم أوامر Redis في هذا الدرس. حتى نتمكن من معرفة كيفية نسخه إلى الخادوم التابع. الآن وبعد أن جهزنا خادوم المتبوع أو السيّد، لننتقل إلى خادوم التابع. الخطوة الثالثة: إعداد Redis التابع نحتاج للقيام ببعض التعديلات التي ستسمح لخادوم التابع بالاتّصال مع المتبوع: افتح الملف etc/redis/redis.conf/ بمحررك المُفضل: sudo nano /etc/redis/redis.conf عدّل الأسطر التالية، بعض الإعدادات ستكون تماما مثل الإعدادات الخاصة بالمتبوع. اجعل الخادوم متاحا للجميع على الويب بتحويل هذا السطر إلى تعليق (عبر إضافة # إلى بدايته): #bind 127.0.0.1 يحتاج التابع كذلك إلى كلمة مرور لنستطيع إعطاء الأوامر له (مثل INFO). أزل التعليق عن هذا السطر وضع كلمة سر للخادوم: requirepass your_redis_slave_password أزل التعليق عن هذا السطر وضع عنوان IP الخاص بالمتبوع، متبوعا برقم المنفذ المضبوط على الخادوم. افتراضيّا يكون الرقم 6379 هو رقم المنفذ: SLAVEOF your_redis_master_ip 6379 تأكد من تغيير your_redis_master_ip إلى عنوان IP الخاص بالمتبوع. احفظ الآن هذه التغييرات، واخرج من الملف. ومن ثم، أعد تشغيل الخدمة كما فعلنا مع خادوم المتبوع: sudo service redis-server restart هذا الأمر سيعيد ضبط Redis وسيحمل الملفات التي عدّلناها. اتصل بـredis: redis-cli -h 127.0.0.1 -p 6379 استوثق بكلمة المرور الخاصة بالتابع: AUTH your_redis_slave_password لقد شغّلنا الآن عنقود Redis يعمل كتابع ومتبوع، مع ضبط كل من الخادومين بشكل صحيح. الخطوة الرابعة: تحقق من نسخ التابع-المتبوع سيسمح لنا اختبار هذا التّنصيب فهم كيفية تصرف خوادم Redis بشكل أفضل، عندما نرغب في بداية برمجة الحماية من الفشل. ما سنفعله الآن هو التحقق من أن الإعدادات تعمل بشكل صحيح، وأن المتبوع يتواصل مع التابع بشكل صحيح. أولا، نتصل بـredis عبر الطرفيّة، على خادوم المتبوع: اتّصل أولا بالنموذج المحليّ، مع استعمال المنفذ الافتراضي 6379. إذا كنت قد غيّرت المنفذ، فغير الأمر بما يناسب: redis-cli -h 127.0.0.1 -p 6379 الآن، استوثق مع Redis باستعمال كلمة المرور التي وضعتها عند ضبط المتبوع: AUTH your_redis_master_password يجب عليك أن تحصل على OK كمُخرج. الآن، كل ما عليك فعله هو تنفيذ الأمر: INFO سترى كلّ ما تحتاج معرفته عن خادوم المتبوع. ما يهمنا هو القسم Replication# والذي يجب أن تبدو كالمخرجات التاليّة: . . . # Replication role:master connected_slaves:1 slave0:ip=111.111.111.222,port=6379,state=online,offset=407,lag=1 master_repl_offset:407 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:2 repl_backlog_histlen:406 . . . لاحظ سطر connected_slaves:1، الذي يخبرنا بأن نموذج التابع يتواصل مع الخادوم المتبوع. كما يُمكنك ملاحظة أنّنا حصلنا على عنوان IP الخاص بالتابع، وكذلك المنفذ، الحالة، ومعلومات أخرى. الآن لنلق نظرة على قسم Replication# في الخادوم الخاص بالتابع، العمليّة نفسها التي قمنا بها مع المتبوع، ادخل إلى Redis، طبق الأمر INFO، وانظر إلى المُخرجات: . . . # Replication role:slave master_host:111.111.111.111 master_port:6379 master_link_status:up master_last_io_seconds_ago:3 master_sync_in_progress:0 slave_repl_offset:1401 slave_priority:100 slave_read_only:1 connected_slaves:0 master_repl_offset:0 repl_backlog_active:0 repl_backlog_size:1048576 repl_backlog_first_byte_offset:0 repl_backlog_histlen:0 . . . يُمكننا ملاحظة أن هذا الخادوم يقوم بدور التابع، وأنه يتواصل مع خادوم Redis المتبوع، ولا يملك أي توابع خاصة به. الخطوة الخامسة: التبديل إلى التابع بناء هذه الهندسة يعني أننا نريد التعامل مع الأخطاء والفشل بطريقة يُمكننا التأكد بها من سلامة البيانات وفي أقل وقت توقف ممكن لتطبيقنا. يُمكن لأي تابع أن يرتقي ليصبح متبوعا. أولا، لنختبر التبديل بشكل يدوي. على خادوم التابع، يجب أن نتصل مع نموذج Redis: redis-cli -h 127.0.0.1 -p 6379 الآن قم بالاستيثاق مع Redis باستخدام كلمة المرور التي استخدمتها عند ضبط التابع. AUTH your_redis_slave_password قم بإنهاء دور التابع: SLAVEOF NO ONE يجب الحصول على OK كمُخرج. الآن، نفذ الأمر: INFO قسم Replication# في الرد يجب أن يبدو كالمخرجات التاليّة: . . . # Replication role:master connected_slaves:0 master_repl_offset:1737 repl_backlog_active:0 repl_backlog_size:1048576 repl_backlog_first_byte_offset:0 repl_backlog_histlen:0 . . . كما هو متوقع، فقد تحول التابع إلى متبوع، وهو الآن جاهز لقبول اتّصالات من خوادم أخرى (إذا كانت موجودة). يُمكننا استعماله كمخزن نسخ احتيّاطي مؤقّت أثناء إصلاح الأخطاء في المتبوع الأصلي. إذا كنت تمتلك عدة توابع مُعتمدة على المتبوع الرئيسي، فسيتوجب عليك توجيههم إلى المتبوع الجديد. يُمكن القيّام بذلك بسهولة، بالخطوات التاليّة التي يجب تطبيقها في حال كُشِف عن أيّ أخطاء. من التطبيق، أرسل جميع الطلبات لـredis إلى خادوم تابع. على هذا التابع، نفّذ الأمر SLAVEOF NO ONE. منذ النسخة 1.0.0 من Redis هذا الأمر يُخبر التابع بالتوقف عن نسخ البيانات، والبداية في التصرف كخادوم متبوع. على جميع التابعين المتبقّين (إذا كانوا موجودين)، تشغيل الأمر SLAVEOF hostname port سيوجههم للتوقف عن النسخ من المتبوع القديم، وتجاهل البيانات، والبداية في النسخ من المتبوع الجديد. تأكد من تغيير hostname و port بالمعلومات المناسبة من المتبوع الجديد. بعد حل المشكلة، قد يرجع المتبوع القديم كمتبوع رئيسي، إذا كانت الإعدادات الخاصّة بك تتطلّب ذلك. هناك العديد من الطرق الممكنة لتنفيذ الخطوات أعلاه. ومع ذلك، الأمر يعود لك لتنفيذ أي حل تراه ملائما لبيئتك، وتأكد من اختبارها قبل أن يحدث أي فشل حقيقي. الخطوة السادسة: إعادة الاتصال بالمتبوع الأصلي لنرجع الاتصال بالمتبوع الأصلي. على الخادوم التابع ادخل إلى Redis وشغل الأمر التالي: SLAVEOF your_redis_master_ip 6379 تأكد من تغيير your_redis_master_ip إلى عنوان IP الخاص بالمتبوع إذا قمت بتشغيل الأمر INFO مجددا، يجب أن تلاحظ أنّنا عدنا إلى الإعدادات الأصليّة. في الختام لقد قمنا بإعداد بيئة مكونة من خادومين بنجاح، واحد يتصرف كمتبوع Redis والآخر ينسخ البيانات كتابع. بهذه الطريقة، إذا كان خادوم المتبوع يعاني من أي أخطاء أو فقد بياناتنا علي، فقد تعلمنا كيفية تبديل تابع ليصبح متبوعا كاحتياط إلى حين إصلاح المشكلة. الخطوات التالية تتعلق ببرمجة إجراء الحماية من الخطأ التلقائي، أو ضمان اتصالات آمنة بين جميع خوادمك باستعمال حلول VPN مثل OpenVPN أو Tinc، اختبار الإجراءات والسكربتات للتحقق من صحة إعداداتك. إضافة إلى ذلك، يجب عليك اتخاذ احتياطات عند نشر مثل هذه لإعدادات على بيئات الإنتاج. يجب أن تدرس توثيق Redis ويجب أن تفهم جيدا أي من نماذج الأمان هي الملائمة لتطبيقك. نستعمل عادة Redis كمَخزن للجلسة، وما يحتويه من معلومات قد يكون ذا قيمة لمهاجم ما. الممارسة الشائعة هي أن تمتلك هذه الخواديم إمكانية وصول فقط عبر شبكة خاصة private network. هذه نقطة بداية بسيطة عن كيفية بناء مخزن بيانات خاص بك؛ وليس درسا شاملا عن ضبط Redis لاستخدام هندسة تابع-متبوع. إذا كان هناك أي شيء كنت ترغب في تغطيّته في هذا الدرس، اترك تعليقات أسفله، ولمزيد من المعلومات عن هذا الموضوع، فإن قسم أسئلة DevOps بالأكاديمية تعتبر أماكن جيّدة لتبدأ منها. ترجمة -وبتصرّف- للمقال How To Configure a Redis Cluster on Ubuntu 14.04 لصاحبه Florin Dobre.
  6. إن Squid هو خادوم تخزين وسيط للويب (web proxy cache server) الذي يوفر خدمات الوساطة والتخزين لبروتوكول نقل النص الفائق (HTTP)، وبروتوكول نقل الملفات (FTP)، وغيرهما من بروتوكولات الشبكة الشهيرة؛ يمكن أن يدعم Squid التخزين والوساطة لطلبات طبقة المقابس الآمنة (SSL) وتخزين طلبيات DNS؛ ويدعم Squid أيضًا بروتوكولات تخزين مخبأ مختلفة، مثل بروتوكول تخزين الإنترنت (Internet Cache Protocol اختصارًا ICP)، وبروتوكول تخزين النص الفائق (Hyper Text Caching Protocol اختصارًا HTCP)، وبروتوكول تخزين مصفوفة التوجيه (Cache Array Routing Protocol اختصارًا CARP)، وبروتوكول تنسيق تخزين الويب (Web Cache Coordination Protocol اختصارًا WCCP). إن الخادوم الوسيط Squid هو حل ممتاز لاحتياجاتٍ كثيرةً للوساطة أو التخزين المؤقت، والتوسع من مكتب فرعي إلى شبكة الشركة الكبيرة وذلك بتوفير آليات مراقبة وتحكم في الوصول للمعاملات المهمة باستخدام بروتوكول إدارة الشبكة المبسط (Simple Network Management Protocol اختصارًا SNMP). عند اختيار حاسوب ليعمل كخادوم Squid، فتأكد أنه مضبوط مع كمية كبيرة من الذاكرة الفيزيائية، حيث يستخدم Squid التخزين في الذاكرة لزيادة الأداء. التثبيتأدخِل الأمر الآتي في الطرفية لتثبيت خادوم Squid: sudo apt-get install squid3الضبطيُضبَط Squid بتعديل التعليمات الموجودة ضمن ملف الضبط ‎/etc/squid3/squid.conf؛ الأمثلة الآتية تعرض بعض التعليمات التي يمكن تعديلها لتغيير سلوك خادوم Squid؛ للمزيد من التفاصيل المعمَّقة حول Squid، فانظر إلى قسم المصادر. تنويه: قبل تعديل ملف الضبط، تأكد أنك ستُنشِئ نسخةً من الملف الأصلي وتحميها من الكتابة كي تحصل على الإعدادات الافتراضية كمرجعٍ لك، أو أن تعيد استخدامها وقت الحاجة. انسخ الملف ‎/etc/squid/squid.conf واحمهِ من الكتابة بإدخال الأوامر الآتية في الطرفية: sudo cp /etc/squid3/squid.conf /etc/squid3/squid.conf.original sudo chmod a-w /etc/squid3/squid.conf.originalلضبط خادوم Squid لكي يستمع إلى منفذ TCP ذو الرقم 8888 بدلًا من منفذ TCP الافتراضي 3128، فعدِّل التعليمة http_port كما يلي: http_port 8888عدِّل التعليمة visible_hostname لكي تعطي خادوم Squid اسم مضيف خاص به؛ هذا الاسم لا يفترض أن يكون نفس اسم المضيف للحاسوب؛ ضُبِطَ في هذا المثال إلى weezie: visible_hostname weezieباستخدام التحكم في الوصول الخاص بخادوم Squid، ربما تضبط استخدام خدمات الإنترنت التي يكون فيها Squid وسيطًا لتتوفر للمستخدمين الذي يملكون عناوين IP معيّنة؛ ففي هذا المثال، سنسمح بالوصول لمستخدمي الشبكة الفرعية 192.168.42.0/24 فقط: أضف ما يلي إلى نهاية قسم ACL من ملف ضبط ‎/etc/squid3/squid.conf: acl fortytwo_network src 192.168.42.0/24ثم أضف ما يلي إلى بداية قسم http_access في ملف ‎/etc/squid3/squid.conf: http_access allow fortytwo_networkباستخدام ميزات التحكم بالوصول الممتازة التي يوفرها Squid؛ فربما تضبط استخدام خدمات الإنترنت التي يكون فيها Squid وسيطًا كي تتوفر فقط أثناء ساعات العمل العادية؛ على سبيل المثال، سنحاكي وصول الموظفين خلال ساعات العمل من 9:00AM إلى 5:00PM ومن الاثنين إلى الجمعة، الذين يستخدمون الشبكة الفرعية 10.1.42.0/42: أضف ما يلي إلى نهاية قسم ACL في ملف ‎/etc/squid3/squid.conf: acl biz_network src 10.1.42.0/24 acl biz_hours time M T W T F 9:00-17:00ثم أضف ما يلي إلى أعلى قسم http_access في ملف ‎/etc/squid3/squid.conf: http_access allow biz_network biz_hoursملاحظة: بعد عمل تغيرات إلى ملف الضبط ‎/etc/squid3/squid.conf، فاحفظ الملف ثم أعد تشغيل خادوم Squid لكي تأخذ التغيرات مجراها بإدخال الأمر الآتي في الطرفية: sudo service squid3 restartمصادرموقع Squid.صفحة ويكي أوبنتو «Squid».ترجمة -وبتصرف- للمقال Ubuntu Server Guide: Squid - Proxy Server.