Sorry symbiont, aber im Gegensatz zu Dir kann Ads mit Fakten und sauber
strukturierten Schilderungen aufwarten.
Back to Topic:
Loßgetreten hat für mich die ganze Debatte ein Blobeitrag auf Comet Daily,
eine Developer Blog wo es einerseits um Serverside Blocking / non Blocking
Threading geht (im Kontext von Tomcat) und vom Server ausgelöste
Events die den angeschlossenen Ajax Client ohne Polling darüber informieren
das sich am Server ein Ergeignis ergeben hat, auf das der Ajax Client reagieren
soll.
Abstrakt:
Natürlich befasst sich der Author des Eintrags in erster Lininie um die Java
Implementierung von Comet in Tomcat 6.20 und der kommenden Version 7.
Seit die neuen JVM’s nun auch non Blocking Threading bieten (via NIO)
wurde in der Comet-Szene die Ansicht vetreten das dieses Verfahren besser
und kosteneffizienter wäre als klassiche Blocking-Workerthreads für jeden
einzelnen Ajax Client der die Verindung hält. Die Paismessungen des Authors
lieferten jedoch im Realitycheck fast identische Lesitungskenndaten wie
die klassischen Blocking Threads. Das ganze Testszenario wurde dann
noch mal weiter aufgebohrt und sogar in einer Supercomputing Umgebung
wiederholt getestet, jedoch zeigt sich auch hier kein anderes Verhalten.
Völlig verwirrt suchte Der Author sich den Rat bei einem Google Engineer
der die ganze Sache dann mit folgendem Statement aufklärte:
The “Revelation”
As a frequent reader of javalobby.org, one day I found an article on avoiding NIO to get better throughput. Dan Dyer cited the blog and a paper of Paul Tyma, a Software Engineer at Google. In his research paper, Paul destroys, with humor and with some tests, the typical well established myths about the superiority of performance and scalability of NIO against IO. I must recognize that I was shocked with Paul’s investigations and soon realized the correlation with long-polling.
…
First of all, in any system, threads are basically pieces of memory:
stacks and state registries. There is no correspondence between
threads and hardware.
Furthermore, usually any processor (or core) is almost a single-thread processor. in other words, a very very small number of running threads completely fulfills the “real” parallelism of any average computer.
The parallelism of threading is an illusion and thread management is
basically a software problem with some necessary support of hardware.
Managing tons of threads is not a hardware problem, but one with software. For example, consider a single core processor saturated with two threads doing some non-blocking tasks. If in a single-real-thread-processor one task needs X time to complete, Y threads doing the same need X*Y as a minimum and in ideal circumstances (in this extreme case threading cost is 0), but the parallelism sensation is important and justifies threading.
The problem of many threads is that the performance cost is significant:
Thread switching has a cost, and this may increase when more threads are added.Uncontended synchronization (calling a synchronized method not blocked) has a cost. Contended synchronization has a cost.
The thread stack occupies memory.
Comet Daily » Blog Archive » Is it Raining Comets and Threads… Again?
Meine Überlegungen
Ok, es handelt sich nicht um ein JVM oder Java Phänomen sondern um ein generelles OS/Application-Problem .Da die Threads oder Forks jedoch vom OS erzeugt werden (der OS Kernel macht das ja, nicht das eigene Usermode Programm) scheint es mir besonders spannend zu sein wie effizient dies auf OS Ebene geschieht. Seit Linux Kernel 2.6 wird ja offiziell NTPL
verwendet, davor war es es wohl ziemlich grausam. Aber angefangen hat mit der ganzn Threading Thematik offenbar Ende der 80er Jahre SUN und SunOS/Solaris war das erste Multitreaded Fähige System.Da stellte sich mir jetzt die praktische Frage ob da eventuell ein Voteil im Thread/Fork Management Bereich besteht, weil die einfach mehr Zeit hatten.
Das ist zumindest erstmal mein naive Vermutung.Kann ja aber auch sein,das Linux z.B im Zusammenhang mit den besseren
Intel Hyperthreading Punkten kann und overall besser im Endergebnis da steht.