# Süreçler Arası İletişim Uygulama Yanıt Süresini Etkiler

Yanıt süresi, yazılımın kullanılabilirliği için kritik öneme sahiptir. Bazı yazılım sistemlerinin yanıt vermesini beklemek kadar sinir bozucu çok az şey vardır, özellikle de yazılımla etkileşimimiz tekrarlanan uyaran ve tepki döngülerini içerdiğinde. Yazılımın zamanımızı boşa harcadığını ve verimliliğimizi etkilediğini hissediyoruz. Performans yönetimi literatürünün çoğu, bazı durumlarda fark yaratabilecek, ancak modern çok katmanlı kurumsal uygulamalarda performansa hükmetme olasılığı çok daha düşük olan veri yapıları ve algoritmalara hala odaklanmaktadır.

Bu tür uygulamalarda performans bir sorun olduğunda, benim deneyimim, veri yapılarını ve algoritmaları incelemenin iyileştirme aramak için doğru yer olmadığı yönündeydi. Tepki süresi, en çok, bir uyarana yanıt olarak yürütülen uzak süreçler arası iletişimlerin (IPC'ler) sayısına bağlıdır. Başka yerel darboğazlar olsa da, süreçler arası uzak iletişimlerin sayısı genellikle baskındır. Her bir uzak süreçler arası iletişim, genel yanıt süresine ihmal edilemeyecek bir gecikme süresine katkıda bulunur ve bu bireysel katkılar, özellikle sırayla gerçekleştiklerinde toplanır.

En iyi örnek, nesne-ilişkisel eşleme kullanan bir uygulamada *dalgalanma yüklemesidir(ripple loading)*. Dalgalı yükleme, nesnelerin grafiğini oluşturmak için gereken verileri seçmek için birçok veritabanı çağrısının sıralı yürütülmesini açıklar (Martin Fowler'ın *Patterns of Enterprise Application Architecture* içindeki [Lazy Load](http://martinfowler.com/eaaCatalog/lazyLoad.html) bölümüne bakın). Veritabanı istemcisi bir web sayfası oluşturan orta düzey bir uygulama sunucusu olduğunda, bu veritabanı çağrıları genellikle tek bir iş parçacığında sırayla yürütülür. Bireysel gecikme süreleri birikerek genel yanıt süresine katkıda bulunur. Her veritabanı araması yalnızca 10 ms sürse bile, 1000 arama gerektiren bir sayfa (ki bu nadir değildir) en az 10 saniyelik bir yanıt süresi sergileyecektir. Diğer örnekler arasında web hizmeti çağırma, bir web tarayıcısından HTTP istekleri, dağıtılmış nesne çağırma, istek-yanıt mesajlaşma ve özel ağ protokolleri üzerinden veri sistemi etkileşimi sayılabilir. Bir uyarana yanıt vermek için ne kadar uzak IPC'ye ihtiyaç duyulursa, yanıt süresi o kadar uzun olacaktır.

Uyaran başına uzak süreçler arası iletişimlerin sayısını azaltmak için nispeten açık ve iyi bilinen birkaç strateji vardır. Bir strateji, eldeki amaç için tam olarak doğru verilerin minimum miktarda etkileşimle değiş tokuş edilmesi için süreçler arasındaki arayüzü optimize ederek tutumluluk ilkesini uygulamaktır. Diğer bir strateji, mümkün olduğunda süreçler arası iletişimi paralel hale getirmektir, böylece genel yanıt süresi esas olarak en uzun gecikmeli IPC tarafından yönlendirilir. Üçüncü bir strateji, önceki IPC'lerin sonuçlarını önbelleğe almaktır, böylece bunun yerine yerel önbelleğe basarak gelecekteki IPC'lerden kaçınılabilir.

Bir uygulama tasarlarken, her bir uyarana yanıt olarak süreçler arası iletişimlerin sayısına dikkat edin. Düşük performanstan muzdarip uygulamaları analiz ederken, genellikle IPC-uyarıcı oranlarının binlere bir olduğunu gördüm. İster önbelleğe alma, ister paralelleştirme veya başka bir teknikle bu oranı azaltmak, veri yapısı seçimini değiştirmekten veya bir sıralama algoritmasında ince ayar yapmaktan çok daha fazlasını kazandıracaktır.

[Randy Stafford](http://programmer.97things.oreilly.com/wiki/index.php/Randy_Stafford) Tarafından


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://97-things-every-x-should-know.gitbook.io/97-things-every-programmer-should-know/tr/thing_41.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
