Bütün cevaplar bende yok. Umarım üzerine biraz ışık tutabilirim .
.NET'in iş parçacığı modelleri hakkındaki önceki ifadelerimi basitleştirmek için Paralel Kitaplığın Görevleri ve Görevler için varsayılan TaskScheduler öğesinin ThreadPool'u kullandığını bilmeniz yeterlidir. Hiyerarşide ne kadar yüksek olursanız (ThreadPool en alttadır), öğeleri oluştururken daha fazla yükünüz olur. Bu ek yük kesinlikle daha yavaş olduğu anlamına gelmez, ancak orada olduğunu bilmek güzel. Sonuçta algoritmanızın çok iş parçacıklı bir ortamda performansı, tasarımına gelir. Ne performans gösterir sıralı olabilir paralel olarak aynı düzeyde performans. Size sert ve hızlı kurallar vermek için çok fazla faktör var, bunlar ne yapmaya çalıştığınıza bağlı olarak değişir. Ağ istekleriyle uğraştığınızdan, küçük bir örnek vermeye çalışacağım.
Soketler konusunda uzman olmadığımı ve Zeroc-Ice hakkında hiçbir şey bilmediğimi söyleyeyim. Eşzamansız işlemler hakkında biraz bilgim var ve burası size gerçekten yardımcı olacak. Bir soket aracılığıyla eşzamanlı bir istek gönderirseniz, aradığınızda Socket.Receive(), bir istek alınana kadar iş parçacığınız engellenir. Bu iyi değil. İleti diziniz engellendiği için başka istekte bulunamaz. Socket.Beginxxxxxx () kullanarak, G / Ç isteği yapılır ve soket için IRP kuyruğuna konur ve iş parçacığınız devam eder. Bu, iş parçacığınızın aslında herhangi bir engelleme olmadan bir döngüde binlerce istekte bulunabileceği anlamına gelir!
Sizi doğru anlıyorsam, test kodunuzda Zeroc-Ice üzerinden çağrıları kullanıyorsunuz, aslında bir http uç noktasına ulaşmaya çalışmıyorsunuz. Eğer durum buysa, Zeroc-Ice'ın nasıl çalıştığını bilmediğimi itiraf edebilirim. Bununla birlikte, burada listelenen tavsiyeleri , özellikle kısmı takip etmenizi öneririm Consider Asynchronous Method Invocation (AMI). Sayfa şunu gösterir:
AMI kullanarak istemci, çağırma gönderilir gönderilmez (veya hemen gönderilemezse sıraya alınır), denetimin iş parçacığını yeniden kazanır ve bu da müşterinin bu iş parçacığını diğer faydalı işleri gerçekleştirmek için kullanmasına olanak tanır .
Hangi yukarıda .NET yuvaları kullanarak tarif eşdeğer gibi görünüyor. Çok sayıda gönderme yapmaya çalışırken performansı artırmanın başka yolları olabilir, ancak buradan veya o sayfada listelenen başka bir öneriyle başlayacağım. Başvurunuzun tasarımı konusunda çok belirsiz davrandınız, bu yüzden yukarıda olduğumdan daha spesifik olabilirim. Unutmayın, ihtiyacınız olanı elde etmek için kesinlikle gerekli olandan daha fazla iş parçacığı kullanmayın , aksi takdirde uygulamanızın istediğinizden çok daha yavaş çalıştığını görürsünüz.
Sözde koddaki bazı örnekler (gerçekten öğrenmek zorunda kalmadan buza mümkün olduğunca yakın yapmaya çalıştım):
var iterations = 100000;
for (int i = 0; i < iterations; i++)
{
// The thread blocks here waiting for the response.
// That slows down your loop and you're just wasting
// CPU cycles that could instead be sending/receiving more objects
MyObjectPrx obj = iceComm.stringToProxy("whateverissupposedtogohere");
obj.DoStuff();
}
En iyi yol:
public interface MyObjectPrx : Ice.ObjectPrx
{
Ice.AsyncResult GetObject(int obj, Ice.AsyncCallback cb, object cookie);
// other functions
}
public static void Finished(Ice.AsyncResult result)
{
MyObjectPrx obj = (MyObjectPrx)result.GetProxy();
obj.DoStuff();
}
static void Main(string[] args)
{
// threaded code...
var iterations = 100000;
for (int i = 0; i < iterations; i++)
{
int num = //whatever
MyObjectPrx prx = //whatever
Ice.AsyncCallback cb = new Ice.AsyncCallback(Finished);
// This function immediately gets called, and the loop continues
// it doesn't wait for a response, it just continually sends out socket
// requests as fast as your CPU can handle them. The response from the
// server will be handled in the callback function when the request
// completes. Hopefully you can see how this is much faster when
// sending sockets. If your server does not use an Async model
// like this, however, it's quite possible that your server won't
// be able to handle the requests
prx.GetObject(num, cb, null);
}
}
Daha fazla iş parçacığı! = Yuva göndermeye çalışırken (veya gerçekten herhangi bir şey yaparken) daha iyi performans olduğunu unutmayın. İş parçacıkları, üzerinde çalıştığınız sorunları otomatik olarak çözecekleri için sihir değildir. İdeal olarak, bir iplik zamanının çoğunu beklemediği sürece çekirdek başına 1 iplik istersiniz, o zaman daha fazlasına sahip olmanızı haklı çıkarabilirsiniz. Bağlam anahtarları ve kaynak israfı olacağından, her isteği kendi iş parçacığında yürütmek kötü bir fikirdir. (Bu konuda yazdığım her şeyi görmek istiyorsanız, düzenle'yi tıklayın ve bu yazının geçmiş revizyonlarına bakın. Yalnızca ana sorunu bulduğu için kaldırdım.)
Saniyede çok sayıda istek yapmak istiyorsanız, bu isteği kesinlikle iş parçacıklarında yapabilirsiniz. Ancak, iş parçacığı oluşturma ile aşırıya kaçmayın. Bir denge bulun ve ona bağlı kalın. Eşzamanlı olmayan bir modelle eşzamanlı bir model kullanırsanız daha iyi performans elde edersiniz.
Umarım bu yardımcı olur.