Indy Sunucuları - İş Parçacığı Modeli (1 / 3)

Indy Sunucuları istemci bağlantılarını işlemek için iş parçacıkları kullanır; yeni bir istemci sunucuya her bağlandığında yeni bir iş parçacığı oluşturulur ve bu iş parçacığı bağlantıyı işler; bu nedenle 100 bağlantınız varsa 100 iş parçacığı olacaktır. Ayrıca indy engelleyen soketler (blocking sockets) kullanır; bu, okuduğunuzda veya yazdığınızda, işlev tamamlanana kadar geri dönmediği anlamına gelir.

Bu modelin bazı avantajları vardır; kod sıralı olarak işlendiği için kodlaması kolaydır. Ancak bir dezavantaj olarak, bağlantı sayısı arttıkça, iş parçacığı bağlam değişimi (context switch) nedeniyle performans giderek kötüleşir. Bağlam değiştirme, bir iş parçacığının durumunu, daha sonraki bir zaman noktasında yürütmeye devam etmek üzere geri yüklenebilmesi için saklama işlemidir. İş parçacıkları arasındaki hızlı bağlam değiştirme, CPU kullanımı açısından pahalıdır. Bir sunucuda 1000 bağlantı oluşturursanız, veri alışverişi olmamasına rağmen cpu'nun çalıştığını göreceksiniz; bu cpu kullanımı iş parçacığı bağlam değişiminden kaynaklanır.

Indy Modeline Alternatifler 

Her bağlantı için 1 iş parçacığı kullanmak yerine, bağlantıları işlemek için bir iş parçacığı havuzu kullanan ve engelleyici olmayan soketler kullanan IOCP (Windows için) veya EPOLL (Linux için) gibi alternatifler vardır. Bu model, eşzamanlı bağlantı sayısı yüksek olduğunda çok daha verimlidir ve varsayılan Indy İş Parçacığı Modelinden çok daha iyi ölçeklenir.

IOCP (Windows) 

G/Ç tamamlama portları, çok işlemcili bir sistemde birden fazla asenkron G/Ç isteğini işlemek için verimli bir iş parçacığı modeli sağlar. Bir işlem bir G/Ç tamamlama portu oluşturduğunda, sistem yalnızca bu istekleri hizmet etmek olan iş parçacıkları için ilişkili bir kuyruk nesnesi oluşturur. Çok sayıda eşzamanlı asenkron G/Ç isteğini işleyen işlemler, bunu, bir G/Ç isteği aldıklarında iş parçacığı oluşturmaktan ziyade önceden ayrılmış bir iş parçacığı havuzuyla birlikte G/Ç tamamlama portlarını kullanarak daha hızlı ve verimli bir şekilde yapabilir.

IOCP Modeli engelleyici olmayan soketler kullanır; Select kullanmak yerine, istemci bağlantılarını işlemek için AcceptEx işlevini ve bir iş parçacığı havuzunu kullanır.

sgcWebSockets Indy sunucusunda IOCP'yi etkinleştirmek için aşağıdaki koda bakın

oServer := TsgcWebSocketHTTPServer.Create(nil);
oServer.NotifyEvents := neNOSync;
oServer.IOHandlerOptions.IOHandlerType := iohIOCP;
oServer.Active := True; 

Yeni bir WebSocket + HTTP Sunucusu oluşturulacak ve bir iş parçacığı havuzu bağlantıları işleyecektir; kullanılan iş parçacığı sayısı, sunucunun çalıştığı cpu sayısına bağlı olacaktır.

EPOLL (Linux) 

Epoll, ilk olarak Linux çekirdeğinin 2.5.44 sürümünde tanıtılan, ölçeklenebilir bir G/Ç olay bildirim mekanizması için bir Linux çekirdek sistem çağrısıdır. İşlevi, herhangi birinde G/Ç'nin mümkün olup olmadığını görmek için birden fazla dosya tanımlayıcısını izlemektir. İzlenen dosya tanımlayıcısı sayısının büyük olduğu daha talepkar uygulamalarda daha iyi performans elde etmek için, eski POSIX select ve poll sistem çağrılarının yerini almak içindir.

100.000 izleme işlemi için performansı karşılaştıran aşağıdaki tabloya bakın:

Bu nedenle, izlenecek 10 civarından fazla dosya tanımlayıcınız olduğunda epoll kullanmak gerçekten çok daha hızlıdır.

EPOLL Modeli engelleyici olmayan soketler kullanır; Select kullanmak yerine, istemci bağlantılarını işlemek için Accept async işlevini ve bir iş parçacığı havuzunu kullanır.

sgcWebSockets Indy sunucusunda EPOLL'u etkinleştirmek için aşağıdaki koda bakın

oServer := TsgcWebSocketHTTPServer.Create(nil);
oServer.NotifyEvents := neNOSync;
oServer.IOHandlerOptions.IOHandlerType := iohEPOLL;
oServer.Active := True;