Optimasi API Menjadi 1500% Lebih Cepat | PZN Reaction
Vložit
- čas přidán 23. 08. 2024
- Optimasi API Menjadi 1500% Lebih Cepat | PZN Reaction
Link : / milan-jovanovic_i-spen...
JOIN PREMIUM : www.youtube.co...
DISCORD PREMIUM : • Post
Donasi :
Saweria : saweria.co/Pro...
Social Media :
Instagram : / programmerzamannow
Facebook : / programmerzamannow
Telegram : t.me/Programme...
CZcams : / programmerzamannow - Věda a technologie
Prinsip Pareto yang juga dikenal sebagai Aturan 80/20 menyatakan bahwa untuk banyak kejadian, sekitar 80% daripada efeknya disebabkan oleh 20% dari penyebabnya. Prinsip ini diajukkan oleh pemikir manajemen bisnis Joseph M. Wikipedia
Yes betul, biasanya ini digunakan juga di Quality Improvement seperti six sigma dll sebagai salah satu cara untuk mencari hal yg perlu di improve
saya kerja sbg devops disalah satu company yg manage infra client, ketika ada issue mostly hampir 90% lebih, masalah / bottleneck terjadi di sisi database, entah querynya lama, connectionnya penuh dll pasti selalu terjadi dan impactnya ke infra. sepengalaman sy sbg ex webdev yg pernah nyoba ngebuat design system utk handling case demikian menurut sy ini sangat penting dan tidak bisa disepelekan, video ini sangat bagus dan memberikan gambaran dan pencerahan untuk para developer yg mungkin masih menyepelekan perihal decision system design & mechanism query ke database salah satunya. pernah dengar juga dari teman saya "if it works, don't touch it" tapi ya ga gitu juga bang 🥲
"if it works, don't touch it" mntap wkwk
@teguhkurniawan878kalo boleh tau, tim infra itu apa ya bg? 🙏🏻
@@houhinkyouma6153 infrastructure engineer
@@houhinkyouma6153 kalo di permesinan ada mekanik, kalo di per-it-an ada infra. kurang lebih seperti itu om
Setujuu, saya orang infra.. pernah kejadian akhir bulan closing sistem muter2 aja, saya yg ngurusin server babak belur sampe begadang2.. udah tuning web server sedemikian rupa , ga pengaruh , ternyata query nya ada loop 😢 giliran udah ketemu issue nya di query cuma ketawa ketiwi aja orang dev.. nasib kerja sistem lempar bola, bukan team yg solid.. nikmatin aja , maap curcol 😊
Lebih ke istilah bisnis sih, contoh pareto customer. 20% customer yang menyumbang 80% order/income/laba
Kayanya butuh dark mode deh pak Eko. Pusing lihatnya kalau lagi di dalam ruangan yg gelap✌️✌️
80/20 -> hukum Pareto. Menyatakan bahwa 80 % permasalahan disebabkan oleh 20% masalah. Fixing 20% masalah akan mengatasi 80% permasalahan tadi
80/20 Pareto diagram pak,,, di Teknik Industri dipelajari
pak eko bahas tentang seputar best practice menghadirkan fitur public user (user hadir ke aplikasi karna register, login dan log out) di toko online kayak seputar struktur database, keamanan data pengguna, dll :D
mantap pak, terima kasih ilmunya. jadi makin solid
makasih pak eko pas bgt ada issue seperti ini...
Pareto principle 80:20
Manteb nih buat merapikan kode aplikasi
agak kecewa sama postingan nya si orang itu di linkedin, kirain bakal diceritain lebih detail dia optimize apa:
- mungkin dikasi context service nya ngapain, yang lambat awalnya dimana dsb
- awalnya dia find bottleneck ngeliat apa, proses deduction nya gimana
- contoh query nya kayamana yang dia optimize
- strategi caching nya kayamana yang dipakai buat solve issue dia, kenapa pilih itu dsb
- cara dia ngetest bisa dapet angka 15x lebih cepet tuh gimana
Ini mah cuman kasi template gitu doang, bohong juga ga ada yg tau hehehe
amazing, thank you pak eko
daging semua ini pas bgt lagi mikirin ini eh muncul
Bagian terakhir bang, kapan sebaiknya redis invalidated? Karena misal kita set 1 jam cachednya, ternyata lets say 30 menit sudah ada data yg berubah di database, harusnya kan redis invalidated. cmiiw. Apakah dibuat trigger jga buat ini?
klw data2 dinamis bgt kaya crud gak pake redis. tp kalau report2 bisa pake redis
Pas ada data berubah, bikin mekanisme buat delete key-value yang udah ga relevan.
kerenn, terima kasih mas eko
Kang mau tanya, kalau misalkan querynya komplex dari aplikasi cuma panggil 1x, tp dalam 1 proses query tersebut terdapat tahapan pengecekan ketersediaan masukannya dengan melakukan query terhadap data lain sebelum query utamanya di jalankan semisal proses tersebut dibungkus kedalam sebuah Stored Procedure. Nah kira-kira tahapan seperti itu salah atau tidak? Terima kasih jika berkenan menjawab. 🤧
Salah 1 fungsi SP memang buat itu, sangat tidak bijaksana mengirimkan 1000 baris query over the network belum lagi skema database bisa terekspos
Mantap pak eko videonya, the prime time tapi versi bahasa indonesia
Mau tanya pak itu kalo semua di taro redis engga meledak ?
Milan Jovanovic dari pemain bola jadi programmer wkwk
tracing monitoring ini tools atau maksudnya kita cek sendiri satu2 functionnya ya?
contohnya pake grafana buat monitoring
coba jngn kerja disini bang
karena penerapan S.O.L.I.D principles, biasanya mengorbankan kinerja backend
berarti misal bang.
saya punya halamn beranda . perubahaan nya jarang.
apakah bisa sy simpan di redis?
pak itu extention apa yg bisa suggest funcctin gtu
github copilot kah?
pak eko gak mau buat tutorial .Net kah? atau C++ or C#?
bang tolong buat tutorial android udah 1 tahun nggak di lanjutin🙏
si service report mungkin ga akan tau kalo data dari service product ada yang berubah, jadi kurang bagus ga sih kalo dicache? kayanya pernah dibahas di salah satu video di channel ini
makanya perlu ada expire time nya
implementasi redis nya gmn, ada expired data, atau update jika data beda. itu yg saya masih penasaran. saya simpan nya di aplikasi nya biasa nya. semisal nodejs. memory jadi banyak. tapi itu juga salah. jadi saya buat variable itu di simpan terus.
mungkin bisa pake LRU buat cachingnya
paling enak handle concurency pakai rxjs sih :v
cache ini agak tricky sih kayaknya
80 20 itu konsep pareto effect
Tutor C# kapan pak?😂
menurut saya masih lebih baik menggunakan function atau procedure untuk satu proses yang banyak call ke tabel, hanya kirim 1 x koneksi ke DB dengan parameter yang diiinginkan tiggal di proses smua di DB , kadang kasian jg RDBMS uda buat function, trigger procedure ga dipake :D
Coba itu di terapin dengan client user yang banyak pasti banyak yang ke lock itu nanti querynya dan apalagi di cluster malah kagak worth it itu db cluster
berhubung tadi nyinggung response time, idealnya kalo misal udah ada standard terkait max response time (misal 3 detik), itu biasanya based on apa ya (local / staging / prod)? karena biasanya tiap environtment itu beda resource 🙏
Pertama, gunakan asymptotic concept di sini dulu Bg, Kedua sesuaikan Resourcenya sesuai dengan kebutuhan melalui vertical scaling atau horizontal scaling (untuk membagi beban/muatan ke sistemnya)
Dotnet di indo masih kurang populer di startup ya
begitulah
mahal sih materinya🔥
20/80 = paretto
kalo case nya create or update gimana mas ?
dalam 1 array ada 100 object, lalu di looping cek ref_code, kalo ada update kalo gk create.
lebih baik metode nya seperti apa ya mas ?
di DB udah ada perintah INSERT ON DUPLICATE UPDATE
@@ProgrammerZamanNow udah bisa mas, saya pake method nya UPSERT
nitip komen % cuma saampai 100 bang
Prinsip pareto biasanya kepakai di testing
prinsip
Orang Java bahas artikel orang .NET 🙃