Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. General

Perhatian Pengembang: NewRelic adalah Senjata Rahasia Anda

by
Read Time:13 minsLanguages:

Indonesian (Bahasa Indonesia) translation by Ilham Saputra (you can also view the original English article)

Sementara judul artikel ini mungkin terdengar seperti klise, menetas di perut PR, saya serius ketika saya mengatakan bahwa NewRelic adalah senjata rahasia Anda.

Pada artikel ini, saya akan berbicara tentang aspek umum kinerja aplikasi web, dan kemudian menunjukkan bagaimana NewRelic membuatnya mudah dikelola.

Dalam hampir enam tahun saya bekerja di Envato - yang sebelumnya mengembangkan dan mengelola marketplaces dan saat ini mengelola pengembangan jaringan blog Tuts+ - Saya telah menggunakan NewRelic untuk menekan biaya, meningkatkan dan men-debug masalah kinerja dari kecil hingga bencana besar, dan mencegah potensi.

Jika Anda baru mengenal topik ini, atau saat ini tidak mengelola situs web untuk seseorang dalam kapasitas apa pun, jangan stres; artikel ini akan tetap bermanfaat. Anda tidak pernah tahu kapan pengetahuan ini bisa menyelamatkan daging Anda, dan saya berani bertaruh itu tidak akan terhindarkan - kecuali, tentu saja, Anda memutuskan untuk melempar handuk pengembang hipotetis dan menjadi astronot atau pemilik peternakan.


NewRelic dalam 20 detik

Sebelum saya memulai omelan yang cukup panjang pada kinerja aplikasi web, masuk akal untuk dengan cepat meringkas apa itu NewRelic sebelum Anda turun ke Reddit atau yang serupa.

NewRelic adalah layanan terkelola (SaaS) yang Anda "pasang" ke aplikasi web Anda, yang mengumpulkan dan menggabungkan metrik kinerja aplikasi web langsung Anda.

Informasi yang diberikannya dapat membantu Anda menemukan jawaban untuk pertanyaan seperti: Apakah situs web saya lambat? Untuk siapa ini lambat? Di mana tepatnya lambat? Apakah kita memerlukan lebih banyak, atau server yang lebih besar? Apa yang bisa kita lakukan untuk memperbaiki keadaan?

Pertanyaan-pertanyaan ini dan jawaban mereka seringkali penting untuk kesuksesan atau kegagalan aplikasi web Anda. Jika Anda belum pernah mengumpulkan metrik kinerja dari aplikasi web langsung, Anda benar-benar berjalan sambil ditutup matanya; pada titik tertentu Anda akan menabrak dinding!

Sebelum saya membawa Anda berkeliling ke fitur-fitur NewRelic, saya harus mendefinisikan apa itu kinerja aplikasi web. Mari kita mulai.


Apa sebenarnya kinerja aplikasi Web?

Kinerja front-end adalah tentang kinerja "persepsi".

Saya suka membagi kinerja aplikasi web menjadi dua bagian konseptual: kinerja front-end dan kinerja back-end. Meskipun kedua area tersebut memang memiliki crossover dan saling mempengaruhi, akan sangat membantu untuk membuat perbedaan.

Terutama, Anda dapat menganggap kinerja front-end sebagai area yang terkait dengan kinerja yang dirasakan, seperti berapa lama waktu yang diperlukan untuk merender sepenuhnya ke pengguna akhir. Variabel yang mempengaruhi tipe kinerja ini meliputi:

  • Seberapa besar HTML, CSS, JavaScript, dan gambar Anda
  • Berapa banyak permintaan HTTP dikirim ke server untuk mengambil semua aset ini
  • Bagaimana mereka diatur dalam halaman untuk mempengaruhi kinerja yang dirasakan, apakah browser pengguna harus mengunduh ulang aset terlepas dari apakah mereka sama atau tidak.

Saya hanya melihat aplikasi web dan situs web "jatuh" sebagai akibat dari kesalahan pengelolaan back-end.

Kinerja back-end melibatkan beberapa jenis bahasa pemrograman yang menjalankan kode Anda (mis. PHP, Ruby), dan beberapa jenis server basis data (mis. MySQL). Umumnya, sebagian besar aplikasi web sedang menyusun dokumen HTML untuk dikirim ke browser pengguna Anda, dan terdiri dari data yang diambil dari satu atau lebih basis data - atau bahkan satu atau lebih layanan eksternal (seperti Twitter API). Saya juga biasanya menyumbat sumber daya server (seperti penggunaan CPU, penggunaan memori, disk IO) ke dalam kategori ini, karena kode tersebut berjalan di server Anda (bukan di browser pengguna Anda) yang memengaruhi sumber daya ini.

Mengapa perbedaan ini begitu penting? Karena, dalam pengalaman saya, saya telah menemukan bahwa kebingungan antara keduanya mengarah pada upaya tidak berguna yang diterapkan ketika mencoba untuk memperbaiki masalah kinerja. Saya telah menyaksikan pekerjaan pada kinerja front-end dari situs web yang sakit ketika masalah sebenarnya adalah backend. Di sisi lain, saya telah melihat orang-orang fokus pada optimasi back-end ketika masalahnya ada di front-end. Sangat penting bagi Anda untuk memahami dan menghargai perbedaannya.

Sendiri, kedua subjek ini bisa agak dalam dan rumit, dan ini adalah topik untuk serangkaian posting yang sama sekali berbeda. Walaupun saya jelas terspesialisasi dalam kinerja back-end, dalam semua karir profesional saya, saya hanya melihat aplikasi web dan situs web "jatuh" sebagai hasil dari salah urus back-end.


Pendekatan Tiga Setengah untuk Mengelola Kinerja

Ada tiga cara di mana orang cenderung mengelola kinerja aplikasi web mereka:

  1. Tulis kode, gunakan, dan harapkan yang terbaik
  2. Tulis kode, tebak bidang mana yang akan menjadi kemacetan, ukur dan optimalkan di muka, gunakan, dan harapkan yang terbaik.
  3. Tulis kode, ukur aplikasi langsung dengan sesuatu seperti NewRelic, lalu perbaiki dan sesuaikan yang sesuai.

Pendekatan pertama adalah 100% reaksioner. Jika Anda mengikuti metode ini, Anda hanya akan tahu jika aplikasi web Anda gagal atau berkinerja buruk ketika pelanggan Anda memberi tahu Anda (jika mereka pernah memberi tahu Anda).

Pendekatan kedua jauh lebih matang; para pengembang mendahului masalah dan berusaha menyelesaikannya di muka. Meskipun ini mengagumkan, kemungkinan menghabiskan sumber daya vital mengoptimalkan area yang salah, dan kurangnya umpan balik yang berkelanjutan akan memberikan beberapa fakta tentang apa yang sebenarnya terjadi di lingkungan hidup.

Pendekatan ketiga adalah situasi yang hampir ideal. Dengan memantau aplikasi web langsung, Anda dapat meninjau berbagai kinerja, berdasarkan apa yang sebenarnya dilakukan pelanggan. Anda dapat menulis kode dan menerima umpan balik langsung tentang seberapa baik (atau tidak) kinerjanya.

Pendekatan Yang Ideal

Pendekatan yang ideal adalah mengikuti yang ketiga dan menerapkan ukuran yang sehat dari yang kedua.

Tidak ada salahnya untuk mempertimbangkan kinerja di depan; itu jauh lebih berguna untuk memiliki metrik sejati. Pepatah pemrograman lama, "optimasi prematur adalah akar dari semua kejahatan" mungkin berlaku di sini, meskipun, dalam pemrograman, seperti dalam kehidupan, aksioma jarang lebih dari setengah kebenaran.


Pengukuran & Manajemen: A Balancing Act

Tidak ada yang namanya satu metode sejati untuk mengelola kinerja aplikasi web Anda.

Tidak peduli apa kata orang (termasuk saya!), Tidak ada satu pun metode yang benar untuk mengelola kinerja aplikasi web Anda. Bergantung pada aplikasi dan pelanggan Anda, akan ada pendekatan dan teknik yang berbeda. Namun satu hal tetap konstan: Anda harus mengukur.

Jadi, apa yang Anda ukur? Sekali lagi, tidak ada satu daftar yang benar, namun akan selalu ada jumlah metrik umum yang layak diukur. Sebagai contoh:

  • Jumlah permintaan aplikasi dari waktu ke waktu.
  • Permintaan waktu jam dinding diperlukan untuk menyelesaikan.
  • Penggunaan CPU dari server Anda dari waktu ke waktu.
  • Hard drive membaca, menulis, dan menggunakan dari waktu ke waktu (dikenal sebagai Disk IO).
  • Jumlah kueri basis data, dan waktu yang diperlukan untuk berjalan.
  • Kueri dijalankan pada database Anda yang membutuhkan waktu lebih dari dua detik untuk menyelesaikan (permintaan lambat).
  • Bandwidth masuk dan keluar seiring waktu.

Daftar ini, walaupun tentu saja tidak lengkap, akan menawarkan wawasan yang signifikan tentang perilaku aplikasi web Anda, terutama jika Anda belum pernah memantaunya sebelumnya.

Setelah Anda memiliki data seperti ini, pengelolaan aplikasi web Anda adalah tempat semua kesenangan dimulai. Anda mungkin menemukan bahwa, setelah menghapus bottleneck di database Anda (mungkin beberapa query yang dieksekusi perlahan), Anda akan mengekspos yang lain karena lebih banyak sumber daya server yang dibebaskan. Ini benar-benar adalah tindakan penyeimbang.

Pada akhirnya, apa yang tampak seperti manajemen yang sukses adalah seperti ini: Anda dapat menggandakan efisiensi server tunggal itu, sehingga Anda dapat menunda pembelian satu detik. Pada skala yang lebih besar, Anda dapat memotong server pertanian Anda dengan faktor 50%, dan pada skala yang cukup besar, yang dapat menyamakan dengan uang serius. Di sisi yang lebih ringan, Anda dapat memberikan kualitas layanan yang baik kepada pelanggan Anda tanpa kejutan mendadak.


NewRelic: Senjata Rahasia Anda

Sekarang kita telah membahas bit "apa" dan "bagaimana", mari kita lihat NewRelic. Sekali waktu di tanah perangkat lunak, Anda harus menggulung pengukuran Anda sendiri ke dalam suatu aplikasi - jika Anda mengukurnya sama sekali (yang bisa sama beratnya dengan menulis aplikasi Anda sendiri). NewRelic memungkinkan Anda cukup mencolokkan agennya ke aplikasi Ruby, PHP, .NET atau Python, dan mulai mengumpulkan data nyata segera.

Dengan penuh pertimbangan, produk mereka dibagi menjadi tiga wilayah inti:

  • Pemantauan pengguna akhir (front-end, browser)
  • Pemantauan aplikasi (back-end, kode Anda)
  • Pemantauan server (back-end, server)

Mari kita lihat masing-masing, sesuai urutan pembebasan mereka secara historis.

Fitur pertama yang diluncurkan NewRelic adalah pemantauan aplikasi. Ini melacak dan melaporkan "Permintaan per Menit" (alias RPM), waktu respons rata-rata dari permintaan ini, dan menyimpan data ini untuk Anda analisis. Ini sangat berguna untuk menemukan tren lalu lintas dari waktu ke waktu (mis. Apakah situs saya semakin lambat karena peningkatan tampilan halaman kami?).

Selain itu, "jejak transaksi lambat" akan memberi Anda daftar permintaan terbaru dari pengguna nyata yang lambat secara tidak proporsional. Memeriksa ini memungkinkan Anda untuk menelusuri dan menentukan mengapa permintaan membutuhkan waktu lama, memberi Anda informasi yang Anda butuhkan untuk memperbaikinya.

Pemantauan pengguna akhir akan memberi Anda wawasan tentang bagaimana situs Anda merender di browser pengguna. Ini memecah total waktu menjadi potongan-potongan, berdasarkan hal-hal seperti waktu jaringan (berapa lama waktu yang dibutuhkan untuk mengunduh), rendering DOM (berapa lama pengeluaran browser Anda untuk mencari HTML Anda), memuat gambar (seperti dilayani oleh server web Anda atau CDN) .

Fitur yang rapi dari pemantauan pengguna akhir adalah menunjukkan kepada Anda seberapa baik atau buruknya kinerja aplikasi Anda untuk pengguna di berbagai negara. Misalnya, mungkin 50% pelanggan Anda berbasis di Inggris, sedangkan 50% lainnya di AS. Anda mungkin menemukan bahwa kinerja front-end tidak terlalu bagus di Inggris, karena jarak fisik dari server Anda. Memperkenalkan CDN atau server di Inggris akan meningkatkan pengalaman mereka.

Bagian terbaik menggunakan NewRelic dan mengambil tindakan berdasarkan datanya adalah bahwa, setelah Anda membuat sejumlah perubahan, Anda dapat segera meninjau apakah perubahannya efektif atau tidak!

Bagian terakhir dari teka-teki, dan pemantauan terbaru yang diperkenalkan NewRelic, adalah alat pemantauan server mereka. Saya selalu berkomentar bahwa Anda harus menghubungkan sumber daya server Anda dengan waktu respons aplikasi web Anda untuk mendapatkan gambaran efisiensi yang lebih lengkap. Anda mungkin memiliki waktu respons yang sangat baik, tetapi Anda juga mungkin mengorbankan sumber daya server yang signifikan untuk menyediakannya.

Saya telah melihat aplikasi dengan skor YSlow yang sangat baik, misalnya, tetapi sama sekali tidak ada ruang kepala untuk lebih banyak lalu lintas - bahkan pada sejumlah besar perangkat keras!

Saya harap sekarang Anda mulai melihat betapa berharganya informasi semacam ini!


Instalasi NewRelic

Anda harus setidaknya menggunakan VPS dan memiliki akses root untuk agen PHP.

Satu-satunya kritik saya terhadap NewRelic adalah tidak mudah menginstal untuk beberapa jenis pengguna. Jika Anda seorang programmer Ruby on Rails, Anda akan menemukannya cukup mudah, karena ini adalah plugin Rails sederhana.

Jika Anda seorang pengembang PHP dan tidak nyaman untuk bermain-main di baris perintah, Anda akan kesulitan menginstalnya, karena ini adalah ekstensi PHP dan memerlukan daemon yang harus diinstal agar berjalan di sisi server web Anda. Namun, beberapa platform cloud PHP, seperti PHPFog menawarkan integrasi NewRelic di luar kotak.

Ini sangat disayangkan dalam pikiran saya, karena itu merupakan rintangan bagi kebanyakan orang. Saya berharap NewRelic saat ini mencari untuk bermitra dengan penyedia hosting web komoditas lebih banyak, sehingga produk mereka lebih mudah diakses oleh audiens yang lebih luas. Tidak ada alat seperti itu di pasaran saat ini, dan mereka seharusnya memudahkan semua pengembang PHP untuk menggunakannya.

Jika Anda menggunakan hosting yang ada, Anda harus setidaknya menggunakan VPS dan memiliki akses root untuk agen PHP. Menjadi benar-benar adil, untuk memutar VPS dari penyedia seperti Linode, dan menginstal Apache, PHP, MySQL, dan NewRelic adalah proses yang singkat, tetapi hal itu membutuhkan kenyamanan dan pengetahuan dalam sebuah shell.

Cara terbaik untuk mulai menggunakan PHP dan NewRelic adalah dengan menggunakan alat seperti Oracle VirtualBox, menginstal Linux, mengatur Apache dan PHP dan kemudian menginstal agen. Maka Anda akan dapat menggunakan NewRelic di lingkungan pengembangan lokal Anda, setidaknya.

Saya pribadi belum punya pengalaman dengan agen Python, dan saya sudah mendengar dari pihak ketiga bahwa komponen .NET semudah pie untuk bangkit dan berjalan.


Bagaimana Envato Menggunakan NewRelic

Envato telah menggunakan NewRelic sejak 2008. Kami telah menggunakannya di produk berikut dengan hasil yang baik (dan terkadang menarik):

Marketplaces

Awalnya, kami menemukan kira-kira tiga titik lambat utama di tempat-tempat tak terduga di pasar. Kami menemukan apa permintaan tertinggi kami yang diperdagangkan, dan fokus untuk mengoptimalkannya secara khusus. Jika 80% waktu kita dihabiskan di satu tempat, menjadikannya dua kali lebih cepat meningkatkan kapasitas dan menyelamatkan kita dari mengalokasikan lebih banyak dana ke perangkat keras. Kami telah melihat lalu lintas yang tidak biasa (seperti spammer dan peretas) yang memungkinkan kami untuk mengambil tindakan pencegahan lebih awal daripada kemudian, sehingga meningkatkan pengalaman bagi pelanggan nyata kami. Kami menggunakannya setiap hari untuk memantau kinerja semua kode baru dan yang ada.

Blog Tuts+

Pada 2009-2010, jaringan blog Envato memiliki masalah stabilitas serius karena sejumlah masalah arsitektur. Adalah tugas saya untuk turun tangan dan menyelesaikan masalah. Setelah melakukan analisis arsitektur dan mendesain ulangnya, kami memasang monitor PHP (yang saat itu beta!). Kami menemukan banyak, banyak hal yang tidak diinginkan!

  • 20% dari permintaan adalah hit ke feed (yang seharusnya di-cache atau dikirim ke FeedBurner)
  • 3 query SQL secara rutin membutuhkan lebih dari 5 detik untuk mengembalikan hasil
  • Tugas WP-Cron yang sudah berjalan lama mengikat kolam pekerja web kami
  • 404 halaman membutuhkan waktu lebih dari 1 detik untuk menghasilkan!

Selama 2010-2011, kami secara progresif menyelesaikan masalah sampai semuanya diselesaikan, lebih atau kurang. Hingga hari ini, kami masih memantau blog PHP menggunakan NewRelic. Dan sekarang, untungnya, jaringan blog bagus dan stabil.

Tuts+ Premium Redesign

Ketika kami meluncurkan pendesainan ulang Tuts+ Premium, kami menggunakan NewRelic untuk men-debug masalah kinerja sebelum peluncuran yang sebenarnya, pada server yang sebenarnya mereka jalankan. Ini meredakan kekhawatiran akan bencana saat diluncurkan. Kami terus memantau kinerja situs, menggunakan NewRelic.

Saat ini, setiap aplikasi penting di Envato memiliki agen NewRelic yang terhubung. Sejujurnya itu telah menghemat banyak waktu dan uang, dan memungkinkan kami memberikan kualitas layanan kepada pengguna dan pelanggan kami.


Alat Lain yang Digunakan Envato untuk Menambah NewRelic

Tidak adil untuk tidak menyebutkan alat lain yang kita gunakan untuk menjaga aplikasi kita. Kami saat ini menggunakan ScoutApp untuk pemantauan server yang lebih halus (ia mendukung 'plugin' yang disumbangkan pengguna sehingga kami dapat memantau layanan tertentu seperti HAProxy, Nginx, dll). Kami juga menggunakan AirBrake yang mencatat dan mengagregasi kesalahan kami di aplikasi Ruby on Rails kami.

Terakhir, kami telah meluncurkan beberapa alat khusus kami yang khusus yang memeriksa hal-hal seperti hit cache, permintaan backend, pendapatan, pendaftaran, pemberitahuan ketika terjadi penyimpangan signifikan dari tren. Misalnya, penghentian atau penurunan pendapatan mungkin berarti integrasi pembayaran kami rusak; perubahan dalam pendaftaran berarti kami mungkin telah ditargetkan oleh spammer yang membuat akun hantu untuk digunakan nanti.


Membungkus

Jika Anda bekerja pada segala jenis aplikasi web yang penting untuk bisnis, atau ditugaskan untuk memperbaiki aplikasi yang tidak berfungsi dengan baik, NewRelic akan sangat berharga bagi Anda.

Jika Anda memiliki pertanyaan, tanyakan di komentar dan saya akan melakukan yang terbaik untuk menjawabnya. Khususnya, jika ada minat pada screencast tentang cara mengatur VPS atau VM dengan NewRelic, saya yakin kami bisa mengaturnya untuk Anda.

Menjadi superhero programmer; gunakan NewRelic!

Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.