![\"\"](\"\/wp-content\/uploads\/2019\/01\/unexcepted.jpg\")
<\/a><\/p>\nBir developer olarak beklentilerimiz, hayat\u0131m\u0131zda oldu\u011fu gibi, geli\u015ftirdi\u011fimiz uygulamalarda da asl\u0131nda her \u015feyin iyi bir \u015fekilde yolunda gitmesinden yana. Geli\u015ftirdi\u011fimiz uygulamalar\u0131n gerek functional \u00f6zelliklerinin sorunsuz (bug<\/strong>‘s\u0131z) ve m\u00fc\u015fterinin istedi\u011fi gibi \u00e7al\u0131\u015fabilmesi, gerekse de iyi bir \u015fekilde non-functional \u00f6zelliklere sahip olabilmesini isteriz. \u00d6rne\u011fin performans<\/strong> kriteri.<\/p>\n Performans kriteri bir \u00e7ok zaman kullan\u0131c\u0131lar\u0131 bizim sistemimizde tutabilmemizi sa\u011flayan \u00f6nemli bir \u015feydir asl\u0131nda. D\u00fc\u015f\u00fcnsenize bir e-ticaret sitesinden al\u0131\u015fveri\u015f yapaca\u011f\u0131z ve bir \u015feyler yolunda gitmiyor. \u00dcr\u00fcnler sepete eklenmiyor ve response’lar \u00e7ok ge\u00e7 geliyor. Son kullan\u0131c\u0131 g\u00f6z\u00fcnden bakarsak, ne kadar da s\u0131k\u0131c\u0131 bir durum de\u011fil mi?<\/p>\n Uygulamam\u0131z \u00e7ok g\u00fczel olabilir fakat performans kriterinin etkileri, uygulamaya k\u00f6t\u00fc bir \u015fekilde yans\u0131yacakt\u0131r.<\/p>\n Biz developer’lara ise burada b\u00fcy\u00fck bir i\u015f d\u00fc\u015f\u00fcyor. \u0130yi performansa sahip bir uygulama geli\u015ftirmek veya iyile\u015ftirmek istiyorsak, uygulamam\u0131z\u0131n hangi par\u00e7as\u0131n\u0131n bottleneck’e d\u00fc\u015ft\u00fc\u011f\u00fcn\u00fc biliyor olmal\u0131y\u0131z ki o noktaya odaklanabilelim.<\/p>\n Her neyse diyece\u011fim o ki, “yaz\u0131l\u0131m geli\u015ftirme” sadece “programlamadan” ibaret de\u011fil. Programlamadan daha fazlas\u0131. Geli\u015ftirdi\u011fimiz bir uygulama her zaman bekledi\u011fimiz gibi davranmayabilir. Beklenmedik zamanlarda performans problemleri ya\u015fanabilir veya insan fakt\u00f6r\u00fcnden kaynakl\u0131 bug’lar meydana gelebilir. San\u0131r\u0131m buradaki as\u0131l nokta ise, ka\u00e7\u0131n\u0131lmaz olan bu ger\u00e7ekler kar\u015f\u0131s\u0131nda nas\u0131l ayakta durabilece\u011fimiz ve \u00fcstesinden nas\u0131l gelebilece\u011fimizdir.<\/p>\n Bu arada “beklenmedik zamanlar\u0131n” i\u015fe yarad\u0131\u011f\u0131 farkl\u0131 konular da var elbette.<\/p><\/blockquote>\n Asl\u0131nda konuyu ba\u011flamak istedi\u011fim nokta ise, Grace Hopper<\/em><\/strong>‘\u0131nda terimlerinde \u00f6nc\u00fcl\u00fck etti\u011fi “bug<\/strong>” ve “debugging<\/strong>” i\u015flemleri.<\/p>\n \u00d6zellikle “debugging<\/em>” ve “profiling<\/em>” i\u015flemlerini runtime \u00fczerinde ger\u00e7ekle\u015ftirmek s\u00f6z konusu olunca, san\u0131r\u0131m as\u0131l challenge<\/strong> ozaman bizim i\u00e7in ba\u015fl\u0131yor.<\/p>\n Bu makale kapsam\u0131nda ise daha \u00f6nce “dotnet reconnect()<\/em><\/a>” etkinli\u011finde de konu\u015fmac\u0131 olarak anlatm\u0131\u015f oldu\u011fum,\u00a0.NET Core<\/em> ile geli\u015ftirmi\u015f oldu\u011fumuz uygulamalar\u0131n linux \u00fczerindeki debugging ve profiling i\u015flemlerini nas\u0131l ger\u00e7ekle\u015ftirebiliriz konusuna bir ka\u00e7 \u00f6rnek use-case ile iki farkl\u0131 makale serisi olarak genel bir bak\u0131\u015f atmaya \u00e7al\u0131\u015faca\u011f\u0131z.<\/p>\n Makale serisi boyunca debugging ve profiling i\u015flemleri s\u0131ras\u0131nda, “Perf<\/em>“, “LTTng<\/em>” “gcore<\/em>“, “FlameGraph” ve “LLDB<\/em>” gibi tool’lardan yararlan\u0131yor olaca\u011f\u0131z. Bu 1. makale serisinde ise, “sampling<\/em>” ve “tracing<\/em>” kavramlar\u0131na bir giri\u015f yapaca\u011f\u0131z ve perf<\/em>\u00a0tool’u ile bir profiling i\u015flemi ard\u0131ndan lttng<\/em>\u00a0tool’u ile de bir tracing i\u015flemi ger\u00e7ekle\u015ftirece\u011fiz.<\/p>\n NOT<\/strong>: Makale boyunca, windows ortam\u0131nda bu tarz i\u015flere yabanc\u0131 olmad\u0131\u011f\u0131n\u0131z varsay\u0131m\u0131yla ilerliyor olaca\u011f\u0131m.<\/p><\/blockquote>\n Debugging & Profiling i\u015flemlerine ba\u015flamadan \u00f6nce, iki farkl\u0131 kavramdan bahsetmek istiyorum. CPU<\/em> \u00f6l\u00e7\u00fcm\u00fc s\u00f6z konusu oldu\u011funda, iki farkl\u0131 measurement mode’una sahibiz. Bunlardan birisi sampling<\/strong>, bir di\u011feri ise tracing<\/strong>‘dir.<\/p>\n Sampling tercih edildi\u011finde, profiler periyodik olarak ilgili kodun yava\u015f \u00e7al\u0131\u015fan k\u0131s\u0131mlar\u0131n\u0131 bulabilmek i\u00e7in thread’lerin call stack’lerini query’lemektedir. Yani belirli window’larda snapshot’lar almaktad\u0131r.<\/p>\n Sampling genelde long running method’larda veya performans bottleneck’lerine kar\u015f\u0131 ilk kez bir g\u00f6z at\u0131lacaksa, iyi bir se\u00e7enektir. Sampling mode’u uygulamaya herhangi bir overhead<\/strong> getirmemektedir ve\u00a0CPU<\/em> time’lar\u0131n\u0131 elde edebilmek m\u00fcmk\u00fcnd\u00fcr. Sampling i\u015fleminin tek dezavantaj\u0131 ise belirli window’larda snapshot’lar ald\u0131\u011f\u0131 i\u00e7in, t\u00fcm call stack’leri capture edememektedir.<\/p>\n Sampling’in aksine tracing mode’u tercih edildi\u011finde ise, profiler, profile edilen her bir method i\u00e7inde harcanan thread CPU<\/em> time’\u0131n\u0131 kaydedebilmek i\u00e7in method invocation’lar\u0131n\u0131 izlemektedir (entry & exit gibi).<\/p>\n Tracing i\u015flemi sampling’in aksine, bize daha detayl\u0131 bilgiler sunmaktad\u0131r. Burada CPU<\/em> time’lar\u0131n\u0131n yan\u0131nda, method invocation count’lar\u0131 da elde edilebilmektedir. Elbette burada bir overhead<\/strong> s\u00f6z konusudur.<\/p>\n Genelde tracing i\u015flemini belirli senaryolarda veya sampling ile elde etti\u011fimiz sonu\u00e7lar yeterli gelmedi\u011fi durumlarda tercih edebiliriz.<\/p>\n Perf<\/em>, linux-based sistemler i\u00e7in performans ara\u015ft\u0131rmas\u0131 yapabilmemizi sa\u011flayan event-oriented bir profiling tool’udur.<\/p>\n Perf<\/em>,\u00a0kernel<\/strong> ve hardware<\/strong> event’leri ba\u015fta olmak \u00fczere, bir \u00e7ok event i\u00e7in hem tracing hem de sampling konular\u0131nda yeteneklidir. Ayr\u0131ca perf<\/em>, linux kernel’\u0131n\u0131n “perf_events<\/em>” interface’ini temel almaktad\u0131r ve “perf_events<\/em>” e ise attach edebilece\u011fimiz bir \u00e7ok event source mevcuttur.<\/p>\n \u00d6rne\u011fin:<\/p>\n Profiling i\u015flemine ba\u015flamadan \u00f6nce, \u00f6rnek ger\u00e7ekle\u015ftirebilmemiz i\u00e7in k\u00f6t\u00fc bir uygulamaya ihtiyac\u0131m\u0131z var. Siz dilerseniz mevcut uygulamalar\u0131n\u0131z \u00fczerinden de ilerleyebilirsiniz. Sonu\u00e7 olarak amac\u0131m\u0131z, uygulamalar\u0131m\u0131z\u0131n CPU<\/em> activity’lerini g\u00f6zlemleyebilmek.<\/p>\n Ben \u00f6rnek ger\u00e7ekle\u015ftirebilmek ad\u0131na,\u00a0fazlas\u0131yla CPU<\/em> consuming’i yapabilecek bir console uygulamas\u0131 olu\u015fturaca\u011f\u0131m. Bu console uygulamas\u0131 kendisine verilen bir dizi say\u0131n\u0131n, ilgili index’indeki asal say\u0131y\u0131 bulan ve ard\u0131ndan karek\u00f6k’\u00fcn\u00fc hesaplayan bir uygulama olacak (Biraz abartm\u0131\u015f olabilirim, \u00f6rne\u011fe odaklanmayal\u0131m).<\/p>\n Olu\u015fturmu\u015f oldu\u011fum \u00f6rnek uygulama ise a\u015fa\u011f\u0131daki gibidir.<\/p>\n “PrimeNumberFinderHelper.cs<\/em>” file’\u0131:<\/p>\n ve “Program.cs<\/em>” file’\u0131 ise a\u015fa\u011f\u0131daki gibidir.<\/p>\n CPU<\/em> intensive \u00e7al\u0131\u015facak ve call chain’i g\u00f6rebilece\u011fimiz \u00f6rnek console uygulamam\u0131z yukar\u0131daki gibidir.<\/p>\n Perf ile profiling i\u015flemine ba\u015flamadan \u00f6nce, bilmemiz gereken bir nokta var. Perf, di\u011fer debugging tool’lar\u0131nda da oldu\u011fu gibi, bizlere anlaml\u0131 bir sonu\u00e7 verebilmesi i\u00e7in “symbol<\/em>” bilgilerine ihtiya\u00e7 duymaktad\u0131r. T\u0131pk\u0131 “pdb<\/em>” file’lar\u0131 gibi.<\/p>\n Bu sayede profile i\u015flemi sonucunda elde edece\u011fimiz bellek adresleri, bizlerin anlayabilece\u011fi bir \u015fekilde “method name<\/em>” ve “variable name’lere<\/em>” d\u00f6n\u00fc\u015fecektir. Aksi halde C#<\/em> gibi compiled dillerde sadece hexadecimal de\u011ferleri g\u00f6r\u00fcr\u00fcz.<\/p>\n Symbol bilgilerini sa\u011flayabilmek i\u00e7in enable etmemiz gereken bir environment<\/strong> de\u011feri bulunmaktad\u0131r. “COMPlus_PerfMapEnabled<\/em>” de\u011ferini enable etti\u011fimizde, CoreCLR<\/em>‘a debug bilgilerini perf’<\/em>\u00fcn kullanabilmesi i\u00e7in vermesi gerekti\u011fini s\u00f6ylemi\u015f oluyoruz.<\/p>\n \u015eimdi environment de\u011ferini a\u015fa\u011f\u0131daki gibi enable edelim ve console uygulamam\u0131z\u0131 \u00e7al\u0131\u015ft\u0131ral\u0131m.<\/p>\n Environment de\u011ferini enable ettik ve uygulamay\u0131 bi hayli zorlayacak bir asal say\u0131y\u0131 bulmas\u0131n\u0131 s\u00f6yledik.<\/p>\n Peki \u015fimdi sistem ne durumda?<\/p>\n Hemen “top<\/em>” command’\u0131n\u0131 yazal\u0131m ve process’lere bir bakal\u0131m.<\/p>\n G\u00f6rd\u00fcn\u00fcz m\u00fc? “30989<\/em>” id’li process, CPU<\/em>‘nun %100 \u00fcn\u00fc kullan\u0131yor!<\/p>\n Haydi bu process’i bir profile edelim. Bir bakal\u0131m uygulamam\u0131z nerede bottleneck’e d\u00fc\u015f\u00fcyor ve hangi kod path’ine odaklanmam\u0131z gerekiyor.<\/p>\n En basit haliyle, “30989<\/em>” id’li process i\u00e7in a\u015fa\u011f\u0131daki komut sat\u0131r\u0131 ile bir profiling i\u015flemi ba\u015flatal\u0131m.<\/p>\n NOT<\/strong>: Kullanabilece\u011fimiz farkl\u0131 parametreler de mevcut. \u0130lgili listeye buradan<\/a><\/em> ula\u015fabilirsiniz.<\/p><\/blockquote>\n Bir ka\u00e7 saniye i\u00e7erisinde ise sampling i\u015flemini durdural\u0131m. Sonucuna bakarsak, perf<\/em>, bir ka\u00e7 saniye i\u00e7erisinde “4.078<\/em>” MB’l\u0131k “19558<\/em>” adet sample elde edebilmi\u015f. Bu elde etti\u011fi sonu\u00e7lar\u0131 ise, “perf.data<\/em>” isimli bir file’a yazm\u0131\u015f.<\/p>\n NOT<\/strong>: E\u011fer \u00e7ok s\u0131k \u00e7a\u011fr\u0131lan bir event dinleniyorsa, “perf.data<\/em>” file’\u0131n\u0131n boyutu olduk\u00e7a b\u00fcy\u00fck olacakt\u0131r. Bunun yerine, “Memory Mapped Buffer” \u0131 kullanarak real-time olarak profiling i\u015flemini ger\u00e7ekle\u015ftirebilmek de m\u00fcmk\u00fcnd\u00fcr.<\/p><\/blockquote>\n Elde etmi\u015f oldu\u011fumuz bu “perf.data<\/em>” dosyas\u0131n\u0131 ister ayn\u0131 makina \u00fczerinde, isterseniz de farkl\u0131 bir makinaya ta\u015f\u0131yarak analiz etme i\u015flemini ger\u00e7ekle\u015ftirebilirsiniz.<\/p>\n Peki, elde etmi\u015f oldu\u011fumuz bu profiling sonucunu nas\u0131l yorumlayabiliriz? Yine en basit haliyle, a\u015fa\u011f\u0131daki komut sat\u0131r\u0131n\u0131 \u00e7al\u0131\u015ft\u0131rarak.<\/p>\n NOT<\/strong>: Profiling sonucunu yorumlarken herhangi bir regular user veya root user karma\u015fas\u0131 ya\u015famamak ad\u0131na, “-f<\/em>” parametresi ile herhangi bir ownership do\u011frulamas\u0131n\u0131n yap\u0131lmamas\u0131n\u0131 sa\u011flayabiliriz.<\/p><\/blockquote>\n Evet, “30989″ <\/em>id’li process’in\u00a0profiling sonucu art\u0131k kar\u015f\u0131m\u0131zda. Yukar\u0131daki sonu\u00e7 \u00fczerinden, process’in call stack’leri \u00fczerindeki CPU<\/em> activity’lerini g\u00f6rebilmek m\u00fcmk\u00fcnd\u00fcr. “Symbol<\/em>” k\u0131s\u0131mlar\u0131na dikkat edersek, bizi ilgilendiren noktalar\u0131n method name ve variable name’lere d\u00f6n\u00fc\u015ft\u00fc\u011f\u00fcn\u00fc g\u00f6rebiliriz.<\/p>\n “Children<\/em>” k\u0131sm\u0131 subsequent call’lar\u0131n overhead’lerini g\u00f6stermektedir. \u0130lk sat\u0131ra bakarsak, “Children<\/em>” k\u0131sm\u0131n\u0131n %100<\/strong> oldu\u011funu, fakat “Self<\/em>” k\u0131sm\u0131n\u0131n %0<\/strong> oldu\u011funu g\u00f6rebiliriz. Yani “Children<\/em>” k\u0131sm\u0131 bize diyor ki, “ben maliyetli bir yolda ilerliyorum, fakat o maliyetli yol \u015fu an buras\u0131 de\u011fil”. “Self<\/em>” k\u0131sm\u0131 ise, o maliyetli k\u0131sm\u0131n oldu\u011fu yer.<\/p>\n Highlight yapt\u0131\u011f\u0131m sat\u0131ra bakarsak, “Self<\/em>” de\u011ferinin %99.93<\/strong> oldu\u011funu g\u00f6rebiliriz. Bu process i\u00e7in CPU<\/em> consuming’inin ger\u00e7ekle\u015fti\u011fi noktan\u0131n, “PrimeNumberFinderHelper<\/em>” class’\u0131 i\u00e7erisindeki “FindNthPrimeNumber<\/em>” method’unda ger\u00e7ekle\u015fti\u011fini s\u00f6yleyebiliriz. Bizim bir developer olarak odaklanmam\u0131z gereken nokta!<\/p>\n Peki, bu “PrimeNumberFinderHelper<\/em>” instance’\u0131 nerede kullan\u0131l\u0131yor? Haydi biraz daha kaz\u0131yal\u0131m, call’lara bakal\u0131m! Bunun i\u00e7in highlight edilmi\u015f sat\u0131r\u0131n \u00fczerinde, “enter<\/em>” tu\u015funa basmam\u0131z yeterli olacakt\u0131r.<\/p>\n Bottleneck’in oldu\u011fu tree’nin en alt k\u0131sm\u0131na bakarsak, kod ak\u0131\u015f\u0131n\u0131n “PrimeNumberFinder.Program::Main<\/em>” method’undan ge\u00e7tikten sonra, “PrimeNumberFinderHelper<\/em>” class’\u0131n\u0131n instance’\u0131 \u00fczerinden “FindNthPrimeNumber<\/em>” method’unu call etti\u011fini g\u00f6rebiliriz.<\/p>\n NOT<\/strong>: Perf<\/em>‘\u00fcn “report<\/em>” command’\u0131nda da kullan\u0131labilecek bir \u00e7ok farkl\u0131 parametreler mevcuttur. \u00d6rne\u011fin verbose seviyesini artt\u0131rabilirsiniz, symbol bilgileri resolve edilmeyenleri gizleyebilirsiniz veya call graph’i farkl\u0131 parametrelere g\u00f6re g\u00f6r\u00fcnt\u00fcleyebilirsiniz. Detayl\u0131 listeye buradan<\/a><\/em> eri\u015febilirsiniz.<\/p><\/blockquote>\n En basit haliyle, process \u00fczerinde bir sampling i\u015flemi ger\u00e7ekle\u015ftirerek problemli noktam\u0131z\u0131 belirlemi\u015f olduk. Art\u0131k bir developer olarak odaklanmam\u0131z gereken noktay\u0131 biliyoruz.<\/p>\n Runtime event’lerinin tracing konusunda ise lttng<\/em> tool’undan yararlanaca\u011f\u0131z.\u00a0LTTng<\/em>, CoreCLR<\/em>‘\u0131n build-time’da generate etti\u011fi tracepoint’leri kullanarak, user-space<\/strong> event’lerini handle etmektedir (yani runtime service’leri ve application-level event’ler gibi). LTTng<\/em>, windows taraf\u0131ndaki ETW<\/em> (Event Tracing for Windows) event’lere benzer bir \u015fekilde, daha zor yani daha derinlemesine problemleri ele alabilmemize olanak sa\u011flayan lightweight bir tracing framework’\u00fcd\u00fcr.<\/p>\n Ne yaz\u0131kki ETW<\/em> events, linux ortam\u0131nda bulunmamaktad\u0131r.\u00a0ETW<\/em> event’lere benzer bir \u015fekilde tracing i\u015flemlerini linux ortam\u0131nda ise lttng<\/em> framework’\u00fc ile ger\u00e7ekle\u015ftirebilmekteyiz.<\/p>\n LTTng<\/em> ile trace edebilece\u011fimiz baz\u0131 event’lere bakarsak:<\/p>\n gibi event’leri trace edebilmek m\u00fcmk\u00fcnd\u00fcr. Perf<\/em>‘de oldu\u011fu gibi trace file’\u0131 ister ayn\u0131 makina \u00fczerinde istersek de ba\u015fka bir makina \u00fczerinde analyze edebilmek m\u00fcmk\u00fcnd\u00fcr.<\/p>\n Peki, az laf \u00e7ok i\u015f diyelim ve uygulamaya ge\u00e7elim.<\/p>\n LTTng<\/em> ile ger\u00e7ekle\u015ftirece\u011fimiz \u00f6rnek senaryoda ise bir API<\/em>‘\u0131m\u0131z oldu\u011funu ve bu API<\/em>‘\u0131n, memory’sini efficient bir \u015fekilde kullanmas\u0131 gerekti\u011fini d\u00fc\u015f\u00fcnelim.<\/p>\n LTTng<\/em> ile tracing i\u015flemine ba\u015flamadan \u00f6nce enable etmemiz gereken bir environment<\/strong> de\u011feri bulunmaktad\u0131r. “COMPlus_EnableEventLog<\/em>” de\u011ferini enable etti\u011fimizde, CoreCLR<\/em>‘a event log’lar\u0131 kullanabilmemiz i\u00e7in generate etmesini s\u00f6ylemi\u015f oluyoruz.<\/p>\n \u00d6rnek API<\/em>‘\u0131n kaynak kodlar\u0131na ise buradan<\/a><\/em> ula\u015fabilirsiniz. Perf<\/em> ile ger\u00e7ekle\u015ftirmi\u015f oldu\u011fumuz \u00f6rne\u011fe benzemektedir. Bu API<\/em> i\u00e7erisindeki “api\/calculate<\/em>” endpoint’ine bir dizi say\u0131lar g\u00f6nderece\u011fiz ve ard\u0131ndan API<\/em> i\u00e7erisinde olu\u015fan object allocation<\/strong>‘lara bir bakaca\u011f\u0131z.<\/p>\n Kullanaca\u011f\u0131m\u0131z komut sat\u0131rlar\u0131 ise a\u015fa\u011f\u0131daki gibidir.<\/p>\n \u0130lk komut sat\u0131r\u0131nda “gc-trace<\/em>” ad\u0131nda bir session olu\u015fturmas\u0131n\u0131 ve ilgili tracing \u00e7\u0131kt\u0131lar\u0131n\u0131 “dotnetkonf-trace<\/em>” path’i alt\u0131nda toplamas\u0131 gerekti\u011fini s\u00f6yedik. Sonraki sat\u0131rlarda ise “lttng add-context<\/em>” parametresi ile, her bir event’in “process id<\/em>“, “thread id<\/em>” ve “process name<\/em>” gibi bilgilere sahip olmas\u0131n\u0131 istedi\u011fimizi belirttik.<\/p>\n En \u00f6nemlisi ise “lttng enable-event<\/em>” parametresi ile, trace etmek istedi\u011fimiz tracepoint’<\/strong>leri tan\u0131mlad\u0131k. Bu sayede CoreCLR<\/em> taraf\u0131ndan generate edilecek olan “DotNETRuntime:GCStart*”<\/em>\u00a0ve “GCAllocationTick*”\u00a0<\/em>gibi \u00f6nemli event’leri trace edebilece\u011fiz. T\u00fcm bunlar\u0131n ard\u0131ndan tracing i\u015flemini ba\u015flat\u0131yoruz ve “20<\/em>” saniye gibi bir s\u00fcre beklettikten sonra (tracing i\u015flemi, sampling i\u015fleminin aksine biraz zaman gerektiren bir i\u015flemdir) i\u015flemi durdurup, session’\u0131 destroy ediyoruz.<\/p>\n NOT<\/strong>: Bu komutlar\u0131n hepsini tek tek yazmak elbette zor olacakt\u0131r. Bu sebeple dilerseniz sizde benim yararland\u0131\u011f\u0131m makefile’a buradan<\/a><\/em> eri\u015febilir ve kullanabilirsiniz.<\/p><\/blockquote>\n Tracing i\u015flemini ba\u015flatmadan \u00f6nce a\u015fa\u011f\u0131daki gibi \u00f6rnek API<\/em>‘\u0131 \u00e7al\u0131\u015ft\u0131ral\u0131m ve “api\/calculate?<\/span>nums=100,200,300,400,500<\/em>” URL<\/em>‘ine biraz istek g\u00f6nderelim. Ben istek g\u00f6nderme i\u015flemini\u00a0Apache Bench <\/em>vas\u0131tas\u0131yla\u00a0ger\u00e7ekle\u015ftirece\u011fim.<\/p>\n \u0130stek g\u00f6nderme i\u015flemi devam ederken yani uygulamam\u0131z aktif olarak \u00e7al\u0131\u015f\u0131rken, tracing i\u015flemini a\u015fa\u011f\u0131daki gibi ba\u015flatal\u0131m. Tracing i\u015flemi 20<\/em> saniye bekledikten sonra duracakt\u0131r.<\/p>\n Peki “dotnetkonf-trace<\/em>” path’i alt\u0131nda toplanan tracing sonu\u00e7lar\u0131n\u0131 nas\u0131l yorumlayabiliriz? \u0130lk se\u00e7enek olarak, default gelen simple bir viewer olan babeltrace<\/em>‘i kullanabiliriz.<\/p>\n Dilerseniz daha user-friendly olan,\u00a0Eclipse Trace Compass<\/em> \u00fcr\u00fcn\u00fcn\u00fc de kullanabilirsiniz. Tracing sonu\u00e7lar\u0131 CTF<\/em>(Common Trace Format) format\u0131nda \u00e7\u0131kt\u0131\u011f\u0131 i\u00e7in, Trace Compas<\/em>s ile g\u00f6rsel olarak da g\u00f6r\u00fcnt\u00fcleyebilmek m\u00fcmk\u00fcnd\u00fcr.<\/p>\n Her neyse, a\u015fa\u011f\u0131daki komut sat\u0131r\u0131 ile tracing sonucuna bakmaya ba\u015flayal\u0131m.<\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\nSampling & Tracing<\/h2>\n
Sampling<\/h3>\n
Tracing<\/h3>\n
1 – Perf ile CPU<\/em> Activity’lerini Profile Etmek<\/h2>\n
<\/a><\/p>\n\n
Perf ile basit bir Profiling<\/h3>\n
using System;\r\n\r\nnamespace PrimeNumberFinder\r\n{\r\n public class PrimeNumberFinderHelper\r\n {\r\n public long FindNthPrimeNumber(int number)\r\n {\r\n int count = 0;\r\n long a = 2;\r\n\r\n while (count < number)\r\n {\r\n long b = 2;\r\n int prime = 1;\r\n while (b * b <= a) { if (a % b == 0) { prime = 0; break; } b++; } if (prime > 0)\r\n {\r\n count++;\r\n }\r\n a++;\r\n }\r\n return (--a);\r\n }\r\n }\r\n}<\/pre>\nusing System;\r\nusing System.Linq;\r\nusing System.Threading;\r\n\r\nnamespace PrimeNumberFinder\r\n{\r\n class Program\r\n {\r\n static PrimeNumberFinderHelper _primeNumberFinderHelper;\r\n\r\n static void Main(string[] args)\r\n {\r\n int[] numbers = GetNumbersFromArgs(args);\r\n\r\n for (int number = 0; number < numbers.Length; number++) { Console.WriteLine(\"Finding {0}nth prime number...\", numbers[number]); _primeNumberFinderHelper = new PrimeNumberFinderHelper(); long nthPrimeNumber = FindNthPrimeNumber(numbers[number]); Console.WriteLine(\"{0}nth prime number is {1}.\", numbers[number], nthPrimeNumber); double squareRootOfNthPrimeNumber = FindSquareRootOfNthPrimeNumber(nthPrimeNumber); Console.WriteLine(\"Square root of {0}nth prime number is {1}.\", numbers[number], squareRootOfNthPrimeNumber); } Console.WriteLine(\"Done!\"); } private static int[] GetNumbersFromArgs(string[] args) { return args.Select(x =>\r\n {\r\n (bool, int) input = CheckIsItANumber(x);\r\n\r\n if (input.Item1)\r\n {\r\n return input.Item2;\r\n }\r\n\r\n return default(int);\r\n }).ToArray();\r\n }\r\n\r\n \/\/Some child methods for profiling callchain.\r\n static double FindSquareRootOfNthPrimeNumber(double nthPrimeNumber)\r\n {\r\n double squareRoot = 0;\r\n\r\n squareRoot = Math.Sqrt(nthPrimeNumber);\r\n\r\n Thread.Sleep(10000);\r\n\r\n return squareRoot;\r\n }\r\n\r\n \/\/Some child methods for profiling callchain.\r\n static long FindNthPrimeNumber(int number)\r\n {\r\n \/\/CPU intensive sample for profiling with perf on linux.\r\n long nthPrimeNumber = _primeNumberFinderHelper.FindNthPrimeNumber(number);\r\n\r\n return nthPrimeNumber;\r\n }\r\n\r\n \/\/Some child methods for profiling callchain.\r\n static (bool, int) CheckIsItANumber(string num)\r\n {\r\n int? result = null;\r\n\r\n try\r\n {\r\n result = int.Parse(num);\r\n }\r\n catch (System.Exception ex)\r\n {\r\n Console.WriteLine(\"Exception occured while parsing.\");\r\n }\r\n\r\n return (result != null, result.GetValueOrDefault()); \/\/ It can be cause wrong business logic.\r\n }\r\n }\r\n}<\/pre>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\nperf record -g -p 30989<\/pre>\n
<\/a><\/p>\n\n
perf report -f<\/pre>\n
<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n2 – LTTng ile Runtime Event’lerini Trace Etmek<\/h2>\n
<\/a><\/p>\n<\/a><\/p>\n\n
sudo lttng create gc-trace -o .\/dotnetkonf-trace\r\nsudo lttng add-context --userspace --type vpid\r\nsudo lttng add-context --userspace --type vtid\r\nsudo lttng add-context --userspace --type procname\r\nsudo lttng enable-event --userspace --tracepoint DotNETRuntime:GCStart*\r\nsudo lttng enable-event --userspace --tracepoint DotNETRuntime:GCEnd*\r\nsudo lttng enable-event --userspace --tracepoint DotNETRuntime:GCHeapStats*\r\nsudo lttng enable-event --userspace --tracepoint DotNETRuntime:GCAllocationTick*\r\nsudo lttng enable-event --userspace --tracepoint DotNETRuntime:GCTriggered\r\nsudo lttng start\r\nsleep 20\r\nsudo lttng stop\r\nsudo lttng destroy<\/pre>\n
ab -n 10000 localhost:5000\/api\/calculate?nums=100,200,300,400,500<\/pre>\n
<\/a><\/p>\n<\/a><\/p>\n