Zitat von sirius:

Zitat von Luckie:

So viel, bis der Speicher ausgeht.

Das ist die Grenze für schlafende Threads. Gleichzeitig laufen sollten aber maximal 16.

Ich habe mich noch mal umgesehen, da mir das mit den 16 Threads keine Ruhe gelassen hat. Diese Portscanner:
http://www.delphipraxis.net/internal...canner&start=0 und
http://www.delphipraxis.net/internal...?p=47533#47533
laufen mit deutlich mehr als 16 aktiven Threads.

Ich hatte gestern 31 laufen. Ohne probs. Im moment laufen *nachguck* 11. Also Peak war bisher 31.

Ich hatte schon über 1000 laufen, allerdings wie viele davon tatsächlich aktiv waren kann ich nicht genau sagen. Aber bestimmt mehr als 16. Aber ich denke, in so einem Fall ist es ganz sinnvoll, wenn man Priorität der Threads runtersetzt.

Zitat von Luckie:

Ich hatte schon über 1000 laufen, allerdings wie viele davon tatsächlich aktiv waren kann ich nicht genau sagen. Aber bestimmt mehr als 16. Aber ich denke, in so einem Fall ist es ganz sinnvoll, wenn man Priorität der Threads runtersetzt.

55.000 threads sind schon machbar (mit 2GB RAM):

http://blogs.technet.com/markrussino...8/3261309.aspx

Cheers,
Michael

Zitat von DelTurbo:

Gibt es da eine obergrenze? Ich habe im moment bis zu 100 threads vorgesehen.

Hallo DelTurbo, ja.

1. Die Stack Size und der zur Verfügung stehende Speicher (RAM)
2. Die Kosten für Threadswitching

Microsoft empfiehlt für Serveranwendung die hohe Last für einzelne Requests erzeugen, auf modernen Xeon Systemen maximal 8 Threads per CPU.

Dh. Das Limit liegt genau dort, wo das Verhältnis der Verwaltungszeit (CPU-Takte für den aufwendigen Threadwechsel)
zum tatsächlichen Nutzen für die Anwendung zu kostspielig wird.

Anderst ausgedrückt, je mehr ein Thread arbeiten muss, desto weniger können kostengünstig verwendet werden.

Perfmon liefert dafür ausagekräftige Werte (Processor Queue Length)

lg. Astat