H2o: ضائع تأخير (نوم ، خيط.نوم) في روضة؟

تم إنشاؤها على ٢ مايو ٢٠١٧ · 6تعليقات · مصدر: h2o/h2o

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

هل هناك أي طريقة للنوم لبضع ثوان في h2o باستخدام mruby (حاولت تثبيت ملحق Thread mruby مخصص ولكن لا يمكنني الحصول على تاريخ للاستجابة من سلسلة الرسائل)؟

الخطأ:
[lib/handler/fastcgi.c] in request:/index.php/tag/science:connection failed:failed to connect to host

الرمز:

if request_is_from_self and links_file_exist and req_is_get
    links = `php #{links_filepath}`

    for link in links.split(' ') do
        req = http_request(link)
        _, _, _ = req.join
    end
end

enhancement mruby

مصدر

taosx

ال 6 كومينتر

مرحباtaosx
أشك إلى حد ما في أن php حقًا لا يمكنه مواكبة ذلك.
هل ترسل طلبات http إلى مثيل h2o الذي يقوم بتشغيل fastcgi بعد ذلك؟

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

هل يمكنك تجربة شيء مثل

links.split(' ').map{|l| http_request }.to_a.map{|r| r.join}

ونشر وصف خطأ أكثر تفصيلاً؟

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

yannick في ٢ مايو ٢٠١٧

👍1

أعتقد أن التعليمات البرمجية الخاصة بك لا تقدم حجة لـ http_request ، لقد قمت بتعديلها على النحو التالي:
links.split(' ').map{|l| http_request(l) }.map{|r| r.join}
ولكن لا يزال أداء الكود الذي نشرته أعلاه أسوأ.
لقد قمت بحل الحل عن طريق تثبيت وتنشيط opcache إلى php والآن انخفض الوقت الذي يستغرقه تنفيذ جميع الطلبات من 27 ثانية إلى 3.1 ثانية بدون أخطاء. باستخدام التعليمات البرمجية الخاصة بك سوف تذهب إلى 4 ثوان.

بعد إجراء المزيد من الاختبارات ، أود فتح مصدر الكود بالكامل لموقع Wordpress الخاص بي باستخدام h2o الذي يخزن الصفحات مؤقتًا كل دقيقتين ، والضغط المسبق باستخدام كل من gzip و brottli في الإعدادات القصوى ويعمل من ذاكرة التخزين المؤقت. أحب h2o حتى الآن ، أشكر جميع المساهمين في h2o !!

أرغب في رؤية المزيد من ميزات البرمجة النصية لـ h2o في المستقبل ، مثل openresty ولكن استنادًا إلى h2o: D

taosx في ٢ مايو ٢٠١٧

taosx آه آسف. لقد نسيت الجزء الحاسم: .to_a

links.split(' ').map{|l| http_request }.to_a.map{|r| r.join}

بدافع الفضول فقط ، هل يمكنك المحاولة مرة أخرى. وكم عدد الطلبات التي تقدمها / ما حجم مصفوفة الروابط؟

yannick في ٢ مايو ٢٠١٧

yannick حاولت مرة أخرى ، اضطررت إلى تعديل http_request لإعطاء الوسيطة (l).
انخفضت السرعة إلى 3.06 ثانية: D وأحيانًا 2.9+ عند تدفئة ذاكرة التخزين المؤقت.
تحتوي مجموعة الروابط على 41 عنصرًا (aws ec2 t2.micro).

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

هل تعتقد أنه يمكنني استخدام h2o مع mruby كذاكرة تخزين مؤقت للوكيل العكسي لـ wp ، أعتقد أنه ممكن.

taosx في ٢ مايو ٢٠١٧

👍1

يبدو أنك تتخلص من php عبر الروابط = php #{links_filepath} . من المحتمل أن يكون هذا بطيئًا للغاية ، هل أزلت ذلك الوقت؟
بالنسبة إلى h2o فقط ، يجب أن يكون t2.micro على ما يرام ، ولكن إذا قمت أيضًا بتشغيل عناصر php على هذا الجهاز ، فإنهم يتنافسون على وحدة المعالجة المركزية الفردية وينخفض الأداء بشكل أكبر. لذلك على الأقل للاختبار ، كنت سأأخذ شيئًا مثل c4.large أو c4.xlarge.

نعم ، يجب أن يكون التخزين المؤقت عبر mruby ممكنًا ، إما أن تفعل ذلك في الذاكرة أو تستخدم redis (والذي لا يزال يحتاج حاليًا إلى تصحيح ولكن يجب دمجه قريبًا ، راجع https://github.com/h2o/h2o/pull/1152)

yannick في ٣ مايو ٢٠١٧

👍1

هذا نقاش ممتع!

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