Korkarım burada "yanlış bir şey yapıyorum", eğer öyleyse beni sil ve özür dilerim. Özellikle, bazı insanların yarattığı düzgün küçük ek açıklamaları nasıl oluşturduğumu göremiyorum. Ancak, bu iş parçacığı üzerinde yapmak için birçok endişe / gözlem var.
1) Popüler cevaplardan birinde sahte kodda yorumlanan öğe
result = query( "select smurfs from some_mushroom" );
// twiddle fingers
go_do_something_with_result( result );
aslında sahte. İş parçacığı hesaplanıyorsa, baş döndürücü değil, gerekli işi yapıyor. Öte yandan, sadece IO tamamlanması bekliyor, o zaman oluyor değil CPU zamanı kullanarak çekirdekteki iplik kontrol altyapısının bütün mesele işlemci yapmak için yararlı bir şeyler bulacaksınız olmasıdır. Burada önerildiği gibi "başparmaklarınızı çevirmek" için tek yol bir yoklama döngüsü oluşturmak olacaktır ve gerçek bir web sunucusu kodlayan kimse bunu yapmak için yeterince beceriksiz.
2) "İş parçacıkları zor", yalnızca veri paylaşımı bağlamında anlamlıdır. Bağımsız web isteklerini işlerken olduğu gibi temel olarak bağımsız iş parçacıklarınız varsa, iş parçacığı basit bir şekilde basittir, sadece bir işin nasıl işleneceğinin doğrusal akışını kodlarsınız ve çok sayıda isteği işleyeceğini bilerek oturursunuz. etkin bir şekilde bağımsız olacak. Şahsen, çoğu programcı için, kapatma / geri arama mekanizmasını öğrenmenin sadece yukarıdan aşağıya iplik versiyonunu kodlamaktan daha karmaşık olduğunu düşünürüm. (Ama evet, eğer iş parçacıkları arasında iletişim kurmak zorunda kalırsanız, hayat gerçekten hızlı bir şekilde zorlaşır, ama sonra kapatma / geri arama mekanizmasının gerçekten bunu değiştirdiğinden emin değilim, sadece seçeneklerinizi kısıtlar, çünkü bu yaklaşım hala iş parçacıkları ile gerçekleştirilebilir Her neyse, bu '
3) Şimdiye kadar, hiç kimse belirli bir bağlam anahtarının neden diğer türlerden daha fazla veya daha az zaman alacağına dair gerçek bir kanıt sunmamıştır. Çok görevli çekirdek oluşturma deneyimim (katıştırılmış denetleyiciler için küçük bir ölçekte, "gerçek" bir işletim sistemi kadar süslü bir şey yok) bu durumun böyle olmayacağını gösteriyor.
4) Düğümün diğer web sunucularından ne kadar daha hızlı olduğunu iddia ettiğine dair gördüğüm tüm illüstrasyonlar korkunç bir şekilde kusurludur, ancak Düğüm için kesinlikle kabul edeceğim bir avantajı dolaylı olarak gösteren bir şekilde kusurludur (ve hiçbir şekilde önemsiz değildir). Düğüm ayarlamaya ihtiyaç duymuyor (hatta izin veriyor). Dişli bir modeliniz varsa, beklenen yükü kaldıracak yeterli dişler oluşturmanız gerekir. Bunu kötü bir şekilde yapın, sonuçta düşük performans elde edersiniz. Çok az sayıda iş parçacığı varsa, CPU boştadır, ancak daha fazla istek kabul edemez, çok fazla iş parçacığı oluşturur ve çekirdek belleğini boşa harcarsınız ve Java ortamı durumunda, ana yığın belleği de harcarsınız . Şimdi, Java için yığın israfı, sistemin performansını düşürmenin ilk, en iyi yoludur, çünkü verimli çöp toplama (şu anda bu G1 ile değişebilir, ancak jüri en azından 2013'ün başından itibaren hala bu noktada değil gibi görünüyor) çok fazla yedek yığının olmasına bağlıdır. Yani, sorun var, çok az sayıda iş parçacığıyla ayarlayın, boş CPU'larınız ve düşük veriminiz var, çok fazla ayar yapın ve başka şekillerde bataklık yapın.
5) Düğüm'ün yaklaşımının "tasarımla daha hızlı" olduğu iddiasının mantığını kabul etmemin başka bir yolu daha var ve işte bu. Çoğu iş parçacığı modeli, daha uygun (değer yargısı uyarısı :) ve daha verimli (bir değer yargısı değil) önleyici modelin üzerine yerleştirilmiş zaman dilimli bir bağlam anahtarı modeli kullanır. Bu iki nedenden ötürü olur, ilk olarak, çoğu programcı öncelik önleme anlamıyor gibi görünüyor ve ikincisi, bir pencere ortamında iplik geçirmeyi öğrenirseniz, hoşunuza gitsin ya da sevmesin zamanlama var (elbette, bu ilk noktayı güçlendiriyor) Özellikle, Java'nın ilk sürümleri Windows'ta Solaris uygulamaları ve zaman dilimlemesinde öncelikli önleme kullandı. modeli her yerde zaman dilimi olarak değiştirdiler). Her neyse, alt satırda zaman dilimleme ek (ve potansiyel olarak gereksiz) bağlam anahtarları oluşturur. Her bağlam anahtarı CPU zamanını alır ve o zaman eldeki gerçek işte yapılabilecek işten etkili bir şekilde çıkarılır. Bununla birlikte, zaman diliminden dolayı bağlam değiştirme için harcanan zaman miktarı, oldukça tuhaf bir şey olmadıkça ve zamanın böyle olmasını beklemem için hiçbir neden yokken, toplam sürenin çok küçük bir yüzdesinden fazla olmamalıdır. basit web sunucusu). Yani, evet, zaman dilimlemeye dahil olan aşırı bağlam anahtarları verimsizdir (ve bunlar gerçekleşmez ve o zaman eldeki gerçek işte yapılabilecek işten etkili bir şekilde çıkarılır. Bununla birlikte, zaman diliminden dolayı bağlam değiştirme için harcanan zaman miktarı, oldukça tuhaf bir şey olmadıkça ve zamanın böyle olmasını beklemem için hiçbir neden yokken, toplam sürenin çok küçük bir yüzdesinden fazla olmamalıdır. basit web sunucusu). Yani, evet, zaman dilimlemeye dahil olan aşırı bağlam anahtarları verimsizdir (ve bunlar gerçekleşmez ve o zaman eldeki gerçek işte yapılabilecek işten etkili bir şekilde çıkarılır. Bununla birlikte, zaman diliminden dolayı bağlam değiştirme için harcanan zaman miktarı, oldukça tuhaf bir şey olmadıkça ve zamanın böyle olmasını beklemem için hiçbir neden yokken, toplam sürenin çok küçük bir yüzdesinden fazla olmamalıdır. basit web sunucusu). Yani, evet, zaman dilimlemede yer alan aşırı bağlam anahtarları verimsizdir (ve bunlarbir kural olarak çekirdek iş parçacıkları, btw), ancak fark, Düğüm için genellikle ima edilen performans iddialarında ima edilen tam sayı faktörlerinin türü değil, verimin yüzde birkaçı olacaktır.
Her neyse, hepsinin uzun ve aşırı olduğu için özür dilerim, ama şimdiye kadar tartışmanın hiçbir şey kanıtlamadığını hissediyorum ve bu durumlardan herhangi birinde birinden haber almaktan memnuniyet duyarım:
a) Düğümün neden daha iyi olması gerektiğine dair gerçek bir açıklama (yukarıda özetlediğim iki senaryonun ötesinde, birincisi (kötü ayarlama) şimdiye kadar gördüğüm tüm testlerin gerçek açıklaması olduğuna inanıyorum. ], aslında, bu konuda ne kadar düşünürsem, çok sayıda yığın tarafından kullanılan belleğin burada önemli olup olmadığını merak ediyorum. Modern iş parçacıkları için varsayılan yığın boyutları oldukça büyük olma eğilimindedir, ancak kapanışa dayalı olay sistemi sadece ihtiyaç duyulan şey olacaktır)
b) tercih edilen dişli sunucuya gerçekten şans tanıyan gerçek bir karşılaştırma ölçütü. En azından bu şekilde, iddiaların aslında yanlış olduğuna inanmayı bırakmalıyım;> ([değiştir] muhtemelen istediğimden daha güçlü, ancak performans avantajları için verilen açıklamaların en iyi şekilde eksik olduğunu hissediyorum ve gösterilen karşılaştırmalar makul değildir).
Şerefe, Toby
select(), iş parçacığı içeriği değişimlerinden daha hızlıdır.