Hallo Bytechanger,

innerhalb einer Funktion bewege und nur auf vorhandene DLL zugreifen kann.

Ich kann zB nicht auf den DirectoryService zugreifen!

Kannst du weitere Infos bereitstellen ob es eine .NET (Core) od. .NET Framework Umgebung ist?

Via der ADSI OLE DB könnte das in .NET gehen (siehe z.B. ADSI Scripting for Administering Windows Active Directory Networks, aber da ist vermtutlich auch eine weitere Referenz (DLL) nötig.

Frag im Zweifel beim Projektverantwortlichen nach ob nicht doch DirectoryService verwendet werden kann. Das führt schließlich schneller zum Ziel (nämlich die LDAP Abfragen).

mfG Gü

Hallo GlaserMarkus25,

Ich bekomme allerdings nur eine html-seite zurück in der ein Javaskript sowie eine "Java needed" Meldung zu finden ist.

Was passiert wenn du mit Postman (o.ä. Tools) das manuell durchführst?
Wenn dort auch nur die HTML-Seite als Antwort kommt, so ist es halt die falsche URL.

mfG Gü

Hallo Andi153,

WhatsApp funktioniert dann immer noch. Aber ich glaub nur 30 Tage, dann wir das WA-Konto gelöscht.
D.h. wenn binnen 30 Tagen ein neuer Vertrag da ist gibt es kein Problem.

Schau aber zur Sicherheit in die WhatsApp-FAQs o.ä. denn dort sollte der Punkt behandelt werden.

mfG Gü

Hallo Palladin007,

da hat sich jemand eine sehr zukunftsträchtige Architektur überlegt und du bist jetzt in der bescheidenen Situation da etwas zu implementieren.

Ein paar Infos sind mehr vorhanden, aber es fehtl noch viel für ein gutes Bild worum es im Grunde geht.

Dieser externe Dienst nimmt (über eine Web-API) Daten entgegen, validiert ziemlich viel und teilt mir mit, ob alles ok ist, oder nicht.

Wann kommen dabei die eingangs genannten Requests (via IIS) ins Spiel?
Hat jeder Benutzer hier seine eigenen Daten od. sind die Daten für viele / alle Benutzer die gleichen?

Die 8000 sind eine Schätzung, die man mir mitgeteilt hat - in der Realität wahrscheinlich sehr viel weniger, die 8000 wären dann also eher ein absoluter Ausnahmefall

Es sollte schon auch vom Worst-Case ausgegangen werden. Oder zumindest von einer 90% Häufigkeit, od. dgl., andernfalls kann das Problem nicht sauber betrachtet werden.

Die komplexen Validierungen sind auch der Grund, warum ich immer sofort eine Antwort brauche

Was heißt "sofort" (siehe vorhin)?
Wohin wird die Antwort geschickt?

Wir müssen die Arbeit also abbrechen und Fehlerinformationen anbieten können

Welche "Arbeit" und wie werden die (bzw. sollen) die Fehlerinfos angeboten?

Würden wir die Nachrichten erst in die DB schreiben und irgendwann später versenden

Warum bringst du eine DB ins Spiel?

Das Zeitfenster von zwei Monaten kommt daher, dass es Prozesse gibt, an die sich die Anwender halten müssen. Ab Datum X wird ein Prozess freigegeben und für zwei Monate können die Anwender dann an diesem Prozess arbeiten (z.B. einen Antrag stellen), danach wird's dann wieder zu gemacht.

Wie ist hier der Zusammenhang mit den Requests?
Es wird wohl kein async Task max. 2 Monate brauchen 😉

Für dieses eine Projekt eine async->sync-Krücke, die ich dann später wieder abstoßen kann - solange es kein Deadlock-Risiko gibt

Mit "sync over async" und max. 8000 Requests wird es so od. so Probleme geben, v.a. in Hinsicht "sofort" (wie immer das auch definiert sein mag).

Dass die generelle Performance bei vielen gleichzeitigen Requests schlecht sein könnte

Was passiert denn nun wenn ein Request zum IIS kommt?
Wird dann das externe API aufgerufen? Das ist doch die zentrale Frage vom Problem und ob dann jeder Request eigentständig das Gleiche machen muss od. ob das irgendwie zusammengefasst werden kann. Wobei das "Zusammenfassen" hängt halt davon ab was gemacht wird und das behälts du uns vor.

Wenn nun für eine Hack-Lösung ein weiterer Hack eingebaut wird, so wird es wohl auch nicht besser werden.
Was passiert z.B. bei einem Windows-Update wenn dort die Logik vom ThreadPool (jenem von Windows) geändert wird unter der Annahme dass der IIS solche Threads verwendet? Was passiert wenn der IIS ein Update erfährt? Wer soll dann wissen wie und weshalb es zu Problemen kommen kann wenn 4000, 5000 od. gar die 8000 Requests kommen? Od. falls es in Zukunft vllt. doch eher 10.000 Requests werden könnten (zu Spitzenzeiten, etc.) und alles so langsam wird dass "sofort" nicht mehr gilt.

Mit den spärlichen Infos ist es mir schier unmöglich konstruktiv beizutragen. Wie vorhin schon gefragt, beschreib doch die wichtigen Punkte und nicht warum was nicht geändert werden kann, etc.

mfG Gü

Hallo Palladin007,

ich hab in meiner Antwort unten auf deine Punkte / Frage reagiert, fürchte aber dass wir so nicht weiterkommen.

Daher beschreib bitte den zeitlichen Ablauf wann was passieren soll. Zuerst einmal für einen Benutzer.
Dann wie es für mehrere Benutzer ausschaut.

Berücksichtige dabei bitte auch, dass wir keine Ahnung von deinem Projekt haben (du jedoch hoffentlich schon 😉).

Alle ThreadPool-Threads wollen synchron auf je einen Task warten, diese Tasks bekommen aber keinen Platz auf dem ThreadPool, weil jeder ThreadPool-Thread auf "seinen" Task wartet.

Auch unter .NET 4.x funktioniert so der ThreadPool nicht. Wenn der TP merkt dass "zuwenig weitergeht", so werden mehr Threads injiziert.

Wenn die Annahme von max. 8000 gilt, so wären das max. 8000 Threads und das ist bei einer CPU mit wesentlich weniger Kernen wohl nicht zielführend (der arme OS-Scheduler soll ja schauen dass die Arbeiten auf die CPUs möglichst fair verteilt werden).

entweder mit Task.Factory.StartNew() und TaskScheduler.Default oder Thread.UnsafeQueueUserWorkItem().
Zwischenfrage: Gibt es da relevante Unterschiede zwischen beiden, wenn das Ziel nur ist, keinerlei Context-Informationen durchreichen zu lassen?

Bei ersterem hast du halt einen Task, bei letzterem nicht.
D.h. Status, Fehlerbehandlung ist mit dem Task meist einfacher. Ebenso falls Continuations benötigt werden hat der Task seine Vorteile und wurde ursprünglich genau wegen solcher Dinge auch eingeführt.

Meine ursorüngliche Aussage, dass sie auf ein Datum warten, war falsch.
Ich können es tatsächlich nicht konkret sagen, wir haben leider auch kein brauchbares Logging, was etwas darüber verraten könnte.
Aber in der Regel sieht es so aus, dass ab einem Datum ein Prozess aus Sicht des Nutzers frei gegeben wird und dann können die Nutzer los legen

Da bin ich bisher noch nicht mit Infos gesegnet 😉
Weiter oben steht

Es wird kein Ergebnis errechnet, sondern eine externe Komponente gesteuert und überwacht.

Was nun?
Wird eine Komponenten überwacht und wenn Ereignis X eintritt, so gehts los?

Oder ist mit Datum wirklich ein Zeitpunkt gemeint, andem ein Benutzer los legen kann?
Warum dann der Request bereits vorher und dieser soll auf das Datum warten?

und sie haben ein Zeitfenster von 2 Monaten

Was passiert in diesem Zeitfenster, v.a. in Hinsicht auf die eingangs (OT) Requests?

Mir fehlt, auch jetzt noch, eine Beschreibung was das Ziel der Sache sein soll.
Wie lange dauern die Requests i.d.R., usw.

Es gibt jede Menge an Sequentialisierung-, Skalarsierung-, etc. Code, aber um das passende Verfahren auszuloten, sollte bekannt was erwünscht ist.

Das funktioniert leider auch nicht, weil die Requests die Antwort oder ggf. Fehler-Informationen selber sofort brauchen.

Das Problem gibt es so gut wie immer. Wobei auf was bezieht sich "sofort"?
Wenn die Request u.U. lange warten, dann ist "sofort" auch schon wieder später.
Warum ist ein "Ablegen" der Anfrage via HTTP, Bearbeitung und dann asynchrone (hier nur zeitlich gemeint) Rückmeldung via SignalR nicht möglich? Das kann sogar eher "sofort" durchgeführt werden, da das System insgesamt weniger unter Last steht und nicht >> Threads benötigt werden.

Aufsplitten, dass das Frontend erst später informiert wird, kommt leider auch nicht in Frage.

Warum nicht? Das wäre gängige Praxis und lässt sich auch mit ASP.NET (nicht Core) umsetzen.

Eine Annahme von mir für ein potentielles Deadlock-Risiko war ja, dass alle ThreadPool-Threads beschäftigt sind, indem sie Tasks auf den ThreadPool ausführen wollen.

Ein guter TP fügt dann einfach mehr Threads hinzu -- und entfernt diese ev. später wieder wenn sie nicht mehr benötigt werden.
Das Verhalten vom Windows-ThreadPool kenn ich aber nicht, nur jenes vom .NET ThreadPool.
Ein Deadlock ist da eher unwahrscheinchlich, eher Thread-Starvation od. Thread-Exhaustion, also dass die CPU vor lauter Threads kaum mehr wirklichen Fortschritt macht od. dass eben keine Threads mehr verfügbar sind.
Daher auch meine Intention zu erfahren was passiert, damit mit möglichst wenigen Threads das gelöst werden kann.

Meinst Du damit die Tatsache, dass die Requests alle synchron arbeiten und damit über die ganze Laufzeit diesen einen Thread blockieren, obwohl eigentlich 99% der Zeit nur auf IO gewartet werden muss?

Wenn auf IO sync gewartet wird, so ist dieser Thread eben blockiert bis IO fertig ist.
Auf IO kann jedoch async gewartet werden, dann wird kein Thread blockiert. Erst wenn IO fertig ist, so wird über den sog. IO-Completionport (ein Windows-Konzept, das es z.B. in Linux so nicht gibt / nicht verbreitet ist) einem im IO-ThreadPool verfügbaren Thread signalisiert dass er mit der "Continuation" (also ab nun dem folgenden Benutzercode) fortfahren kann.
Sind hier jedoch sehr viele (max. 8000?) Continuations registriert, so gibt es eine Menge zu tun. Da bin ich mir sicher, dass diese anders gelöst werden kann.

Oder meinst Du, dass ich den CustomTaskScheduler mit nur einem Thread implementiert habe?

Ich hab mir den Code (mangels Zeit) nicht angeschaut.

mfG Gü

Hallo Palladin007,

ganz hab ich das eigentliche Problem nicht verstanden. Kannst du das etwas allgemeiner beschreiben?
Bisher sind die Möglichkeiten schon sehr in eine Richtung getrieben, aber mein Gefühl mein dass es da eine andere Möglichkeit geben sollte.

z.B. sehr viele Nutzer

Lässt sich das größenordnungsmäßig angeben?

Der betreffende Code kann sehr oft gleichzeitig laufen, also z.B. sehr viele Nutzer, die ein bestimmtes Datum abwarten und dann alle auf einmal los rennen, Requests produzieren und ThreadPool-Threads füllen. Die Requests laufen auch recht lange,

Warten die alle auf das gleiche bestimmte Datum od. jeder für sein eigenes od. gibt es Gruppen von Datums auf die gewartet wird?

Müssen die Requests warten od. kann z.B. via SignalR das nur 1x laufen und die Benachrichtigungen, etc. werden dann zu den Clients gesendet?

UnitTest zu schreiben, der alle ThreadPool-Threads füllt

Da der ThreadPool in .NET (seit .NET 4) adaptiv arbeitet (mit einem Hill-Climbing Algorithmus) um so die Anzahl der Threads an die Workload anzupassen, bringt so ein Test recht wenig.
Außer die Min-/Max-Threadzahl wird begrenzt, aber da handelst du dir womöglich an anderer Stelle ein Problem ein.

IIRC verwendet der IIS pro Request einen (Windows-) Thread (ob dieser vom Windows ThreadPool stammt od. nicht weiß ich nicht), somit ist das Beschränken auf letztlich einen Thread so od. so eher fraglich ohne massive Skalierungsproblem zu haben und gleichzeitig die Gefahr von latenten Deadlocks groß.

mfG Gü

Hallo Andi153,

Hinweise zum Code:

• HttpClient nicht jedes mal neu erstellen → Guidelines for using HttpClient
• das JSON der Antwort kann direkt deserialisiert (halbwegs neue .NET Version vorausgesetzt) werden, der Umweg via string ist nicht nötig
• statt JArray wäre besser einen eigenen Typ zu haben, zu dem deserialisiert wird

Wenn zu jedem TextChanged-Ereignis ein HTTP-Request durchgeführt wird, so ist das ziemlich unperformant.
Da sollte zumindest eine Art "debouncing" eingeführt werden (bitte selbst danach suchen).

Gehts dir jetzt um Geolokation, also Koordinaten → Ortsname, od. nur um Suchvervollständigung wie "Ber" → "Berlin"?

Entsprechend dem Beispiel der Frage, so sollten mehrere Treffer angezeigt werden, denn für "Ber" könnte auch "Bernhaupten" passen. Mit welcher Priorisierung die möglichen Treffer angezeigt werden hängt vom deinem Anwendungsfall ab.

Ist die mögliche Suchmenge überschaubar, z.B. nur Städte in Deutschland, und wenn die Suchmenge als eher fix angenommen werden kann (so schnell ändert sich die Menge der Städte ja nicht), so könntest du anstatt der HTTP-Request die Menge an Städten lokal vorhalten und in diesen lokalen Daten suchen. Zum Suchen hierbei (Textvervollständigung) ist z.B. ein Trie ganz praktisch und effizient.

Sollte das nicht gehen und es sind HTTP-Request nötig, so ist je nach Anwendungstyp (hier wohl Desktop) auch ein lokales Caching möglich.

mfG Gü

Hallo glandorf,

alte Projekte werden nicht migriert und die Moq-Version aber auch nicht erhöht. Einfach weil eben Anderes zu tun ist.

Gibt es jedoch in alten Projekten neue Tests, so wird für diese NSubstitute verwendet. D.h. es existiert Moq und NSubstitute parallel.
Nur wenn das alte Projekt sehr überschaubar ist, so flog Moq komplett raus.

Bei neuen Projekten ausschließlich NSubstitute, Moq hat sich disqualifiziert.

BTW: mir gefällt die Arbeit mit NSubstitute eigentlich besser als mit Moq, daher hab ich mich ein paar gefragt warum nicht schon früher einmal der Blick auf Alternativen zum (damaligen) de-facto Standard Moq gemacht wurde.

Aber Abts Blog zur KI-gestützen Migration werde ich mir noch näher anschauen. Danke für den Tipp!

mfG Gü

Hallo Lance7ot,

Ich habe keinerlei Erfahrung über Softwareenticklung, sowie Programmierung

Siehe z.B. [FAQ] Wie finde ich den Einstieg in C#?.

mfG Gü

Hallo wdani,

mit welchem Library greifst du auf Excel zu bzw. hast die Excel-Datei erstellt? Danach richten sich dann auch die Lösungsmöglichkeiten.

eine Exceldatei erstellt und möchte nun die letzte beschriebene Zeile ermitteln

Wenn die Datei eh erstellt wird, kannst du dabei nicht einfach verfolgen was die letzte Zeile (pro Spalte, etc.) ist?

mfG Gü