Terima kasih videonya pak. Dari ulasannya, imho cuma teknik rejection yang termasuk dalam back pressure, yang lain adalah cara menghandle spike, bukan back pressure itu sendiri. Pemahaman saya back pressure adalah teknik memberi sinyal ke client bahwa sistem dalam keadaan sibuk. Contoh lain implementasi back pressure adalah 1) menambah delay virtual untuk mengerem rate request client, 2) memberikan informasi di response ke client supaya client menahan request berikutnya supaya jangan terlalu cepat, 3) memberikan informasi di response client untuk mengulang request ke alamat server lain yang tidak sibuk.
saya cuma bisa ucapin terimakasih banyak pak Eko atas ilmunya,, semoga pak Eko diberi keberkahan umur untuk dapat terus berbagi kepada kami yang fakir ilmu..
wah udah lama nich pakai queue, reject, tapi baru sekarang tau kalau proses2 itu solusi backpresure( istilah ini baru tahu, hehehe ). Terima kasih ilmunya Pak.
Mantap mas, ini ilmu yg advance di jabarin dalam 30 menit, menurut saya solusi paling enak antara scaling klo harus real-time tapi klo bisa async pake message broker
Nanya mas. tolong dikoreksi klo salah, sepemahaman saya, thread ini berbanding lurus dengan jumlah core yang kita punya. misalkan, saya punya server dengan 2 cores. klo saya buat 100 thread maka ini justru akan memperlambat performance (karena pembuatan thread itu ada overhead costnya) jadi idealnya, jumlah thread itu relative sama atau sedikit lebih besar dari jumlah core di server. saya sudah tidak pernah bermain thread di level coding (buat thread secara manual), saya prefer pakai high level library/tools yang sudah accomodate management thread di belakang layar(alokasi thread, komunikasi ke thread pool, assignment, dll). alasannya karena saya prefer delegate hal2 seperti ini dari pada kita sebagai engineer yang harus mengerjakan detailnya. contoh, di JAVA saya pernah pakai PCDP library,di .NET ada TPL yang sediakan high level API untuk parallel programming. either ini CPU atau I/O bound works, harusnya teorinya masih sama. Sedikit tambahan dari pengalaman pribadi, jangan blindly increase jumlah thread secara signifikan. baiknya, naikan jumlah thread secara bertahap sedikit demi sedikut. kemudian lihat performancenya. you can thank me later.
kalau nonton sampai habis, dijelaskan juga sama kang eko kalau multi thread ini bukan solusi yang paling ampuh, makanya dijelasinnya bertahap dari yang level 1-5. multi thread, horizontal/verical scale, queue, reject request, baru yang paling ampuh messege broker
tergantung, kalo cpu bound benar, jumlah thread tidak boleh lebih dari cpu, karena percuma, nanti thread nya gak kerja karena rebutan cpu tapi rata2 aplikasi kita jarang cpu bound, kebanyakan io bound, karena cuma tektokan sama database dan betul, jangan seenaknya naikin jumlah thread, karena bisa makan memory terlalu besar
@@jeckyfreaky saya ga bahas soal ampuh ga ampuh, saya bahas konsep parallel programming. engineering solution itu soal trade-off. ga ada itu paling ampuh atau paling bagus.
@@ProgrammerZamanNowklo I/O bound secara teori jumlah thread at most berapa kali jumlah core mas? saya cuma pernah at most 2 kali jumlah cores. klo diatas itu, performancenya relative menurun.
gak ada aturan juga sebenernya, karena kan tetep walaupun iobound, soal speed proses dan logic, balik lagi ke kode kita masing2, jadi mau gak mau harus tetep di perf test tiap ngerubah setting thread nya
mantap pak echo materinya. Kalo dari sisi aplikasi sudah dibahas mengenai solusi backpressure. Nah kalo dari aplikasi nya kencang tapi database nya yang sekarang lambat atau tidak mampu menyamai kecepatan aplikasi itu bagaimana ya approach solusi nya pak? Nuhun pak🙏
Nice pak eko. Request pak eko, bahas gimana bikin server database yang zero downtime, saat ada insiden misalnya. Pernah denger sekilas tentang replication, clustering, virtualisasi, dan lainnya apalah itu. Terima kasih.
kalau mau database zero downtime ada caranya om, saya rekomen untuk setup Galera MariaDB Cluster. Syaratnya sediain minimal 4 server, satu server untuk reverse proxy, dan 3 server lainnya sebagai node galera cluster. 4 Server itu harus memiliki minimal 4 NIC, satu mengarah ke public, satu mengarah untuk node cluster, jadi cara kerjanya ketika kita mau koneksi ke Database harus melewati Reverse Proxy bisa pakai NGINX atau HAProxy. kalau minimal node bisa baca raft consensus om. Mas eko bisa bahas zero down time dimulai dari raft consensus tersebut mungkin lebih menarik
Mas Eko, thread ini mengunakan paralel kan ya?,di video go coroutines di jelaskan proses i/o bond seperti pengambilan API di database implementasi thread(paralel) tidak terlalu membantu meningkatkan performa, namun dalam penjelasan ini bisa digunakan meningkatkan performa? Kenapa bisa beda ya mas? Apakah setiap thread itu mengabil data/proses i/o secara bersamaan?
Pak izin , bahas tentang penjualan website freelance yang di jual ulang oleh pembeli , gimana mengatasi itu pak ? Apa aja yg saya harus pelajari juga , terima kasih pak
Pak bahas database slow query dong, kasusnya di api sudah RTO, tapi mysql masih running query, alhasil request api berikutnya jadi stuck dan lambat. Mohon solusinya
nambahin pa untuk nodejs ada child process & multi threads(cluster) default nodejs / expressjs running di 1 threads (apapun cpu nya, 1 core = bisa banyak threads (misal cpu intel i3 gen 3 gen 4, 2 core tapi punya 4 threads) multi threads = menggunakan semua threads (gabung threads berdasarkan jumlah threads yng diinginkan) , kurang significant kalo di nodejs , masih lebih bagus semua threadsnya pake child process (latency nya lebih ringan) child process = menggunakan threads berdasarkan yang dipilih (ini setiap threads gak nungguin threads lain, threads 1 gak nungguin threads 2, tapi threads 2 tetep masuk beban nungguin threads 2 kalo ada antrian berlanjut) biasanya saya kalo misal punya core 8 core 16 threads , 4 threads jadi multithreads, 8 threadsnya child process (trs saya buat child processnya ngurut processnya untuk setiap threads process jadi gak dobel request di setiap threads yg sama dalam waktu bersamaan), sisa threadsnya untuk handle vm, promotheus(node exporter,pm2 exporter), jenkins ssh agent, biar gak terlalu berat kalo di NestJs ada adapter (fastfiy) yang bikin lebih cepet juga CMIIW
mau tanya, kalo multi thread gitu, apalagi yg sistem update balance / stock. gmn handle ny y? kalo dr database locking, apakah sanggup database handle sebanyak itu request ny? 🤔
Nice content pak eko 👏👏👏. Terimakasih banyak utk ilmu2 nya slama ini. Sukses selalu buat channel PZN. Anw, izin bertanya. Ada kemungkinan ga ya ketika implementasi message broker, API yang udah di horizontal scale nge consume message/request yang sama ? Misalnya jadi malah ada 2 server API yang nge proses gitu Atau yg kek gini biasa nya udah dihandle oleh message brokernya supaya ga kejadian?
komen pertama,, cihuy,,, mohon bahas antara uuid dengan autoinrement biasa,, apakah id increment bisa menimbulkan masalah,, karena saya ngalamin, sebuah API tidak mau membuat data baru karena dianggap id sudah ada,, padahal blm ada ketika saya cek di database... thx
yg anehnya ketika membuat di level databse,, tapi ga bisa karena dianggap sudah ada oleh orm nya,,, ada solusi kah untuk ini ? atau ada penjelasan kah? thx@@ProgrammerZamanNow
Kalau pake message broker atau queue, misalkan request yg masuk banyak pak, client menunggu response dan ternyata timeout yg otomatis http connectionnya closed. Atau misalkan ketika client request dan dimasukkan ke message broker/queuenya kemudian dikasih response dan http connectionnya jg langsung closed. Cara ngasih response hasil processingnya ke client bagaimana pak?
Thanks pak eko disini dicontohin misalnya server bisa nerima request 100/s dsb, nah bagaimana kita bisa benchmark server kita untuk dapatin nilai tersebut? thanks pak eko
pak eko, sy juga ada project terkait ini, kalo mau bikin testing terkait backpressure itu gmn kang? kemarin trouble ini, akhir nya solusi memang horizontal scalling biar cepet. nah kondisinya sy bingung untuk testing nya. misal mau bikin 100req/second itu gmn cara testing nya kang ?
