C_12303_Anlage_V1.0.0
Prereleases:
C_12303_Anlage
| Vorabinformation zum Änderungseintrag: Folgende Änderungen sind Bestandteil des Änderungseintrages bzgl. GS-A_5029-* und A_27451-*:
Hinweise zur Lesart: Text, der zur Erklärung der Änderung dient - wird nicht mit eingearbeitet/übernommen. Text, der neu ist oder aktualisiert wurde. Text, der entfernt wird. |
Inhaltsverzeichnis
gemSpec_Perf Änderungen
1 gemSpec_Perf - Produkttypspezifische Vorgaben
1.1 Intermediär VSDM (PDT21)
1.1.1 Leistungsanforderungen Intermediär VSDM
1.1.1.1 Performancevorgaben Intermediär VSDM
Für die Anforderung GS-A_5029-02 wird eine neue Version erstellt und folgende Punkte ergänzt:
- Konkretisierung, welche Nachweise für die Zulassung zu erbringen sind
- Reduzieren der Erfüllungsquote
- Hinweistext wird entfernt
Neue Anforderung:
GS-A_5029-03 - Performance – VSDM Intermediär – Bearbeitungszeit unter Last
Die Produkttypen Intermediär VSDM MUSS die Bearbeitungszeitvorgaben unter der für die Operation parallel anliegenden Spitzenlast dauerhaft erfüllen. Tabelle 1: Tab_gemSpec_Perf_Intermediaer: Last- u. Bearbeitungszeitvorgaben
| Operation | Spitzenlast [1/sec] | Mittlere Bearbeitungszeit [msec] | Maximale Bearbeitungszeit [msec] | Erfüllungsquote |
|---|---|---|---|---|
| INT.UC_1 | 1.400 | 100 | 150 | 99,99% 98% |
Hinweis: Die Vorgaben beziehen sich auf die einzelnen Request-Response-Zyklen. Sie beinhalten die Bearbeitungszeitbeiträge aus Request und Response in Summe. Die Spitzenlastvorgaben entsprechen einem Marktanteil von 100% und basieren auf einer Gesamtanzahl von 173.149 Konnektoren (M21). Die Spitzenlastvorgaben sind entsprechend des realen Marktanteils des Produktes/Anbieters anzupassen, wobei die minimal zu erfüllende Spitzenlast bei 10% der geforderten Spitzenlast pro Sekunde liegt. Für die Berechnung der Spitzenlast je Anbieter gilt die Anzahl der registrierten Konnektoren gemäß [A_23497-*] oder HSK Instanzen gemäß [A_23988-*], welche in der letzten Bestandsdatenlieferung des Vormonats übermittelt wurde.
Beispiel 1: 54.907 Konnektoren entsprechen einem Marktanteil von 31,71%. Das ergibt eine Spitzenlast von 444 Aufrufen / Sekunde.
Beispiel 2: 48 HSK Instanzen entsprechen einem Marktanteil von 0,03%. Die minimal zu erfüllende Spitzenlast liegt bei 10% der geforderten Spitzenlast. Das ergibt eine Spitzenlast von 140 Aufrufen / Sekunde.
Für die Zulassung ist der Nachweis von 10% der geforderten Spitzenlast der mittleren und der maximalen Bearbeitungszeit bei einer Last von 100 Anfragen pro Sekunde zu erbringen. Die maximale Bearbeitungszeit gilt als erfüllt, wenn mindestens 98% (Erfüllungsquote) aller Anfragen im Testzeitraum innerhalb der vorgegebenen maximalen Bearbeitungszeit erfolgreich beantwortet werden.
[<=]
Der entfernte Hinweistext wird unter der AFO direkt im Dokument hinterlegt, da diese für die SLA-Berechnung im Betrieb aber nicht für die Produktzulassung notwendig ist:
Hinweis: Die Spitzenlastvorgaben entsprechen einem Marktanteil von 100% und basieren auf einer Gesamtanzahl von 173.149 Konnektoren (M21). Die Spitzenlastvorgaben sind entsprechend des realen Marktanteils des Produktes/Anbieters anzupassen, wobei die minimal zu erfüllende Spitzenlast bei 10% der geforderten Spitzenlast pro Sekunde liegt. Für die Berechnung der Spitzenlast je Anbieter gilt die Anzahl der registrierten Konnektoren gemäß [A_23497-*] oder HSK Instanzen gemäß [A_23988-*], welche in der letzten Bestandsdatenlieferung des Vormonats übermittelt wurde.
Beispiel 1: 54.907 Konnektoren entsprechen einem Marktanteil von 31,71%. Das ergibt eine Spitzenlast von 444 Aufrufen / Sekunde.
Beispiel 2: 48 HSK Instanzen entsprechen einem Marktanteil von 0,03%. Die minimal zu erfüllende Spitzenlast liegt bei 10% der geforderten Spitzenlast. Das ergibt eine Spitzenlast von 140 Aufrufen / Sekunde.
gemKPT_Betr Änderungen
2 gemKPT_Betr - Kenngrößen und Service Level
2.1 Technische Service Level / Performance-Kenngrößen
2.1.1 Spezifische Ausprägungen
2.1.1.1 Intermediär VSDM (PDT21)
Schnittstellen::Operation bzw. Anwendungsfall
Liste der Operationen/Anwendungsfälle:
- PDT21 - [gemSpec_Perf#Kap. 3.12 Intermediär VSDM#Tab_gemSpec_Perf_Berichtsformat_Intermediär_VSDM]
Tabelle 2: Tab_gemKPT_Betr_Intermediär_VSDM_S::O/A
| Produkttyp / Anwen-dungstyp (PDT-ID) |
S/A-ID |
Schnittstellen::Operation / Anwendungsfall (S/A) |
Beschreibung | Berichtsformat-Alias (sofern von Schnittstellen::Operation bzw. Anwendungsfall abweichend) |
|---|---|---|---|---|
| PDT21 | S01 | I* | verwendet für Verfügbarkeitsberechnung | |
| PDT21 | A02 | INT.UC_1 |
Aufruf einer Intermediär-Instanz durch ein Fachmodul |
- |
Performance-Kenngrößen / SL-Werte
Der Erfassungszeitraum für die aufgeführten Soll-Werte beträgt ein Kalendermonat.
Die Bildung der Performance-Kenngrößen basiert auf folgenden PG-Schemata: PG-Schema-I
Tabelle 3: Tab_gemKPT_Betr_Intermediär_VSDM_Performance-Kenngroessen
| Performance- Kenngröße (PKG-ID) |
Beschreibung | berechnet aus (Betriebsdaten, Probing) | SL-Wert (Soll-Wert) |
min / max | Normative Referenz |
|---|---|---|---|---|---|
| Intermediär VSDM - PDT21 | |||||
| PDT21-S01-D3-G14 | Relative Verfügbarkeit im Betrachtungszeitraum zur Hauptzeit exkl. Wartung. [%*1000] | Probing |
99900 | min | GS-A_5030-02 |
| PDT21-S01-D3-G16 | Relative Verfügbarkeit im Betrachtungszeitraum zur Nebenzeit exkl. Wartung. [%*1000] | Probing |
99000 | min | GS-A_5030-02 |
| Intermediär VSDM - PDT21 - INT.UC_1 | |||||
| PDT21-A02-D2-G08 | Mittlere Bearbeitungszeit im Betrachtungszeitraum. [msec] | Betriebsdaten | 100 | max | GS-A_5029-03 |
| PDT21-A02-D2-G30 | Maximale Bearbeitungszeit im Betrachtungszeitraum. [msec] | Betriebsdaten | 150 | max | GS-A_5029-03 |
| PDT21-A02-D2-G31 | Anteil Bearbeitungen innerhalb der Bearbeitungszeitvorgabe im Betrachtungszeitraum. [%*1000] | Betriebsdaten | 99990 98000 | min | GS-A_5029-03 |
gemSpec_SST_VSDM Änderungen
3 gemSpec_SST_VSDM - Allgemeine Festlegungen
3.1 Connection pooling durch den Intermediär
Der Aufbau einer Verbindung vom Intermediär zum Fachdienst (im folgenden HTTP-Verbindung genannt) ist auf Grund von TCP-Handshake, TLS-Handshake und Abfragen auf anderen Schnittstellen zeitaufwendig. Um Verzögerungen bei der Abarbeitung eines Aufrufs vom Fachmodul zu minimieren, wird die HTTP-Verbindung zum Fachdienst nicht für jedes Request/Response-Paar neu aufgebaut. Der Intermediär hält dauerhaft HTTP-Verbindungen (persistent Connection) zu den Fachdiensten offen. Diese werden für mehrere Request/Response Paare wiederverwendet.
Connection Pool
Der Intermediär muss zu jedem Fachdienst (UFS, VSDD und CMS) einen Pool von HTTP-Verbindungen vorhalten. Die Anzahl der Verbindungen muss konfigurierbar sein. Wenn eine der vorgehaltenen Verbindungen, z.B. durch einen Fehler, vom Server abgebaut wird, dann muss der Intermediär die Verbindung innerhalb einer Zeit von höchstens 1s wieder aufbauen. Wenn der Server beim Aufbau der Verbindungen nicht erreichbar ist, dann soll der Intermediär das Connection pooling für einen Zeitraum aussetzen, bis der Endpunkt wieder erreichbar ist. [VSDM-A_3022] [A_17644][A_17645]
Zwei Request/Response-Paare, die auf Anwendungsebene zu einer Online-Aktualisierung gehören, können über verschiedene HTTP-Verbindungen übertragen werden.
Sollten die vorgehaltenen Verbindungen bei Lastspitzen nicht ausreichen, muss der Intermediär zusätzliche HTTP-Verbindungen etablieren, die dann nach Bedarf wieder geschlossen werden [VSDM-A_3023] [VSDM-A_3028]. Um eine effiziente Nutzung der Verbindungen zu gewährleisten, ist die Anzahl der gleichzeitig offenen Verbindungen so zu steuern, dass sie sowohl den Bedarf während der Spitzenlast als auch die Systemressourcen optimal ausnutzt. Damit eine Überlast am Fachdienst VSDM durch zu viele Verbindungen vermieden wird, ist für den Intermediär VSDM eine maximale Anzahl an HTTP-Verbindungen vorgegeben, die er zu den Fachdiensten aufbauen darf [A_27451-*].
Intermediär - Maximale Anzahl an HTTP-Verbindungen
Die maximale Anzahl an HTTP-Verbindungen, die ein Intermediär zum Fachdienst VSDM aufbauen darf, ergibt sich aus der vom Intermediär zu unterstützenden Spitzenlast pro Sekunde gemäß [gemSpec_Perf#GS-A_5029-*] im Kontext zur maximalen Bearbeitungszeit des jeweiligen Fachdienstes VSDM in Millisekunden gemäß [gemSpec_Perf#GS-A_5031-*], die ein Fachdienst benötigt, um eine Anfrage beantworten zu können [gemSpec_Perf#GS-A_5031-01] und wird wie folgt abgeleitet:
Maximale Anzahl HTTP-Verbindungen zum Fachdienst UFS = Spitzenlast Intermediär * Anbieter Marktanteil in % / (1000msec / Maximale Bearbeitungszeit Fachdienst VSDM)
Maximale Anzahl HTTP-Verbindungen zum Fachdienst CMS/VSD = Spitzenlast Intermediär * Anbieter Marktanteil in % * 0,025 / (1000msec / Maximale Bearbeitungszeit Fachdienst VSDM)
Hinweis zum Faktor 0,025: Gemäß des Mengengerüsts aus [gemSpec_Perf#3.12.1.1 Lastmodell Intermediär VSDM] wird angenommen, dass bei lediglich 2,5% der Online-Prüfungen eine Aktualisierung der Daten durch die Fachdienste CMS/VSD erforderlich ist.
Beispiel 1 (UFS): Die Spitzenlast des Intermediäres beträgt 1.400 Anfragen / Sekunde. Ein Anbieter hat einen Marktanteil von 30%. Die maximale Bearbeitungszeit zum Beantworten einer UFS-Anfrage vom Fachdienst UFS beträgt 280msec. Das ergibt eine maximale Anzahl an HTTP-Verbindungen von 118 (Maximale Anzahl HTTP-Verbindungen = 1.400 * 0,30 / (1000/280)).
Beispiel 2 (CMS): Die Spitzenlast des Intermediäres beträgt 1.400 Anfragen / Sekunde. Ein Anbieter hat einen Marktanteil von 30%. Die maximale Bearbeitungszeit zum Beantworten einer CMS-Anfrage vom Fachdienst CMS beträgt 5.585msec. Lediglich 2,5% der Anfragen erfordern eine Aktualisierung der Daten. Das ergibt eine maximale Anzahl an HTTP-Verbindungen von 59 (Maximale Anzahl HTTP-Verbindungen = 1.400 * 0,30 * 0,025 / (1000/5585)).
4 gemSpec_SST_VSDM - Anhang B - Anforderungshaushalt
4.1 Ausgangsanforderungen
Für die Anforderung A_27451 wird eine neue Version erstellt und folgende Punkte ergänzt:
- Konkretisierung, welche Nachweise für die Zulassung zu erbringen sind
- Hinweistext wird entfernt
Neue Anforderung:
A_27451-01 - Intermediär VSDM: Maximale Anzahl HTTP-Verbindungen zu Fachdiensten
Der Intermediär VSDM MUSS die maximale Anzahl an HTTP-Verbindungen zum Fachdienst gemäß folgender Berechnung begrenzen:
- Maximale Anzahl HTTP-Verbindungen zum Fachdienst UFS = Spitzenlast Intermediär * Anbieter Marktanteil in % / (1000msec / Maximale Bearbeitungszeit Fachdienst VSDM 280msec)
- Maximale Anzahl HTTP-Verbindungen zum Fachdienst CMS/VSD = Spitzenlast Intermediär * Anbieter Marktanteil in % * 0,025 / (1000msec / Maximale Bearbeitungszeit Fachdienst VSDM 5585msec)
Hinweis: Zusätzliche Informationen zur Berechnung können im Kapitel 2.3 Connection pooling durch den Intermediär nachgelesen werden.
[<=]
Der entfernte Hinweistext wird unter der AFO direkt im Dokument hinterlegt:
Hinweis: Zusätzliche Informationen zur Berechnung können im Kapitel 2.3 Connection pooling durch den Intermediär nachgelesen werden.
Es wird eine redaktionelle Änderung der Anforderung A_27452 durchgeführt:
A_27452 - Intermediär VSDM: Ressourcenschonende, effiziente und verhältnismäßige Nutzung von Verbindungen
Der Intermediär VSDM MUSS die Verbindungen zu anderen TI-Diensten ressourcenschonend, effizient und verhältnismäßig nutzen, um die Systemperformance zu optimieren und gleichzeitig unnötige Belastungen der Infrastruktur zu vermeiden. Dabei MUSS der Intermediär VSDM die Verbindungen so verwalten, dass nur Ressourcen beansprucht werden, die benötigt werden, um die Anforderungen an die Bearbeitungszeiten unter Last [gemSpec_Perf#GS-A_5029-*] zuverlässig zu erfüllen