Get best of the week

Besi atau optimasi? Badoo, Avito dan Mamba - tentang kinerja PHP

Masalah kinerja PHP untuk Badoo adalah salah satu yang paling penting. Kualitas PHP backend secara langsung tergantung pada jumlah sumber daya yang kami habiskan untuk pengembangan dan operasi, kecepatan layanan dan kesan yang dibuat pada pengguna.

Oleh karena itu, topik pertemuan ketiga komunitas pengembang PHP di kantor kami, kami membuat kinerja backend dan mengundang kolega dari Avito dan Mamba untuk berdiskusi.



Baca di bawah transkrip cutscene diskusi, di mana saya beruntung menjadi moderator: bagaimana infrastruktur dari tiga perusahaan diatur, bagaimana kita mengukur produktivitas dan metrik apa yang kita fokuskan, alat apa yang kita gunakan, bagaimana kita membuat pilihan antara perangkat keras dan optimisasi.

Dan pada 15 Februari, datanglah ke Pertemuan PHP Badoo berikutnya : diskusikan Legacy.



Kami telah menguraikan hanya bagian dari diskusi, yang menurut kami paling menarik. Versi lengkap tersedia di video.

Pakar:

  • Semyon Kataev, Kepala Unit Pengembangan di Core Services Avito
  • Pavel Murzakov pmurzakov, PHP Timlid di Badoo
  • Mikhail Buylov mipxtx, Direktur IT dari Mamba


Ceritakan kisah tentang pengoptimalan dari latihan Anda: kesuksesan besar atau kegagalan besar adalah sesuatu yang menarik untuk dibagikan.

Mikhail Buylov, Mamba


Saya punya perumpamaan.

Sekitar enam bulan sekali kami melihat metrik dan mencari apa yang melambat, tidak berfungsi dengan baik, apa yang perlu dioptimalkan. Suatu ketika kami memperhatikan wadah ketergantungan symfony kami, yang tumbuh hingga 52.000 baris. Kami memutuskan bahwa dia, si bajingan, yang harus disalahkan atas segalanya: 20 ms overhead untuk setiap permintaan. Kami melihatnya. Kami menguranginya. Kami entah bagaimana mencoba memisahkannya, tetapi tidak ada yang membantu.

Dan kemudian ternyata kami memiliki anti-spam yang perlu masuk ke 20 database untuk memenuhi semua permintaan yang diperlukan.

Solusi yang didahulukan tidak selalu yang tepat. Terlihat lebih baik pada jejak, log, dan tolok ukur permintaan Anda, dan jangan putus secara langsung. Ini adalah sebuah cerita.

Pavel Murzakov, Badoo


Kami memiliki ekosistem yang cukup besar di PHP, jadi kami melakukan optimasi secara berkala. Kami berkembang, kami mencapai level CPU, kami memahami bahwa kami perlu membeli perangkat keras atau mengoptimalkan. Timbang argumen untuk dan terhadap setiap opsi dan putuskan. Paling sering - mendukung optimasi, karena besi membutuhkan banyak.

Pada salah satu poin ini, kami mengidentifikasi seluruh kelompok yang terlibat dalam mencari berbagai hal yang tidak optimal dalam skrip PHP dan mengoptimalkannya. Ini terjadi secara harfiah “setetes demi setetes”: di sini mereka menemukan persentase, di sana mereka menemukan persentase - beberapa orang menemukan persentase dalam sebulan. Pada titik tertentu, sishnik kami ada di dekatnyaeinstein_man. Dia memutuskan untuk melihat apa yang bisa dia lakukan: dia pergi di malam hari, meluncurkan Perf, menemukan beberapa masalah dalam ekstensi PHP - dan mempercepat semuanya dalam beberapa malam sebesar 13%!

Semyon Kataev, Avito


Saya punya dua cerita. Satu tentang file, yang lain tentang super developer.

Tentang Gagal. Kami memiliki banyak layanan Microsoft, termasuk PHP. Semua orang bekerja di Kubernetes. Saya mengerjakan salah satu dari layanan microser ini. Ada pemanfaatan CPU yang signifikan: mereka menghabiskan satu minggu untuk mengoptimalkan dan menemukan masalah. Ternyata salah satu pengembang menambahkan Xdebug ke gambar dasar untuk menghitung tes cakupan kode dalam layanan (lainnya), setelah semua layanan mikron dalam produksi bekerja dengan Xdebug selama seperempat! Setelah seperempat, kami menemukan ini, memperbaiki gambar dasar - dan mulai menangkap hadiah tak terduga: Saya memutar ulang layanan saya, dan mulai bekerja lebih cepat. Di setiap penyebaran, gambar layanan kami dibangun kembali, dan sekarang tanpa Xdebug.

Sejarah kesuksesan. Kami memiliki banyak layanan microser, dan mereka menjadi semakin banyak. Dalam situasi ini, jumlah panggilan RPC menjadi masalah. Misalnya, pada kartu pengumuman - dan ini adalah salah satu halaman yang paling sering di Avito - sekitar 30 layanan mikro terlibat dalam merender halaman. Selain itu, semua ini tidak dilakukan dengan sangat eksplisit: sepertinya Anda memanggil semacam abstraksi, dan di bawahnya lima panggilan RPC ke layanan lain dilakukan secara berurutan.

Selama bertahun-tahun, kartu pengumuman telah sangat terdegradasi. Satu pengembang kuat berjuang selama seperempat, dioptimalkan, dan mengeluarkan semua panggilan RPC. Ketika dia bisa melakukan ini, dia memparalelkannya melalui Guzzle multi permintaan - dan bukannya 30 permintaan sinkron berturut-turut, dia menerima 30 permintaan yang sama, tetapi yang paralel, yang sangat mempercepat pekerjaan. Setelah refactoring ini, waktu respons kartu sama dengan waktu respons maksimum dari salah satu layanan. Tetapi dia membutuhkan seperempat penuh untuk mengoptimalkan / menulis ulang kode tampilan kartu pengumuman.

Beri tahu kami, berapa ukuran cluster PHP Anda, bagaimana cara mengonfigurasinya - setidaknya PHP-FPM, atau mungkin di suatu tempat Apache mendapat masalah?

Mikhail Buylov, Mamba


Kami memiliki sekitar 15.000 RPS. Sekelompok 80 server FPM dibeli beberapa tahun yang lalu. Pada setiap cluster, FPM (maksimum 50 anak) diluncurkan ke statika. Ini memuat sekitar sepuluh pada puncaknya di prime time. Waktu respons rata-rata adalah 100 ms, dan kami mencoba menahannya (ketika melebihi 100 ms, kami mulai mencari bagian pengereman).

Kami memiliki sistem pemantauan kinerja kami sendiri. Kami menyebarkan banyak penghitung dalam kode, sekitar 120 per permintaan. Kami memantau banyak peristiwa yang terjadi di dalam kode di PHP.

Pavel Murzakov, Badoo


Semuanya standar dengan kami: nginx, PHP-FPM. Sekitar 600 server dengan FPM. Jika berbicara tentang PHP sama sekali, maka, mungkin, ada sekitar 300 server lagi untuk berbagai keperluan, seperti skrip, back-office dan lainnya.

Dari fitur konfigurasi, ada dua. Pertama, kami memiliki proxy BMA - ini adalah proxy untuk seluler. Yaitu, sebelum permintaan tiba di nginx, itu akan sampai ke proxy khusus yang memegang koneksi persisten dan mengirimkan permintaan ke nginx. Fitur kedua - kadang-kadang Anda harus mematikan opcache CLI (kami telah menghidupkan mesin scripting). Setelah kami tidak mematikannya dan kehilangan 30% dari CPU pada ini. Setelah mereka menyadari kesalahan mereka, mereka terkejut betapa Anda dapat menghemat dengan satu pengaturan.

Kami memiliki tambalan PHP, tetapi hampir tidak terkait dengan kinerja.

Ada satu poin dengan kunci APCu yang kompetitif - ketika Anda perlu banyak menulis ke kunci yang sama. Arsitektur internal APCu dibangun sedemikian rupa sehingga ada kunci kunci global, dan selama perekaman intensif, rem dimulai. Karenanya, kami memiliki ekstensi khusus di sana yang menyelesaikan masalah ini. Ini hanya sebagian berhubungan dengan kinerja, karena ini mempengaruhi waktu respons, tetapi bukan konsumsi CPU.

Semyon Kataev, Avito


Kami memiliki sekitar 2 juta permintaan per menit (~ 33 kRPS). Aplikasi monolitik yang ditulis dalam PHP telah ditulis selama lebih dari 11 tahun. Ia berada dalam fase pertumbuhan yang cepat. Ketika perusahaan mulai, ada 65 LXC di 65 server fisik. Pada setiap wadah dengan aplikasi, PHP-FPM, nginx dan perangkat lunak tambahan untuk metrik dan pencatatan sedang berjalan. Tidak ada yang spesial.

Selama bertahun-tahun, kami tidak pernah menambahkan zat besi untuk monolit. Kami meningkatkan kehadiran, jumlah iklan, jumlah transaksi pengguna, dan kami terus mengoptimalkan, meningkatkan kode, mengoptimalkan perangkat lunak. Konsumsi CPU dan memori telah menurun selama beberapa tahun terakhir: 65 kontainer untuk monolit sekarang cukup untuk kita.

Bagaimana Anda mengukur kinerja? Alat apa yang Anda ukur waktu respons klien?

Mikhail Buylov, Mamba


Kami memiliki sistem pengumpulan log. Log dua indikator - waktu dari awal FPM ke fungsi shutdown dan sampai akhir skrip. Metrik kedua diperlukan untuk melihat apa yang terjadi setelah fungsi shutdown.

Kami mengukur JS. Ini, sebenarnya, adalah metrik biasa-biasa saja, saluran jaringan sangat sering dilanggar. Akibatnya, memuat di suatu tempat di pedalaman Rusia mulai tumpul. Oleh karena itu, kita terlihat seperti ini: "Oh, melompat - itu berarti ada sesuatu yang jatuh." Ditambah iklan pihak ketiga sangat menyimpangkan metrik. Dan, yang paling penting, spammer datang, dan ini umumnya semacam keacakan.

Semyon Kataev, Avito


Omong-omong, kami dulu menggunakan Pinba dari Badoo dengan sangat aktif . Saya suka dia sekarang. Sebagian besar metrik dikumpulkan olehnya, tetapi kemudian beralih ke protokol StatsD. Sekarang kami melakukan pengukuran dari berbagai titik: dari depan, dari server di depan aplikasi, dari nginx dan dari aplikasi PHP itu sendiri. Kami memiliki tim kinerja yang berdedikasi. Dia mulai dengan kinerja bagian depan, tetapi kemudian beralih ke dukungan. Dari depan, ia mengumpulkan tidak hanya JS, CSS, dan statika lainnya, tetapi pada saat yang sama juga waktu respons server. Pertama-tama, kami fokus pada waktu respons aplikasi.

Pavel Murzakov, Badoo


Semuanya mirip dengan apa yang orang-orang katakan kepada kami. Menggunakan Pinba klasik untuk PHP, kami mengukur waktu berjalan skrip PHP dalam hal PHP. Tetapi kami juga memiliki, misalnya, Pinba untuk nginx, yang mengukur waktu respons dari sudut pandang nginx. Kami juga mengumpulkan metrik pada klien.

Apa yang kita lihat? Di satu sisi, waktu respons. Ini tidak terkait dengan perencanaan sumber daya. Jika buruk, perlu ditingkatkan, karena pada kenyataannya, kualitas layanan. Hal lain adalah Anda harus merencanakan setrika dengan cara apa pun. ITOps dan tim pemantau kami memantau semua perangkat keras. Ada beberapa bar di jaringan, di disk. Ada beberapa nilai setelah peringatan terjadi - dan kami melakukan sesuatu. Seperti yang telah ditunjukkan oleh praktik, kami biasanya mengoptimalkan CPU: kami menabraknya.

Semyon Kataev, Avito


Pada kami aplikasi PHP mengukur dirinya sendiri dan di register_shutdown_function () membuang metrik. Setiap LXC memiliki server StatsD, yang mengumpulkan metrik ini dan mengirimkannya melalui kolektor ke cluster Graphite (termasuk ClickHouse), tempat data disimpan. Ini adalah diagnosa diri.

Juga di setiap wadah adalah nginx, mis. Nginx + PHP-FPM. Dengan nginx, kami mengumpulkan metrik eksternal yang terkait dengan waktu berjalan aplikasi PHP. Mereka juga menghadapi server terpisah (kami menyebutnya avi-http) nginx, yang melakukan perutean dasar, yang juga mengumpulkan metrik tingkat yang lebih tinggi, seperti waktu respons, jumlah 500 kode respons, dan lainnya.

Alat apa yang Anda miliki untuk trek kinerja? Apa yang paling sering Anda gunakan?

Mikhail Buylov, Mamba


Kami menulis alat kami sendiri. Ketika Pinba baru saja keluar - pada tahun 2012, waktu yang sangat lama - itu adalah modul untuk MySQL yang menerima sesuatu seperti ini di atas UDP. Sulit untuk mengeluarkan grafis, itu tidak sangat dioptimalkan untuk kinerja. Dan kami tidak menghasilkan sesuatu yang lebih baik daripada menulis hal kami sendiri yang disebut Better Than Pinba. Ini hanya server penghitung yang menerimanya dari klien PHP.

Kami menyebarkan banyak penghitung waktu dalam kode: setiap kali kami ingin mengukur sesuatu, kami mengatur waktu mulai dan berhenti penghitung waktu dalam kode. Modul itu sendiri akan menghitung runtime penghitung, mengagregasikan penghitung yang terakumulasi ke dalam suatu paket, dan mengirimkannya ke daemon. Antarmuka itu sendiri akan mengekstrak semua yang Anda butuhkan dan membangun grafik yang terhubung di penghitung yang diinginkan.

Salah satu masalah Pinba adalah kurangnya antarmuka sendiri - itu perlu untuk mentransfer data ke RRD (kemudian ada kegelapan). Oleh karena itu, kami menulis antarmuka kami sendiri. Setiap kali kita melihat apa yang melompat, kita dapat menginstal skrip. Dalam skrip semua konter agregat dikirim kepada kami, yang dikirimkan kepada kami. Kita dapat melihat di mana penghitung telah tumbuh, atau waktu respons di penghitung telah meningkat, atau jumlah penghitung telah meningkat.

Itu bisa dilihat saat kinerja turun. Kami mulai menggali dengan cara ini. Sebelum PHP 7, kami menggunakan XHProf, lalu berhenti membangun bersama kami. Karena itu, kami beralih ke Xdebug. Xdebug kami menyodok hanya ketika masalah terlihat.

Pavel Murzakov, Badoo


Ini adalah kepercayaan umum bahwa XHProf tidak akan dibangun di PHP 7. Ini benar, tetapi hanya sebagian. Jika Anda mengambil XHProf dari wizard, itu tidak akan terjadi. Tetapi jika pada GitHub Anda beralih ke cabang yang disebut Eksperimental (atau sesuatu seperti itu), maka semuanya berfungsi dengan baik untuk PHP 7, siap produksi. Diperiksa

Mikhail Buylov, Mamba


Tidak, saya beralih. Itu tidak berhasil untuk saya.

Pavel Murzakov, Badoo


Saya ingin menambahkan tentang Pinba. Anda telah menjadi nabi sampai batas tertentu. Kami juga, pada beberapa titik kehilangan produktivitas. Kami membuat Pinba2 , yang sangat cepat. Ini dapat digunakan sebagai pengganti Pinba.

Semyon Kataev, Avito


Semuanya sederhana dengan kita. Kami hanya mengambil arahan kinerja ke dalam pekerjaan: kami mengumpulkan metrik, seperti waktu respons. Kami menggunakan StatsD. Kami belum menggunakan profiler apa pun secara teratur, tetapi saya tahu pasti bahwa beberapa tim menggunakannya dalam layanan Microsoft yang ditulis dalam PHP. Menurut pendapat saya, bahkan seseorang relik New Relic. Namun dalam konteks aplikasi monolitik utama, sejauh ini kami hanya mendekati ini.

Pavel Murzakov, Badoo


Sejarah besi dipantau di Grafana, Zabbix. Adapun bagian PHP, kami memiliki Pinba, kami memiliki banyak timer; Kami membangun grafik yang nyaman di atasnya. Kami menggunakan XHProf, pada produksi kami mengendarainya untuk sebagian permintaan. Kami selalu memiliki profil XHProf baru. Kami memiliki liveprof: ini adalah alat kami, Anda dapat membacanya, termasuk di artikel saya . Itu semua terjadi secara otomatis, Anda hanya perlu menonton. Kami menggunakan phpspy. Itu tidak selalu dimulai dengan kita: ketika seseorang ingin melihat sesuatu, dia memasuki mobil, melepas profilnya. Pada prinsipnya, seperti halnya dengan Perf.

Semyon Kataev, Avito


XHProf memiliki cerita yang sama. Kami pernah menggunakannya sejak lama: itu adalah inisiatif pribadi dari beberapa pengembang, dan, pada kenyataannya, tidak lepas landas. Dia berhenti mengumpulkan. Kami mengumpulkan banyak metrik dari panggilan router, pengontrol, berbagai model. Sekitar 60–70% dari jaringan internal pusat data ditempati oleh paket-paket UDP dengan metrik. Saat ini, ini sudah cukup bagi kami. Sekarang kita akan mencari tempat baru untuk optimasi.

Karena kita telah mencapai titik puncak: apakah seseorang secara sistematis terlibat dalam perencanaan kapasitas di perusahaan Anda? Bagaimana proses ini dibangun?

Semyon Kataev, Avito


Aplikasi monolitik berjalan setidaknya 65 LXC selama setidaknya lima tahun. Kami mengoptimalkan kode, memperbaikinya: ia memiliki sumber daya yang cukup. Perencanaan kapasitas utama kami berlaku untuk Kubernetes, di mana sekitar 400 lebih atau kurang layanan mikro ditulis dalam PHP / Go. Kami perlahan-lahan memotong potongan-potongan dari monolith, tetapi masih terus tumbuh. Kita tidak bisa menghentikannya.

Secara umum, PHP adalah bahasa yang keren. Dengan cepat mengimplementasikan logika bisnis.

Pavel Murzakov, Badoo


Pertama-tama, ITOps dan tim pemantau memastikan bahwa ada sumber daya yang cukup. Jika kita mulai mendekati nilai ambang, kolega memperhatikan ini. Mereka mungkin terutama bertanggung jawab atas perencanaan kapasitas global. Bagian PHP memiliki sumber daya CPU utama, jadi kami ikuti sendiri.

Kita mengatur sendiri bar: kita tidak boleh "makan" lebih dari 60% dari cluster. 60%, dan bukan 95%, karena kami mengalami hipertensi, yang juga memeras lebih banyak dari prosesor daripada yang dapat Anda hilangkan tanpa itu. Untuk ini, kami membayar dengan fakta bahwa setelah 50% dari konsumsi CPU kami, kami dapat tumbuh dengan cara yang tidak terduga, karena kernel hyper -reading tidak sepenuhnya jujur.

Mikhail Buylov, Mamba


Kami melakukan penyebaran dan melihat ada sesuatu yang gagal dengan kami - perencanaan kapasitas seperti itu. Dengan mata! Kami memiliki margin produktivitas tertentu yang memungkinkan kami melakukan ini. Kami mencoba untuk tetap berpegang pada itu.

Selain itu, kami melakukan optimasi post factum. Ketika kita melihat sesuatu telah jatuh, kita mundur jika semuanya benar-benar buruk. Tapi ini praktis tidak terjadi.

Atau kita hanya melihat bahwa "di sini tidak optimal, sekarang kita akan segera memperbaiki semuanya dan semuanya akan berfungsi sebagaimana mestinya."

Kami tidak terlalu peduli: sangat sulit, dan knalpotnya tidak akan terlalu besar.

Anda berbicara tentang layanan mikro. Bagaimana mereka berinteraksi? Apakah ini ISTIRAHAT atau Anda menggunakan protokol biner?

Semyon Kataev, Avito


Kafka digunakan untuk mengirim acara antar layanan, JSON-RPC digunakan untuk memastikan interaksi antar layanan, tetapi tidak lengkap, tetapi versi yang disederhanakan, yang tidak dapat kita singkirkan. Ada implementasi yang lebih cepat: protobuf yang sama, gRPC. Ini ada dalam rencana kami, tetapi tentu saja bukan prioritas. Dengan lebih dari 400 layanan mikro, sulit untuk memindahkan semuanya ke protokol baru. Ada banyak tempat lain untuk dioptimalkan. Kami jelas tidak sanggup melakukannya sekarang.

Pavel Murzakov, Badoo


Kami dengan demikian tidak memiliki layanan microser. Ada layanan, ada juga Kafka, protokolnya sendiri di atas protobuf Google. Mungkin, kita akan menggunakan gRPC, karena itu keren, ia memiliki dukungan untuk semua bahasa, kemampuan untuk dengan mudah mengikat bagian yang berbeda. Tetapi ketika kami membutuhkannya, gRPC belum ada di sana. Tapi ada protobuf, dan kami mengambilnya. Di atas itu, hal-hal yang berbeda ditambahkan sehingga bukan hanya serialisasi, tetapi protokol lengkap.

Mikhail Buylov, Mamba


Kami juga tidak memiliki layanan microser. Ada sebagian besar layanan yang ditulis dalam C. Kami menggunakan JSON-RPC karena nyaman. Anda baru saja membuka soket ketika Anda men-debug kode Anda, dan dengan cepat menulis apa yang Anda inginkan. Sesuatu telah kembali padamu. Protobuf lebih sulit karena Anda perlu menggunakan beberapa alat tambahan. Ada overhead kecil, tapi kami percaya Anda perlu membayar untuk kenyamanan, dan ini bukan harga yang besar.

Anda memiliki basis data yang sangat besar. Ketika Anda perlu mengubah sirkuit di salah satu dari mereka, bagaimana Anda melakukannya? Semacam migrasi? Jika migrasi ini memakan waktu beberapa hari, bagaimana ini mempengaruhi kinerja?

Mikhail Buylov, Mamba


Kami memiliki meja besar, monolitik. Ada beling. Shard berubah cukup cepat, karena ada banyak perubahan paralel sekaligus. Meja besar dengan profil diubah sekitar tiga jam. Kami menggunakan alat Perkonovskie yang tidak membuatnya membaca dan menulis. Selain itu, kami menerapkan untuk mengubah sehingga kode mendukung kedua negara. Setelah perubahan, kami juga menggunakan: penerapan lebih cepat daripada menerapkan skema apa pun.

Pavel Murzakov, Badoo


Kami memiliki penyimpanan terbesar (kami menyebutnya "tempat") - ini adalah basis data yang sangat luas. Jika kita mengambil tabel “Pengguna”, maka dia memiliki banyak pecahan. Saya tidak akan memberi tahu Anda dengan tepat berapa banyak tabel di satu server: idenya adalah ada banyak tabel kecil. Ketika kita mengubah sirkuit, sebenarnya, kita hanya melakukan perubahan. Di setiap meja kecil, itu terjadi dengan cepat. Ada repositori lain - sudah ada pendekatan lain. Jika ada satu basis besar, ada alat Perconian.

Secara umum, kami menggunakan berbagai hal sesuai dengan kebutuhan. Perubahan yang paling sering adalah perubahan basis tempat yang sangat luas ini, di mana kami sudah memiliki proses yang dibangun. Semuanya bekerja sangat sederhana.

Semyon Kataev, Avito


Aplikasi monolitik yang sama yang melayani sebagian besar lalu lintas digunakan lima hingga enam kali sehari. Hampir setiap dua jam.

Dalam hal bekerja dengan database, ini merupakan masalah yang terpisah. Ada migrasi, mereka bergulir secara otomatis. Ini adalah ulasan DBA. Ada opsi untuk melewati migrasi dan memutar secara manual. Migrasi akan secara otomatis beralih ke pementasan saat menguji kode. Tetapi pada produksi, jika ada semacam migrasi meragukan yang menggunakan banyak sumber daya, maka DBA akan memulainya secara manual.

Kode harus sedemikian rupa sehingga berfungsi dengan struktur database lama dan baru. Kami sering melakukan beberapa perjalanan untuk menggunakan fitur. Untuk dua atau tiga peluncuran, dimungkinkan untuk mendapatkan status yang diinginkan. Demikian juga, ada database yang sangat besar, basis data yang terbengkalai. Jika kami menghitung untuk semua layanan microser, maka pasti ada 100-150 penyebaran per hari.

Saya ingin tahu berapa waktu respons backend standar untuk Anda yang Anda ikuti? Kapan Anda memahami apa yang perlu Anda optimalkan lebih lanjut, atau berapa waktu untuk menyelesaikannya? Apakah ada nilai "rata-rata rumah sakit"?

Pavel Murzakov, Badoo


Tidak. Tergantung pada titik akhir. Kami melihat semuanya secara terpisah. Mencoba memahami betapa pentingnya hal ini. Beberapa titik akhir umumnya diminta di latar belakang. Ini tidak mempengaruhi pengguna dengan cara apa pun, bahkan jika waktu responsnya adalah 20 detik. Ini akan terjadi di latar belakang, tidak ada perbedaan. Hal utama adalah bahwa beberapa hal penting dilakukan dengan cepat. Mungkin 200 ms masih ok, tetapi peningkatan kecil sudah penting.

Mikhail Buylov, Mamba


Kami beralih dari rendering HTML ke permintaan API. Faktanya, API merespons jauh lebih cepat daripada respons HTML besar dan berat. Oleh karena itu, sulit untuk membedakan, misalnya, nilai 100 ms. Kami fokus pada 200 ms. Kemudian terjadi PHP 7 - dan kami mulai fokus pada 100 ms. Ini adalah "rata-rata untuk rumah sakit." Ini adalah metrik yang sangat kabur, yang menunjukkan bahwa inilah saatnya untuk setidaknya melihat ke sana. Jadi kami lebih fokus pada penyebaran dan melompati waktu respons setelahnya.

Semyon Kataev, Avito


Kami membuat sketsa dari salah satu tim pertunjukan. Kolega mengukur seberapa banyak penghasilan yang diperoleh perusahaan dengan mempercepat pemuatan halaman di bawah berbagai skenario. Kami menghitung berapa banyak lagi pembeli, transaksi, panggilan, transisi, dan seterusnya. Menurut data ini, dapat dipahami bahwa pada titik tertentu, akselerasi tidak lagi masuk akal. Misalnya, jika waktu respons salah satu halaman dari 90 ms dipercepat menjadi 70 ms, ini memberi + 2% pembeli. Dan jika Anda mempercepat dari 70 ms ke 60 ms, maka sudah ada ditambah 0,1% dari pembeli, yang umumnya termasuk dalam kesalahan. Sama seperti dengan teman-teman, semuanya sangat tergantung pada halaman yang sedang kami kerjakan. Secara umum, Avito 75 persentil - sekitar 75 ms. Menurut saya, ini lambat. Kami sekarang mencari tempat untuk mengoptimalkan. Sebelum transisi ke layanan mikro, semuanya terjadi jauh lebih cepat bagi kami, dan kami berusaha untuk mengoptimalkan kinerja.



Dan pertanyaan abadi: besi atau optimasi? Bagaimana memahami apakah layak membeli perangkat keras atau lebih baik berinvestasi dalam optimasi? Dimana perbatasannya?

Semyon Kataev, Avito


Pendapat saya: seorang programmer sebenarnya adalah optimasi. Sepertinya saya bahwa di perusahaan besar seperti Badoo, tambang, Yandex, ada banyak pengembang dari berbagai tingkatan. Ada pengembang junior / magang dan pengembang terkemuka. Sepertinya saya bahwa jumlah tempat untuk optimasi / revisi selalu ditambahkan di sana. Besi adalah langkah terakhir. Untuk monolit pada 65 LXC, kami belum menambahkan zat besi untuk waktu yang sangat lama. Pemanfaatan CPU - 20%. Kami sudah berpikir untuk mentransfernya ke kluster Kubernetes.

Pavel Murzakov, Badoo


Saya sangat suka posisi Semyon. Tetapi saya memiliki sudut pandang yang sangat berlawanan. Pertama-tama, saya akan melihat besi. Apakah mungkin untuk menjatuhkan zat besi dan apakah akan lebih murah? Jika demikian, maka lebih mudah untuk menyelesaikan masalah dengan setrika. Pengembang dapat melakukan hal lain, berguna saat ini. Waktu pengembang membutuhkan uang. Zat besi juga membutuhkan biaya, jadi Anda harus membandingkan.

Yang mana dari ini yang lebih penting tidak jelas. Jika keduanya sama biayanya, maka perangkat kerasnya menang, karena pengembang akan dapat melakukan sesuatu saat ini. Khususnya, dalam hal PHP backend, kami tidak dapat melakukan ini. Optimalisasi harganya jauh lebih murah daripada membeli besi.

Akan berhenti. Dalam hal perencanaan, kami memiliki beberapa jenis bar. Jika kita mengurangi konsumsi CPU di bawahnya, maka kita berhenti. Di sisi lain, ada juga kualitas layanan. Jika kita melihat bahwa waktu respons tidak cocok untuk kita di suatu tempat, maka kita perlu mengoptimalkan.

Mikhail Buylov, Mamba


Menurut saya, semuanya tergantung pada ukuran tim dan proyek. Semakin kecil proyek, semakin mudah untuk membeli perangkat keras, karena gaji pengembang konstan, dan kode yang berfungsi, pengguna yang bekerja dengannya, sangat berbeda. Jika ada beberapa pengguna, maka lebih mudah untuk membeli perangkat keras dan mempercayakan pekerjaan kepada pengembang untuk mengembangkan proyek. Jika ada banyak pengguna, maka satu pengembang dapat mengkompensasi sebagian besar biaya server.

Semyon Kataev, Avito


Semuanya sangat tergantung pada skalanya. Jika Anda memiliki seribu server dan optimasi mengarah pada fakta bahwa Anda tidak memerlukan seribu server lain, maka jelas lebih baik untuk mengoptimalkan. Jika Anda memiliki satu server, maka Anda dapat dengan aman membeli dua atau tiga server lagi dan menilai pengoptimalan. Jika perintah kecil, maka mulai server dibeli. Jika tim besar dan Anda memiliki dua atau tiga pusat data, maka membeli enam pusat data sudah tidak begitu murah, tidak terlalu cepat.

Karena kita memiliki mitap PHP, frasa ini harus berbunyi: mengapa kita membutuhkan PHP, karena kita memiliki masalah seperti itu sepanjang waktu? Mari kita menulis ulang Go, C, C #, Rust, Node.js!
Apakah menurut Anda pendekatan penulisan ulang secara umum dapat dibenarkan? Apakah ada masalah untuk solusi yang layak dilakukan dan investasi saat ini?

Semyon Kataev, Avito


Secara umum, PHP adalah bahasa yang sangat baik. Ini benar-benar memungkinkan Anda untuk memecahkan masalah bisnis. Dia cukup cepat. Semua masalah kinerja adalah masalah kesalahan, bug, kode lawas (semacam kode yang kurang mahal, hal-hal yang tidak optimal yang akan ditembak dalam bahasa lain dengan cara yang sama). Dengan porting mereka mentah ke Golang, Java, Python, Anda mendapatkan kinerja yang sama. Seluruh masalah adalah bahwa ada banyak warisan.

Memperkenalkan bahasa baru, menurut saya, masuk akal untuk memperluas tumpukan dan peluang kerja. Sekarang cukup sulit untuk menemukan pengembang PHP yang bagus. Jika kami memperkenalkan Golang ke dalam techradar, maka kami dapat merekrut gophers. Ada beberapa shnik PHP dan sedikit akan menghubungkan di pasar, dan bersama-sama sudah ada banyak dari mereka. Misalnya, kami memiliki satu percobaan. Kami mengambil pengembang C # yang siap untuk belajar bahasa baru - kami hanya memperluas tumpukan perekrutan. Jika kami memberi tahu orang-orang bahwa kami akan mengajari mereka cara menulis dalam PHP, mereka mengatakan bahwa lebih baik tidak melakukannya. Dan jika kami menawarkan mereka untuk belajar menulis dalam PHP, Pergi dan masih menjanjikan kesempatan untuk menulis dengan Python, maka orang-orang lebih bersedia untuk merespons. Bagi saya, ini merupakan perpanjangan dari peluang kerja. Dalam bahasa lain, ada beberapa hal yang benar-benar hilang di PHP. Namun secara umum, PHP sangat memadai untuk menyelesaikan masalah bisnis dan mengimplementasikan proyek-proyek besar.

Pavel Murzakov, Badoo


Saya mungkin sepenuhnya setuju dengan Semyon. Menulis ulang tidak masuk akal. PHP adalah bahasa yang cukup produktif. Jika Anda membandingkannya dengan bahasa non-kompilasi skrip lain, maka itu mungkin akan menjadi yang tercepat. Menulis ulang ke dalam beberapa bahasa seperti Go dan lainnya? Ini adalah bahasa lain, mereka memiliki masalah lain. Masih lebih sulit untuk menuliskannya: tidak terlalu cepat dan ada banyak nuansa.

Meskipun demikian, ada hal-hal yang sulit atau tidak nyaman untuk ditulis dalam PHP. Beberapa hal multi-proses, multi-utas lebih baik untuk ditulis dalam bahasa lain. Contoh tugas di mana non-penggunaan PHP dibenarkan, pada prinsipnya, penyimpanan apa pun. Jika ini adalah layanan yang menyimpan banyak memori, maka PHP mungkin bukan bahasa terbaik, karena memiliki overhead memori yang sangat besar karena pengetikan dinamis. Ternyata Anda menyimpan int 4-byte, dan 50 byte dikonsumsi. Tentu saja, saya melebih-lebihkan, tetapi overhead ini masih sangat besar. Jika Anda memiliki beberapa jenis penyimpanan, lebih baik menulisnya dalam bahasa kompilasi lain dengan pengetikan statis. Sama seperti beberapa hal yang membutuhkan eksekusi multi-threaded.

Mikhail Buylov, Mamba


Mengapa PHP dianggap tidak terlalu cepat? Karena itu dinamis. Terjemahan Go adalah solusi untuk masalah menerjemahkan kode dari pengetikan dinamis ke statis. Karena ini, semuanya terjadi lebih cepat. Khusus untuk Go, dalam rencana saya ada tugas aliran data tertentu. Misalnya, jika ada semacam aliran data yang perlu dikonversi ke format yang lebih nyaman, ini adalah hal yang ideal. Dibesarkan oleh daemon, ia menerima satu aliran data pada input, ia mengeluarkan yang lain. Memori kecil makan. PHP memakan banyak memori dalam hal ini: Anda harus hati-hati memastikan bahwa itu dibersihkan.

Transfer ke Pergi adalah transfer ke layanan microser, karena Anda tidak akan memotong seluruh kode. Anda tidak akan mengambil dan menulis ulang secara keseluruhan. Penerjemahan ke layanan mikro adalah tugas yang lebih dalam daripada terjemahan dari satu bahasa ke bahasa lain. Penting untuk menyelesaikannya terlebih dahulu, dan kemudian pikirkan tentang bahasa apa yang akan ditulis. Bagian tersulit adalah mempelajari cara menjalankan layanan mikro.

Semyon Kataev, Avito


Tidak perlu menggunakan Go dalam layanan microser. Banyak layanan ditulis dalam PHP dan memiliki waktu respons yang dapat diterima. Tim yang mendukung mereka memutuskan sendiri bahwa mereka perlu menulis logika bisnis dengan sangat cepat dan memperkenalkan fitur. Mereka kadang-kadang melakukan lebih cepat daripada penjual.

Kami memiliki kecenderungan untuk merekrut pedagang, menerjemahkan ke Go. Tetapi kami masih memiliki sebagian besar kode yang ditulis dalam PHP, dan itu akan menjadi setidaknya untuk beberapa tahun lagi. Tidak ada ras yang sebenarnya, kami tidak memutuskan bahwa Go lebih baik atau lebih buruk. Enam rilis diluncurkan ke monolith setiap hari. Obrolan kami "Avito Deploy" memiliki daftar tugas yang dikerahkan. Setidaknya 20 tugas diluncurkan per hari di setiap rilis: setidaknya lima atau enam rilis per hari, sekitar 80 tugas yang telah dilakukan orang pada tugas-tugas ini. Semua ini dilakukan dalam PHP.

? -, ?

,


Ini sangat sulit. Ada momen psikologis: Saya meluncurkan fitur baru - Anda selesai. Meluncurkan fitur baru yang luar biasa - Anda super muda! Ketika seorang manajer atau pengembang mengatakan bahwa ia menghapus fitur (dinonaktifkan), ia tidak menerima pengakuan tersebut. Karyanya tidak terlihat. Sebagai contoh, sebuah tim dapat menerima bonus untuk keberhasilan implementasi fitur baru, tetapi saya belum melihat adanya penghargaan untuk fungsionalitas mati atau eksperimental. Dan hasil dari ini bisa sangat kolosal.

Banyak fitur warisan yang belum ada yang menggunakan benar-benar memperlambat pengembangan. Ada ratusan kasus ketika seseorang baru memasuki perusahaan dan mere-refactore kode mati yang tidak pernah dipanggil karena dia tidak tahu bahwa itu adalah kode mati.

Kami mencoba bernegosiasi dengan para manajer, mencari tahu dengan fitur seperti apa itu, dengan para analis kami mempertimbangkan berapa banyak uang yang dihasilkannya, siapa yang membutuhkannya, dan hanya setelah itu kami mencoba memotongnya. Ini adalah proses yang rumit.

Mikhail Buylov, Mamba


Kami memotong kode mati ketika kami sampai ke sana. Dan jauh dari selalu mungkin untuk memotongnya dengan cepat. Pertama Anda menulis satu kode, lalu yang lain, di atas yang ketiga, dan kemudian di bawahnya ternyata fitur ini tidak diperlukan. Dia menarik sejumlah besar dependensi, yang juga perlu diperbaiki. Ini tidak selalu memungkinkan, dan manajer perlu melaporkannya.

Manajer menetapkan tugas, Anda menilainya. Anda berkata: "Anda tahu, bung, saya akan melakukan ini selama enam bulan. Apakah Anda siap untuk mentolerir setengah tahun? " Dia mengatakan: "Tidak, mari kita pikirkan apa yang perlu dipotong, apa yang bisa ditinggalkan. Apa yang secara fundamental diperlukan dan apa yang dibutuhkan untuk bermain-main. " Begitulah caranya.

Pavel Murzakov, Badoo


Ketika seorang pengembang menerima fitur, ia mengevaluasi seberapa sulitnya dalam hal pengembangan, seberapa sulit itu dalam hal kinerja. Jika dia melihat salah satu atau yang lain, dia mengklarifikasi dengan manajer produk apakah ini benar-benar diperlukan, apakah kita dapat menghapus sesuatu di suatu tempat. Kadang-kadang terjadi bahwa perubahan tidak kritis, dan manajer dengan cepat membuat konsesi ketika mereka mengetahui bahwa hal ini rumit atau memakan sumber daya. Itu terjadi begitu saja: Anda mengatakan "Ayo hapus" - dan hanya itu.

Kebetulan fitur tersebut pergi, dan setelah itu kami perhatikan bahwa itu tidak akan berfungsi sebaik yang kami inginkan. Dan kemudian, sekali lagi, Anda dapat berbicara dengan manajer. Seringkali semuanya berakhir dengan sukses.

Tidak ada proses bawaan untuk menghapus fitur. Ini dilakukan secara sporadis. Kami melihat ada beberapa fitur, kami datang dan menawarkan untuk mematikannya. Kami mematikannya, menonton apa yang memberi, dan hentikan itu. Hal lain adalah kode mati. Kami memiliki ekstensi khusus, bahkan seluruh infrastruktur, untuk deteksi kode mati. Kami melihat kode mati ini. Kami mencoba untuk memotongnya perlahan. Pertanyaan lain adalah jika benar-benar mati dan permintaan tidak pernah masuk, maka itu tidak mempengaruhi kinerja dengan cara apa pun. Itu mempengaruhi daya dukungan. Orang-orang terus membacanya, meskipun mereka mungkin tidak membacanya. Tidak ada koneksi khusus dengan kinerja.

15 Badoo PHP Meetup. , : SuperJob, ManyChat, , Badoo FunCorp .

, , YouTube-. , - .

, .

Source: https://habr.com/ru/post/undefined/

More articles:


All Articles