جديدالجمعة السوداء: خصم ٥٠٪ على دفعتك الأولى
استكشاف أخطاء ووردبريس

تجاوز الحد الأقصى لوقت التنفيذ

أوقفت PHP برنامج نصي كان يعمل لفترة أطول مما هو مسموح به. الحد قام بعمله ؛ السؤال هو ما إذا كانت الوظيفة تنتمي إلى طلب ويب.

Fatal error: Maximum execution time of 30 seconds exceeded

الإجابة المختصرة

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

التشخيص

الأسباب الأرجح أولًا.

افحص القائمة بالترتيب. يتيح لك كل فحص تأكيد السبب أو استبعاده قبل تغيير أي شيء، لأن الحلول تختلف والتخمين يكلّف أكثر من تنفيذ أمر للتحقق.

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

الإصلاح خطوة بخطوة.

تفترض الأوامر توفر WP-CLI والوصول إلى سطر الأوامر. إن لم يتوفرا، تشرح كل خطوة الإجراء كي تنفذه من لوحة التحكم أو عبر SFTP.

  1. معرفة أي حد ينطبق حيث

    عادةً لا يشارك سطر الأوامر وطلب الويب قيمة.

    php -i | grep max_execution_time
    php -r 'echo ini_get("max_execution_time"), PHP_EOL;'
  2. نقل الوظيفة إلى حيث لا ينطبق الحد الأقصى

    WP-CLI يعمل دون ساعة الحائط فوقه ، وهذا هو السبب في أن الوظائف الطويلة تنتمي إلى هناك.

    wp plugin install some-plugin --activate
  3. إذا كان يجب أن تعمل في طلب، رفعه لهذا المسار فقط

    نطاقها إلى سياق المشرف بدلا من كل شيء يخدم الموقع.

    wp config set WP_MEMORY_LIMIT '256M'
  4. تحقق مما إذا كان الوقت يخرج

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

    wp eval 'var_dump( wp_remote_get( "https://example.com", [ "timeout" => 5 ] ) );'
  5. تأكيد الآن انتهاء

    قم بتشغيل نفس الوظيفة مرة أخرى وشاهدها كاملة بدلاً من افتراض أنها ستفعل.

    time wp cron event run --due-now
على MagicWP

ما تتولاه المنصة عنك.

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

الأسئلة الشائعة

الأسئلة الشائعة.

لماذا الحد الأقصى هو 30 ثانية؟
هو الافتراضي PHP لطلبات الويب, وطلب على شبكة الإنترنت هو كريم. لا زائر ينتظر ثلاثين ثانية. الحد الأقصى هو مشكلة فقط عندما وظيفة التي لا ينبغي أن يكون في طلب يجد نفسه في واحد.
هل ينطبق الحد الأقصى على WP-CLI؟
لا. يعمل PHP سطر الأوامر بدون حد زمني للتنفيذ افتراضيًا ، وهذا هو بالضبط سبب وجود واردات وصادرات وهجرات طويلة هناك.
لقد أثرت ذلك والوظيفة لا تزال تفشل في نفس النقطة.
ثم الحد الذي أثار ليس هو الذي يجري فرضه. يمكن أن تحمل طلبات Cron و web قيمًا مختلفة ، ويمكن للوكيل الموجود أمامك مهلة قبل أن تفعل PHP.
هل هذا هو نفس 504؟
ذات صلة ولكن ليس هو نفسه. هذا هو PHP توقف نفسها. 504 هو خادم الويب التخلي عن PHP. يمكن أن تنتج مهمة طويلة إما ، اعتمادًا على الساعة التي تنفد أولاً.
أخطاء مرتبطة

إن لم يكن هذا هو السبب.

قد تبدو هذه الأخطاء متشابهة في المتصفح.