Go ile Paralel HTTP İsteklerini Kararlı Hale Getirmek: Markdown Linter Deneyimlerinden Öğrenilenler

Go ile Paralel HTTP İsteklerini Kararlı Hale Getirmek: Markdown Linter Deneyimlerinden Öğrenilenler

Günümüz web uygulamalarında performans ve yanıt süresi kritik öneme sahiptir. Bu hedeflere ulaşmak için paralel HTTP istekleri yapmak yaygın bir stratejidir. Ancak, bu yaklaşım beraberinde kararlılık, kaynak yönetimi ve hata toleransı gibi zorlukları da getirir. Bu makalede, Go programlama dilinin eşzamanlılık yeteneklerini kullanarak paralel HTTP isteklerini nasıl daha kararlı hale getirebileceğimizi, bir Markdown linter geliştirirken edindiğimiz deneyimler ışığında detaylıca inceleyeceğiz.

Paralel İsteklerin Gücü ve Riskleri

Paralel istekler, birden fazla HTTP isteğini aynı anda veya çakışık bir şekilde yürüterek uygulamaların genel işlem süresini önemli ölçüde azaltabilir. Bu, özellikle dış kaynaklardan veri çekerken veya birden fazla API’yi sorgularken büyük bir avantaj sağlar.

Hız ve Verimlilik Artışı

Bir uygulamanın aynı anda birden fazla bağımsız görevi yerine getirebilmesi, kullanıcı deneyimini doğrudan iyileştirir. Örneğin, bir web sayfasının farklı bileşenlerini (resimler, CSS, JS dosyaları) paralel olarak yüklemek, sayfanın toplam yüklenme süresini kısaltır. Benzer şekilde, bir linterın binlerce harici bağlantıyı kontrol etmesi gerektiğinde, her birini sırayla kontrol etmek yerine paralel olarak yapmak, işlemi dakikalardan saniyelere indirebilir.

Ortaya Çıkabilecek Sorunlar: Kaynak Tükenmesi ve Hata Durumları

Paralel isteklerin kontrolsüz kullanımı, sunucu kaynaklarının (CPU, bellek, ağ bağlantıları) hızla tükenmesine yol açabilir. Hedef sunuculara aşırı yük bindirmek, hız sınırlamalarına (rate limiting) takılmaya veya IP adresinizin engellenmesine neden olabilir. Ayrıca, ağ kesintileri, sunucu hataları veya zaman aşımları gibi hata durumları, paralel sistemlerde yönetilmesi daha karmaşık hale gelir. Bu hataların doğru bir şekilde ele alınmaması, uygulamanın çökmesine veya tutarsız sonuçlar üretmesine neden olabilir.

Dağıtık Sistemlerdeki Önemi

Mikroservis mimarileri ve dağıtık sistemler, paralel istekleri temel bir yapı taşı olarak kullanır. Bir servisin birden fazla başka servisle iletişim kurması gerektiğinde, bu iletişimlerin paralel ve kararlı bir şekilde yürütülmesi, tüm sistemin performansını ve güvenilirliğini doğrudan etkiler. Bu nedenle, paralel isteklerin doğru bir şekilde tasarlanması ve uygulanması, modern yazılım mimarileri için vazgeçilmezdir.

Go’nun Eşzamanlılık Modeli ve Goroutine’ler

Go, eşzamanlılık için yerleşik ve güçlü mekanizmalar sunar. Bu mekanizmalar, paralel HTTP isteklerini yönetmeyi diğer dillere göre daha kolay ve verimli hale getirir.

Goroutine’ler ve Hafif İş Parçacıkları

Go’nun eşzamanlılık modelinin kalbinde “goroutine”ler bulunur. Goroutine’ler, işletim sistemi iş parçacıklarına göre çok daha hafif (birkaç KB yığın belleği ile başlar) ve Go çalışma zamanı tarafından yönetilen iş parçacıklarıdır. Binlerce hatta yüz binlerce goroutine’i aynı anda çalıştırmak mümkündür, bu da paralel HTTP istekleri gibi G/Ç yoğun görevler için idealdir. Bir fonksiyonun başına go anahtar kelimesini ekleyerek kolayca bir goroutine başlatılabilir: go myFunction().

Channel’lar ile Güvenli İletişim

Goroutine’ler arasında güvenli ve etkili iletişim kurmanın ana yolu “channel”lardır. Channel’lar, goroutine’lerin birbirlerine veri göndermesini ve almasını sağlayan tip güvenli borular gibidir. Bu, paylaşılan bellek üzerinden kilitleme mekanizmaları kullanmak yerine, “paylaşılan bellek üzerinden iletişim kurmak yerine, iletişim kurarak belleği paylaş” (Don’t communicate by sharing memory; instead, share memory by communicating) felsefesini destekler. Bu yaklaşım, veri yarışlarını (data races) büyük ölçüde azaltır ve eşzamanlı programlamayı basitleştirir.

package main

import (
	"fmt"
	"time"
)

func worker(id int, jobs <-chan int, results chan<- string) {
	for j := range jobs {
		fmt.Printf("Worker %d: İş %d başladı\n", id, j)
		time.Sleep(time.Millisecond * 100) // Simülasyon
		results <- fmt.Sprintf("Worker %d: İş %d tamamlandı", id, j)
	}
}

func main() {
	jobs := make(chan int, 100)
	results := make(chan string, 100)

	// 3 worker goroutine başlat
	for w := 1; w <= 3; w++ {
		go worker(w, jobs, results)
	}

	// 9 iş gönder
	for j := 1; j <= 9; j++ {
		jobs <- j
	}
	close(jobs) // İşler bitti, channel'ı kapat

	// Sonuçları topla
	for a := 1; a <= 9; a++ {
		fmt.Println(<-results)
	}
}

Bu örnekte, jobs channel'ı üzerinden işler worker'lara gönderilirken, results channel'ı üzerinden sonuçlar geri alınır.

sync Paketi ve Eşzamanlılık Primitifleri

Go'nun sync paketi, daha düşük seviyeli eşzamanlılık kontrolü için çeşitli primitifler sunar. sync.WaitGroup, bir grup goroutine'in tamamlanmasını beklemek için kullanılır ve paralel HTTP isteklerinde tüm isteklerin bitmesini beklemek için vazgeçilmezdir. sync.Mutex ve sync.RWMutex gibi kilitler, paylaşılan verilere güvenli erişim sağlamak için kullanılır, ancak channel'lar mümkün olduğunca tercih edilmelidir.

HTTP İsteklerinde Kararlılık Sorunları

Paralel HTTP istekleri yaparken karşılaşabileceğimiz temel kararlılık sorunlarını ve bunların Go'da nasıl ele alınabileceğini anlamak önemlidir.

Zaman Aşımı (Timeouts) ve Ağ Gecikmeleri

Harici servislere yapılan HTTP istekleri, ağ sorunları, sunucu yükü veya yavaş yanıt süreleri nedeniyle takılı kalabilir. Bu durum, uygulamanızın kaynaklarını tüketebilir ve yanıt veremez hale gelmesine neden olabilir. Go'da http.Client yapısı, istekler için genel zaman aşımları (Dial, TLS el sıkışma, başlıklar ve tam yanıt için) tanımlamanıza olanak tanır.

import (
	"net/http"
	"time"
)

client := &http.Client{
	Timeout: 10 * time.Second, // Toplam istek zaman aşımı
	Transport: &http.Transport{
		DialContext: (&net.Dialer{
			Timeout: 5 * time.Second, // Bağlantı kurma zaman aşımı
		}).DialContext,
		TLSHandshakeTimeout: 5 * time.Second, // TLS el sıkışma zaman aşımı
	},
}

Sunucu Tarafı Hız Sınırlamaları (Rate Limiting)

Çoğu API ve web servisi, belirli bir zaman diliminde yapabileceğiniz istek sayısını sınırlayan hız sınırlamaları uygular. Bu sınırlamalara takılmak, 429 Too Many Requests HTTP durum koduyla sonuçlanır ve isteklerinizin reddedilmesine neden olur. Paralel isteklerde bu durumla karşılaşma olasılığı daha yüksektir. Bu durumu yönetmek için, istekler arasına gecikmeler eklemek veya bir "token bucket" algoritması kullanarak istekleri düzenlemek gerekebilir.

Bağlantı Yönetimi ve Havuzlama

Her HTTP isteği için yeni bir TCP bağlantısı açmak ve kapatmak maliyetli bir işlemdir. Go'nun http.Client yapısı, bağlantı havuzlamayı (connection pooling) varsayılan olarak destekler. Bu, aynı hedefe yapılan sonraki istekler için mevcut bağlantıların yeniden kullanılması anlamına gelir. Ancak, havuzdaki bağlantı sayısını veya ömrünü optimize etmek, yüksek performanslı uygulamalar için önemlidir. http.Transport ayarlarıyla bu davranış özelleştirilebilir.

Bellek ve CPU Tüketimi

Kontrolsüz paralel istekler, uygulamanızın belleğini hızla tüketebilir. Özellikle büyük yanıt gövdeleri indirirken veya çok sayıda goroutine oluştururken bu risk artar. Her goroutine'in minimum bir bellek ayak izi olsa da, binlerce goroutine bir araya geldiğinde bu miktar önemli hale gelebilir. CPU tüketimi de, özellikle yanıtların işlenmesi veya karmaşık veri dönüşümleri yapılması gerektiğinde artabilir.

Bir Markdown Linter Örneği Üzerinden Senaryo

Markdown linterları, belgelerdeki stil, biçim ve yapısal hataları kontrol eden araçlardır. Geliştirdiğimiz linter, sadece yerel kuralları değil, aynı zamanda Markdown dosyalarındaki harici bağlantıların geçerliliğini de kontrol etmesi gerekiyordu.

Harici Bağlantıları Doğrulama İhtiyacı

Bir Markdown dosyasında yüzlerce harici bağlantı (URL) bulunabilir. Bu bağlantıların her birinin gerçekten erişilebilir olup olmadığını kontrol etmek, linterın kalitesini artıran önemli bir özelliktir. Kırık bağlantılar, kullanıcı deneyimini olumsuz etkiler ve içeriğin güvenilirliğini azaltır.

Paralel İsteklerin Getirdiği Zorluklar

Eğer her bir bağlantıyı sırayla kontrol etseydik, bu işlem çok uzun sürecekti. Örneğin, 1000 bağlantı ve her bir bağlantının kontrolü ortalama 500 ms sürse, toplamda 500 saniye (yaklaşık 8 dakika) demekti. Bu, bir linter için kabul edilemez bir süredir. Paralel istekler bu süreyi önemli ölçüde kısaltabilir, ancak yukarıda bahsedilen zaman aşımı, hız sınırlamaları ve kaynak tüketimi gibi sorunlarla yüzleşmemiz gerekiyordu.

Örnek Senaryo: Çok Sayıda Bağlantının Kontrolü

Linterımız, bir Markdown dosyasını ayrıştırır ve tüm [metin](url) formatındaki bağlantıları çıkarır. Ardından, bu URL'leri bir HTTP HEAD isteği ile kontrol eder. HEAD isteği, yanıt gövdesini indirmeden yalnızca başlıkları alarak bant genişliğini ve işlem süresini azaltır. Ancak, binlerce URL'i aynı anda kontrol etmeye çalıştığımızda, hedef sunucuların bizi engellemesi veya ağ kaynaklarımızın tükenmesi gibi sorunlarla karşılaştık. Bu noktada, kararlı paralel istek desenlerini uygulamak zorunlu hale geldi.

Kararlı Paralel İstekler İçin Go Desenleri ve Araçları

Go'nun eşzamanlılık araçlarını kullanarak paralel HTTP isteklerini daha kararlı hale getirebiliriz.

sync.WaitGroup ile İşlerin Takibi

sync.WaitGroup, bir grup goroutine'in tamamlanmasını beklemek için kullanılır. Her bir goroutine başlatıldığında Add(1) ile sayacı artırır, işi bittiğinde Done() ile azaltırız. Ana goroutine ise Wait() çağrısı ile tüm goroutine'lerin bitmesini bekler.

package main

import (
	"fmt"
	"net/http"
	"sync"
	"time"
)

func checkURL(url string, wg *sync.WaitGroup, results chan<- string) {
	defer wg.Done()
	client := http.Client{Timeout: 5 * time.Second}
	resp, err := client.Head(url)
	if err != nil {
		results <- fmt.Sprintf("Hata: %s -> %v", url, err)
		return
	}
	defer resp.Body.Close()
	results <- fmt.Sprintf("OK: %s -> Durum: %s", url, resp.Status)
}

func main() {
	urls := []string{
		"https://www.google.com",
		"https://www.github.com",
		"https://nonexistent-site.com", // Hatalı URL
		"https://www.example.com",
	}

	var wg sync.WaitGroup
	results := make(chan string, len(urls))

	for _, url := range urls {
		wg.Add(1)
		go checkURL(url, &wg, results)
	}

	wg.Wait() // Tüm goroutine'lerin bitmesini bekle
	close(results)

	for res := range results {
		fmt.Println(res)
	}
}

Semafor (Semaphore) Kullanarak Paralellik Sınırlama

Kontrolsüz goroutine başlatmak kaynak tükenmesine yol açabilir. Bir semafor kullanarak aynı anda çalışacak goroutine sayısını sınırlayabiliriz. Bu, bir "worker pool" oluşturmanın basit bir yoludur.

package main

import (
	"fmt"
	"net/http"
	"sync"
	"time"
)

func checkURLWithSemaphore(url string, wg *sync.WaitGroup, sem chan struct{}, results chan<- string) {
	defer wg.Done()
	sem <- struct{}{} // Semaforu al (bir slot doldur)
	defer func() { <-sem }() // İş bitince semaforu bırak (slotu boşalt)

	client := http.Client{Timeout: 5 * time.Second}
	resp, err := client.Head(url)
	if err != nil {
		results <- fmt.Sprintf("Hata: %s -> %v", url, err)
		return
	}
	defer resp.Body.Close()
	results <- fmt.Sprintf("OK: %s -> Durum: %s", url, resp.Status)
}

func main() {
	urls := make([]string, 50)
	for i := 0; i < 50; i++ {
		urls[i] = fmt.Sprintf("https://www.example.com/%d", i) // Örnek URL'ler
	}
	urls[10] = "https://nonexistent-site.com" // Hatalı URL ekle

	var wg sync.WaitGroup
	results := make(chan string, len(urls))
	maxParallel := 5 // Aynı anda çalışacak maksimum goroutine sayısı
	sem := make(chan struct{}, maxParallel) // Semafor channel'ı

	for _, url := range urls {
		wg.Add(1)
		go checkURLWithSemaphore(url, &wg, sem, results)
	}

	wg.Wait()
	close(results)

	for res := range results {
		fmt.Println(res)
	}
}

Bu örnekte, sem channel'ı maxParallel kapasiteli bir semafor görevi görür. Her goroutine çalışmaya başlamadan önce sem <- struct{}{} ile bir slotu doldurur, işi bitince <-sem ile slotu boşaltır.

context Paketi ile İptal ve Zaman Aşımı Yönetimi

context paketi, isteklerin yaşam döngüsünü yönetmek, iptal sinyalleri göndermek ve zaman aşımlarını izlemek için güçlü bir mekanizma sunar. Özellikle uzun süreli veya zincirleme isteklerde çok faydalıdır.

import (
	"context"
	"net/http"
	"time"
)

func fetchWithContext(ctx context.Context, url string) (string, error) {
	req, err := http.NewRequestWithContext(ctx, "GET", url, nil)
	if err != nil {
		return "", err
	}

	client := http.Client{}
	resp, err := client.Do(req)
	if err != nil {
		return "", err
	}
	defer resp.Body.Close()
	// ... yanıtı oku ve işle ...
	return fmt.Sprintf("URL %s başarıyla çekildi.", url), nil
}

func main() {
	ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second)
	defer cancel() // İşlem bitince veya zaman aşımı olunca iptal et

	result, err := fetchWithContext(ctx, "https://www.google.com")
	if err != nil {
		fmt.Println("Hata:", err)
		return
	}
	fmt.Println(result)
}

context.WithTimeout ile belirli bir süre sonra otomatik olarak iptal edilecek bir bağlam oluşturulur.

http.Client Konfigürasyonu

http.Client'ın Transport alanı, bağlantı havuzlama, TLS yapılandırması ve vekil sunucu ayarları gibi düşük seviyeli ağ ayarlarını kontrol etmenizi sağlar. Optimize edilmiş bir http.Client kullanımı, paralel isteklerin kararlılığını artırır.

import (
	"net"
	"net/http"
	"time"
)

// Global veya singleton olarak tanımlanmalı
var httpClient = &http.Client{
	Timeout: 10 * time.Second, // Toplam istek zaman aşımı
	Transport: &http.Transport{
		MaxIdleConns:        100,             // Havuzdaki maksimum boşta bağlantı sayısı
		MaxIdleConnsPerHost: 10,              // Her host için maksimum boşta bağlantı sayısı
		IdleConnTimeout:     90 * time.Second, // Boşta kalan bağlantıların ne kadar süreyle açık kalacağı
		TLSHandshakeTimeout: 5 * time.Second,
		ExpectContinueTimeout: 1 * time.Second,
		DialContext: (&net.Dialer{
			Timeout:   5 * time.Second, // Bağlantı kurma zaman aşımı
			KeepAlive: 30 * time.Second, // TCP Keep-Alive
		}).DialContext,
	},
}

Hata Yönetimi ve Yeniden Deneme Stratejileri

Paralel isteklerde hatalar kaçınılmazdır. Bu hataları doğru bir şekilde yönetmek, uygulamanın dayanıklılığını artırır.

Hata Türlerini Ayırt Etme

Tüm hatalar aynı değildir. Ağ hataları (geçici), sunucu tarafı hataları (5xx durum kodları, geçici veya kalıcı), istemci tarafı hataları (4xx durum kodları, genellikle kalıcı) farklı stratejiler gerektirir. Örneğin, bir 500 Internal Server Error veya bir ağ zaman aşımı, genellikle yeniden denemeye değerken, bir 404 Not Found veya 403 Forbidden genellikle kalıcıdır ve yeniden denemeye gerek yoktur.

Üstel Geri Çekilme (Exponential Backoff) ile Yeniden Deneme

Geçici hatalarla karşılaşıldığında, hemen yeniden denemek yerine, bir süre bekleyip sonra denemek daha iyidir. Üstel geri çekilme, her başarısız denemeden sonra bekleme süresini katlayarak artırır. Bu, hedef sunucunun toparlanmasına zaman tanır ve aşırı yüklenmesini önler.

package main

import (
	"fmt"
	"net/http"
	"time"
)

func makeRequestWithRetry(url string, maxRetries int) (*http.Response, error) {
	client := http.Client{Timeout: 5 * time.Second}
	var resp *http.Response
	var err error
	for i := 0; i < maxRetries; i++ {
		resp, err = client.Get(url)
		if err == nil && resp.StatusCode >= 200 && resp.StatusCode < 300 {
			return resp, nil
		}
		if resp != nil && (resp.StatusCode == http.StatusTooManyRequests || resp.StatusCode >= 500) {
			// Yeniden denenebilir hata
			backoffTime := time.Duration(1<

Devre Kesici (Circuit Breaker) Deseni
Bir servis sürekli olarak hata veriyorsa, ona sürekli istek göndermek kaynak israfıdır ve hedef servisin daha da kötüleşmesine neden olabilir. Devre kesici deseni, belirli bir hata oranına ulaşıldığında servise yapılan istekleri geçici olarak durdurur. Belirli bir süre sonra, servisin toparlanıp toparlanmadığını kontrol etmek için birkaç "yarı açık" deneme yapar. Bu desen, dağıtık sistemlerde şelale (cascading) hataları önlemek için kritik öneme sahiptir. Go için github.com/sony/gobreaker gibi kütüphaneler mevcuttur.
Kaynak Yönetimi ve Performans İpuçları
Paralel HTTP isteklerini yönetirken performansı optimize etmek ve kaynakları verimli kullanmak için dikkat edilmesi gereken bazı noktalar vardır.
Bağlantı Havuzlamanın Önemi
Yukarıda bahsedildiği gibi, http.Client'ın Transport ayarlarını doğru yapılandırmak, TCP bağlantılarının yeniden kullanılmasını sağlayarak bağlantı açma/kapama maliyetini ortadan kaldırır. MaxIdleConns, MaxIdleConnsPerHost ve IdleConnTimeout gibi parametreler, uygulamanızın ihtiyaçlarına göre ayarlanmalıdır.
Goroutine Sızıntılarını Önleme
Bir goroutine başlatıldığında, işi bitene kadar veya açıkça iptal edilene kadar çalışmaya devam eder. Eğer bir goroutine bir channel'dan veri bekliyor ve o channel asla kapanmıyor veya veri göndermiyorsa, o goroutine sonsuza kadar takılı kalabilir (goroutine sızıntısı). Bu, bellek ve CPU kaynaklarının gereksiz yere tüketilmesine yol açar. context paketi ve select ifadeleri, goroutine'lerin düzenli bir şekilde sonlandırılmasını sağlamak için önemlidir.
Bellek Kullanımını Optimize Etme
Büyük HTTP yanıt gövdelerini okurken, yanıtın tamamını belleğe yüklemek yerine io.Copy veya io.LimitReader gibi araçlarla parça parça okumak veya sadece gerekli kısımları ayrıştırmak bellek tüketimini azaltabilir. defer resp.Body.Close() ifadesini her zaman kullanmak, bağlantıların ve ilişkili kaynakların düzgün bir şekilde serbest bırakılmasını sağlar.
Profilleme ve Gözlemleme
Uygulamanızın performans darboğazlarını ve kaynak tüketimini anlamak için Go'nun yerleşik profil araçlarını (pprof) kullanmak çok önemlidir. CPU, bellek ve goroutine profilleri, sızıntıları veya verimsiz kod bölgelerini tespit etmenize yardımcı olur. Prometheus veya Grafana gibi gözlemleme araçlarıyla entegrasyon, üretim ortamında uygulamanızın davranışını izlemek için kritik öneme sahiptir.
Sonuç
Go'nun eşzamanlılık modeli, paralel HTTP isteklerini verimli bir şekilde yönetmek için güçlü bir temel sunar. Ancak, kararlı ve güvenilir sistemler inşa etmek, sadece goroutine'leri ve channel'ları kullanmaktan ibaret değildir. Zaman aşımlarını yönetmek, hız sınırlamalarına saygı duymak, akıllı yeniden deneme stratejileri uygulamak, kaynakları optimize etmek ve hataları doğru bir şekilde ele almak, bu sürecin ayrılmaz parçalarıdır. Bir Markdown linter örneği üzerinden gördüğümüz gibi, bu prensipleri uygulamak, uygulamanızın performansını artırırken aynı zamanda dayanıklılığını da sağlamlaştırır. Bu yaklaşımlar sayesinde, Go ile inşa ettiğiniz paralel sistemler hem hızlı hem de güvenilir olacaktır.
SSS (Sık Sorulan Sorular)
Neden Go, paralel HTTP istekleri için iyi bir seçimdir?
Go, goroutine'ler ve channel'lar gibi yerleşik eşzamanlılık primitifleri sayesinde paralel işlemleri çok verimli ve kolay bir şekilde yönetir. Goroutine'ler hafif olduğundan, binlerce eşzamanlı HTTP isteğini aynı anda işleyebilir ve bu da yüksek performanslı G/Ç yoğun uygulamalar için idealdir.
Paralel isteklerde en sık karşılaşılan sorunlar nelerdir?
En sık karşılaşılan sorunlar arasında zaman aşımları, hedef sunucuların hız sınırlamaları (rate limiting) nedeniyle istekleri reddetmesi, kaynak tükenmesi (bellek, CPU, açık dosya limitleri) ve karmaşık hata yönetimi bulunur.
context paketi ne işe yarar?
context paketi, isteklerin yaşam döngüsünü yönetmek için kullanılır. Goroutine'ler arasında iptal sinyalleri, zaman aşımı limitleri ve istek başına değerler gibi bilgileri taşımak için bir mekanizma sağlar. Bu, özellikle bir isteğin birden fazla goroutine'i veya alt isteği tetiklediği durumlarda çok önemlidir.
Yeniden deneme stratejileri ne zaman kullanılmalı?
Yeniden deneme stratejileri, genellikle geçici ağ hataları (bağlantı kesintileri, DNS sorunları) veya sunucu tarafı geçici hatalar (5xx durum kodları, hız sınırlamaları) ile karşılaşıldığında kullanılmalıdır. Üstel geri çekilme, hedef servisin toparlanmasına zaman tanıyarak daha etkili bir yeniden deneme mekanizması sunar.
Bir linterda paralel istekler neden gereklidir?
Bir linter, genellikle birden fazla dosya veya bir dosya içindeki çok sayıda öğeyi (örneğin, harici bağlantıları) kontrol eder. Bu kontrollerin her biri bağımsız bir işlem olduğundan, bunları paralel olarak yürütmek, linterın toplam çalışma süresini önemli ölçüde azaltarak kullanıcı deneyimini iyileştirir.