كيفية تحسين تطبيق PHP Laravel Web لأداء عالي؟

Laravel أشياء كثيرة. لكن الصيام ليس واحدًا منهم. دعونا نتعلم بعض الحيل للتجارة لجعلها أسرع!


لا تمس مطور PHP من قبل Laravel هذه الأيام. هم إما مطور صغير أو متوسط ​​المستوى يحبون التطور السريع الذي تقدمه Laravel ، أو أنهم مطور كبير يضطر لتعلم Laravel بسبب ضغوط السوق.

في كلتا الحالتين ، لا يمكن إنكار أن Laravel قد أعادت تنشيط نظام PHP البيئي (بالتأكيد ، كنت سأترك عالم PHP منذ فترة طويلة إذا لم يكن Laravel موجودًا).

مقتطف من الثناء الذاتي (المبرر إلى حد ما) من Laravel

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

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

النقطة هي ، افتراضيًا هذه الطبقات على طبقات التعليمات البرمجية ، تجعل Laravel بطيئًا.

ما مدى بطء Laravel?

بصراحة ، من المستحيل الإجابة على هذا السؤال لعدة أسباب.

أول, لا يوجد معيار مقبول وموضوعي ومعقول لقياس سرعة تطبيقات الويب. أسرع أم أبطأ مقارنة بماذا؟ في ظل ظروف ما?

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

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

يمر هذا GitHub محترمة إلى حد ما مصدر, إليك كيفية ترتيب أطر عمل PHP عند المقارنة:

قد لا تلاحظ حتى Laravel هنا (حتى لو كنت تحدق بشدة) إلا إذا قمت بإلقاء قضيتك في نهاية الذيل. نعم ، أصدقائي الأعزاء ، يأتي Laravel في المرتبة الأخيرة! الآن ، من المسلم به ، أن معظم هذه “الأطر” ليست عملية للغاية أو حتى مفيدة ، لكنها تخبرنا عن مدى بطء Laravel عند مقارنتها بأخرى أكثر شعبية.

عادةً ، لا يظهر هذا “البطء” في التطبيقات لأن تطبيقات الويب اليومية الخاصة بنا نادرًا ما تصل إلى أرقام عالية. ولكن بمجرد أن تفعل ذلك (على سبيل المثال ، ما يزيد عن 200-500 التزامن) ، تبدأ الخوادم في الاختناق والموت. لقد حان الوقت الذي لا يؤدي فيه إلقاء المزيد من الأجهزة على المشكلة إلى قطعها ، وتتسلق فواتير البنية التحتية بسرعة كبيرة لدرجة أن المثل العليا للحوسبة السحابية تنهار.

ولكن مهلا ، ابتهج! لا تتناول هذه المقالة ما لا يمكن فعله ، ولكن ما يمكن فعله. ��

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

أربعة أنواع من التحسينات

في رأيي ، يمكن إجراء التحسين على أربعة مستويات مميزة (عندما يتعلق الأمر بتطبيقات PHP ، أي):

  1. مستوى اللغة: هذا يعني أنك تستخدم إصدارًا أسرع من اللغة وتجنب ميزات / أنماط معينة من الترميز في اللغة تجعل الرمز الخاص بك بطيئًا.
  2. على مستوى الإطار: هذه هي الأشياء التي سنغطيها في هذه المقالة.
  3. على مستوى البنية التحتية: ضبط مدير عملية PHP ، خادم الويب ، قاعدة البيانات ، إلخ.
  4. على مستوى الأجهزة: الانتقال إلى مزود استضافة أجهزة أفضل وأسرع وأقوى.

كل هذه الأنواع من التحسينات لها مكانها (على سبيل المثال ، يعد تحسين php-fpm أمرًا بالغ الأهمية وقويًا). لكن محور هذه المقالة سيكون تحسينات من النوع 2 فقط: تلك المتعلقة بالإطار.

بالمناسبة ، لا يوجد أساس منطقي للترقيم ، وليس معيارًا مقبولًا. لقد صنعت هذه للتو. من فضلك لا تقتبس مني أبداً وتقول: “نحن بحاجة إلى تحسين من النوع 3 على خادمنا” ، وإلا فإن قائد فريقك سيقتلك ، ويجدني ، ثم يقتلني أيضًا. ��

والآن ، أخيرًا ، نصل إلى أرض الميعاد.

كن على علم باستعلامات قاعدة البيانات n + 1

مشكلة الاستعلام n + 1 شائعة عند استخدام ORMs. لدى Laravel جهاز ORM قوي يسمى Eloquent ، وهو جميل للغاية ومريح للغاية ، وننسى غالبًا أن ننظر إلى ما يحدث.

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

في Laravel ، قد نتخيل وظيفة تحكم تقوم بهذه المهمة على النحو التالي:

ClassController يمتد وحدة التحكم
{
// …

الوظيفة العامة getAllByCustomers (طلب $ request ، مصفوفة $ ids) {
$ customers = Customer :: findMany ($ ids)؛
$ orders = collect () ؛ // مجموعة جديدة

foreach ($ customers as $ customer) {
أوامر $ = أوامر $->دمج ($ customer->الطلب #٪ s)؛
}}

عرض الإرجاع (‘admin.reports.orders’، [‘orders’ => أوامر $]) ؛
}}
}}

حلو! والأهم من ذلك أنها أنيقة وجميلة. ����

لسوء الحظ ، إنها طريقة كارثية لكتابة كود في Laravel.

هنا لماذا.

عندما نطلب من ORM البحث عن العملاء المحددين ، يتم إنشاء استعلام SQL مثل هذا:

حدد * من العملاء حيث معرف (22 ، 45 ، 34 ،…) ؛

وهو بالضبط كما هو متوقع. ونتيجة لذلك ، يتم تخزين جميع الصفوف المرتجعة في عملاء $ المجموعة داخل وظيفة وحدة التحكم.

الآن نحن ندور كل عميل على حدة ونحصل على طلباتهم. يؤدي هذا إلى تنفيذ الاستعلام التالي . . .

SELECT * FROM orders WHERE customer_id = 22؛

. . . عدد المرات التي يكون فيها العملاء.

بمعنى آخر ، إذا احتجنا إلى الحصول على بيانات الطلب لـ 1000 عميل ، فسيكون إجمالي عدد استعلامات قاعدة البيانات المنفذة 1 (لجلب جميع بيانات العملاء) + 1000 (لجلب بيانات الطلب لكل عميل) = 1001. هذا من أين يأتي الاسم n + 1.

هل يمكننا القيام بعمل أفضل؟ من المؤكد! باستخدام ما يُعرف بالتحميل الحريص ، يمكننا إجبار ORM على تنفيذ JOIN وإرجاع جميع البيانات المطلوبة في استعلام واحد! مثله:

$ orders = Customer :: findMany ($ ids)->مع (“الطلبات”)->احصل على()؛

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

حدد * من العملاء INNER JOIN الطلبات على customers.id = orders.customer_id WHERE customers.id IN (22، 45،…)؛

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

التخزين المؤقت للتكوين!

أحد أسباب مرونة Laravel هو الكثير من ملفات التكوين التي تعد جزءًا من إطار العمل. تريد تغيير كيفية / مكان تخزين الصور?

حسنًا ، ما عليك سوى تغيير ملف config / filesystems.php (على الأقل حتى وقت الكتابة). هل تريد العمل مع العديد من برامج تشغيل قائمة الانتظار؟ لا تتردد في وصفها في config / queue.php. لقد عدت للتو ووجدت أن هناك 13 ملف تهيئة لجوانب مختلفة من الإطار ، مما يضمن لك عدم خيبة الأمل بغض النظر عما تريد تغييره.

نظرًا لطبيعة PHP ، في كل مرة يأتي طلب ويب جديد ، يستيقظ Laravel ، ويقوم بتشغيل كل شيء ، ويحلل كل ملفات التكوين هذه لمعرفة كيفية القيام بالأشياء بشكل مختلف هذه المرة. إلا أنه من الغباء إذا لم يتغير شيء في الأيام القليلة الماضية! إعادة بناء التكوين في كل طلب هو مضيعة يمكن تجنبها (في الواقع ، يجب) ، والمخرج هو أمر بسيط يقدمه Laravel:

التكوين الحرفي فب: ذاكرة التخزين المؤقت

ما يفعله هذا هو دمج جميع ملفات التكوين المتاحة في ملف واحد وذاكرة التخزين المؤقت في مكان ما لاسترجاعها بسرعة. في المرة التالية التي يكون فيها طلب ويب ، ستقرأ Laravel هذا الملف الفردي وستبدأ.

ومع ذلك ، فإن التخزين المؤقت للتكوين هو عملية دقيقة للغاية يمكن أن تنفجر في وجهك. أكبر مسكتك هو أنه بمجرد إصدار هذا الأمر ، ستستدعي وظيفة الدالة env () من كل مكان باستثناء ملفات التكوين فارغة!

من المنطقي عندما تفكر في ذلك. إذا كنت تستخدم التخزين المؤقت للتهيئة ، فأنت بذلك تخبر الإطار ، “أنت تعرف ما ، أعتقد أنني قد أعددت الأمور بشكل جيد وأنا متأكد 100٪ من أنني لا أريدها أن تتغير.” بعبارة أخرى ، أنت تتوقع أن تظل البيئة ثابتة ، وهذا هو الغرض من ملفات .env.

مع ذلك ، إليك بعض القواعد المغطاة بالحديد والمقدس وغير القابلة للكسر في التخزين المؤقت للتكوين:

  1. افعل ذلك فقط على نظام الإنتاج.
  2. لا تفعل ذلك إلا إذا كنت متأكدًا حقًا من رغبتك في تجميد التكوين.
  3. في حالة حدوث خطأ ما ، التراجع عن الإعداد باستخدام ذاكرة التخزين المؤقت الحرفي php: clear
  4. صلوا أن الضرر الذي لحق بالنشاط التجاري لم يكن كبيرا!

تقليل الخدمات المحملة تلقائيًا

للمساعدة ، تقوم Laravel بتحميل الكثير من الخدمات عندما تستيقظ. هذه متوفرة في ملف config / app.php كجزء من مفتاح الصفيف “موفري”. دعنا نلقي نظرة على ما لدي في حالتي:

/ *
|————————————————————————–
| مقدمو الخدمة الذين تم تحميلهم تلقائيًا
|————————————————————————–
|
| سيتم تحميل مزودي الخدمة المدرجين هنا تلقائيًا على
| طلب إلى التطبيق الخاص بك. لا تتردد في إضافة خدماتك الخاصة إلى
| هذا الصفيف لمنح وظائف موسعة لتطبيقاتك.
|
* /

“الموفرون” => [

/ *
* مزودو خدمات Laravel Framework…
* /
تضيء \ Auth \ AuthServiceProvider :: class,
تضيء \ Broadcasting \ BroadcastServiceProvider :: class,
تضيء \ Bus \ BusServiceProvider :: class,
تضيء \ Cache \ CacheServiceProvider :: class,
تضيء \ Foundation \ Providers \ ConsoleSupportServiceProvider :: class,
تضيء \ Cookie \ CookieServiceProvider :: class,
إضاءه \ قاعدة بيانات \ DatabaseServiceProvider :: class,
تضيء \ Encryption \ EncryptionServiceProvider :: class,
تضيء \ Filesystem \ FilesystemServiceProvider :: class,
تضيء \ Foundation \ Providers \ FoundationServiceProvider :: class,
تضيء \ Hashing \ HashServiceProvider :: class,
تضيء \ Mail \ MailServiceProvider :: class,
تضيء \ الإخطارات \ NotificationServiceProvider :: class,
تضيء \ ترقيم الصفحات \ PaginationServiceProvider :: class,
تضيء \ Pipeline \ PipelineServiceProvider :: class,
تضيء \ Queue \ QueueServiceProvider :: class,
تضيء \ Redis \ RedisServiceProvider :: class,
قم بإضاءة \ Auth \ Passwords \ PasswordResetServiceProvider :: class,
تضيء \ Session \ SessionServiceProvider :: class,
إضاءة \ ترجمة \ ترجمة خدمة الترجمة :: الفئة,
إضاءه \ التحقق من الصحة \ ValidationServiceProvider :: class,
تضيء \ عرض \ ViewServiceProvider :: class,

/ *
* مزودي خدمة الحزمة…
* /

/ *
* مزودي خدمة التطبيقات…
* /
App \ Providers \ AppServiceProvider :: class,
التطبيق \ الموفرون \ AuthServiceProvider :: class,
// App \ Providers \ BroadcastServiceProvider :: class,
التطبيق \ الموفرون \ EventServiceProvider :: class,
التطبيق \ الموفرون \ RouteServiceProvider :: class,

],

مرة أخرى ، أحصيت ، وهناك 27 خدمة مدرجة! الآن ، قد تحتاجهم جميعًا ، لكن هذا مستبعد.

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

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

كن حكيماً مع أكوام الوسيطة

عندما تحتاج إلى معالجة مخصصة لطلب الويب الوارد ، فإن إنشاء وسيط جديد هو الجواب. الآن ، من المغري فتح app / Http / Kernel.php وإلصاق الوسيطة في الويب أو مكدس واجهة برمجة التطبيقات ؛ بهذه الطريقة ، يصبح متاحًا عبر التطبيق وإذا لم يفعل شيئًا تدخليًا (مثل تسجيل الدخول أو الإخطار ، على سبيل المثال).

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

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

تجنب ORM (في بعض الأحيان)

بينما تجعل Eloquent العديد من جوانب تفاعل DB ممتعة ، إلا أنها تأتي على حساب السرعة. كونه مصمم خرائط ، لا يتعين على ORM جلب السجلات من قاعدة البيانات فحسب ، بل يجب أيضًا إنشاء كائنات النموذج وترطيبها (ملءها) ببيانات العمود.

لذلك ، إذا قمت بعمل $ بسيط للمستخدمين = User :: all () وهناك ، على سبيل المثال ، 10000 مستخدم ، فإن الإطار سيجلب 10000 صف من قاعدة البيانات ويقوم داخليًا بـ 10000 مستخدم جديد () ويملأ خصائصهم بالبيانات ذات الصلة . هذه كميات هائلة من العمل الذي يتم القيام به من وراء الكواليس ، وإذا كانت قاعدة البيانات هي المكان الذي يصبح فيه تطبيقك عنق الزجاجة ، فإن تجاوز ORM يعد فكرة جيدة في بعض الأحيان.

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

يمر هذه دراسة الأداء ، حتى بالنسبة للإدخالات البسيطة ، فإن Eloquent أبطأ كثيرًا حيث يرتفع عدد السجلات:

استخدم التخزين المؤقت قدر الإمكان

يعد التخزين المؤقت أحد أفضل الأسرار التي تم الاحتفاظ بها لتحسين تطبيق الويب.

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

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

يحتوي Laravel على دعم مدمج لعدة أنواع من التخزين المؤقت. بالإضافة إلى استخدام برنامج تشغيل التخزين المؤقت وبناء نظام التخزين المؤقت من الألف إلى الياء ، قد ترغب في استخدام بعض حزم Laravel التي تسهل التخزين المؤقت النموذجي, التخزين المؤقت الاستعلام, إلخ.

ولكن لاحظ أنه بخلاف حالة استخدام مبسطة معينة ، يمكن أن تتسبب حزم التخزين المؤقت سابقة الإعداد في مشاكل أكثر من حلها.

تفضل التخزين المؤقت في الذاكرة

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

من الناحية المثالية ، تريد استخدام ذاكرة تخزين مؤقت في الذاكرة (تعيش في ذاكرة الوصول العشوائي تمامًا) مثل Redis و Memcached و MongoDB ، وما إلى ذلك ، حتى في ظل الأحمال الأعلى ، يخدم التخزين المؤقت استخدامًا حيويًا بدلاً من أن يصبح اختناقًا في حد ذاته.

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

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

قم بتخزين المسارات

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

مسار الحرفي php: مخبأ

وعندما ينتهي بك الأمر بإضافة مسارات أو تغييرها ، قم ببساطة بما يلي:

مسار الحرفيين فب: واضح

تحسين الصورة و CDN

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

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

بدلاً من ذلك ، ابحث عن حل مثل سحابي يقوم تلقائيًا بتغيير حجم الصور وتحسينها بسرعة.

إذا لم يكن ذلك ممكنًا ، فاستخدم شيئًا مثل Cloudflare لتخزين الصور مؤقتًا وعرضها أثناء تخزينها على خادمك.

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

الخادم {

تم اقتطاع ملف واحد

# إعدادات ضغط gzip
gzip على.
gzip_comp_level 5 ؛
gzip_min_length 256 ؛
gzip_proxied أي ؛
gzip_vary قيد التشغيل ؛

# التحكم في ذاكرة التخزين المؤقت للمتصفح
الموقع ~ * \. (ico | css | js | gif | jpeg | jpg | png | woff | ttf | otf | svg | woff2 | eot) $ {
تنتهي الصلاحية في 1 د ؛
الوصول
add_header براغما العامة ؛
add_header التحكم في ذاكرة التخزين المؤقت "الجمهور ، الحد الأقصى للعمر = 86400"؛
}}
}}

أعلم أن تحسين الصورة ليس له علاقة بـ Laravel ، ولكن هذه خدعة بسيطة وقوية (ويتم إهمالها غالبًا) والتي لا يمكن أن تساعد نفسي.

تحسين برنامج التحميل التلقائي

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

تثبيت الملحن – تحسين-التحميل التلقائي – لا-ديف

تكوين صداقات مع قوائم الانتظار

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

على سبيل المثال ، في منتج تم إطلاقه مؤخرًا ، قد ترغب في إعلام قيادة الشركة (بعض عناوين البريد الإلكتروني 6-7) كلما قدم شخص ما طلبًا أعلى من قيمة معينة. على افتراض أن بوابة البريد الإلكتروني الخاصة بك يمكنها الاستجابة لطلب SMTP الخاص بك في 500 مللي ثانية ، فإننا نتحدث عن انتظار جيد لمدة 3-4 ثوانٍ للمستخدم قبل بدء تأكيد الطلب. يوافق على.

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

ائتمانات: Microsoft.com

في حين أن نظام قائمة الانتظار يعقد الإعداد قليلاً (ويضيف بعض عمليات المراقبة العامة) ، فإنه لا غنى عنه في تطبيق الويب الحديث.

تحسين الأصول (Laravel Mix)

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

المزيج هو غلاف خفيف (وممتع ، بكل أمانة!) حول Webpack يهتم بكل ملفات CSS ، SASS ، JS ، إلخ ، للإنتاج. يمكن أن يكون ملف .mix.js النموذجي صغيراً بهذا الحجم ومازال يعمل المعجزات:

خليط كونست = = (“مزيج لارافيل”) ؛

mix.js (‘resources / js / app.js’، ‘public / js’)
.sass (‘resources / sass / app.scss’، ‘public / css’)؛

يتولى هذا تلقائيًا عمليات الاستيراد والتصغير والتحسين والمحتوى الكامل عندما تكون جاهزًا للإنتاج وتشغيل إنتاج npm. لا يهتم Mix بملفات JS و CSS التقليدية فحسب ، بل يهتم أيضًا بمكونات Vue و React التي قد تكون لديك في سير عمل التطبيق.

مزيد من المعلومات هنا!

استنتاج

تحسين الأداء هو فن أكثر من العلم – معرفة كيف وكم يجب القيام به أمر مهم من ما يجب القيام به. ومع ذلك ، ليس هناك حد لمقدار ما يمكنك تحسينه في تطبيق Laravel.

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

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

ولكي تصبح newbiew سيدة Laravel ، تحقق من ذلك دورة على شبكة الإنترنت.

نرجو أن تعمل تطبيقاتك بشكل أسرع بكثير! ��

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map