G\u00fcn\u00fcm\u00fcz web uygulamalar\u0131nda performans ve yan\u0131t s\u00fcresi kritik \u00f6neme sahiptir. Bu hedeflere ula\u015fmak i\u00e7in paralel HTTP istekleri yapmak yayg\u0131n bir stratejidir. Ancak, bu yakla\u015f\u0131m beraberinde kararl\u0131l\u0131k, kaynak y\u00f6netimi ve hata tolerans\u0131 gibi zorluklar\u0131 da getirir. Bu makalede, Go programlama dilinin e\u015fzamanl\u0131l\u0131k yeteneklerini kullanarak paralel HTTP isteklerini nas\u0131l daha kararl\u0131 hale getirebilece\u011fimizi, bir Markdown linter geli\u015ftirirken edindi\u011fimiz deneyimler \u0131\u015f\u0131\u011f\u0131nda detayl\u0131ca inceleyece\u011fiz.<\/p>\n
Paralel istekler, birden fazla HTTP iste\u011fini ayn\u0131 anda veya \u00e7ak\u0131\u015f\u0131k bir \u015fekilde y\u00fcr\u00fcterek uygulamalar\u0131n genel i\u015flem s\u00fcresini \u00f6nemli \u00f6l\u00e7\u00fcde azaltabilir. Bu, \u00f6zellikle d\u0131\u015f kaynaklardan veri \u00e7ekerken veya birden fazla API’yi sorgularken b\u00fcy\u00fck bir avantaj sa\u011flar.<\/p>\n
Bir uygulaman\u0131n ayn\u0131 anda birden fazla ba\u011f\u0131ms\u0131z g\u00f6revi yerine getirebilmesi, kullan\u0131c\u0131 deneyimini do\u011frudan iyile\u015ftirir. \u00d6rne\u011fin, bir web sayfas\u0131n\u0131n farkl\u0131 bile\u015fenlerini (resimler, CSS, JS dosyalar\u0131) paralel olarak y\u00fcklemek, sayfan\u0131n toplam y\u00fcklenme s\u00fcresini k\u0131salt\u0131r. Benzer \u015fekilde, bir linter\u0131n binlerce harici ba\u011flant\u0131y\u0131 kontrol etmesi gerekti\u011finde, her birini s\u0131rayla kontrol etmek yerine paralel olarak yapmak, i\u015flemi dakikalardan saniyelere indirebilir.<\/p>\n
Paralel isteklerin kontrols\u00fcz kullan\u0131m\u0131, sunucu kaynaklar\u0131n\u0131n (CPU, bellek, a\u011f ba\u011flant\u0131lar\u0131) h\u0131zla t\u00fckenmesine yol a\u00e7abilir. Hedef sunuculara a\u015f\u0131r\u0131 y\u00fck bindirmek, h\u0131z s\u0131n\u0131rlamalar\u0131na (rate limiting) tak\u0131lmaya veya IP adresinizin engellenmesine neden olabilir. Ayr\u0131ca, a\u011f kesintileri, sunucu hatalar\u0131 veya zaman a\u015f\u0131mlar\u0131 gibi hata durumlar\u0131, paralel sistemlerde y\u00f6netilmesi daha karma\u015f\u0131k hale gelir. Bu hatalar\u0131n do\u011fru bir \u015fekilde ele al\u0131nmamas\u0131, uygulaman\u0131n \u00e7\u00f6kmesine veya tutars\u0131z sonu\u00e7lar \u00fcretmesine neden olabilir.<\/p>\n
Mikroservis mimarileri ve da\u011f\u0131t\u0131k sistemler, paralel istekleri temel bir yap\u0131 ta\u015f\u0131 olarak kullan\u0131r. Bir servisin birden fazla ba\u015fka servisle ileti\u015fim kurmas\u0131 gerekti\u011finde, bu ileti\u015fimlerin paralel ve kararl\u0131 bir \u015fekilde y\u00fcr\u00fct\u00fclmesi, t\u00fcm sistemin performans\u0131n\u0131 ve g\u00fcvenilirli\u011fini do\u011frudan etkiler. Bu nedenle, paralel isteklerin do\u011fru bir \u015fekilde tasarlanmas\u0131 ve uygulanmas\u0131, modern yaz\u0131l\u0131m mimarileri i\u00e7in vazge\u00e7ilmezdir.<\/p>\n
Go, e\u015fzamanl\u0131l\u0131k i\u00e7in yerle\u015fik ve g\u00fc\u00e7l\u00fc mekanizmalar sunar. Bu mekanizmalar, paralel HTTP isteklerini y\u00f6netmeyi di\u011fer dillere g\u00f6re daha kolay ve verimli hale getirir.<\/p>\n
Go’nun e\u015fzamanl\u0131l\u0131k modelinin kalbinde “goroutine”ler bulunur. Goroutine’ler, i\u015fletim sistemi i\u015f par\u00e7ac\u0131klar\u0131na g\u00f6re \u00e7ok daha hafif (birka\u00e7 KB y\u0131\u011f\u0131n belle\u011fi ile ba\u015flar) ve Go \u00e7al\u0131\u015fma zaman\u0131 taraf\u0131ndan y\u00f6netilen i\u015f par\u00e7ac\u0131klar\u0131d\u0131r. Binlerce hatta y\u00fcz binlerce goroutine’i ayn\u0131 anda \u00e7al\u0131\u015ft\u0131rmak m\u00fcmk\u00fcnd\u00fcr, bu da paralel HTTP istekleri gibi G\/\u00c7 yo\u011fun g\u00f6revler i\u00e7in idealdir. Bir fonksiyonun ba\u015f\u0131na Goroutine’ler aras\u0131nda g\u00fcvenli ve etkili ileti\u015fim kurman\u0131n ana yolu “channel”lard\u0131r. Channel’lar, goroutine’lerin birbirlerine veri g\u00f6ndermesini ve almas\u0131n\u0131 sa\u011flayan tip g\u00fcvenli borular gibidir. Bu, payla\u015f\u0131lan bellek \u00fczerinden kilitleme mekanizmalar\u0131 kullanmak yerine, “payla\u015f\u0131lan bellek \u00fczerinden ileti\u015fim kurmak yerine, ileti\u015fim kurarak belle\u011fi payla\u015f” (Don’t communicate by sharing memory; instead, share memory by communicating) felsefesini destekler. Bu yakla\u015f\u0131m, veri yar\u0131\u015flar\u0131n\u0131 (data races) b\u00fcy\u00fck \u00f6l\u00e7\u00fcde azalt\u0131r ve e\u015fzamanl\u0131 programlamay\u0131 basitle\u015ftirir.<\/p>\n <\/code> Go'nun Paralel HTTP istekleri yaparken kar\u015f\u0131la\u015fabilece\u011fimiz temel kararl\u0131l\u0131k sorunlar\u0131n\u0131 ve bunlar\u0131n Go'da nas\u0131l ele al\u0131nabilece\u011fini anlamak \u00f6nemlidir.<\/p>\n Harici servislere yap\u0131lan HTTP istekleri, a\u011f sorunlar\u0131, sunucu y\u00fck\u00fc veya yava\u015f yan\u0131t s\u00fcreleri nedeniyle tak\u0131l\u0131 kalabilir. Bu durum, uygulaman\u0131z\u0131n kaynaklar\u0131n\u0131 t\u00fcketebilir ve yan\u0131t veremez hale gelmesine neden olabilir. Go'da <\/code><\/p>\n \u00c7o\u011fu API ve web servisi, belirli bir zaman diliminde yapabilece\u011finiz istek say\u0131s\u0131n\u0131 s\u0131n\u0131rlayan h\u0131z s\u0131n\u0131rlamalar\u0131 uygular. Bu s\u0131n\u0131rlamalara tak\u0131lmak, 429 Too Many Requests HTTP durum koduyla sonu\u00e7lan\u0131r ve isteklerinizin reddedilmesine neden olur. Paralel isteklerde bu durumla kar\u015f\u0131la\u015fma olas\u0131l\u0131\u011f\u0131 daha y\u00fcksektir. Bu durumu y\u00f6netmek i\u00e7in, istekler aras\u0131na gecikmeler eklemek veya bir \"token bucket\" algoritmas\u0131 kullanarak istekleri d\u00fczenlemek gerekebilir.<\/p>\n Her HTTP iste\u011fi i\u00e7in yeni bir TCP ba\u011flant\u0131s\u0131 a\u00e7mak ve kapatmak maliyetli bir i\u015flemdir. Go'nun Kontrols\u00fcz paralel istekler, uygulaman\u0131z\u0131n belle\u011fini h\u0131zla t\u00fcketebilir. \u00d6zellikle b\u00fcy\u00fck yan\u0131t g\u00f6vdeleri indirirken veya \u00e7ok say\u0131da goroutine olu\u015ftururken bu risk artar. Her goroutine'in minimum bir bellek ayak izi olsa da, binlerce goroutine bir araya geldi\u011finde bu miktar \u00f6nemli hale gelebilir. CPU t\u00fcketimi de, \u00f6zellikle yan\u0131tlar\u0131n i\u015flenmesi veya karma\u015f\u0131k veri d\u00f6n\u00fc\u015f\u00fcmleri yap\u0131lmas\u0131 gerekti\u011finde artabilir.<\/p>\n Markdown linterlar\u0131, belgelerdeki stil, bi\u00e7im ve yap\u0131sal hatalar\u0131 kontrol eden ara\u00e7lard\u0131r. Geli\u015ftirdi\u011fimiz linter, sadece yerel kurallar\u0131 de\u011fil, ayn\u0131 zamanda Markdown dosyalar\u0131ndaki harici ba\u011flant\u0131lar\u0131n ge\u00e7erlili\u011fini de kontrol etmesi gerekiyordu.<\/p>\n Bir Markdown dosyas\u0131nda y\u00fczlerce harici ba\u011flant\u0131 (URL) bulunabilir. Bu ba\u011flant\u0131lar\u0131n her birinin ger\u00e7ekten eri\u015filebilir olup olmad\u0131\u011f\u0131n\u0131 kontrol etmek, linter\u0131n kalitesini art\u0131ran \u00f6nemli bir \u00f6zelliktir. K\u0131r\u0131k ba\u011flant\u0131lar, kullan\u0131c\u0131 deneyimini olumsuz etkiler ve i\u00e7eri\u011fin g\u00fcvenilirli\u011fini azalt\u0131r.<\/p>\n E\u011fer her bir ba\u011flant\u0131y\u0131 s\u0131rayla kontrol etseydik, bu i\u015flem \u00e7ok uzun s\u00fcrecekti. \u00d6rne\u011fin, 1000 ba\u011flant\u0131 ve her bir ba\u011flant\u0131n\u0131n kontrol\u00fc ortalama 500 ms s\u00fcrse, toplamda 500 saniye (yakla\u015f\u0131k 8 dakika) demekti. Bu, bir linter i\u00e7in kabul edilemez bir s\u00fcredir. Paralel istekler bu s\u00fcreyi \u00f6nemli \u00f6l\u00e7\u00fcde k\u0131saltabilir, ancak yukar\u0131da bahsedilen zaman a\u015f\u0131m\u0131, h\u0131z s\u0131n\u0131rlamalar\u0131 ve kaynak t\u00fcketimi gibi sorunlarla y\u00fczle\u015fmemiz gerekiyordu.<\/p>\n Linter\u0131m\u0131z, bir Markdown dosyas\u0131n\u0131 ayr\u0131\u015ft\u0131r\u0131r ve t\u00fcm Go'nun e\u015fzamanl\u0131l\u0131k ara\u00e7lar\u0131n\u0131 kullanarak paralel HTTP isteklerini daha kararl\u0131 hale getirebiliriz.<\/p>\n <\/code><\/p>\n Kontrols\u00fcz goroutine ba\u015flatmak kaynak t\u00fckenmesine yol a\u00e7abilir. Bir semafor kullanarak ayn\u0131 anda \u00e7al\u0131\u015facak goroutine say\u0131s\u0131n\u0131 s\u0131n\u0131rlayabiliriz. Bu, bir \"worker pool\" olu\u015fturman\u0131n basit bir yoludur.<\/p>\n <\/code> <\/code> <\/code><\/p>\n Paralel isteklerde hatalar ka\u00e7\u0131n\u0131lmazd\u0131r. Bu hatalar\u0131 do\u011fru bir \u015fekilde y\u00f6netmek, uygulaman\u0131n dayan\u0131kl\u0131l\u0131\u011f\u0131n\u0131 art\u0131r\u0131r.<\/p>\n T\u00fcm hatalar ayn\u0131 de\u011fildir. A\u011f hatalar\u0131 (ge\u00e7ici), sunucu taraf\u0131 hatalar\u0131 (5xx durum kodlar\u0131, ge\u00e7ici veya kal\u0131c\u0131), istemci taraf\u0131 hatalar\u0131 (4xx durum kodlar\u0131, genellikle kal\u0131c\u0131) farkl\u0131 stratejiler gerektirir. \u00d6rne\u011fin, bir 500 Internal Server Error veya bir a\u011f zaman a\u015f\u0131m\u0131, genellikle yeniden denemeye de\u011ferken, bir 404 Not Found veya 403 Forbidden genellikle kal\u0131c\u0131d\u0131r ve yeniden denemeye gerek yoktur.<\/p>\n Ge\u00e7ici hatalarla kar\u015f\u0131la\u015f\u0131ld\u0131\u011f\u0131nda, hemen yeniden denemek yerine, bir s\u00fcre bekleyip sonra denemek daha iyidir. \u00dcstel geri \u00e7ekilme, her ba\u015far\u0131s\u0131z denemeden sonra bekleme s\u00fcresini katlayarak art\u0131r\u0131r. Bu, hedef sunucunun toparlanmas\u0131na zaman tan\u0131r ve a\u015f\u0131r\u0131 y\u00fcklenmesini \u00f6nler.<\/p>\n <\/code><\/p>\n Bir servis s\u00fcrekli olarak hata veriyorsa, ona s\u00fcrekli istek g\u00f6ndermek kaynak israf\u0131d\u0131r ve hedef servisin daha da k\u00f6t\u00fcle\u015fmesine neden olabilir. Devre kesici deseni, belirli bir hata oran\u0131na ula\u015f\u0131ld\u0131\u011f\u0131nda servise yap\u0131lan istekleri ge\u00e7ici olarak durdurur. Belirli bir s\u00fcre sonra, servisin toparlan\u0131p toparlanmad\u0131\u011f\u0131n\u0131 kontrol etmek i\u00e7in birka\u00e7 \"yar\u0131 a\u00e7\u0131k\" deneme yapar. Bu desen, da\u011f\u0131t\u0131k sistemlerde \u015felale (cascading) hatalar\u0131 \u00f6nlemek i\u00e7in kritik \u00f6neme sahiptir. Go i\u00e7in Paralel HTTP isteklerini y\u00f6netirken performans\u0131 optimize etmek ve kaynaklar\u0131 verimli kullanmak i\u00e7in dikkat edilmesi gereken baz\u0131 noktalar vard\u0131r.<\/p>\n Yukar\u0131da bahsedildi\u011fi gibi, Bir goroutine ba\u015flat\u0131ld\u0131\u011f\u0131nda, i\u015fi bitene kadar veya a\u00e7\u0131k\u00e7a iptal edilene kadar \u00e7al\u0131\u015fmaya devam eder. E\u011fer bir goroutine bir channel'dan veri bekliyor ve o channel asla kapanm\u0131yor veya veri g\u00f6ndermiyorsa, o goroutine sonsuza kadar tak\u0131l\u0131 kalabilir (goroutine s\u0131z\u0131nt\u0131s\u0131). Bu, bellek ve CPU kaynaklar\u0131n\u0131n gereksiz yere t\u00fcketilmesine yol a\u00e7ar. B\u00fcy\u00fck HTTP yan\u0131t g\u00f6vdelerini okurken, yan\u0131t\u0131n tamam\u0131n\u0131 belle\u011fe y\u00fcklemek yerine Uygulaman\u0131z\u0131n performans darbo\u011fazlar\u0131n\u0131 ve kaynak t\u00fcketimini anlamak i\u00e7in Go'nun yerle\u015fik profil ara\u00e7lar\u0131n\u0131 ( Go'nun e\u015fzamanl\u0131l\u0131k modeli, paralel HTTP isteklerini verimli bir \u015fekilde y\u00f6netmek i\u00e7in g\u00fc\u00e7l\u00fc bir temel sunar. Ancak, kararl\u0131 ve g\u00fcvenilir sistemler in\u015fa etmek, sadece goroutine'leri ve channel'lar\u0131 kullanmaktan ibaret de\u011fildir. Zaman a\u015f\u0131mlar\u0131n\u0131 y\u00f6netmek, h\u0131z s\u0131n\u0131rlamalar\u0131na sayg\u0131 duymak, ak\u0131ll\u0131 yeniden deneme stratejileri uygulamak, kaynaklar\u0131 optimize etmek ve hatalar\u0131 do\u011fru bir \u015fekilde ele almak, bu s\u00fcrecin ayr\u0131lmaz par\u00e7alar\u0131d\u0131r. Bir Markdown linter \u00f6rne\u011fi \u00fczerinden g\u00f6rd\u00fc\u011f\u00fcm\u00fcz gibi, bu prensipleri uygulamak, uygulaman\u0131z\u0131n performans\u0131n\u0131 art\u0131r\u0131rken ayn\u0131 zamanda dayan\u0131kl\u0131l\u0131\u011f\u0131n\u0131 da sa\u011flamla\u015ft\u0131r\u0131r. Bu yakla\u015f\u0131mlar sayesinde, Go ile in\u015fa etti\u011finiz paralel sistemler hem h\u0131zl\u0131 hem de g\u00fcvenilir olacakt\u0131r.<\/p>\n Go, goroutine'ler ve channel'lar gibi yerle\u015fik e\u015fzamanl\u0131l\u0131k primitifleri sayesinde paralel i\u015flemleri \u00e7ok verimli ve kolay bir \u015fekilde y\u00f6netir. Goroutine'ler hafif oldu\u011fundan, binlerce e\u015fzamanl\u0131 HTTP iste\u011fini ayn\u0131 anda i\u015fleyebilir ve bu da y\u00fcksek performansl\u0131 G\/\u00c7 yo\u011fun uygulamalar i\u00e7in idealdir.<\/p>\n En s\u0131k kar\u015f\u0131la\u015f\u0131lan sorunlar aras\u0131nda zaman a\u015f\u0131mlar\u0131, hedef sunucular\u0131n h\u0131z s\u0131n\u0131rlamalar\u0131 (rate limiting) nedeniyle istekleri reddetmesi, kaynak t\u00fckenmesi (bellek, CPU, a\u00e7\u0131k dosya limitleri) ve karma\u015f\u0131k hata y\u00f6netimi bulunur.<\/p>\n Yeniden deneme stratejileri, genellikle ge\u00e7ici a\u011f hatalar\u0131 (ba\u011flant\u0131 kesintileri, DNS sorunlar\u0131) veya sunucu taraf\u0131 ge\u00e7ici hatalar (5xx durum kodlar\u0131, h\u0131z s\u0131n\u0131rlamalar\u0131) ile kar\u015f\u0131la\u015f\u0131ld\u0131\u011f\u0131nda kullan\u0131lmal\u0131d\u0131r. \u00dcstel geri \u00e7ekilme, hedef servisin toparlanmas\u0131na zaman tan\u0131yarak daha etkili bir yeniden deneme mekanizmas\u0131 sunar.<\/p>\n Bir linter, genellikle birden fazla dosya veya bir dosya i\u00e7indeki \u00e7ok say\u0131da \u00f6\u011feyi (\u00f6rne\u011fin, harici ba\u011flant\u0131lar\u0131) kontrol eder. Bu kontrollerin her biri ba\u011f\u0131ms\u0131z bir i\u015flem oldu\u011fundan, bunlar\u0131 paralel olarak y\u00fcr\u00fctmek, linter\u0131n toplam \u00e7al\u0131\u015fma s\u00fcresini \u00f6nemli \u00f6l\u00e7\u00fcde azaltarak kullan\u0131c\u0131 deneyimini iyile\u015ftirir.<\/p>\n","protected":false},"excerpt":{"rendered":"Go ile Paralel HTTP \u0130steklerini Kararl\u0131 Hale Getirmek: Markdown Linter Deneyimlerinden \u00d6\u011frenilenler\nG\u00fcn\u00fcm\u00fcz web uygulamalar\u0131nda performans ve yan\u0131t…","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"csco_page_header_type":"","csco_page_load_nextpost":"","csco_page_subscribe_form":"","csco_page_contact_form":"","footnotes":""},"categories":[1],"tags":[],"class_list":{"0":"post-37794","1":"post","2":"type-post","3":"status-publish","4":"format-standard","6":"category-genel","7":"cs-entry","8":"cs-video-wrap"},"yoast_head":"\ngo<\/code> anahtar kelimesini ekleyerek kolayca bir goroutine ba\u015flat\u0131labilir: go myFunction()<\/code>.<\/p>\nChannel’lar ile G\u00fcvenli \u0130leti\u015fim<\/h4>\n
package main\n\nimport (\n\t\"fmt\"\n\t\"time\"\n)\n\nfunc worker(id int, jobs <-chan int, results chan<- string) {\n\tfor j := range jobs {\n\t\tfmt.Printf(\"Worker %d: \u0130\u015f %d ba\u015flad\u0131\\n\", id, j)\n\t\ttime.Sleep(time.Millisecond * 100) \/\/ Sim\u00fclasyon\n\t\tresults <- fmt.Sprintf(\"Worker %d: \u0130\u015f %d tamamland\u0131\", id, j)\n\t}\n}\n\nfunc main() {\n\tjobs := make(chan int, 100)\n\tresults := make(chan string, 100)\n\n\t\/\/ 3 worker goroutine ba\u015flat\n\tfor w := 1; w <= 3; w++ {\n\t\tgo worker(w, jobs, results)\n\t}\n\n\t\/\/ 9 i\u015f g\u00f6nder\n\tfor j := 1; j <= 9; j++ {\n\t\tjobs <- j\n\t}\n\tclose(jobs) \/\/ \u0130\u015fler bitti, channel'\u0131 kapat\n\n\t\/\/ Sonu\u00e7lar\u0131 topla\n\tfor a := 1; a <= 9; a++ {\n\t\tfmt.Println(<-results)\n\t}\n}<\/pre>\n
\nBu \u00f6rnekte, jobs<\/code> channel'\u0131 \u00fczerinden i\u015fler worker'lara g\u00f6nderilirken, results<\/code> channel'\u0131 \u00fczerinden sonu\u00e7lar geri al\u0131n\u0131r.<\/p>\nsync<\/code> Paketi ve E\u015fzamanl\u0131l\u0131k Primitifleri<\/h4>\nsync<\/code> paketi, daha d\u00fc\u015f\u00fck seviyeli e\u015fzamanl\u0131l\u0131k kontrol\u00fc i\u00e7in \u00e7e\u015fitli primitifler sunar. sync.WaitGroup<\/code>, bir grup goroutine'in tamamlanmas\u0131n\u0131 beklemek i\u00e7in kullan\u0131l\u0131r ve paralel HTTP isteklerinde t\u00fcm isteklerin bitmesini beklemek i\u00e7in vazge\u00e7ilmezdir. sync.Mutex<\/code> ve sync.RWMutex<\/code> gibi kilitler, payla\u015f\u0131lan verilere g\u00fcvenli eri\u015fim sa\u011flamak i\u00e7in kullan\u0131l\u0131r, ancak channel'lar m\u00fcmk\u00fcn oldu\u011funca tercih edilmelidir.<\/p>\nHTTP \u0130steklerinde Kararl\u0131l\u0131k Sorunlar\u0131<\/h3>\n
Zaman A\u015f\u0131m\u0131 (Timeouts) ve A\u011f Gecikmeleri<\/h4>\n
http.Client<\/code> yap\u0131s\u0131, istekler i\u00e7in genel zaman a\u015f\u0131mlar\u0131 (Dial, TLS el s\u0131k\u0131\u015fma, ba\u015fl\u0131klar ve tam yan\u0131t i\u00e7in) tan\u0131mlaman\u0131za olanak tan\u0131r.<\/p>\nimport (\n\t\"net\/http\"\n\t\"time\"\n)\n\nclient := &http.Client{\n\tTimeout: 10 * time.Second, \/\/ Toplam istek zaman a\u015f\u0131m\u0131\n\tTransport: &http.Transport{\n\t\tDialContext: (&net.Dialer{\n\t\t\tTimeout: 5 * time.Second, \/\/ Ba\u011flant\u0131 kurma zaman a\u015f\u0131m\u0131\n\t\t}).DialContext,\n\t\tTLSHandshakeTimeout: 5 * time.Second, \/\/ TLS el s\u0131k\u0131\u015fma zaman a\u015f\u0131m\u0131\n\t},\n}<\/pre>\nSunucu Taraf\u0131 H\u0131z S\u0131n\u0131rlamalar\u0131 (Rate Limiting)<\/h4>\n
Ba\u011flant\u0131 Y\u00f6netimi ve Havuzlama<\/h4>\n
http.Client<\/code> yap\u0131s\u0131, ba\u011flant\u0131 havuzlamay\u0131 (connection pooling) varsay\u0131lan olarak destekler. Bu, ayn\u0131 hedefe yap\u0131lan sonraki istekler i\u00e7in mevcut ba\u011flant\u0131lar\u0131n yeniden kullan\u0131lmas\u0131 anlam\u0131na gelir. Ancak, havuzdaki ba\u011flant\u0131 say\u0131s\u0131n\u0131 veya \u00f6mr\u00fcn\u00fc optimize etmek, y\u00fcksek performansl\u0131 uygulamalar i\u00e7in \u00f6nemlidir. http.Transport<\/code> ayarlar\u0131yla bu davran\u0131\u015f \u00f6zelle\u015ftirilebilir.<\/p>\nBellek ve CPU T\u00fcketimi<\/h4>\n
Bir Markdown Linter \u00d6rne\u011fi \u00dczerinden Senaryo<\/h3>\n
Harici Ba\u011flant\u0131lar\u0131 Do\u011frulama \u0130htiyac\u0131<\/h4>\n
Paralel \u0130steklerin Getirdi\u011fi Zorluklar<\/h4>\n
\u00d6rnek Senaryo: \u00c7ok Say\u0131da Ba\u011flant\u0131n\u0131n Kontrol\u00fc<\/h4>\n
[metin](url)<\/code> format\u0131ndaki ba\u011flant\u0131lar\u0131 \u00e7\u0131kar\u0131r. Ard\u0131ndan, bu URL'leri bir HTTP HEAD iste\u011fi ile kontrol eder. HEAD iste\u011fi, yan\u0131t g\u00f6vdesini indirmeden yaln\u0131zca ba\u015fl\u0131klar\u0131 alarak bant geni\u015fli\u011fini ve i\u015flem s\u00fcresini azalt\u0131r. Ancak, binlerce URL'i ayn\u0131 anda kontrol etmeye \u00e7al\u0131\u015ft\u0131\u011f\u0131m\u0131zda, hedef sunucular\u0131n bizi engellemesi veya a\u011f kaynaklar\u0131m\u0131z\u0131n t\u00fckenmesi gibi sorunlarla kar\u015f\u0131la\u015ft\u0131k. Bu noktada, kararl\u0131 paralel istek desenlerini uygulamak zorunlu hale geldi.<\/p>\nKararl\u0131 Paralel \u0130stekler \u0130\u00e7in Go Desenleri ve Ara\u00e7lar\u0131<\/h3>\n
sync.WaitGroup<\/code> ile \u0130\u015flerin Takibi<\/h4>\nsync.WaitGroup<\/code>, bir grup goroutine'in tamamlanmas\u0131n\u0131 beklemek i\u00e7in kullan\u0131l\u0131r. Her bir goroutine ba\u015flat\u0131ld\u0131\u011f\u0131nda Add(1)<\/code> ile sayac\u0131 art\u0131r\u0131r, i\u015fi bitti\u011finde Done()<\/code> ile azalt\u0131r\u0131z. Ana goroutine ise Wait()<\/code> \u00e7a\u011fr\u0131s\u0131 ile t\u00fcm goroutine'lerin bitmesini bekler.<\/p>\npackage main\n\nimport (\n\t\"fmt\"\n\t\"net\/http\"\n\t\"sync\"\n\t\"time\"\n)\n\nfunc checkURL(url string, wg *sync.WaitGroup, results chan<- string) {\n\tdefer wg.Done()\n\tclient := http.Client{Timeout: 5 * time.Second}\n\tresp, err := client.Head(url)\n\tif err != nil {\n\t\tresults <- fmt.Sprintf(\"Hata: %s -> %v\", url, err)\n\t\treturn\n\t}\n\tdefer resp.Body.Close()\n\tresults <- fmt.Sprintf(\"OK: %s -> Durum: %s\", url, resp.Status)\n}\n\nfunc main() {\n\turls := []string{\n\t\t\"https:\/\/www.google.com\",\n\t\t\"https:\/\/www.github.com\",\n\t\t\"https:\/\/nonexistent-site.com\", \/\/ Hatal\u0131 URL\n\t\t\"https:\/\/www.example.com\",\n\t}\n\n\tvar wg sync.WaitGroup\n\tresults := make(chan string, len(urls))\n\n\tfor _, url := range urls {\n\t\twg.Add(1)\n\t\tgo checkURL(url, &wg, results)\n\t}\n\n\twg.Wait() \/\/ T\u00fcm goroutine'lerin bitmesini bekle\n\tclose(results)\n\n\tfor res := range results {\n\t\tfmt.Println(res)\n\t}\n}<\/pre>\nSemafor (Semaphore) Kullanarak Paralellik S\u0131n\u0131rlama<\/h4>\n
package main\n\nimport (\n\t\"fmt\"\n\t\"net\/http\"\n\t\"sync\"\n\t\"time\"\n)\n\nfunc checkURLWithSemaphore(url string, wg *sync.WaitGroup, sem chan struct{}, results chan<- string) {\n\tdefer wg.Done()\n\tsem <- struct{}{} \/\/ Semaforu al (bir slot doldur)\n\tdefer func() { <-sem }() \/\/ \u0130\u015f bitince semaforu b\u0131rak (slotu bo\u015falt)\n\n\tclient := http.Client{Timeout: 5 * time.Second}\n\tresp, err := client.Head(url)\n\tif err != nil {\n\t\tresults <- fmt.Sprintf(\"Hata: %s -> %v\", url, err)\n\t\treturn\n\t}\n\tdefer resp.Body.Close()\n\tresults <- fmt.Sprintf(\"OK: %s -> Durum: %s\", url, resp.Status)\n}\n\nfunc main() {\n\turls := make([]string, 50)\n\tfor i := 0; i < 50; i++ {\n\t\turls[i] = fmt.Sprintf(\"https:\/\/www.example.com\/%d\", i) \/\/ \u00d6rnek URL'ler\n\t}\n\turls[10] = \"https:\/\/nonexistent-site.com\" \/\/ Hatal\u0131 URL ekle\n\n\tvar wg sync.WaitGroup\n\tresults := make(chan string, len(urls))\n\tmaxParallel := 5 \/\/ Ayn\u0131 anda \u00e7al\u0131\u015facak maksimum goroutine say\u0131s\u0131\n\tsem := make(chan struct{}, maxParallel) \/\/ Semafor channel'\u0131\n\n\tfor _, url := range urls {\n\t\twg.Add(1)\n\t\tgo checkURLWithSemaphore(url, &wg, sem, results)\n\t}\n\n\twg.Wait()\n\tclose(results)\n\n\tfor res := range results {\n\t\tfmt.Println(res)\n\t}\n}<\/pre>\n
\nBu \u00f6rnekte, sem<\/code> channel'\u0131 maxParallel<\/code> kapasiteli bir semafor g\u00f6revi g\u00f6r\u00fcr. Her goroutine \u00e7al\u0131\u015fmaya ba\u015flamadan \u00f6nce sem <- struct{}{}<\/code> ile bir slotu doldurur, i\u015fi bitince <-sem<\/code> ile slotu bo\u015falt\u0131r.<\/p>\ncontext<\/code> Paketi ile \u0130ptal ve Zaman A\u015f\u0131m\u0131 Y\u00f6netimi<\/h4>\ncontext<\/code> paketi, isteklerin ya\u015fam d\u00f6ng\u00fcs\u00fcn\u00fc y\u00f6netmek, iptal sinyalleri g\u00f6ndermek ve zaman a\u015f\u0131mlar\u0131n\u0131 izlemek i\u00e7in g\u00fc\u00e7l\u00fc bir mekanizma sunar. \u00d6zellikle uzun s\u00fcreli veya zincirleme isteklerde \u00e7ok faydal\u0131d\u0131r.<\/p>\nimport (\n\t\"context\"\n\t\"net\/http\"\n\t\"time\"\n)\n\nfunc fetchWithContext(ctx context.Context, url string) (string, error) {\n\treq, err := http.NewRequestWithContext(ctx, \"GET\", url, nil)\n\tif err != nil {\n\t\treturn \"\", err\n\t}\n\n\tclient := http.Client{}\n\tresp, err := client.Do(req)\n\tif err != nil {\n\t\treturn \"\", err\n\t}\n\tdefer resp.Body.Close()\n\t\/\/ ... yan\u0131t\u0131 oku ve i\u015fle ...\n\treturn fmt.Sprintf(\"URL %s ba\u015far\u0131yla \u00e7ekildi.\", url), nil\n}\n\nfunc main() {\n\tctx, cancel := context.WithTimeout(context.Background(), 3*time.Second)\n\tdefer cancel() \/\/ \u0130\u015flem bitince veya zaman a\u015f\u0131m\u0131 olunca iptal et\n\n\tresult, err := fetchWithContext(ctx, \"https:\/\/www.google.com\")\n\tif err != nil {\n\t\tfmt.Println(\"Hata:\", err)\n\t\treturn\n\t}\n\tfmt.Println(result)\n}<\/pre>\n
\ncontext.WithTimeout<\/code> ile belirli bir s\u00fcre sonra otomatik olarak iptal edilecek bir ba\u011flam olu\u015fturulur.<\/p>\nhttp.Client<\/code> Konfig\u00fcrasyonu<\/h4>\nhttp.Client<\/code>'\u0131n Transport<\/code> alan\u0131, ba\u011flant\u0131 havuzlama, TLS yap\u0131land\u0131rmas\u0131 ve vekil sunucu ayarlar\u0131 gibi d\u00fc\u015f\u00fck seviyeli a\u011f ayarlar\u0131n\u0131 kontrol etmenizi sa\u011flar. Optimize edilmi\u015f bir http.Client<\/code> kullan\u0131m\u0131, paralel isteklerin kararl\u0131l\u0131\u011f\u0131n\u0131 art\u0131r\u0131r.<\/p>\nimport (\n\t\"net\"\n\t\"net\/http\"\n\t\"time\"\n)\n\n\/\/ Global veya singleton olarak tan\u0131mlanmal\u0131\nvar httpClient = &http.Client{\n\tTimeout: 10 * time.Second, \/\/ Toplam istek zaman a\u015f\u0131m\u0131\n\tTransport: &http.Transport{\n\t\tMaxIdleConns: 100, \/\/ Havuzdaki maksimum bo\u015fta ba\u011flant\u0131 say\u0131s\u0131\n\t\tMaxIdleConnsPerHost: 10, \/\/ Her host i\u00e7in maksimum bo\u015fta ba\u011flant\u0131 say\u0131s\u0131\n\t\tIdleConnTimeout: 90 * time.Second, \/\/ Bo\u015fta kalan ba\u011flant\u0131lar\u0131n ne kadar s\u00fcreyle a\u00e7\u0131k kalaca\u011f\u0131\n\t\tTLSHandshakeTimeout: 5 * time.Second,\n\t\tExpectContinueTimeout: 1 * time.Second,\n\t\tDialContext: (&net.Dialer{\n\t\t\tTimeout: 5 * time.Second, \/\/ Ba\u011flant\u0131 kurma zaman a\u015f\u0131m\u0131\n\t\t\tKeepAlive: 30 * time.Second, \/\/ TCP Keep-Alive\n\t\t}).DialContext,\n\t},\n}<\/pre>\nHata Y\u00f6netimi ve Yeniden Deneme Stratejileri<\/h3>\n
Hata T\u00fcrlerini Ay\u0131rt Etme<\/h4>\n
\u00dcstel Geri \u00c7ekilme (Exponential Backoff) ile Yeniden Deneme<\/h4>\n
package main\n\nimport (\n\t\"fmt\"\n\t\"net\/http\"\n\t\"time\"\n)\n\nfunc makeRequestWithRetry(url string, maxRetries int) (*http.Response, error) {\n\tclient := http.Client{Timeout: 5 * time.Second}\n\tvar resp *http.Response\n\tvar err error\n\tfor i := 0; i < maxRetries; i++ {\n\t\tresp, err = client.Get(url)\n\t\tif err == nil && resp.StatusCode >= 200 && resp.StatusCode < 300 {\n\t\t\treturn resp, nil\n\t\t}\n\t\tif resp != nil && (resp.StatusCode == http.StatusTooManyRequests || resp.StatusCode >= 500) {\n\t\t\t\/\/ Yeniden denenebilir hata\n\t\t\tbackoffTime := time.Duration(1<Devre Kesici (Circuit Breaker) Deseni<\/h4>\n
github.com\/sony\/gobreaker<\/code> gibi k\u00fct\u00fcphaneler mevcuttur.<\/p>\nKaynak Y\u00f6netimi ve Performans \u0130pu\u00e7lar\u0131<\/h3>\n
Ba\u011flant\u0131 Havuzlaman\u0131n \u00d6nemi<\/h4>\n
http.Client<\/code>'\u0131n Transport<\/code> ayarlar\u0131n\u0131 do\u011fru yap\u0131land\u0131rmak, TCP ba\u011flant\u0131lar\u0131n\u0131n yeniden kullan\u0131lmas\u0131n\u0131 sa\u011flayarak ba\u011flant\u0131 a\u00e7ma\/kapama maliyetini ortadan kald\u0131r\u0131r. MaxIdleConns<\/code>, MaxIdleConnsPerHost<\/code> ve IdleConnTimeout<\/code> gibi parametreler, uygulaman\u0131z\u0131n ihtiya\u00e7lar\u0131na g\u00f6re ayarlanmal\u0131d\u0131r.<\/p>\nGoroutine S\u0131z\u0131nt\u0131lar\u0131n\u0131 \u00d6nleme<\/h4>\n
context<\/code> paketi ve select<\/code> ifadeleri, goroutine'lerin d\u00fczenli bir \u015fekilde sonland\u0131r\u0131lmas\u0131n\u0131 sa\u011flamak i\u00e7in \u00f6nemlidir.<\/p>\nBellek Kullan\u0131m\u0131n\u0131 Optimize Etme<\/h4>\n
io.Copy<\/code> veya io.LimitReader<\/code> gibi ara\u00e7larla par\u00e7a par\u00e7a okumak veya sadece gerekli k\u0131s\u0131mlar\u0131 ayr\u0131\u015ft\u0131rmak bellek t\u00fcketimini azaltabilir. defer resp.Body.Close()<\/code> ifadesini her zaman kullanmak, ba\u011flant\u0131lar\u0131n ve ili\u015fkili kaynaklar\u0131n d\u00fczg\u00fcn bir \u015fekilde serbest b\u0131rak\u0131lmas\u0131n\u0131 sa\u011flar.<\/p>\nProfilleme ve G\u00f6zlemleme<\/h4>\n
pprof<\/code>) kullanmak \u00e7ok \u00f6nemlidir. CPU, bellek ve goroutine profilleri, s\u0131z\u0131nt\u0131lar\u0131 veya verimsiz kod b\u00f6lgelerini tespit etmenize yard\u0131mc\u0131 olur. Prometheus veya Grafana gibi g\u00f6zlemleme ara\u00e7lar\u0131yla entegrasyon, \u00fcretim ortam\u0131nda uygulaman\u0131z\u0131n davran\u0131\u015f\u0131n\u0131 izlemek i\u00e7in kritik \u00f6neme sahiptir.<\/p>\nSonu\u00e7<\/h3>\n
SSS (S\u0131k Sorulan Sorular)<\/h3>\n
Neden Go, paralel HTTP istekleri i\u00e7in iyi bir se\u00e7imdir?<\/h4>\n
Paralel isteklerde en s\u0131k kar\u015f\u0131la\u015f\u0131lan sorunlar nelerdir?<\/h4>\n
context<\/code> paketi ne i\u015fe yarar?<\/h4>\ncontext<\/code> paketi, isteklerin ya\u015fam d\u00f6ng\u00fcs\u00fcn\u00fc y\u00f6netmek i\u00e7in kullan\u0131l\u0131r. Goroutine'ler aras\u0131nda iptal sinyalleri, zaman a\u015f\u0131m\u0131 limitleri ve istek ba\u015f\u0131na de\u011ferler gibi bilgileri ta\u015f\u0131mak i\u00e7in bir mekanizma sa\u011flar. Bu, \u00f6zellikle bir iste\u011fin birden fazla goroutine'i veya alt iste\u011fi tetikledi\u011fi durumlarda \u00e7ok \u00f6nemlidir.<\/p>\nYeniden deneme stratejileri ne zaman kullan\u0131lmal\u0131?<\/h4>\n
Bir linterda paralel istekler neden gereklidir?<\/h4>\n