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 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 Tarafından