The Ephemeral Data

Bismillahirrahmanirrahiim. Dengan nama Allah yang Maha Pemurah lagi Maha Penyayang.

...

"Ni gambar konsep epheremal data — abstrak, glowing, macam data stream tengah hilang dalam udara. Harap suka!",  kata ChatGPT yang tolong generate gambar ni.

... 

Lately ni banyak pulak citer pasal hati dan perasaan aku. hahahah. Mari kita distract sikit masalah kehidupan kita dengan masalah teknikal pulak.

Bear in minds, ni citer masa  end of November 2024 to early December 2025.

... 

Performance Test datang lagi.

Performance test ni biasanya merujuk kepada pengujian untuk menguji ability sistem yang dibangunkan tu boleh handle berapa banyak user serentak atau dalam satu - satu (predefined) masa. Biasa ada dua parameter penting masa buat performance test ni.

1. Total User, dan
2. Ramp Up.

Contoh, target untuk nak dapatkan concurrency 10,000 dalam masa 100 saat, so parameter dia akan jadi \( \text{Total User} =10,000 \) dan \( \text{Ramp Up} = 100 \) saat. Means that, dalam masa 100 saat, 10,000 user sepatutnya loaded ke dalam sistem tersebut.

Dan biasanya strategy yang digunakan adalah dia akan load \( \frac{\text{Total User}}{\text{Ramp Up}} \) user ke dalam user untuk setiap saat (to make the test more predictable instead of pakai random atau sela masa yang lebih kecil). Dan setiap user tu pula, akan load another predefined test plan.

Test Plan.

Dalam test plan tu ada list of flow, based on the normal flow untuk sesuatu sistem tu.

Contoh, katakan dalam test plan tu dia akan execute cenggini,

1. Create random number, preparing for session id on client side.
   
2. Call create session endpoint
3. Execute calculation with session id on the server
4. Execute another calculation with session id on the server
5. Get all result from the server
6. Close session
   

Maksudnya akan ada 5 execution dalam satu test plan tu (exclude no 1 sebab tu takde hit server). So dari 10,000 users tu, maksudnya akan ada 50,000 benda akan diexecutekan ke system dalam masa 100 saat.

Biasanya, kami gunakan Apache JMeter untuk execute test plan ni. Dia dah jadi macam standard. So application Apache JMeter ni yang akan execute test plan tu.

Cuma kadang - kadang, tak boleh nak load serentak 50,000 execution tu dalam satu application tu. So the architect design untuk Apache JMeter ni boleh run sebagai Master-Slave configuration.

Ok kita citer pasal Apache JMeter Master-Slave sikit.

Apa yang JMeter Master-Slave ni buat is that, the master akan distribute load kepada semua slave dia tu. So that dia akan load dia tu akan distributed evenly (as evenly as possible) ke semua slave dia, so tak jadi beban kalau pakai satu je application.

Contoh lagi. Aku nak execute 10,000 tu tapi aku tak nak dia bottleneck kat Apache JMeter aku. So aku (painfully) buat another 5 Virtual Machines to help distribute the load. Jadi, untuk setiap VM tu, aku akan set dia run 2,000 so that aku akan dapat total 10,000 users loaded. Ramp up takde kacau sebab kita memang nak dia run dalam sela masa tu.

Ok in summary, boleh rujuk kepada rajah bawah ni.

Figure 149: Contoh JMeter dan Load Generator masa Performance Test

Ok I think it should be enough introduction.

...

Ada certain - certain projek kitorang yang akan ada performance test. Ni biasanya depends kepada macam mana bos aku punya direction nak nego untuk buat performance test atau tak (basically ada bayaran ke tak, boleh claim ke tak).

Tapi kami takde la over ambitious sangat. Sebelum bos aku commit untuk nak buat performance test kat client, biasa dia akan tanya aku dulu.

    En A: "You confident ke nak buat performance test ni?"

Aku tak boleh nak cakap tak boleh. Logically speaking, mestilah kene buat. Confident atau tak.. To be honest memang aku tak confident.

Tapi..

Nak kata aku suka buat ke tak performance test ni,.. Well.. basically it is a superposition bagi aku. Aku nak dan dan dalam masa yang sama, aku tak nak.

Seriously. 

Sebab aku tau. Kalau nak run performance test ni, aku kene spend banyak sangat masa nak debug semua benda. All the layers. All the codes. Semua kena semak balik satu persatu in case ada bottleneck kat mana - mana.

But at the same time, aku suka sangat performance test ni. Aku suka sebab ni la yang boleh memaksa aku test theory yang aku tahu/dapat dan terus apply. Time ni la betul - betul nak kene faham sistem yang aku buat dan dependency dia. Time ni la aku nak pastikan apa yang aku faham tu, betul apa aku faham.

Katakan lah kalau ada exam pasal kerja/projek aku buat ni, so actually kat sini la dia punya exam dia. Aku betul - betul ke faham apa yang berlaku dari depan sedepan depannya sampai lah ke terpaling belakang.

Maksudnya takde masalah kalau aku nak tuning. Aku patut tahu kat mana aku nak usik atau nak tune. And obviously, with minimal changes (sebab masa untuk Perf Test biasa kejap je window dia). Tapi bahaya jugak.

Sebabnya kalau salah tuning, result aku ke laut. Salah configuration, silap hari bulan, terus tak boleh akses. Salah teori, habis bazir masa aku.

Kalau tanya aku. Aku tak suka.. Dan sangat suka for the performance test ni.

So menjawab kepada persoalan bos aku tadi tu, aku jawab simply,

    Aku: Emm ok la kot.

Tapi sekali rupanya bos aku dah pergi meeting sebelum tu (aku cuti time tu) dan bos aku memang dah commit akan buat performance test.

Ciss.

Habis tu buat apa tanya aku lagi?? Hahah

...

Ok ceritanya, ni first time aku buat cloud native application. And it is going to go live! And it is for national use! And it will be used by a lot of people!!

Sebelum tu, aku jugak yang gatal cakap kat bos aku.

    Aku: En A. Untuk projek ni, saya nak go full cloud native. Boleh tak?

    En A: Kalau u ok, buat je la. Apa yang u perlukan?

Kadang ni yang buat aku suka kerja kat sini. Bos aku punya direction, aku kene execute dan aku boleh (mengada) nak mintak beli itu ini. 

So during the development, sikit - sikit aku mintak kat bos aku. Mintak software mahal. Dapat. Mintak bayarkan untuk training. Takde hal, dia ok.

So patutnya aku dah equip diri aku dengan all the required things untuk aku nak go full cloud mode. Kan?

But to be fair, masa yang diberikan sangat suntuk. So aku just ciluk sana sini mana yang aku rasa penting je aku nak tau.

Akhirnya, dapatlah aku craft satu sistem yang native cloud. Rujuk kepada rajah di bawah.

Figure 150: Aku punya achitecture lol. Ala korang bukannya tau pon aku buat projek apa kann

 

Basically aku ada 4 services running on kubernetes (microservices), tiga serverless function (FaaS), guna Cloud Relational Database Service (RDS, jenis - jenis PaaS) dan guna infra yang disediakan IaaS (LB) dan SaaS (WAF.. etc).

Fuh canggih betul teknologi sekarang.

Cumaa. Sekarang ni aku kene faham betul - betul apa yang aku buat tu. Contoh, dah kenape ada HAProxy lepas LB dan lepas tu ada LB lagi?? Dah macam tiga layer LB dah tu.

Aku sebenarnya tak suka sangat aku kene letak HAProxy selepas dari LB tu. Sebab HAProxy tu aku buat untuk nak load balancekan dari HTTP punya level (Layer 7). Sebab aku tak jumpa jugak macam mana nak set path based kat Load Balancer yang aku pakai ni. (Cloud aku pakai ni dia derived dari Huawei Cloud solution). First Load Balancer tu terlalu simple sangat. So aku kene tambah satu lagi software load balancer (HAProxy) yang boleh manipulate HTTP request.

So macam tu lah. Kenapa aku letak itu ini semua tu, ada lah sebab dia. Dan aku pilih semua managed services (cloud service) selagi mana yang boleh.

Tapi tak pe lah. Itu je yang aku boleh buat untuk masa yang singkat tu kan.

...

21 November 2024.

So the time has come. Masa yang dinantikan telah tiba.

Aku sebenarnya tak sempat betul nak run aku punya own performance test. Beberapa hari sebelum tu, aku dok sibuk meeting dengan dynatrace untuk nak configure dynatrace guna sebagai monitor resource.

Sampaikan pagi 21 Nov tu pon aku dok bermeeting dengan Dynatrace.

Aku cakap kat budak performance tester tu, "Kita strart petang boleh?".

Diorang cakap, "Boleh2."

Fuh lega aku. Rezeki dapat team yang memahami. So dengan rasa bersalah, aku buat la sampai kasi jadi.

Interestingly enough, aku dapat belajar benda baru. Dynatrace rupanya ada option guna open source untuk telemetry, nama dia OpenTelemetry.

Figure 151: OpenTelemetry reference architecture. Lawa. Jangan bandingkan dengan aku punya diagram hahah [111]

So lepas aku configure dan pastikan ianya jalan, aku cerita lah kat bos aku pasal OpenTelemetry ni (sebab dia jenis suka explore teknology baru).

En A cakap, "Menarik tu. I nak lepas ni nanti you explore dengan tengok macam mana kita nak pakai untuk future projek kita. But without the Dynatrace. Guna benda ni je".. Aku terdiam. "Tapi saya tengah banyak keje ni En A".. En A cakap balik, "Nanti2 lepas ni pon takpe".

Maka fahamlah aku. Dia kasi side quest baru. hahah (update Ogos 2025 - dia lupa, aku pon lupa pasal ni hahah)

...

21 November 2024 (petang).

So diorang pon run lah performance test tu.

Aku memang masa tu pasrah. Penat sangat. Tak sempat buat apa.

And the result ----------> FAILED.

Figure 152: Ni aku amik dari report tu. Sedih tau tak

Tapi mana ada masa nak sedih - sedih. Bak kata pakcik aku dulu - dulu, "kalau nak sedih - sedih, pergi menangis tepi longkang la wey". Tapi daripada aku nak carik longkang untuk menangis, baik aku repair apa yang boleh. Kann?

So aku mintak diorang tunggu kejap sebab masa diorang tengah run tu, aku bukak monitoring Dynatrace, dan nampak la banyak connection aku sangkut. (aku tak boleh pulak nak view lagi dynatrace tu sekarang so aku tak boleh nak access).

But basically, aku nampak banyak connection to database timed out.

Kalau korang ingat architecture aku tu, semua akan connect ke database.

Figure 153: Senak lah database aku wey

Aku memang dah agak benda ni akan berlaku. So kat dalam code aku tu, aku memang awal - awal allow untuk edit connection pooling just from configuration (budak java biasa benda ni - edit kat jdbc je, tapi kalau budak2 Python, kitorang kene buat manually and there's no standard way lol.. kau tanya 10 budak python nak buat connection pooling, semua akan kasi approach beza2).

So sementara benda tu tengah running, aku godek2 sikit code aku dan edit balik configuration connection pooling aku.

CW (gelaran budak yang run Performance Test tu) cakap, "So macam mana ni? Baru 5k dah failed?"

Aku minta tolong lagi sekali kasi masa dalam 20 minit aku update config.

Dia agree. Nasib baik ada makan2 dalam bilik meeting yang diorang run Performance Test tu. Bijak jugak Project Manager aku.

So dia pon run lah lagi sekali.

Figure 154: Magic

 

Actually takde la magic. Aku mintak 20 minit sebab, 5 minit aku guna untuk deployment semua komponen aku tu (I'm a script kiddie, but not the kid part -anymore-, instead the one that like to use script for mundane operation macam deployment ni ha). dan the rest 15 minutes tu aku test sendiri pakai jmeter aku.

Alhamdulillah lepas. Tapi ni baru 5k. Target 200k. Jauh lagi perjalanan ni.

And then, sangkut lagi.

"Fairuz, dia sangkut lagi la"

Aku check balik kat Dynatrace aku.

Ok I understood.

So aku ubah bilangan pod untuk HAProxy aku.

Ok bende - bende macam kuberenetes, pods, nodes, dan istilah istilah berkaitan ni agak baru jugak bagi aku. Ni first time aku guna container untuk deployment. Aku takde team research nak explore benda - benda macam ni. Tapi aku tetap nak venture/jump/terjun dalam new technology. Bos aku agree dan dia tau aku baru nak belajar benda ni. So dia ok je aku belajar benda baru dan terus apply for production ready product. Aku rasa bos aku percaya kat aku kot. Fuh berat tanggung jawab aku.

Figure 155: Pod, Node dan docker (containered app)

But basically korang boleh anggap pod tu macam mini VM. Cuma tak boleh nak ubah code directly kat dalam pod tu sbb ianya tak persist (panjang sikit kalau nak citer pasal ni). Kasi aku study lagi lebih lanjut, nanti aku bukak kelas. Echewahhh.

So apa yang aku buat, aku spin sikit pod itu, dan pod ini, lepas tu aku run aku punya perf test.

Aku tambahkan pod ni ke 20 and monitor ada improvement tak. Ok takde. So aku reduce balik ke 15. Aku increase another pod ke 50. Ada potential. So aku tukar lain pula.

Camtulah keje aku petang tu aku dok tukar itu ini. Just tukar the numbers je.

Aku test lagi sampai aku dapat reach 10k sebelum aku tengok dah nak masuk waktu Asar. Penat sangat. Aku perlu rehat. So aku pass ke CW punya team untuk proceed.

 

Figure 156: CW punya result

Better sikit. But not enough. I think i know where to look at. Tapi sayangnya, petang tu aku kene balik ke Johor sebab aku kena pergi ke Kluang pagi Jumaat (esoknya) tu. Tapi along the way, aku dok fikir camne aku nak improvekan lagi.

So dalam bas, aku bukak laptop dan carik apa punca dia. So aku perasan yang database tu, dia tak indexed properly. So aku tunggu data tu semua clear, baru aku try buat index.

Dan sampai je JB, aku try tuning lagi sekali bilangan pod aku dan aku run aku punya test.

Tapi masa tu dah lewat sangat. Sampai pukul 3 pagi. Tu je yang aku larat.

Aku pasrah.

Aku biarkan apa yang the best aku dapat buat masa tu, dan aku release ke team Perf Test untuk nak test pagi Jumaat tu.

 

22 November 2024 (pagi).

So team Perf Test buat lagi perf test. Alhamdulillah nampak naik.

Tapi naik ke dalam 25,000 je. Baru 10%. Sedihnya.

 

Figure 157: High response time at 25,000 users.

 

Masa tu dah pukul 12 tengah hari. CW dah mesej aku, tanya aku nak buat apa - apa lagi tak. Aku cakap kat dia, takpe nanti you guys try pukul 3 petang nanti.

Dia tanya aku, aku nak buat apa2 ke time tu. Aku senyap je.

Actually, aku dah siap buat semua auto cleanup dan all the required script untuk dia auto rebalance balik.

So.. Between 12 tengah hari ke 3 petang tu tak buat apa pon (kat server ni lah).

 

22 November 2024 (petang).

So diorang run lagi. And they notice that performance degraded!

What?

Figure 158: Performance Degraded!!

Macam mana dari 25,000 boleh turun ke 15,000 without me doing anything. Something bad has happened.

 

Figure 159: Huhuhuh

So aku cakap kat dia, pull the plug. Rehat dulu untuk petang tu. No need to proceed. Dia tanya kenapa, aku jawab je aku pon tengah takde idea nak buat apa lagi. And she's agree.

Actually aku ada idea apa aku nak buat. Tapi aku tak berani.

Aku tak berani nak fikir pasal the last and final alternative yang tinggal ni.

Tapi nampaknya macam tinggal ni je cara yang ada. 

Tapi aku masih lagi nak try fix. 

 

22 November 2024 (malam).

So malam tu, aku bukak laptop kat homestay kat Kluang tu, dan aku dok godek2 sistem aku kat cloud tu. Apa lagi yang aku boleh buat.

And then I notice. Database aku tu sloww sangat. Aku dah index dah. Tapi slowww sangat.. 

Lepas tu aku dah terus tak boleh nak akses. Allahuakhbar.

So aku raise ticket ke team cloud untuk nak tolong tengok. 

 

Figure 160

 

Tak membantu. Tak membantu langsung. Huhuu. Aku minta tolong restart instance DB. Pon sama gak. Aku siap biarkan laptop aku try connect lebih sejam. No response.

So aku try tengok kat aku punya Serverless Function log. 

Ok Serverless Function.

Ni satu teknologi yang actually developer tak perlu nak deploy code ke dalam VM atau ke dalam container. Developer hanya perlu upload code je ke cloud. I repeat. Upload code ke cloud.

Canggih sangat.

So kita tak payah nak pikir deployment plan dengan bermain dengan infra. Just upload and click sana sini je. Kat AWS dia panggil as AWS Lambda.

So dalam solution kitorang, kitorang sangat pakai benda ni untuk cleanup kitorang punya session data. Sebab session data supposed to be ephemeral data. Dia akan duduk sekejap dan akan kene buang lepas expired.

 

Figure 161

 

So aku bukak log serverless application aku.

Error.

Semua error. 

Astaghfirullah. Aku try tengok log dia, semua problem connection ke db. Dan aku memang letak log.info kat serverless aku, nampak total millions of data tak deleted properly. Dia delete dalam 10,000 data lepas tu process tu kena kill dengan master worker serverless application tu (sebab severless memang kena letak limit berapa lama dia boleh execute sebab tak nak cost tinggi). 

So aku dah nampak.

Semua perkara ni berkait.

So the rentetan dia is that,

1. Aku dan team Perf Test dok hentak buat perf test kat system.
2. System keeps building up the data in the RDS (database).
3. Serverless application try to delete the ephemeral data, tapi failed.
4. But the data keeps building up, rapidly.
5. So that is why the Perf Test degraded and database aku tak boleh akses. 

Aku duduk terdiam. Aku perhatikan je skrin.

I think I know what to do.

Tapi berani ke aku?

 

23 November 2024 - 24 November 2024

Ingat tak tadi aku cakap pasal the least idea yang aku nak implement.

Malam jumaat tu aku preparekan minda aku.

"I need to do this. I have to do this".

So what happened in these two days, aku dok bukak internet, dok tanya ChatGPT, dok carik2 best possible course of action aku nak kene buat.

This is a major thing. And aku nak kena pakai satu software yang aku tak familiar sangat.

But I need it.

 

25 November 2025. 

Pagi - pagi lagi, CW mesej aku. On tak hari ni?

Aku cakap kat dia, nanti dulu.

So aku tunggu je bos aku masuk.

Sebelum aku nak buat something major ni, aku kena dapatkan persetujuan bos aku dulu! 

Nampak je dia masuk, aku tengok dia tengah rilek2 kejap, aku jumpa dia.

Aku: Kita punya failed lagi perf test.

En A: Takpe. You try fix lagi minggu ni sampai jadi.

Aku: Saya ada idea. Tapi mungkin amik masa.

En A: What's the idea.

Aku: (explain pasal error serverless app aku dan database tu).

En A: So you nak buat apa?

Aku: Saya nak ditch database. Saya nak pakai redis.

En A: You biasa guna redis?

Aku: Tak pernah pakai. But theoritically patut ok.

En A: You jangan nak teori2.

Aku: This is the last option yang saya boleh fikir.

En A terdiam.

En A: So what you need?

Aku: Satu minggu UNINTERRUPTED. Sebab this is major changes. Saya kena tukar code. Tukar architecture. Banyak nak kena testing. Lagi pon saya tak pernah pakai redis. Banyak nak baca best practice dia.

En A: Ok. Nanti you nego dengan team CW.

Alhamdulillah. Bos aku agree. So aku terus carik CW dan explain mintak tangguh satu minggu. CW bising sebab dia kata dia the following week dia patut pergi ke off-site. So dia mintak aku nego dengan Project Manager dia.

So aku terus carik Project Manager dia. Try nego - nego. Dan alhamdulillah dia agree.

 

25 November 2025 - 29 November 2025 

So dalam minggu tu, aku dok melantak tukar itu ini. Semua benda aku cuba tukar.

Aku carik PDF pasal redis. Baca what is the best practise. And yang paling aku tekankan, what is the strategy for production. So means that, even in my development environment dan local aku, aku terus setup Production Grade Redis.

 

Figure 162: Obviously aku pilih nak pakai HA Clustered Database kat local development machine aku.

Aku tak tau macam mana, tapi alhamdulillah. Semua urusan aku dipermudahkan. Nak faham pon senang (bagus betul documentation redis kat redis.io.. No need pon baca PDF).

And surprisingly, on Rabu 27 November 2025 petang tu, aku dah siap semua dan puas hati aku test functionality.

Tinggal hari khamis pagi aku deploy ke production (remember aku pakai script je untuk deployment?) and just do minor changes.

So hari khamis petang aku terus test guna performance test aku.

Masa untuk tuning.

Aku increase this pod, tengok apa jadi. Aku increase another pod, aku tengok apa jadi.

Then jadi balik problem aku. Dia stuck at tens thousand request.

Aku diam. Aku tengok balik stack aku. And aku nampak another thing yang aku boleh improve.

 

Figure 163

Nampak kan? Macam mana sekali pon aku kena carik cara untuk pakai satu je LB. Aku kene buang HAProxy (kesayangan) aku tu.

Aku balik rumah. Rehat - rehat. Selesaikan yang fardu dulu. Borak - borak dengan orang surau. Kasi clear sikit minda aku.

Dan balik tu aku duduk balik depan kompiter aku. Aku godek2 la kat Load Balancer tu.

Alhamdulillah. Ternampak ada satu settings kecikk je untuk tukar Load Balancer L4 tu jadi as Layer 7.

So apa lagi. Terus lah aku test.

Dan alhamdulillah lagi. Semua berjaya. Aku boleh reach sampai 100,000 users.

Tapi sampai tu je. Aku increase pods aku, aku increase itu ini. Limit dia kat situ.

So tengah - tengah malam tu, aku mesej lagi team support.

Figure 164

Figure 165

 

So tengah hari jumaat tu diorang tolong upgrade kan. And alhamdulillah yang bagusnya pakai container ni, aku tak payah buat apa. Dia TUKAR kubernetes nodes ke lain (yang upgraded) tapi aku tak payah buat apa sebab dia auto deploy.

So jumaat petang tu aku test lagi.

Alhamdulillah.

Reach 200,000. Dan aku test lagi can go sampai 250,000 concurrent users.

Aku rasa aku boleh increase lagi.

But I think it is enough.

Aku penat sangat.

So the next week, aku pass ke team perf test.

 

2 December 2025

Figure 166

 

Alhamdulillah. Dapat between 250,000 and 300,000 concurrency.

CW tanya aku, "You nak tune lagi tak?" sambil gelak - gelak.

Wei dah tak nak dah. Ni dah lebih 50,000 ni pon dah ok la ni.

Aku citer kat boss aku, dia just cakap, "Good job". Aku nak dengar tu jeee.

Alhamdulillah.

...

Satu benda yang betul - betul sangat perasan masa aku buat ni, satu yang paling penting.

Kalau aku stuck dah tak tau nak buat apa, aku jumpa satu solution. Ambil wudhu dan solat sunat. Clear minda aku.

Memang betullah,

 

حَدَّثَنَا مُحَمَّدُ بْنُ كَثِيرٍ، أَخْبَرَنَا إِسْرَائِيلُ، حَدَّثَنَا عُثْمَانُ بْنُ الْمُغِيرَةِ، عَنْ سَالِمِ بْنِ أَبِي الْجَعْدِ، عَنْ عَبْدِ اللَّهِ بْنِ مُحَمَّدِ ابْنِ الْحَنَفِيَّةِ، قَالَ انْطَلَقْتُ أَنَا وَأَبِي، إِلَى صِهْرٍ لَنَا مِنَ الأَنْصَارِ نَعُودُهُ فَحَضَرَتِ الصَّلاَةُ فَقَالَ لِبَعْضِ أَهْلِهِ يَا جَارِيَةُ ائْتُونِي بِوَضُوءٍ لَعَلِّي أُصَلِّي فَأَسْتَرِيحَ - قَالَ - فَأَنْكَرْنَا ذَلِكَ عَلَيْهِ فَقَالَ سَمِعْتُ رَسُولَ اللَّهِ صلى الله عليه وسلم يَقُولُ ‏ "‏ قُمْ يَا بِلاَلُ أَقِمْ فَأَرِحْنَا بِالصَّلاَةِ ‏"‏ ‏.‏

Narrated Abdullah ibn Muhammad ibn al-Hanafiyyah: 
I and my father went to the house of my father-in-law from the Ansar to pay a sick visit to him. The time of prayer came. He said to someone of his relatives: O girl! bring me water for ablution so that I pray and get comfort. We objected to him for it. He said: I heard the Messenger of Allah (ﷺ) say: Get up, Bilal, and give us comfort by the prayer.

Sunan Abi Dawud 4986
https://sunnah.com/abudawud:4986 

Sebelum ni kita buat solat sunat on predefined time macam dhuha atau witr. But we forget that, ada banyak lagi solat sunat yang kita boleh buat. Dan kalau kita betul - betul stuck, berdoalah kepadaNya. Dan cara paling terbaik adalah dengan melakukan solat.

Aku rasa ni take out yang paling besar sekali aku dapat.