الحديد أم التحسين؟ Badoo و Avito و Mamba - حول أداء PHP
تعد مشكلة أداء PHP لـ Badoo واحدة من أهم المشكلات. تعتمد جودة الواجهة الخلفية لـ PHP بشكل مباشر على مقدار الموارد التي ننفقها على التطوير والتشغيل ، وسرعة الخدمة والانطباع الذي تتركه على المستخدمين.لذلك ، موضوع الاجتماع الثالث لمجتمع مطوري PHP في مكتبنا قدمنا أداء الخلفية ودعونا الزملاء من Avito و Mamba للمناقشة.
اقرأ تحت النص المختصر للمناقشة ، حيث كنت محظوظًا لكوني مشرفًا: كيف يتم ترتيب البنية التحتية للشركات الثلاث ، وكيف نقيس الإنتاجية وما هي المقاييس التي نركز عليها ، وما هي الأدوات التي نستخدمها ، وكيف نختار بين الأجهزة والتحسين.وفي 15 فبراير ، تعال إلى لقاء Badoo PHP التالي : مناقشة الإرث.لقد قمنا بفك شفرة جزء المناقشة الذي بدا لنا الأكثر إثارة للاهتمام. النسخة الكاملة متاحة على الفيديو.الخبراء:- سيميون كاتاييف ، رئيس وحدة التطوير في Core Services Avito
- بافيل مورزاكوف pmurzakov، PHP Timlid في بادو
- ميخائيل Buylov mipxtx، مدير تكنولوجيا المعلومات في Mamba
أخبر قصة عن التحسين من ممارستك: النجاح الكبير أو الفشل الكبير شيء مثير للاهتمام للمشاركة.
ميخائيل بييلوف ، مامبا
لدي مثل.مرة واحدة كل ستة أشهر تقريبًا ، نلقي نظرة على المقاييس ونبحث عما يبطئ ، ولا يعمل بشكل جيد ، وما الذي يجب تحسينه. بمجرد أن لاحظنا حاوية التبعية symfony ، التي نمت إلى 52000 خط. قررنا أنه هو ، الوغد ، هو المسؤول عن كل شيء: 20 مللي ثانية من النفقات العامة لكل طلب. شاهدنا ذلك. قللنا ذلك. حاولنا بطريقة أو بأخرى فصله ، لكن لا شيء ساعد.ثم اتضح أن لدينا مكافحة البريد الإلكتروني العشوائي الذي يحتاج إلى الانتقال إلى 20 قاعدة بيانات من أجل تلبية جميع الطلبات الضرورية.الحلول التي تأتي أولاً ليست دائمًا الحلول الصحيحة. انظر بشكل أفضل إلى آثار طلباتك وسجلاتها ومعاييرها ولا تكسرها مباشرة. هنا قصة.بافيل مورزاكوف ، بادو
لدينا نظام بيئي كبير إلى حد ما في PHP ، لذلك نقوم بالتحسين بشكل دوري. نحن ننمو ، ونصل إلى مستوى ما في وحدة المعالجة المركزية ، ونحن نتفهم أننا بحاجة إما إلى شراء الأجهزة أو التحسين. وزن الحجج المؤيدة والمعارضة لكل خيار والبت فيها. في أغلب الأحيان - لصالح التحسين ، لأن الحديد يحتاج إلى الكثير.في إحدى هذه النقاط ، حددنا مجموعة كاملة كانت منخرطة في البحث عن أشياء مختلفة غير مثالية في نصوص PHP وتحسينها. حدث هذا حرفياً "قطرة قطرة": هنا وجدوا نسبة مئوية ، وجدوا نسبة مئوية - وجد العديد من الأشخاص نسبة مئوية في غضون شهر. في وقت ما ، كان sishnik لدينا قريبeinstein_man. قرر أن يرى ما يمكنه القيام به: ذهب في المساء ، وأطلق بيرف ، ووجد بضع مشاكل في امتدادات PHP - وسرع كل شيء في بضع أمسيات بنسبة 13 ٪!سيميون كاتايف ، أفيتو
لدي قصتين. واحد حول الملف ، والآخر حول المطور الفائق.عن الفشل. لدينا العديد من الخدمات الدقيقة ، بما في ذلك PHP. يعمل الجميع في Kubernetes. عملت في واحدة من هذه الخدمات الصغيرة. كان هناك استخدام كبير لوحدة المعالجة المركزية: لقد أمضوا أسبوعًا في التحسين والعثور على المشاكل. اتضح أن أحد المطورين أضاف Xdebug إلى الصور الأساسية لحساب اختبارات تغطية الكود في خدمته (الأخرى) ، وبعد ذلك تم تشغيل جميع الخدمات الصغيرة في الإنتاج مع Xdebug قيد التشغيل لربع كامل! بعد ربع ، اكتشفنا هذه الصور الأساسية الثابتة - وبدأنا في التقاط هدايا غير متوقعة: لقد أعدت تقديم الخدمة ، وبدأت في العمل بشكل أسرع. في كل عملية نشر ، يتم إعادة بناء صورة خدمتنا ، والآن بدون Xdebug.تاريخ النجاح. لدينا العديد من الخدمات الدقيقة ، وأصبحت أكثر فأكثر. في هذه الحالة ، يصبح عدد مكالمات RPC مشكلة. على سبيل المثال ، على بطاقة إعلان - وهذه واحدة من أكثر الصفحات شيوعًا في Avito - يشارك حوالي 30 خدمة صغيرة في عرض صفحة. علاوة على ذلك ، لم يتم كل هذا بشكل صريح للغاية: يبدو أنك تقوم باستدعاء نوع من التجريد ، وتحت ذلك يتم إجراء خمس مكالمات RPC إلى خدمات أخرى بشكل متسلسل.على مر السنين ، تدهورت بطاقة الإعلان إلى حد كبير. قاتل مطور قوي لمدة ربع عام ، وتم تحسينه ، وأخرج جميع مكالمات RPC. عندما كان قادرًا على القيام بذلك ، قام بموازنتها من خلال طلب Guzzle المتعدد - وبدلاً من 30 طلبًا متزامنًا متتاليًا ، تلقى نفس الطلبات 30 ، ولكن الطلبات الموازية ، والتي عجلت بشكل كبير من العمل. بعد إعادة الهيكلة هذه ، فإن وقت استجابة البطاقة يساوي الحد الأقصى لوقت الاستجابة لأي من الخدمات. لكنه كان بحاجة إلى ربع كامل لتحسين / إعادة كتابة رمز العرض لبطاقة الإعلان.أخبرنا ، ما هو حجم مجموعة PHP ، وكيف يتم تكوينه - على الأقل PHP-FPM ، أو ربما في مكان ما واجهته أباتشي في مشكلة؟
ميخائيل بييلوف ، مامبا
لدينا حوالي 15000 RPS. تم شراء مجموعة من 80 خادم FPM قبل عدة سنوات. في كل عنقود ، يتم إطلاق FPM (حتى 50 طفلًا كحد أقصى) في الإحصائيات. تم تحميل حوالي عشرة في ذروة وقت الذروة. يبلغ متوسط زمن الاستجابة 100 مللي ثانية ، ونحاول الاحتفاظ بها (عندما تتجاوز 100 مللي ثانية ، نبدأ البحث عن قطع الكبح).لدينا نظام مراقبة الأداء الخاص بنا. قمنا بتوزيع الكثير من العدادات في الكود ، حوالي 120 لكل طلب. نحن نراقب الكثير من الأحداث التي تحدث داخل الكود في PHP.بافيل مورزاكوف ، بادو
كل شيء قياسي معنا: nginx ، PHP-FPM. ما يقرب من 600 خادم مع FPM. إذا كنت تتحدث عن PHP على الإطلاق ، فمن المحتمل أن هناك حوالي 300 خادم إضافي لأغراض مختلفة ، مثل البرنامج النصي والمكتب الخلفي وغيرها.من ميزات التكوين ، هناك نوعان. أولاً ، لدينا وكيل BMA - هذا وكيل للجوال. أي أنه قبل وصول الطلب إلى nginx ، يتم الوصول إلى وكيل خاص يحمل اتصال مستمر ويرسل الطلبات إلى nginx. الميزة الثانية - في بعض الأحيان تحتاج إلى إيقاف تشغيل opcache CLI (لقد قمنا بتشغيل آلات البرمجة النصية). بمجرد عدم إيقاف تشغيله وفقدنا 30 ٪ من وحدة المعالجة المركزية على هذا. بعد أن أدركوا خطأهم ، فوجئوا بقدر ما يمكنك توفيره مع إعداد واحد.لدينا تصحيحات PHP ، لكنها لا تتعلق تقريبًا بالأداء.هناك نقطة مع قفل APCu التنافسي - عندما تحتاج إلى كتابة الكثير إلى نفس المفتاح. تم بناء البنية الداخلية لـ APCu بحيث يكون هناك قفل مفتاح عالمي ، وأثناء التسجيل المكثف ، تبدأ الفرامل. لذلك ، لدينا ملحق مخصص هناك يحل هذه المشكلة. يتعلق هذا جزئياً بالأداء ، لأنه يؤثر على وقت الاستجابة ، ولكن ليس على استهلاك وحدة المعالجة المركزية.سيميون كاتايف ، أفيتو
لدينا حوالي 2 مليون طلب في الدقيقة (~ 33 kRPS). تمت كتابة تطبيق مترابط مكتوب بلغة PHP لأكثر من 11 عامًا. إنه في مرحلة النمو السريع. عندما بدأت الشركة ، كان هناك 65 LXCs على 65 خادمًا فعليًا. في كل حاوية مع التطبيق ، يتم تشغيل PHP-FPM و nginx والبرامج المساعدة للمقاييس وتسجيل الدخول. لا شيء مميز.على مر السنين ، لم نقم أبدًا بإضافة الحديد إلى المونوليث. نحن نعمل على زيادة الحضور ، وعدد الإعلانات ، وعدد معاملات المستخدم ، ونحن نعمل باستمرار على تحسين وتحسين الشفرة وتحسين البرامج. انخفض استهلاك وحدة المعالجة المركزية والذاكرة على مدى السنوات الماضية: 65 حاوية من أجل وحدة متجانسة تكفي الآن بالنسبة لنا.كيف تقيس الأداء؟ ما الأداة التي تقيس وقت استجابة العميل؟
ميخائيل بييلوف ، مامبا
لدينا نظام لجمع السجلات. يسجل مؤشرين - الوقت من بداية FPM إلى وظيفة إيقاف التشغيل وحتى نهاية البرنامج النصي. المقياس الثاني مطلوب لمعرفة ما يحدث بعد وظيفة الإغلاق.نقيس شبيبة. هذا ، في الواقع ، متري للغاية ؛ قنوات الشبكة تنتهك في كثير من الأحيان. ونتيجة لذلك ، فإن التحميل في مكان ما في المناطق النائية الروسية يبدأ في التراجع. لذلك ، نبدو هكذا: "أوه ، قفزت - هذا يعني أن شيئًا ما سقط في مكان ما." بالإضافة إلى إعلانات الجهات الخارجية يشوه إلى حد كبير المقياس. والأهم من ذلك ، يأتي مرسلو البريد العشوائي ، وهذا بشكل عام نوع من العشوائية.سيميون كاتايف ، أفيتو
بالمناسبة ، اعتدنا على استخدام Pinba من Badoo بنشاط كبير . أنا أحبها الآن. تم جمع معظم المقاييس من قبله ، ولكن بعد ذلك تم تحويله إلى بروتوكول StatsD. الآن نأخذ قياسات من نقاط مختلفة: من الأمام ، من الخوادم أمام التطبيق ، من nginx ومن تطبيق PHP نفسه. لدينا فريق أداء مخصص. بدأت بأداء الجبهة ، لكنها تحولت بعد ذلك إلى الدعم. من الأمام ، لا يجمع فقط JS و CSS وإحصائيات أخرى ، ولكن في نفس الوقت أيضًا وقت استجابة الخادم. بادئ ذي بدء ، نحن نركز على وقت استجابة التطبيق.بافيل مورزاكوف ، بادو
كل شيء مشابه لما قاله لنا الرجال. باستخدام Pinba الكلاسيكي لـ PHP ، نقيس وقت تشغيل برنامج PHP النصي من حيث PHP. ولكن لدينا أيضًا ، على سبيل المثال ، Pinba لـ nginx ، والذي يقيس وقت الاستجابة من وجهة نظر nginx. نقوم أيضًا بجمع المقاييس على العميل.إلى ماذا ننظر؟ من ناحية وقت الاستجابة. لا علاقة لها بتخطيط الموارد. إذا كان سيئًا ، فيجب تحسينه ، لأنه في الواقع جودة الخدمة. شيء آخر هو أنك تحتاج إلى تخطيط الحديد بطريقة أو بأخرى. تراقب ITOps وفرق المراقبة جميع الأجهزة. هناك بعض الأشرطة على الشبكة ، على القرص. هناك بعض القيم التي يحدث بعدها التنبيه - ونحن نفعل شيئًا. كما أظهرت الممارسة ، نقوم عادةً بتحسين وحدة المعالجة المركزية: نواجهها.سيميون كاتايف ، أفيتو
علينا تطبيق PHP يقيس نفسه و في register_shutdown_function () يطرح المقاييس. يحتوي كل LXC على خادم StatsD ، الذي يجمع هذه المقاييس ويرسلها عبر جامعي إلى مجموعة الجرافيت (بما في ذلك ClickHouse) ، حيث يتم تخزين البيانات. هذا تشخيص ذاتي.أيضا في كل حاوية nginx ، أي nginx + PHP-FPM. مع nginx ، نجمع المقاييس الخارجية المتعلقة بوقت تشغيل تطبيق PHP. كما أنهم يواجهون خوادم منفصلة (نسميها avi-http) nginx ، والتي تؤدي التوجيه الأساسي ، والتي تجمع أيضًا مقاييس عالية المستوى ، مثل وقت الاستجابة ، وعدد 500 رمز استجابة ، وغيرها.ما الأدوات التي تمتلكها لمسار الأداء؟ ماذا تستخدم في أغلب الأحيان؟
ميخائيل بييلوف ، مامبا
كتبنا أداتنا الخاصة. عندما خرج Pinba للتو - في عام 2012 ، منذ وقت طويل جدًا - كانت وحدة MySQL تتلقى شيئًا كهذا عبر UDP. كان من الصعب إخراج الرسومات ؛ لم يتم تحسينها للأداء. ولم نتوصل إلى أي شيء أفضل من كتابة شيء خاص بنا يسمى Better Than Pinba. إنه مجرد خادم عداد يقبلهم من عميل PHP.قمنا بتناثر الكثير من المؤقتات في الكود: في كل مرة نريد قياس شيء ما ، نقوم بتعيين بداية وإيقاف المؤقت في الكود. ستقوم الوحدة النمطية نفسها بحساب وقت تشغيل العداد ، وتجميع العدادات المتراكمة في حزمة وإرسالها إلى البرنامج الخفي. ستستخرج الواجهة نفسها كل ما تحتاجه وتبني الرسوم البيانية المتصلة على العداد المطلوب.كانت إحدى مشكلات Pinba هي عدم وجود واجهة خاصة بها - كان من الضروري نقل البيانات إلى RRD (ثم كان هناك مثل هذا الظلام). لذلك ، كتبنا الواجهة الخاصة بنا. في كل مرة نرى ما قفز ، يمكننا تثبيت البرنامج النصي. في البرنامج النصي يتم إرسال جميع العدادات المجمعة إلينا ، والتي يتم إرسالها إلينا. يمكننا أن نرى أين نما العداد ، أو زاد وقت الاستجابة عند العداد ، أو زاد عدد العدادات.يمكن رؤيته عندما ينخفض الأداء. بدأنا نحفر بهذه الطريقة. قبل PHP 7 ، استخدمنا XHProf ، ثم توقفنا عن البناء معنا. لذلك ، تحولنا إلى Xdebug. Xdebug نحن كزة فقط عندما تكون المشكلة مرئية.بافيل مورزاكوف ، بادو
هذا اعتقاد شائع بأن XHProf لن يتم بناؤه في PHP 7. هذا صحيح ، ولكن جزئيا فقط. إذا أخذت XHProf من المعالج ، فلن يحدث ذلك. ولكن إذا قمت بالتبديل إلى GitHub إلى فرع يسمى التجريبية (أو شيء من هذا القبيل) ، فإن كل شيء يعمل بشكل جيد لـ PHP 7 ، فإن الإنتاج جاهز. التحقق.ميخائيل بييلوف ، مامبا
لا ، بدلت. لم تنجح معي.بافيل مورزاكوف ، بادو
أريد أن أضيف عن Pinba. لقد أصبحت أنبياء إلى حد ما. نحن أيضًا فقدنا الإنتاجية في مرحلة ما. لقد صنعنا Pinba2 ، وهو سريع جدًا. يمكن استخدامه كبديل عن Pinba.سيميون كاتايف ، أفيتو
كل شيء متواضع معنا. لقد اتخذنا للتو اتجاه الأداء في العمل: نجمع المقاييس ، مثل وقت الاستجابة. نحن نستخدم StatsD. نحن لا نستخدم أي محللين بشكل منتظم حتى الآن ، لكنني أعلم بالتأكيد أن بعض الفرق تستخدمهم في خدماتهم الدقيقة المكتوبة بلغة PHP. في رأيي ، حتى شخص ما ينقل ريليك جديد. ولكن في سياق التطبيق المتآلف الرئيسي ، نحن نقترب حتى الآن من ذلك فقط.بافيل مورزاكوف ، بادو
يتم رصد تاريخ الحديد في جرافانا ، زابيكس. أما بالنسبة لجزء PHP ، فلدينا Pinba ، ولدينا مجموعة من المؤقتات. نحن نبني رسومات مريحة عليهم. نحن نستخدم XHProf ، أثناء الإنتاج ، نوجهه لجزء من الطلبات. لدينا دائمًا ملفات تعريف XHProf جديدة متاحة. لدينا liveprof: هذه هي أداتنا ، يمكنك القراءة عنها ، بما في ذلك في مقالتي . كل ذلك يحدث تلقائيًا ، ما عليك سوى مشاهدته. نستخدم phpspy. لا يبدأ دائمًا معنا: عندما يريد شخص ما رؤية شيء ما ، يدخل السيارة ، ويزيل ملفه الشخصي. من حيث المبدأ ، كما هو الحال مع بيرف.سيميون كاتايف ، أفيتو
XHProf له نفس القصة. لقد استخدمناه ذات مرة منذ وقت طويل: كانت مبادرة شخصية من زوجين من المطورين ، وفي الواقع ، لم تنطلق. توقف عن الجمع. نقوم بجمع مجموعة من المقاييس من مكالمات أجهزة التوجيه ، وحدات التحكم ، النماذج المختلفة. حوالي 60-70٪ من الشبكة الداخلية لمركز البيانات مشغولة بحزم UDP بمقاييس. في الوقت الحالي ، هذا يكفي بالنسبة لنا. الآن سنبحث عن أماكن جديدة للتحسين.منذ أن وصلنا إلى نقطة الحديد: هل يشارك شخص بشكل منهجي في تخطيط السعة في شركتك؟ كيف يتم بناء هذه العملية؟
سيميون كاتايف ، أفيتو
يعمل التطبيق المترابط على الأقل 65 LXC لمدة خمس سنوات على الأقل. نقوم بتحسين الشفرة وتحسينها: فهي تحتوي على موارد كافية. يذهب تخطيط السعة الرئيسية لدينا إلى Kubernetes ، حيث تتم كتابة حوالي 400 خدمة صغيرة أو أكثر في PHP / Go. نحن نقطع قطعًا ببطء من المونوليث ، لكنها لا تزال تنمو. لا يمكننا منعه.بشكل عام ، لغة PHP هي لغة رائعة. ينفذ بسرعة منطق الأعمال.بافيل مورزاكوف ، بادو
بادئ ذي بدء ، ITOps وفرق المراقبة تتأكد من وجود موارد كافية. إذا بدأنا في الاقتراب من قيمة العتبة ، يلاحظ الزملاء ذلك. هم على الأرجح مسؤولون في المقام الأول عن تخطيط القدرات العالمية. يحتوي جزء PHP على مورد وحدة المعالجة المركزية الرئيسي ، لذلك نتبعه بأنفسنا.وضعنا أنفسنا العائق: لا يجب أن "نأكل" أكثر من 60٪ من المجموعة. 60٪ ، وليس 95٪ ، لأننا نستخدم فرط قراءة ، والذي يضغط أيضًا خارج المعالج أكثر مما يمكنك الضغط عليه بدونه. لهذا ، ندفع بحقيقة أنه بعد 50 ٪ من استهلاك وحدة المعالجة المركزية لدينا يمكننا أن ننمو بطريقة لا يمكن التنبؤ بها ، لأن نوى القراءة المفرطة ليست صادقة تمامًا.ميخائيل بييلوف ، مامبا
نقوم بالانتشار ونرى أن شيئًا ما فشل معنا - مثل تخطيط السعة. بالعين! لدينا هامش معين من الإنتاجية يسمح لنا بذلك. نحن نحاول التمسك بها.بالإضافة إلى ذلك ، فإننا نقوم بتحسين ما بعد ذلك. عندما نرى أن شيئًا ما قد سقط ، فإننا نتراجع إذا كان كل شيء سيئًا تمامًا. لكن هذا لا يحدث عمليا.أو نرى فقط "هنا ليس الأمثل ، الآن سنقوم بإصلاح كل شيء بسرعة وسيعمل كل شيء كما ينبغي."نحن لا ننزعج بشكل خاص: إنه صعب للغاية ، ولن يكون العادم كبيرًا جدًا.أنت تتحدث عن الخدمات الصغيرة. كيف يتفاعلون؟ هل هو REST أم أنك تستخدم البروتوكولات الثنائية؟
سيميون كاتايف ، أفيتو
يستخدم كافكا لإرسال الأحداث بين الخدمات ، ويستخدم JSON-RPC لضمان التفاعل بين الخدمات ، ولكن ليس كاملًا ، ولكن نسخته المبسطة ، والتي لا يمكننا التخلص منها. هناك تطبيقات أسرع: نفس protobuf ، gRPC. هذا في خططنا ، لكن بالتأكيد ليس أولوية. مع أكثر من 400 خدمة صغيرة ، من الصعب نقلها جميعًا إلى البروتوكول الجديد. هناك الكثير من الأماكن الأخرى لتحسينها. نحن بالتأكيد لا نصل إليها الآن.بافيل مورزاكوف ، بادو
نحن على هذا النحو ليس لدينا خدمات متناهية الصغر. هناك خدمات ، وهناك أيضًا كافكا ، بروتوكولها الخاص على رأس Google protobuf. ربما ، نستخدم gRPC ، لأنه رائع ، ولديه دعم لجميع اللغات ، والقدرة على ربط قطع مختلفة بسهولة. ولكن عندما احتجنا إليها ، لم يكن gRPC موجودًا بعد. ولكن كان هناك protobuf ، وأخذناها. علاوة على ذلك ، تمت إضافة أشياء مختلفة بحيث لم يكن مجرد تسلسل ، ولكن بروتوكول كامل.ميخائيل بييلوف ، مامبا
كما أننا لا نمتلك خدمات دقيقة. هناك خدمات مكتوبة بشكل أساسي في C. نستخدم JSON-RPC لأنه مناسب. لقد قمت للتو بفتح المقبس عندما تقوم بتصحيح التعليمات البرمجية الخاصة بك ، وكتبت بسرعة ما تريد. شيء ما عاد إليك. Protobuf أكثر صعوبة لأنك تحتاج إلى استخدام بعض الأدوات الإضافية. يوجد مبلغ صغير ، ولكننا نعتقد أنك بحاجة إلى الدفع مقابل الراحة ، وهذا ليس سعرًا كبيرًا.لديك قواعد بيانات ضخمة. عندما تحتاج إلى تغيير الدائرة في أحدها ، كيف تفعل ذلك؟ نوع من الهجرة؟ إذا كانت عمليات الترحيل هذه تستغرق عدة أيام ، فكيف يؤثر ذلك على الأداء؟
ميخائيل بييلوف ، مامبا
لدينا طاولات كبيرة متجانسة. هناك قشرة. يتغير الجزء بسرعة كبيرة ، نظرًا لوجود العديد من التغييرات المتوازية في وقت واحد. تغيرت طاولة كبيرة مع ملفات تعريف حوالي ثلاث ساعات. نحن نستخدم أدوات Perkonovskie التي لا تمتلكها للقراءة والكتابة. بالإضافة إلى ذلك ، نقوم بالتبديل لتغيير الكود بحيث يدعم كلا الحالتين. بعد التعديل ، نقوم أيضًا بنشر: النشر أسرع من تطبيق أي مخططات.بافيل مورزاكوف ، بادو
لدينا أكبر مساحة تخزين (نسميها "بقع") - هذه قاعدة بيانات ضخمة وموزعة. إذا أخذنا جدول "المستخدم" ، فإن لديها الكثير من الأجزاء. لن أخبرك بالضبط عدد الجداول التي ستكون على خادم واحد: الفكرة هي أن هناك العديد من الجداول الصغيرة. عندما نغير الدائرة ، في الواقع ، نقوم بتغيير فقط. على كل طاولة صغيرة ، يحدث ذلك بسرعة. هناك مستودعات أخرى - هناك بالفعل مناهج أخرى. إذا كانت هناك قاعدة ضخمة واحدة ، فهناك أدوات بيركونية.بشكل عام ، نستخدم أشياء مختلفة وفقًا للاحتياجات. التغيير الأكثر شيوعًا هو تغيير في هذه القاعدة الضخمة المسقطة الضخمة ، والتي لدينا بالفعل عملية مبنية. كل شيء يعمل بكل بساطة.سيميون كاتايف ، أفيتو
يتم نشر نفس التطبيق المترابط الذي يخدم معظم حركة المرور خمس إلى ست مرات في اليوم. كل ساعتين تقريبًا.من حيث العمل مع قاعدة البيانات ، هذه مسألة منفصلة. هناك عمليات ترحيل ، تتدحرج تلقائيًا. هذه مراجعة DBA. هناك خيار لتخطي الترحيل واللف يدويًا. سينتقل الترحيل تلقائيًا إلى مراحل عند اختبار الرمز. ولكن عند الإنتاج ، إذا كان هناك نوع من الهجرة المريبة التي تستخدم مجموعة من الموارد ، فسيبدأ DBA ذلك يدويًا.يجب أن تكون التعليمات البرمجية بحيث تعمل مع هياكل قاعدة البيانات القديمة والجديدة. غالبًا ما نقوم برحلات متعددة لنشر الميزات. للحصول على اثنين أو ثلاثة عمليات نشر ، من الممكن الحصول على الحالة المطلوبة. وبالمثل ، هناك قواعد بيانات ضخمة وقواعد بيانات مجزأة. إذا حسبنا جميع الخدمات الدقيقة ، فهناك بالتأكيد 100-150 عملية نشر في اليوم.أود أن أعرف ما هو الوقت القياسي لاستجابة الخلفية الذي تتبعه؟ متى تفهم ما تحتاج إلى تحسينه أكثر ، أو ما هو وقت الانتهاء؟ هل هناك قيمة "متوسط للمستشفى"؟
بافيل مورزاكوف ، بادو
لا. يعتمد على نقطة النهاية. نحن ننظر إلى كل شيء على حدة. محاولة فهم مدى أهمية هذا. تُطلب بعض نقاط النهاية بشكل عام في الخلفية. هذا لا يؤثر على المستخدم بأي شكل من الأشكال ، حتى لو كان وقت الاستجابة 20 ثانية. سيحدث هذا في الخلفية ، لا يوجد فرق. الشيء الرئيسي هو أن يتم القيام ببعض الأشياء الهامة بسرعة. ربما 200 مللي ثانية لا تزال على ما يرام ، ولكن زيادة صغيرة مهمة بالفعل.ميخائيل بييلوف ، مامبا
نحن ننتقل من عرض HTML إلى طلبات API. هنا ، في الواقع ، تستجيب واجهة برمجة التطبيقات بشكل أسرع بكثير من استجابة HTML الكبيرة والثقيلة. لذلك ، من الصعب التمييز ، على سبيل المثال ، قيمة 100 مللي ثانية. ركزنا على 200 مللي ثانية. ثم حدث PHP 7 - وبدأنا في التركيز على 100 مللي ثانية. هذا هو "متوسط المستشفى". هذا مقياس غامض للغاية ، مما يشير إلى أن الوقت قد حان للنظر على الأقل هناك. ولذا فإننا نركز بدلاً من ذلك على النشر وزاد وقت الاستجابة بعده.سيميون كاتايف ، أفيتو
قمنا بعمل رسم تخطيطي لأحد فرق الأداء. قام الزملاء بقياس مقدار ما تكسبه الشركة من خلال تسريع تحميل الصفحة في ظل سيناريوهات مختلفة. حسبنا عدد المشترين والمعاملات والمكالمات والتحويلات وما إلى ذلك. وفقًا لهذه البيانات ، يمكن فهم أنه في مرحلة ما ، يتوقف التسارع عن معنى. على سبيل المثال ، إذا تم تسريع وقت استجابة إحدى الصفحات من 90 مللي ثانية إلى 70 مللي ثانية ، فإن هذا يعطي + 2٪ من المشترين. وإذا قمت بالتسريع من 70 مللي ثانية إلى 60 مللي ثانية ، فهناك بالفعل 0.1٪ من المشترين ، والذي يتم تضمينه بشكل عام في الخطأ. تمامًا كما هو الحال مع الرجال ، يعتمد كل شيء كثيرًا على الصفحة التي نعمل معها. بشكل عام ، Avito 75th المئوية - حوالي 75 مللي ثانية. في رأيي ، هذا بطيء. نحن نبحث الآن عن أماكن لتحسينها. قبل الانتقال إلى الخدمات المصغرة ، حدث كل شيء بشكل أسرع بالنسبة لنا ، ونحن نحاول تحسين الأداء.
والسؤال الأبدي: الحديد أم التحسين؟ كيف نفهم ما إذا كان الأمر يستحق شراء الأجهزة أم أنه من الأفضل الاستثمار في التحسين؟ أين الحدود؟
سيميون كاتايف ، أفيتو
رأيي: مبرمج حقيقي هو التحسين. يبدو لي أنه في الشركات الكبيرة مثل Badoo ، و الألغام ، و Yandex ، هناك العديد من المطورين من مستويات مختلفة. هناك كل من المطورين المبتدئين / المتدربين والمطورين الرائدين. يبدو لي أنه يتم دائمًا إضافة عدد الأماكن للتحسين / المراجعة هناك. الحديد هو الخطوة الأخيرة. لموحد في 65 LXC ، لم نقم بإضافة الحديد لفترة طويلة. استخدام وحدة المعالجة المركزية - 20٪. نحن نفكر بالفعل في نقلها إلى مجموعة Kubernetes.بافيل مورزاكوف ، بادو
أنا حقا أحب موقف Semyon. ولكن لدي وجهة نظر معاكسة تمامًا. بادئ ذي بدء ، أود أن أنظر إلى الحديد. هل من الممكن إسقاط الحديد وهل سيكون أرخص؟ إذا كان الأمر كذلك ، فمن الأسهل حل المشكلة بالحديد. يمكن للمطور أن يفعل شيئًا آخر مفيدًا في هذا الوقت. وقت المطور يكلف المال. يكلف الحديد أيضًا المال ، لذلك تحتاج إلى المقارنة.أيهما أكثر أهمية غير واضح. إذا كان كلاهما يكلفان نفس التكلفة ، فإن الجهاز يفوز ، لأن المطور سيكون قادرًا على القيام بشيء في هذا الوقت. على وجه التحديد ، فيما يتعلق بالواجهة الخلفية لـ PHP ، لا يمكننا القيام بذلك. يكلفنا التحسين أرخص بكثير من شراء الحديد.على وشك التوقف. من حيث التخطيط ، لدينا نوع من البار. إذا قللنا استهلاك وحدة المعالجة المركزية أدناه ، فإننا نتوقف. من ناحية أخرى ، هناك أيضًا جودة الخدمة. إذا رأينا أن وقت الاستجابة لا يناسبنا في مكان ما ، فإننا بحاجة إلى التحسين.ميخائيل بييلوف ، مامبا
يبدو لي أن كل شيء يعتمد على حجم الفريق والمشروع. كلما كان المشروع أصغر ، كان من الأسهل شراء الأجهزة ، لأن راتب المطور ثابت ، والرمز الذي يعمل ، المستخدمون الذين يعملون معه ، مختلفون تمامًا. إذا كان هناك عدد قليل من المستخدمين ، فمن السهل شراء الأجهزة وتكليف المطور بالعمل على تطوير المشروع. إذا كان هناك الكثير من المستخدمين ، فيمكن لمطور واحد تعويض معظم تكلفة الخوادم.سيميون كاتايف ، أفيتو
كل شيء يعتمد حقًا على المقياس. إذا كان لديك آلاف الخوادم ويؤدي التحسين إلى حقيقة أنك لست بحاجة إلى آلاف خوادم أخرى ، فمن الواضح أنه من الأفضل التحسين. إذا كان لديك خادم واحد ، فيمكنك شراء خوادم أو ثلاثة بأمان والحصول على نقاط في التحسين. إذا كان الأمر صغيرًا ، فبدء شراء الخوادم. إذا كان الفريق كبيرًا ولديك مركزان أو ثلاثة مراكز بيانات ، فإن شراء ستة مراكز بيانات ليس رخيصًا بالفعل ، وليس سريعًا جدًا.نظرًا لأن لدينا PHP mitap ، يجب أن تبدو هذه العبارة: لماذا نحتاج إلى PHP ، نظرًا لأن لدينا مثل هذه المشاكل طوال الوقت؟ لنعيد كتابة Go، C، C #، Rust، Node.js!
هل تعتقد أن نهج إعادة الكتابة مبرر بشكل عام؟ هل هناك أي مشاكل للحل يستحق القيام بذلك والاستثمار في هذا الوقت؟
سيميون كاتايف ، أفيتو
بشكل عام ، تعد لغة PHP لغة جيدة جدًا. يسمح لك حقًا بحل مشاكل العمل. إنه سريع بما فيه الكفاية. جميع مشاكل الأداء هي مشاكل الأخطاء ، والأخطاء ، والرمز القديم (بعض الرموز غير المستوفاة ، والأشياء غير المثالية التي يمكن تصويرها بلغة أخرى بنفس الطريقة). من خلال نقلهم إلى الخام في Golang ، Java ، Python ، يمكنك الحصول على نفس الأداء. المشكلة برمتها أن هناك الكثير من الإرث.إن إدخال لغة جديدة ، في رأيي ، أمر منطقي من أجل توسيع المكدس وفرص العمل. الآن من الصعب العثور على مطورين PHP جيدين. إذا أدخلنا Golang في techradar ، فيمكننا استئجار الجوفر. هناك عدد قليل من shniks PHP وقلة من الجعة في السوق ، وهناك بالفعل الكثير منهم. على سبيل المثال ، كان لدينا تجربة واحدة. أخذنا مطوري C # المستعدين لتعلم لغات جديدة - قمنا ببساطة بتوسيع مجموعة التوظيف. إذا أخبرنا الناس أننا سنعلمهم كيفية الكتابة بلغة PHP ، فإنهم يقولون أنه من الأفضل عدم القيام بذلك. وإذا عرضنا عليهم أن يتعلموا الكتابة بلغة PHP ، اذهب وما زلت تعد بفرصة الكتابة بلغة Python ، فسيكون الناس أكثر استعدادًا للرد. بالنسبة لي ، هذا امتداد لفرص العمل. في لغات أخرى ، هناك بعض الأشياء المفقودة في PHP. ولكن بشكل عام ، تعد PHP كافية جدًا لحل مشكلات العمل وتنفيذ المشاريع الكبيرة.بافيل مورزاكوف ، بادو
ربما أتفق تمامًا مع Semyon. إعادة الكتابة فقط لا معنى لها. لغة PHP هي لغة منتجة إلى حد ما. إذا قارنته باللغات الأخرى غير المصنفة والمكتوبة ، فمن المحتمل أن تكون الأسرع تقريبًا. إعادة الكتابة إلى بعض اللغات مثل Go وغيرها؟ هذه لغات أخرى ، لديهم مشاكل أخرى. لا يزال من الصعب الكتابة عليهم: ليس بهذه السرعة وهناك الكثير من الفروق الدقيقة.ومع ذلك ، هناك أشياء صعبة أو غير ملائمة للكتابة في PHP. بعض الأشياء متعددة العمليات والمترابطة من الأفضل أن تكتب بلغة أخرى. مثال على مهمة حيث يتم تبرير عدم استخدام PHP ، من حيث المبدأ ، أي تخزين. إذا كانت هذه خدمة تخزن الكثير من الذاكرة ، فمن المحتمل أن PHP ليست اللغة الأفضل ، لأنها تحتوي على ذاكرة كبيرة جدًا بسبب الكتابة الديناميكية. وتبين أنك تحفظ 4 بايت ، ويتم استهلاك 50 بايت. بالطبع ، أبالغ ، ولكن هذا المبلغ لا يزال كبيرًا جدًا. إذا كان لديك نوع من التخزين ، فمن الأفضل كتابته بلغة مجمعة أخرى مع كتابة ثابتة. تمامًا مثل بعض الأشياء التي تتطلب تنفيذًا متعدد الخيوط.ميخائيل بييلوف ، مامبا
لماذا لا تعتبر PHP سريعة جدًا؟ لأنه ديناميكي. Go translation هو حل لمشكلة ترجمة التعليمات البرمجية من الكتابة الديناميكية إلى ثابتة. ونتيجة لذلك ، كل شيء يحدث بشكل أسرع. على وجه التحديد لـ Go ، في خطتي توجد مهام دفق بيانات محدد. على سبيل المثال ، إذا كان هناك نوع من دفق البيانات يحتاج إلى تحويله إلى تنسيقات أكثر ملاءمة ، فهذا شيء مثالي. يتم رفعه بواسطة برنامج خفي ، يتلقى تدفق بيانات واحد عند الإدخال ، يصدر إصدارًا آخر. يأكل القليل من الذاكرة. تستهلك PHP الكثير من الذاكرة في هذه الحالة: تحتاج إلى التأكد بعناية من تنظيفها.التحويل إلى Go هو نقل إلى الخدمات المصغرة ، لأنك لن تقطع الرمز بالكامل. لن تأخذها وتعيد كتابتها بالكامل. إن الترجمة إلى الخدمات المصغرة هي مهمة أعمق من الترجمة من لغة إلى أخرى. من الضروري حلها أولاً ، ثم التفكير في اللغة التي يجب كتابتها. الجزء الأصعب هو تعلم كيفية تقديم الخدمات الصغيرة.سيميون كاتايف ، أفيتو
ليس من الضروري استخدام Go في الخدمات الدقيقة. تتم كتابة العديد من الخدمات بلغة PHP ولها وقت استجابة مقبول. قرر الفريق الذي يدعمهم بأنفسهم أنهم بحاجة إلى كتابة منطق الأعمال بسرعة كبيرة وتقديم الميزات. في الواقع ، إنهم يفعلون في بعض الأحيان أسرع من الجوف.لدينا ميل لاستئجار غولف ، ترجمة لغو. ولكن لا يزال لدينا معظم الشفرة المكتوبة بلغة PHP ، ولذا سيكون على الأقل لبضع سنوات أخرى. لا يوجد عرق حقيقي ، لم نقرر أن Go أفضل أو أسوأ. يتم طرح ستة إصدارات في المونوليث يوميًا. تحتوي محادثتنا "Avito Deploy" على قائمة بالمهام التي يتم نشرها. يتم طرح ما لا يقل عن 20 مهمة يوميًا في كل إصدار: ما لا يقل عن خمسة أو ستة إصدارات في اليوم ، ما يقرب من 80 مهمة قام بها الأشخاص في هذه المهام. كل هذا يتم في PHP.? -, ?
,
انه صعب جدا. هناك لحظة نفسية: لقد أطلقت ميزة جديدة - لقد انتهيت. أطلقت ميزة جديدة ضخمة - أنت صغير جدًا! عندما يقول مدير أو مطور أنه أزال ميزة (خارج الخدمة) ، فإنه لا يتلقى هذا الاعتراف. عمله غير مرئي. على سبيل المثال ، قد يحصل الفريق على مكافأة للتنفيذ الناجح للميزات الجديدة ، لكنني لم أر أي جوائز عن الوظائف الميتة أو التجريبية. والنتيجة من هذا يمكن أن تكون هائلة حقا.إن مجموعة من الميزات القديمة التي لا يستخدمها أحد بالفعل تؤدي إلى إبطاء عملية التطوير. هناك المئات من الحالات عندما يدخل شخص جديد إلى شركة ويقوم بإعادة بناء رمز ميت لا يتم الاتصال به مطلقًا لأنه لا يعرف أنه رمز ميت.نحن نحاول أن نتفاوض بطريقة أو بأخرى مع المديرين ، ونكتشف من خلال golog نوع الميزة التي كانت عليها ، مع المحللين ننظر في مقدار الأموال التي تجلبها ، ومن يحتاجها ، وبعد ذلك فقط نحاول قطعها. هذه عملية معقدة.ميخائيل بييلوف ، مامبا
نقطع الشفرة الميتة عندما نصل إليها. وليس من الممكن دائمًا قطعها بسرعة. أولاً تكتب رمزًا ، ثم رمزًا آخر ، على رأس الثلث ، ثم تحته كل ذلك يتبين أن هذه الميزة ليست ضرورية. تسحب عددًا كبيرًا من التبعيات ، والتي تحتاج أيضًا إلى الإصلاح. هذا ليس ممكنًا دائمًا ، ويجب على المديرين الإبلاغ عنه.يقوم المدير بتحديد المهمة ، تقوم بتقييمها. تقول: "أتعلم يا رجل ، سأفعل ذلك لمدة ستة أشهر. هل أنت مستعد لتحمل نصف عام؟ " يقول: "لا ، دعنا نفكر في ما يجب قطعه ، وما يمكن تركه. ما هو ضروري جوهريًا وما هو مطلوب للعب ". هكذا تمشي الامور.بافيل مورزاكوف ، بادو
عندما يتلقى المطور ميزة ، فهو يقيّم مدى صعوبة التطوير ، ومدى صعوبة الأداء. إذا رأى ذلك إما أحدهما أو الآخر ، يوضح مع مدير المنتج ما إذا كان ذلك ضروريًا حقًا ، وما إذا كان بإمكاننا إزالة شيء ما في مكان ما. في بعض الأحيان يحدث أن التغييرات ليست حاسمة ، ويقدم المديرون تنازلات بسرعة عندما يكتشفون أن هذا الشيء معقد أو يأكل الموارد. يحدث ذلك فقط: تقول "دعنا نزيلها" - وهذا كل شيء.يحدث أن تغادر ميزة ، وبعد ذلك نلاحظ أنها لن تعمل بشكل جيد كما نود. وبعد ذلك ، مرة أخرى ، يمكنك التحدث مع المدير. غالبًا ما ينتهي كل شيء بنجاح.لا توجد عملية مضمنة لإزالة الميزات. يتم ذلك بشكل متقطع. نرى أن هناك بعض الميزات ، ونأتي ونعرض إيقاف تشغيله. نطفئه ، ونراقب ما يعطيه ، ونقطعه. شيء آخر هو رمز ميت. لدينا امتداد خاص ، حتى بنية تحتية كاملة ، لاكتشاف الكود الميت. نرى هذا الرمز الميت. نحن نحاول قطعها ببطء. سؤال آخر هو ما إذا كان ميتًا حقًا ولم يدخله الطلب أبدًا ، فلن يؤثر على الأداء بأي شكل من الأشكال. يؤثر على الدعم. يقرأه الناس باستمرار ، على الرغم من أنهم قد لا يقرؤونه. لا يوجد اتصال خاص بالأداء.15 Badoo PHP Meetup. , : SuperJob, ManyChat, , Badoo FunCorp .
, , YouTube-. , - .
, .
Source: https://habr.com/ru/post/undefined/
All Articles