RFC Multitasking mit Servergroup
4 Beiträge
•
Seite 1 von 1
4 Beiträge
Seite 1 von 1
Hallo zusammen,
wenn man einen RFC Baustein mit DESTINATION IN GROUP aufruft und die RFC Gruppe (RZ12) hat 50% für die maximale Anzahl Dialogprozesse, werden dann bei jedem Aufruf 50% der GERADE VERFÜGBAREN Tasks verwendet oder 50% ALLER verfügbaren Tasks des Servers verwendet (das wäre meine Intention)?
Hintergrund:
Ich habe für einen Kunden ein Kalkulationscockpit erstellt. In einem Userexit in der Materialkalkulation (CK11N, CK24, CK40N) starte ich einen RFC FB mit STARTING NEW TASK 000001 (um die Kalkulation nicht zeitlich zu belasten), der in einer Tabelle weitere Kalkulationswerke nachliest und diese dann wieder per BAPI kalkuliert. Dieser Aufruf ruft dann wieder diesen FB auf um die Kalkulation für ein weiteres Werk zu erstellen usw. Jeder Aufruf liest dann wieder die Tabelle und erzeugt neue Kalkulationen. Jedes Material/Werk/Kalkulationsvariante wird in einer Sperrtabelle verwaltet damit nicht doppelt kalkuliert wird. Das funktioniert auch alles.
Das Problem ist, das jeder neu aufgerufene Task sich sofort einen Dialogtask holt, je nach Anzahl Werke eben dann alle verfügbaren Tasks, das muss natürlich eingeschränkt werden bevor es produktiv geht. Da jeder Aufruf aus dem Kalkulationsexit autark ist, habe ich auch keine zentrale Instanz, mit der ich die RFC Aufrufe kontrollieren könnte. Deshalb habe ich jeden neuen Task mit DESTINATION IN GROUP gestartet um die gesamten Aufrufe über die Gruppe auf max. 50% zu begrenzen. Ist kein neuer Task verfügbar ( Rückmeldung RFC Aufruf), warte ich x sekunden und starte den Aufruf dann x mal (x kann ich variabel einstellen).
Liege ich hier mit meiner Annahme richtig? Auf dem Testsystem habe ich gesehen dass mehr als 50% der freien Tasks belegt werden.
Ich habe eine eigene Servergruppe angelegt auf dem Testsystem mit 50%, reicht das oder muss das System dann neu gestartet werden (diese Meldung erschien beim Sichern) oder reicht ab- und anmelden?
Vielen Dank für einen Tipp!
Gruß Wolfgang
wenn man einen RFC Baustein mit DESTINATION IN GROUP aufruft und die RFC Gruppe (RZ12) hat 50% für die maximale Anzahl Dialogprozesse, werden dann bei jedem Aufruf 50% der GERADE VERFÜGBAREN Tasks verwendet oder 50% ALLER verfügbaren Tasks des Servers verwendet (das wäre meine Intention)?
Hintergrund:
Ich habe für einen Kunden ein Kalkulationscockpit erstellt. In einem Userexit in der Materialkalkulation (CK11N, CK24, CK40N) starte ich einen RFC FB mit STARTING NEW TASK 000001 (um die Kalkulation nicht zeitlich zu belasten), der in einer Tabelle weitere Kalkulationswerke nachliest und diese dann wieder per BAPI kalkuliert. Dieser Aufruf ruft dann wieder diesen FB auf um die Kalkulation für ein weiteres Werk zu erstellen usw. Jeder Aufruf liest dann wieder die Tabelle und erzeugt neue Kalkulationen. Jedes Material/Werk/Kalkulationsvariante wird in einer Sperrtabelle verwaltet damit nicht doppelt kalkuliert wird. Das funktioniert auch alles.
Das Problem ist, das jeder neu aufgerufene Task sich sofort einen Dialogtask holt, je nach Anzahl Werke eben dann alle verfügbaren Tasks, das muss natürlich eingeschränkt werden bevor es produktiv geht. Da jeder Aufruf aus dem Kalkulationsexit autark ist, habe ich auch keine zentrale Instanz, mit der ich die RFC Aufrufe kontrollieren könnte. Deshalb habe ich jeden neuen Task mit DESTINATION IN GROUP gestartet um die gesamten Aufrufe über die Gruppe auf max. 50% zu begrenzen. Ist kein neuer Task verfügbar ( Rückmeldung RFC Aufruf), warte ich x sekunden und starte den Aufruf dann x mal (x kann ich variabel einstellen).
Liege ich hier mit meiner Annahme richtig? Auf dem Testsystem habe ich gesehen dass mehr als 50% der freien Tasks belegt werden.
Ich habe eine eigene Servergruppe angelegt auf dem Testsystem mit 50%, reicht das oder muss das System dann neu gestartet werden (diese Meldung erschien beim Sichern) oder reicht ab- und anmelden?
Vielen Dank für einen Tipp!
Gruß Wolfgang
Geht nicht gibts nicht
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von a-dead-trousers (Top Expert / 4397 / 223 /
1182
)
»
Du könntest eine Server Gruppe verwenden, die nur einen Teil eurer Applikationsserver umfasst. Auf diese kannst du dann dein Programm ohne Modifikation loslassen und die RFC Schnittstelle die Verwaltung der Ressourcen selbst überlassen. Die nicht inkludierten Applikationsserver stehen den normalen Anwendern weiterhin und uneingeschränkt zur Verfügung.
Ein anderer Ansatz wäre, aus dem Exit heraus zuerst ein "Verwaltungsprogram" zu starten, das dann die eigentliche Kalkulation für die Werke seriell (oder mit einer eingeschränkten Menge paralell) startet.
Alternativ kann man auch, anstatt die Kalkulation direkt zu starten, diese Anfrage in einer Tabelle speichern und durch einen Job im Hintergrund abarbeiten zu lassen. Da ja eh mit STARTING NEW TASK gearbeitet wird, wird das Ergebnis nicht "sofort" benötigt.
Ein anderer Ansatz wäre, aus dem Exit heraus zuerst ein "Verwaltungsprogram" zu starten, das dann die eigentliche Kalkulation für die Werke seriell (oder mit einer eingeschränkten Menge paralell) startet.
Alternativ kann man auch, anstatt die Kalkulation direkt zu starten, diese Anfrage in einer Tabelle speichern und durch einen Job im Hintergrund abarbeiten zu lassen. Da ja eh mit STARTING NEW TASK gearbeitet wird, wird das Ergebnis nicht "sofort" benötigt.
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Hallo adt,
Das mit dem einen Server ist eine gute Idee wenn das mit der RFC Gruppe doch nicht das gewünschte Ergebnis liefert, ein erster Massentest lief aber schon mal super ohne sich alle Prozesse zu holen, dauert halt länger.
An das Verwaltungsprogramm habe ich auch schon gedacht, aber die CK40N startet sehr viele Kalkulationen an, ich könnte höchstens über die Laufnummer (die in jeder Kalkulation mitgegeben wird) feststellen, ob für diesen Lauf bereits ein Programm gestartet wurde, das Ende müsste ich über die Jobs ermitteln. Wäre eine Alternative, aber nur für die CK40N. Wenn eine einzelne Kalkulation im Dialog angestartet, läuft im Hintergrunde auch wieder die Kette los, Jeder Task autark.
Die Idee mit der Tabelle hatte ich schon umgesetzt, hat aber (noch) nicht so funktioniert wie es sollte.
Aber nochmal zurück zu eigentlichen Frage, gibt mir eine Servergruppe immer von den gerade verfügbaren Prozessen 50% oder generell nur 50% aller Tasks auf dem Server?
Beispiel: Server hat 100 Dialogprozess, 60 sind gerade von anderen Usern in Benutzung, kann ich dann noch 20 Taks starten (50% von den restlichen 40) oder gar keinen, weil bereits mehr als 50% der Tasks vergeben sind?
Danke und Gruß,
Wolfgang
Das mit dem einen Server ist eine gute Idee wenn das mit der RFC Gruppe doch nicht das gewünschte Ergebnis liefert, ein erster Massentest lief aber schon mal super ohne sich alle Prozesse zu holen, dauert halt länger.
An das Verwaltungsprogramm habe ich auch schon gedacht, aber die CK40N startet sehr viele Kalkulationen an, ich könnte höchstens über die Laufnummer (die in jeder Kalkulation mitgegeben wird) feststellen, ob für diesen Lauf bereits ein Programm gestartet wurde, das Ende müsste ich über die Jobs ermitteln. Wäre eine Alternative, aber nur für die CK40N. Wenn eine einzelne Kalkulation im Dialog angestartet, läuft im Hintergrunde auch wieder die Kette los, Jeder Task autark.
Die Idee mit der Tabelle hatte ich schon umgesetzt, hat aber (noch) nicht so funktioniert wie es sollte.
Aber nochmal zurück zu eigentlichen Frage, gibt mir eine Servergruppe immer von den gerade verfügbaren Prozessen 50% oder generell nur 50% aller Tasks auf dem Server?
Beispiel: Server hat 100 Dialogprozess, 60 sind gerade von anderen Usern in Benutzung, kann ich dann noch 20 Taks starten (50% von den restlichen 40) oder gar keinen, weil bereits mehr als 50% der Tasks vergeben sind?
Danke und Gruß,
Wolfgang
Geht nicht gibts nicht
Beitrag
von a-dead-trousers (Top Expert / 4397 / 223 /
1182
)
»
Rein gefühlsmäßig würde ich sagen 50% von den max. verfügbaren Dialogprozessen.
Da bei "normalen" Interaktionen durch Benutzer die Dialogprozesse nur "ganz kurz" belegt sind, ist die tatsächliche Auslastung (oder die gerade belegten Dialogprozesse) nur eine sehr kurzfristige Momentaufnahme. Davon dann 50% zu ermitteln scheint mir von der Verwaltung her etwas zu aufwändig zu sein. Vor Allem da sich das im Sekundentakt ändern kann.
Wenn du also 100 Prozesse hast, wird die Servergruppe max. 50 Prozesse gleichzeitig zu belegen versuchen. Die restlichen 50 bleiben den anderen Benutzern übrig. Aber so streng darf man das dann auch nicht sehen. Der Loadbalancer versucht die anstehenden Anfragen trotzdem möglichst gleichmäßig auf die Dialogprozesse zu verteilen. Ich glaube daher nicht, dass deine Berechnungen jemals die 50 Prozesse voll belegen werden können, weil jede abgeschlossene Berechnung sofort den Prozesse wieder für andere freigibt (außer du baust Endlosschleifen ein).
Da bei "normalen" Interaktionen durch Benutzer die Dialogprozesse nur "ganz kurz" belegt sind, ist die tatsächliche Auslastung (oder die gerade belegten Dialogprozesse) nur eine sehr kurzfristige Momentaufnahme. Davon dann 50% zu ermitteln scheint mir von der Verwaltung her etwas zu aufwändig zu sein. Vor Allem da sich das im Sekundentakt ändern kann.
Wenn du also 100 Prozesse hast, wird die Servergruppe max. 50 Prozesse gleichzeitig zu belegen versuchen. Die restlichen 50 bleiben den anderen Benutzern übrig. Aber so streng darf man das dann auch nicht sehen. Der Loadbalancer versucht die anstehenden Anfragen trotzdem möglichst gleichmäßig auf die Dialogprozesse zu verteilen. Ich glaube daher nicht, dass deine Berechnungen jemals die 50 Prozesse voll belegen werden können, weil jede abgeschlossene Berechnung sofort den Prozesse wieder für andere freigibt (außer du baust Endlosschleifen ein).
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Seite 1 von 1
Frage die ABAP Experten
Über diesen Beitrag
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Umherspringende Methoden im quelltextbasierten Class Builder
vor 7 Stunden von ralf.wenzel 104 / 10026
vor 7 Stunden von ralf.wenzel 104 / 10026
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.
Aktuelle Forenbeiträge
Umherspringende Methoden im quelltextbasierten Class Builder
vor 7 Stunden von ralf.wenzel 104 / 10026
vor 7 Stunden von ralf.wenzel 104 / 10026