DE60206789T2

DE60206789T2 - Echtzeitverarbeitung

Info

Publication number: DE60206789T2
Application number: DE60206789T
Authority: DE
Inventors: Paul Collett; Philip Bruce JENSEN; Ian Stephen MARTIN
Original assignee: Marconi UK Intellectual Property Ltd
Current assignee: Ericsson AB
Priority date: 2001-06-07
Filing date: 2002-05-02
Publication date: 2006-06-08
Anticipated expiration: 2022-05-03
Also published as: CN1636363A; EP1433057B1; DE60206789D1; GB0113844D0; US20040213158A1; CN1297113C; EP1433057A2; JP2005501316A; AU2002307910A1; CA2450574A1; WO2002099555A2; ATE307354T1; WO2002099555A3

Description

Die vorliegende Erfindung betrifft ein Transaktions-Verarbeitungssystem mit einem Leaky-Bucket.
Im Stand der Technik sind Lösungen bekannt, die das Konzept des Leaky-Bucket verwenden, zum Beispiel wird in dem Dokument von M. G. Hluchyi und N. Yin "A second-order leaky bucket algorithm to guarantee QoS in ATM networks" – Global Telecommunications Conference, 1996; GLOBECOM '96; Seiten 1090–1096, beschrieben, wie zwei Standard-Leaky-Bucket-Algorithmen Langzeit-Verkehrs-Eigenschaften unterstützen können. Das erste Bucket unterstützt die Verkehrs-Rate, und das zweite Bucket unterstützt die maximale Verkehrs-Anhäufung. Ein weiteres Dokument, das den Leaky-Bucket-Algorithmus betrifft, ist "Resource allocation in ATM networks" von J. Murphy. Jedoch sind Operationen wie in der Erfindung, die nun beschrieben werden, in den Dokumenten gemäß Stand der Technik weder offenbart noch vorgeschlagen.
Gemäß einem ersten Aspekt der vorliegenden Erfindung ist ein Transaktions-Verarbeitungssystem mit einem Leaky-Bucket und einem Ablauf-Steuermittel vorgesehen, wobei das Ablauf-Steuermittel dazu angeordnet ist, die Antwortzeit von jeder Transaktion zu überwachen und jede Antwortzeit mit einer vorbestimmten Antwortzeit zu vergleichen, wobei zumindest zwei unterschiedliche Werte der vorbestimmten Antwortzeit für unterschiedliche Transaktionen verwendet werden, und die Inhalte des Leaky-Bucket zu erhöhen, wenn die Antwortzeit von einer Transaktion die vorbestimmte Antwortzeit in Zusammenhang mit der bestimmten Transaktion übersteigt, und wobei das Ablauf-Steuermittel dazu angeordnet ist, den Inhalt des Leaky-Bucket zu überwachen und Transaktionen im Verhältnis zu den Inhalten des Leaky-Bucket abzulehnen.
Gemäß einem zweiten Aspekt der vorliegenden Erfindung ist ein Verfahren zum Betreiben eines Transaktions-Verarbeitungssystems vorgesehen.
Weitere Merkmale der vorliegenden Erfindung sind in den abhängigen Ansprüchen beansprucht.
Die vorliegende Erfindung wird nun anhand eines Beispiels unter Bezugnahme auf die beiliegenden Zeichnungen beschrieben, in denen:
1 eine grafische Darstellung von einem "Leaky Bucket" zeigt, um die Funktion der Erfindung darzustellen;
2 eine Single-Box SCP (Service-Steuerpunkt) Architektur darstellt, die für die Simulation angenommen wird;
3 eine Multi-Box SCP(C)/SDF (Service-Datenpunkt) Architektur darstellt, die für die Simulation angenommen wird;
4 ein beispielhaftes Histogramm der Verteilung von Antwortzeiten zeigt. Dieses zeigt die Antwortzeiten in ms von einem Einmal-Lesen-Service, der bei einer Prozessorbelegung von etwa 70% bei der Single-Box SPC Simulation läuft;
5 die lineare Beziehung zwischen der Variablen x = Belegung/(1-Belegung) und y = 95% Antwortzeit in ms zeigt, x = 1 entspricht einer Belegung von 50%;
6 die lineare Beziehung zwischen der Anzahl von Lesevorgängen n = 1, 2, 3, 4, 5 und der "Warteschlangen"-Zeit Tq von 95% darstellt;
7A–7B einen Einmal-Schreiben-Service bei der Single-Box SCP Simulation darstellen. Die annähernd lineare Beziehung zwischen der Variablen x = Belegung/(100-Belegung) und der 95% Antwortzeit in ms (y-Achse) für Daten, die bei der SCP-Simulation gemessen werden;
8A und 8B lineare Übereinstimmungen wie in 7A–7B bei einem Zweimal-Schreiben-Service (8A) und einem Dreimal-Schreiben-Service (8B) zeigen;
9A–9C die annähernd lineare Beziehung zwischen der Variablen x = Belegung/(100-Belegung) und der 95% Antwortzeit in ms (y-Achse) für Daten zeigen, die bei einem realen Single-Box SCP gemessen werden. 9A ist ein Einmal-Lesen-Service, 9B ist ein Einmal-Lesen-, Einmal-Schreiben-Service, und 9C ist ein 12-Lesen, 1-Schreiben-Service;
10A–10D die 95% Zeitverzögerung (y-Achse) über Belegung/(1-Belegung) (x-Achse) für 1, 3, 5 bzw. 8 Lese-Vorgänge zeigen. Belegung ist die CPU-Belegung von dem (Master) SDP, und die Konfiguration war: 2 SCP(C)s (jeweils 2 Prozessoren) und 2 SDPs (Master/Slave) (jeweils 2 Prozessoren);
11 die 95% Zeitverzögerung (y-Achse) über Belegung/(1-Belegung) (x-Achse) für 1-Lesen zeigt. Die Konfiguration war: 4 SCP(C)s (jeweils 2 Prozessoren) und 2 SDPs (Master/Slave) (jeweils 2 Prozessoren);
12A–12C die Leistungsfähigkeit von einem Leaky-Bucket und einem Verkehrs-Mix A zeigen, wobei 12A den aufgenommenen Verkehr (y-Achse) über dem angebotenen Verkehr (x-Achse) (Anrufe/Sekunde) zeigt; 12B die mittlere Antwortzeit (ms) über der angebotenen Verkehrs-Rate (Anrufe/Sekunde) zeigt; und 12C die SCP (Master) CPU-Belegung (Prozent) als eine Funktion der angebotenen Verkehrsrate (Anrufe/Sekunde) zeigt;
13A–13C die Leistungsfähigkeit von einem Leaky-Bucket und einem Verkehrs-Mix B zeigen, wobei 13A den aufgenommenen Verkehr (y-Achse) über dem angebotenen Verkehr (x-Achse) (Anrufe/Sekunde) zeigt; 13B die mittlere Antwortzeit (ms) über der angebotenen Verkehrs-Rate (Anrufe/Sekunde) zeigt; und 13C die SCP (Master) CPU-Belegung (Prozent) als eine Funktion der angebotenen Verkehrs-Rate (Anrufe/Sekunde) zeigt;
14A darstellt, dass das Ausdrucken der Rohdaten eine lineare Beziehung zwischen x und y vermuten lässt; und
14B die Formeln für die Methode der kleinsten Quadrate darstellt, die verwendet werden, um die am besten geeignete Grafik y = a + bx durch die Punkte von 14A auszudrucken.
Zuerst wird ein praktisches Beispiel der Erfindung beschrieben.
Das Problem betrifft den Vizepräsidenten einer Bank. Die Bank betreibt ein Call-Center für Kunden in Sunderland, mit Hilfe dessen das gesamte Land bedient wird. Der Vizepräsident möchte wissen, wie ausgelastet das Call-Center ist und welche Art von Service die meisten Kunden bekommen, vertraut aber nicht dem Manager des Call-Centers, dass er ihm korrekte Informationen gibt. Es gibt eine gute Möglichkeit, die Informationen zu erhalten, ohne das Büro in London zu verlassen. Er könnte das Call-Center mehrmals täglich anrufen und sich Notizen darüber machen, wie lange er warten muss, bevor er eine Antwort erhält. Das heißt, er schreibt sich die Gesamtzahl von Sekunden des Klingelns und der Ankündigung der "Bitte Warten" Musik zuzüglich der Länge der Transaktion (Prüfen des Kontostands) auf.
Wenn er immer eine lange Zeit warten muss, bedeutet dies, dass das Call-Center sehr beschäftigt ist. Wenn er immer beim zweiten Klingeln eine Antwort erhält und die Transaktion schnell erfolgt, kann er möglicherweise die Anzahl der Beschäftigten vermindern.
Es ist wahrscheinlich, dass er eine Mischung von Zeiten erhält, was bedeutet, dass das Call-Center beschäftigt aber nicht zu beschäftigt ist.
Das heißt, die Verzögerungszeit, wenn häufig abgefragt, gibt einen Überblick über die Belegung von einem entfernten Server, ohne ihn direkt abfragen zu müssen.
Es ergibt sich, dass Kunden anfangen, sich über lange Wartezeiten zu bestimmten Tageszeiten zu beschweren.
Der Vizepräsident möchte die Menge an Arbeit kontrollieren, die in dem Call-Center anfällt. Ein Problem ist die Ausfallzeit infolge der stündlichen Kaffeepausen. Er installiert ein System, bei dem er das Schaltpult von seinem Büro in London kontrollieren kann. Er entscheidet sich, dieses System einzuführen: jedes Mal dann, wenn ein Anruf eingeht, legt er eine Bohne in einen Eimer (Bucket). Jedes Mal dann, wenn ein Kunde auflegt, nimmt er eine Bohne heraus. Wenn der Eimer voll ist, wechselt er die Telefone, so dass für die Kunden eine "Rufen Sie später an" Ankündigung abgespielt wird. Dadurch wird garantiert, dass dann, wenn alle Beschäftigten des Call-Centers gleichzeitig eine Kaffeepause machen, nicht zu viele Kunden unzufrieden sind. Durch Hinzufügen einer konstanten Menge in den Eimer jedes Mal dann, wenn ein Anruf eingeht, wird der Eimer möglicherweise gefüllt, wenn der entfernte Server ausfällt, und Anrufe können abgelehnt werden.
Dieses System arbeitet aber nur im Fall eines Totalausfalls. Der Vizepräsident möchte den Verkehr ablehnen (Abspielen der "Rufen Sie später an" Ankündigung), wenn die Auslastung des Call-Centers zu hoch wird.
Er ist besorgt über die Überlastung seiner Angestellten, wenn deren Auslastung bei nahe 100 liegt, was zu Problemen mit der Gewerkschaft oder zu Streitfällen vor Gericht führen kann. Er weiß aus seinen früheren Experimenten, die ihm gezeigt haben, dass eine Auslastung hoch ist, wenn die Klingeln-plus-Musik-Wartezeiten zu lang werden. Er entscheidet sich, die Gesamtzeiten (Wartezeit plus Servicezeit) bei der maximalen legalen Belegung (70%) aufzuzeichnen. Er findet heraus, dass es einen Bereich von Zeiten zwischen 30 Sekunden und 5 Minuten gibt, aber 95% der Anrufe betragen weniger als 2 Minuten. Somit entscheidet er sich für Folgendes: für jeden Anruf, der länger als 2 Minuten dauert, legt er eine Bohne in den Eimer. Auf diese Weise, wenn die Anrufe zu lange dauern, füllt sich der Eimer, und er erhält eine Regel über die Ablehnung von Verkehr.
Bei diesem Szenario gibt es allerdings ein Problem. Was ist mit den 5% der Anrufe, die lange dauern, und zwar auch dann, wenn sich das Call-Center bei oder unter der legalen Belegung befindet? Wenn das Call-Center bei 70% Belegung läuft, dann führen 5% der Anrufe (die Anrufe, die länger als 2 Minuten dauern) dazu, dass eine Bohne in den Eimer gelegt wird (und dort bleibt).
Möglicherweise findet der Bankpräsident heraus, dass sich der Eimer füllt, und gemäß dieser Regel ist er gezwungen, Anrufe abzulehnen. Er entscheidet sich, das System zu verändern: er fügt eine "Leckstelle" ein. So oft er will, kann er einige Bohnen aus dem Eimer nehmen. Er berechnet die Leck-Rate, indem er einfach sagt, dass es eine durchschnittliche Rate gibt, mit der Bohnen in den Eimer eingehen, und zwar bei der maximal zumutbaren Kunden-Anruf-Rate. Wenn er die maximal zumutbare Rate auf den Gleichgewichtspunkt einstellt, bei dem die Rate der in den Eimer eingehenden Bohnen gleich der Rate der ausgehenden Bohnen ist, kann er sicher sein, dass immer dann, wenn die Kunden-Anruf-Rate über dem Maximum liegt, mehr Bohnen eingehen als herauslecken, und der Eimer füllt sich. Um spezieller zu werden, er hat 100 niedrig bezahlte Arbeiter in dem Call-Center. Er möchte, dass zu jedem Zeitpunkt maximal 70% belegt sind. Er findet heraus, dass der durchschnittliche Anruf 1 Minute dauert und dass 95% weniger als 2 Minuten dauern, und zwar bei einer Belegung von 70%. Eine Belegung von 70% liegt dann vor, wenn die Anruf-Rate 70 pro Minute beträgt. Bei dieser Anruf-Rate gibt es 3,5 Anrufe pro Minute, die länger als 2 Minuten dauern (3,5 entspricht 5% von 70). Die Regel besteht darin, dass jeder Anruf von länger als 2 Minuten bestraft wird, indem eine Bohne in den Eimer gelegt wird. Dies bedeutet, dass er gemäß diesen Regeln 3,5 Bohnen pro Minute in den Eimer legt, wenn die Anruf-Rate 70 Anrufe/Minute beträgt. Er nimmt 3,5 Bohnen pro Minute aus dem Eimer, so dass der Eimer im Durchschnitt auf dem gleichen Pegel bleibt, was einem Füllstand von 10% entspricht.
Nun steigt die Anruf-Rate auf 80 Anrufe/Minute. Die Angestellten sind gestresster und weniger effektiv, und es gibt mehr Kunden, die auf eine freie Leitung warten, so dass die durchschnittliche Anrufzeit auf 1,1 Minuten ansteigt, und mehr als 20% der Anrufe dauern länger als 2 Minuten. Die Belegung steigt auf 80% an. Aber nun tritt das Regelungssystem des Eimers in Kraft. Da er immer noch die 2-Minuten-Strafregel anwendet, legt er nun 20%·80 Anrufe/Minute = 16 Bohnen/Minute in den Eimer. Da lediglich 3,5 Bohnen/Minute herauslecken, füllt sich der Eimer nach wenigen Minuten (die genaue Anzahl an Minuten hängt von der Größe des Eimers ab), und dann beginnt man, Anrufe abzulehnen. Wenn Anrufe abgelehnt werden, dann geht die (zugelassene) Anruf-Rate nach unten, die Belegung und die Anrufzeit sinken, und die Situation stabilisiert sich wieder auf etwa 70% Belegung. Was passiert, wenn die Anruf-Rate 50 Anrufe/Minute beträgt? Bei dieser Rate beträgt die durchschnittliche Zeit immer noch etwa 1 Minute, aber lediglich 1% der Anrufe dauern länger als 2 Minuten. Somit gehen lediglich 0,5 (1% von 50) Bohnen/Minute in den Eimer. Aber es lecken immer noch 3,5 Bohnen/Minute heraus.
Somit ist der Eimer die meiste Zeit leer.
Dieser Algorithmus verwendet die Service + Warten – Zeiten, um den Verkehr zu steuern. Lange Zeiten bedeuten, dass eine Strafe zum Eimer hinzugefügt wird. Wenn sich der Eimer füllt, wird neuer Verkehr abgelehnt. Es gibt eine Leckstelle, so dass verhindert wird, dass sich der Eimer durch gelegentliche auftretende lange Zeiten füllt, wenn der Verkehr niedrig ist. Es gibt noch eine Verfeinerung. Der Vizepräsident der Bank findet heraus, dass der "Alles oder Nichts" Ablehnungs-Algorithmus ein bisschen zu streng ist. Daher richtet er in dem Eimer eine Ablehnungszone ein. Der Anteil des abgelehnten Verkehrs wird durch den Anteil der Ablehnungszone gegeben, der unter dem Pegel an Bohnen in dem Eimer liegt. Es wird beispielsweise angenommen, dass sich die Ablehnungszone in der oberen Hälfte des Eimers befindet. Wenn der Eimer weniger als zur Hälfte gefüllt ist, wird kein Verkehr abgelehnt. Wenn der Verkehr zu 3/4 gefüllt ist, werden 50% des Verkehrs abgelehnt. Wenn der Eimer zu 90% gefüllt ist, werden 80% des Verkehrs abgelehnt. Wenn der Eimer zu 100 gefüllt ist, werden 100% des Verkehrs abgelehnt.
Der Verkehr wird entsprechend dem Anteil der Eimer-Ablehnungszone abgelehnt, die durch den Eimer-Pegel abgedeckt ist.
Es werden nun einige weitere Komplikationen eingeführt. Der Telefon-Service mit einer durchschnittlichen Haltezeit von 1 Minute war ein einfacher Kontoabfrage-Service. Die Bank hat nun neue Services eingeführt, die es dem Anrufer am Telefon ermöglichen, die Einrichtung eines neuen Kontos zu beantragen, Auslandswährungen zu kaufen, etc. Das System des Ablehnens von Verkehr bricht zusammen, bis realisiert wird, dass Anrufe in Kategorien unterteilt werden können:

*diese Zeiten werden bei 70% Belegung gemessen

Es wird entschieden, dass für jede Kategorie eine Straf-Bohne in den Eimer gelegt wird, wenn der Anruf länger als seine "95% Zeit" für diesen Typ von Anruf dauert.
Es tritt nun ein Problem auf. Wegen eines preiswerten Angebots gibt es eine Flut von neuen Konto-Anmeldungen per Telefon, da die durchschnittliche Zeit 30 Minuten beträgt, ist eine Anruf-Rate von 3,3 Anrufen/Minute ausreichend, um 100 Beschäftigte in dem Call-Center Vollzeit zu beschäftigen. Das Call-Center ist während der gesamten Zeit vollständig belegt. Es wurde aber herausgefunden, dass sich der Eimer nicht auffüllt.
Eine Untersuchung hat ergeben, dass jeder einzelne Anruf zu lange dauert, so dass 3,3 Bohnen/Minute in den Eimer eingehen. Aber der Eimer leckt immer noch mit einer Rate von 3,5 Bohnen/Minute. Der Eimer bleibt nahezu leer, und keine Anrufe werden jemals abgelehnt. Dies stellt eine Fehlfunktion in dem Schutzmechanismus dar, und daher muss er modifiziert werden.
Es wird entschieden, der Strafe einen "Gewichtungs"-Faktor zu verleihen, so dass zeitaufwendigere Anrufe zu einer größeren Strafe führen als relativ einfache Anrufe. Der Gewichtungs-Faktor ist so gewählt, dass für jeden einzelnen Typ von Anruf die Rate von Bohnen, die in den Eimer fließen, und zwar bei maximaler Anruf-Rate (d.h. die Anruf-Rat, bei der das Center zu 70% belegt ist), exakt mit der Leck-Rate ausgeglichen ist. Es sei zum Beispiel angenommen, dass 100% der Anrufe Anträge für neue Konten sind. Dann ist das Call-Center mit einer Anruf-Rate von 2,33 Anrufen/Minute zu 70% belegt. Wenn 5% der Anrufe zu lange dauern, dann bedeutet dies:
0,05*2,33** Strafe = 3,5 oder Strafe = 30.
Für jeden zu langen Anruf dieses Typs müssen dann 30 Bohnen in den Eimer gefüllt werden. Dies macht Sinn, da dieser Typ von Anruf 30 mal so viel "kostet" wie ein Anruf von einer Minute kostet. Sowohl die vorbestimmten langen Zeiten als auch die Strafen hängen von dem Typ des Anrufs ab. Die Strafe ist proportional zu den Kosten des Anrufs.
Es werden numerische Simulationen einer SCP/SDP Architektur verwendet, um einen Schaltsteuerungs-Leaky-Bucket-Ladesteuerungs-Algorithmus zu untersuchen. Dieser Algorithmus zieht die Anzahl der einzelnen Lese- und Schreibvorgänge in einem Service in Betracht, um eine Antwortzeit vorherzusagen. Wenn die Anfrage später als diese Zeit zu der Schaltsteuerung zurückgeführt wird, dann werden Strafpunkte zu einem Zähler addiert (der Eimer). Wenn der Pegel des Eimers höher ist als ein fester Wert, dann wird ein Anteil des neuen Verkehrs abgelehnt. Dieser Anteil steigt mit dem Pegel des Eimers: wenn der Eimer vollständig voll ist, dann wird der gesamte Verkehr abgelehnt. Aus dem Eimer lecken aus zwei Gründen periodisch Punkte heraus:

1) Störpunkte, die während solcher Perioden mit wenig Verkehr akkumuliert werden, müssen herauslecken, und
2) der Eimer muss in der Lage sein, von selbst zu lecken und zwar bei Überlastung, die durch Verkehr-Anhäufung bewirkt wird.

Dieser Algorithmus wird für die in 2 und 3 gezeigten Architekturen untersucht. In 2 befinden sich das SCP und SDP in einer einzigen Unix-Box. In 3 senden einige Dual-CPU SCP(C)-Boxen Anfragen über Kommunikationsleitungen zu zwei Multi-CPU SDP-Boxen (Master und Slave).
Das Single-Box SCP-Simulationsmodell wurde verwendet, um die Antwortzeiten und Prozessor-Belegungen als Funktion der Verkehrs-Rate für verschiedene Typen von Verkehr zu messen. Es ist gezeigt, wie diese Messungen verwendet werden, um die Eingangsdaten für den Leaky-Bucket-Algorithmus einzurichten.
Durch Verwendung vorläufiger Messungen der Software-Prozesse, die in Tabellen 1 und 2 angegeben sind, wurde ein einfaches Simulationsmodell für die Architektur aus 3 geschrieben. Dieses Modell lief mit Überlast-Abschaltung, um die Antwortzeiten und Prozessor-Belegungen als Funktion der Verkehrs-Rate für verschiedene Verkehrs-Typen zu messen.
Er wurde ebenfalls verwendet, um andere Merkmale zu untersuchen. Von besonderem Interesse war die Auswahl der Anzahl von sdp-Kunden-Software-Prozessen. Diese Anzahl ist konfigurierbar, und wenn sie zu klein ist, kann die Leistungsfähigkeit stark beeinträchtigt werden.
Die Daten von den Modell-Durchläufen wurden wiederum verwendet, um die Eingangsparameter für ein Leaky-Bucket-Modell zu berechnen, das heißt, die Koeffizienten in den Formeln für die Ziel-Antwortzeit und die Strafe für die verschiedenen Services. Diese Konfigurationsdaten wurden in das Modell zurückgeführt, und das Modell wurde dann mit Überlast-aktiv für verschiedene Typen von Verkehr laufen gelassen, einschließlich 'realistische' Verkehrs-Mischungen, unterschiedlichen Anzahlen von SCPs und unterschiedlichen Anzahlen von SDP CPUs.
Die Ziel-Antwortzeit und die Strafe können unter Verwendung einfacher linearer Gleichungen berechnet werden. Der Prozess, der verwendet wurde, um die Koeffizienten für diese Gleichungen zu finden, ist im Detail beschrieben, und zwar sowohl in den Messungen, die durchgeführt werden müssen, als auch der Technik zum Erhalten der am besten passenden Gleichung. In einem großen Ausmaß kann dieser Prozess automatisiert werden.
Die lineare Gleichung für die Strafen kann erwartungsgemäß unter allen Umständen angewendet werden. Die lineare Gleichung für die Ziel-Antwortzeiten bricht in bestimmten Fällen zusammen, die später erläutert werden.
Die Grenzwert-Antwortzeit T_Ziel wird gewählt, um dem 95%-Punkt in der Verteilung der Antwortzeiten zu entsprechen, wenn die Prozessor-Belegung bei dem gewünschten Maximum liegt. Wenn der Begriff "Prozessor-Belegung" verwendet wird, dann ist die gesamte Belegung der Single-Box-Architektur und die SDP CPU-Belegung der Multi-Box-Architektur gemeint. Das heißt, es wird angenommen, dass die gewünschte maximale Belegung 66% beträgt. Wenn die CPU zu 66% belegt ist, dann betragen 95% der Antwortzeiten weniger als T_Ziel. Beispielsweise beträgt in 4, die das Histogramm von Antwortzeiten für einen Einmal-Lesen-Service, der bei 220 Anrufen pro Sekunde in dem SPC-Simulationsmodell läuft, die 95%-Zeit etwa 120 ms. Dies liegt nahe bei T_Ziel. Die Darstellung zeigt tatsächlich das Antwortzeit-Histogramm für eine Verkehrs-Rate, die einer CPU-Belegung von 70% entspricht. Unter Verwendung von 'Trial and Error', um die Verkehrs-Rate zu finden, die zu einer Belegung von genau 66% führt, ist schwierig. Hier ist gezeigt, dass die Antwortzeit T_Antwort als eine Funktion der Belegung durch die folgende Formel berechnet werden kann: TAntwort = T0 (nr, nw) + Tq (nr, nw) × Belegung/(1-Belegung)wobei T₀ (n_r, n_w) + Tq (n_r, n_w) von der Anzahl der Lese- und Schreibvorgänge abhängen und gemessen werden müssen. Dies ist eine dritte Kategorie von Aktion, die ein fehlerhaftes Lesen oder Schreiben ist. Obwohl dies in dem Algorithmus enthalten ist, wird die Abhängigkeit von n_r in der nachfolgenden Diskussion ignoriert. Um T_Ziel zu erhalten, wird die Belegung zur gewünschten CPU-Belegung hier in der obigen Formel mit 66% angenommen. Statt diese Formel mathematisch zu beurteilen, sei einfach angemerkt, dass sie zu guten Ergebnissen für die verfügbaren Daten (siehe 5) führt. Details werden später diskutiert.
Wenn die Anzahl von Strafpunkten, die dem Eimer hinzugefügt werden, von dem Service unabhängig ist, dann gibt es ein offensichtliches Problem bei der Beibehaltung einer konsistenten Überlast-Strategie. Es wird das folgende Beispiel betrachtet: Wenn durch einen Einmal-Lesen-Service 100 Strafpunkte eingegeben werden, wenn die Antwortzeit größer als 142 ms ist, dann sind 5% der Antwortzeiten größer als dies der Fall wäre, wenn die Antwort-Rate einer CPU-Belegung von 66% entspricht. Diese Verkehrs-Rate beträgt 202 Anrufe pro Sekunde. Bei 202 Anrufe/Sekunde beträgt die Rate, mit der Punkte in den Eimer gefüllt werden: 0,05 × 202 × 100 = 1000 Punkte/Sekunde. Es sei angenommen, dass der Eimer dann eine Leck-Rate von 1000 Punkte/Sekunde hat, so dass der Pegel des Eimers bei dieser Verkehrs-Rate etwa konstant bleibt – in jeder Sekunde ist die gleiche Anzahl von Punkten, die in den Eimer eingehen, gleich der Anzahl, die herauslecken. Wenn die Verkehrs-Rate nach oben geht, dann wird der Eimer aufgefüllt, der Überlast-Ablehnungs-Algorithmus wird eingeschaltet, und es wird begonnen, Verkehr abzulehnen.
Es wird nun angenommen, dass der Verkehr lediglich einen 3-Lesen-Service beinhaltet. Der Verkehrs-Pegel, der einer CPU- Belegung von 66% entspricht, beträgt etwa 91 Anrufe/Sekunde. Bei dieser Rate, wenn die gleiche "100 Punkte pro zu lange Antwort"-Regel angewendet wird, beträgt die Rate an Punkten, die in den Eimer eingehen, etwa 500 pro Sekunde. Aber der Eimer ist eingestellt, um mit 1000 pro Sekunde zu lecken. In diesem Fall leckt der Eimer doppelt so schnell, wie er gefüllt wird, und das System hat nur eine geringe Chance, in den Überlast-Zustand gebracht zu werden, und zwar obwohl sich der Verkehrs-Pegel bei seinem Maximalwert befindet.
Daher muss die Anzahl an Strafpunkten, die dem Eimer hinzugefügt werden, proportional zu den CPU-Kosten des Service sein – ein 3-Lesen-Service muss mehr Punkte für jede zu lange Antwort eingeben als ein 1-Lesen-Service. Die Formel für die Größe von dem Punkt beträgt: (Leckrate)/[Anrufrate bei max. Belegung × 0,05] = Punktgröße
Nachfolgend wird eine Leck-Rate von 1000 Punkte/Sekunde angenommen.
1 zeigt eine Analyse von n_r-Lesen-Durchläufen (n_r = 1, ..., 5) bei dem SCP Simulationsmodell.
Tabelle 1
Hier ist R_T66 die Verkehrs-Rate bei einer Belegung von 66%, und die Kosten sind durch die Formel angegeben: Kosten = Anzahl von CPUs × 1000 ms/sec × Belegung/(Anruf-Rate in Anrufe/Sekunde)
Die Kosten werden in Millisekunden gemessen.
Diese Tabelle schlägt vor, wie erwartet werden kann, dass T₀ etwa konstant ist, mit einem Durchschnitt (der 5-Lesen-Wert wird ignoriert) von 45 ms, und T_q ist eine lineare Funktion der Anzahl der Lese-Vorgänge. Die beste Anpassung an die Daten (berechnet durch die Methode der kleinsten Quadrate, wie später erläutert wird) führt zu T_q = 27,5n – 3,8. Wenn aber 6 und Tabelle 1 betrachtet werden, dann wird gesehen, dass der 5-Lesen-Punkt herauszufallen scheint – T_q scheint zu groß zu sein, und T₀ scheint zu klein zu sein. Wenn der 5-Lesen-Punkt nicht enthalten ist, dann gibt es eine annähernd perfekte Anpassung an die übrigen 4 Punkte, und zwar mit der Formel T_q = 22,7n + 5,8.
Ein Ziel besteht darin, eine Einrichtung zum Berechnen der Ziel-Antwortzeit T_Ziel über eine Formel zu finden. Eine Formel für die 95%-Antwortzeit für eine willkürliche Anzahl von Lesevorgängen und CPU-Belegung lautet: TAntwort (n, Belegung) = 45 + (22,7n + 5,8) × (Belegung/(1-Belegung)
Wenn eine Belegung von 66% angenommen wird, dann wird Tabelle 2 verwendet. In dieser Tabelle wird T_Ziel(n) = 45 + 2 (22,7n + 5,8) mit der Formel berechnet, wobei die T_ziel für die obige Tabelle für n_r = 1, 2, 3, 4, 5 verglichen werden. [Es sei angemerkt, dass Belegung = 66%, so dass (1-Belegung)/Belegung = 2]
Tabelle 2
Obwohl die Vorhersageleistung dieser Formel nicht schlecht ist, scheint es so, als würde die Formel für n_r = 5 zusammenbrechen. Es scheint, dass eine einfache lineare Formel, obwohl sie allgemein gut ist, nicht gut genug sein kann, um die Grenzwert-Antwortzeit für alle Services genau zu berechnen, und die Ziel-Antwortzeiten müssen individuell gemessen werden. Die nachfolgenden Abschnitte zeigen eine ähnliche Schlussfolgerung für den Multi-Box-Fall. Die gesamte obige Analyse sollte gleichermaßen gültig sein, wenn n_w-Schreiben-Services anstelle von n_r-Lesen-Services untersucht werden. Das heißt, obwohl ein Schreiben zeitaufwendiger ist als ein Lesen, müssen die gleichen funktionalen Beziehungen zwischen Anruf-Rate, Belegung und 95%-Antwortzeit beibehalten werden.
Hier werden einige Daten von der SCP-Simulation für einen "langes Lesen"-Service dargestellt, der für diese Zwecke als ein Schreiben bezeichnet wird.
Das Modell lief bei einigen verschiedenen Verkehrs-Raten für einmal, zweimal und dreimal Schreiben. Diese Daten wurden dann analysiert, um die Koeffizienten für den Leaky-Bucket-Algorithmus zu extrahieren. Dabei wurden die Datenpunkte bei hohen Belegungen beseitigt, um eine vernünftige lineare Anpassung zu erreichen (7).
Die vorhergehende Analyse ist vollständig abhängig von vorhandenen bestimmten Beziehungen zwischen der Anruf-Rate, der Belegung und den Antwortzeiten. Es scheint, dass die SCP-Simulationsdaten sehr gut zu diesen Beziehungen passen. Es ist interessant zu sehen, wenn reale Daten bei dem SCP gesammelt werden, dass diese zu den gleichen Beziehungen wie bei dem Modell führen. Hier führen die Resultate von einigen Messungen, die bei einem Single-Box-SCP-Modell gesammelt wurden, zu Darstellungen für drei verschiedene Services (9). Die Daten entsprechen einem Einmal-Lesen (Benchmark 5) und einem Einmal-Lesen & Einmal-Schreiben-Service (Benchmark C). Der dritte Service war für einen langen und teuren Service, der aus 12-Lesen und 1-Schreiben bestand. Die Daten sind nachfolgend angegeben. Die Darstellungen geben an, dass es in der Tat eine lineare Beziehung zwischen der Belegung und der Anruf-Rate sowie eine lineare Beziehung zwischen der Variablen x = Belegung/(100-Belegung) und der 95%-Antwortzeit gibt.
Tabelle 3
Wenn die in 3 gezeigte Architektur betrachtet wird, dann kommt ein Anruf bei dem SCP(C) an und wird zu dem slp (Service-Logik-Programm) weitergeleitet. Es wird vorgeschlagen, dass der Anruf zwei Datenbank-Zugriffe erfordert: einmal Lesen und einmal Schreiben. Das slp weist die Lesen-Anfrage dem nächsten sdp-Kunden-Prozess zu, der mit k bezeichnet ist, und die Anfrage geht in die Warteschlange k. Der sdp-Kunden-Prozess sendet die Anfrage zu einer der SDP-Boxen, alternativ zwischen dem Master und dem Slave. Die Anfrage wird durch die Software-Prozesse rcv, sdb-serv_k, slp-dba_k und durch den Informix-Datenbank-Zugriffsprozess oninit_k geleitet. Für die Zwecke der Simulation wird angenommen, dass jeder Software-Prozess eine feste Zeitdauer der cpu-Zeit in Anspruch nimmt, mit Ausnahme für den Datenbank-Zugriff, wo eine Poisson-Zeitverteilung angenommen wird. Natürlich führt die Anfrage zu Warteschlangen-Verzögerungen, wenn der Prozess für CPU-Zeit in der Warteschlange warten muss.
Die Zeiten für die verschiedenen Software-Prozesse wurden in dem SCP/SDP-Modell erstellt und sind in den nachfolgenden Tabellen 4–6 gezeigt. Es wurden Durchläufe für einen Einmal-Lesen- und einen Einmal-Lesen/Einmal-Schreiben-Prozess durchgeführt. Die Zeiten für einen Einmal-Lesen-Service wurden durch Bestimmen der Differenz erhalten.
Tabelle 4
Tabelle 5
Tabelle 6
Um die Eimer-Eingabe-Parameter zu berechnen, lief das Modell bei verschiedenen Verkehrs-Raten für Services, die 1-, 3-, 5und 8-Lesen beinhalten. Die Ausdrucke der 95% Antwortzeiten als Funktionen von X = Belegung/(1-Belegung) sind in 10 gezeigt.
Es sei angemerkt, dass eine lineare 1-Lesen Anpassung nicht sehr gut ist. Der Grund ist der folgende: in den Ausdrucken ist Belegung die CPU-Belegung von dem SDP. Das heißt, es wird angenommen, dass die Verzögerung aus der Warteschlangenzeit für die CPU-Zeit in dem SDP resultiert. Aber für einen Einmal-Lesen-Service betragen die CPU-Kosten von einem Anruf 4,618 ms auf einem SCP(C) und 3,19 ms auf einem SDP, was bedeutet, dass die Belegung bei einem 2-Box, 2 CPU-pro-Box SCP(C) größer ist als bei einem 2-Box, 2 CPU-pro-Box SDP. Daher kommt für einen hohen Verkehr die am meisten signifikante Verzögerung aus der Warteschlangenzeit für CPU-Zeit bei dem SCP(C) und nicht aus der Warteschlangenzeit auf dem SDP. Dieser Effekt beeinträchtigt die Vorhersagen des Programms, die am besten passende Formel für die Antwortzeiten zu finden. Die Mathematica-erzeugte Tabelle der Formeln und Vorhersagen unter Verwendung der in 9 gezeigten Daten (ausschließlich Daten von den Schreiben-Durchläufen) (Mathematica ist eine eingetragene Marke für ein Software-Programm der Wolfram Research Inc.) lautet:
Die Vorhersagen für T_95(T_Ziel) sind nicht sehr gut. Wenn der Datensatz Lesen aus der Eingabe beseitigt wird, ist die Tabelle wie folgt:
(Die Schreibdaten sind in dem zweiten Ausdruck enthalten). Es ist klar, dass dann, wenn die 1-Lesen-Messungen nicht von dem Programm verwendet werden, die Vorhersagen für die anderen Services sehr viel besser sind. Ein Weg, um dieses Problem zu umgehen, besteht darin, den Einmal-Lesen-Service als einen speziellen Fall zu betrachten, indem die Ziel-Antwortzeit, die aus Messungen abgeleitet wird, "von Hand" eingetragen werden und das Mathematica kleinste Quadrate anpassen Programm verwendet wird, um zu einer Formel für die n_r-Lesen Zielantwortzeiten zu führen (n_r > 1). Hier wird dann ein Zielwert verwendet.
Andererseits kann argumentiert werden, dass es dem SCP nie erlaubt werden soll, eine höhere Belegung zu haben als das SDP, so dass dann, wenn ein wesentlicher Anteil des Verkehrs durch einen 1-Lesen-Service gegeben ist (wie in dem Fall für einige Installationen), mehr SCP-Boxen addiert werden müssen. Dies hätte den natürlichen Effekt, dass die CPU-Belastung auf jedem SCP(C) bei einer äquivalenten Anruf-Rate vermindert wird. Die Test-Daten wurden erneut mit 4 SCP(C) Boxen durchlaufen gelassen. Bei diesem Durchlauf gab es kein spezielles Problem mit dem 1-Lesen-Service: 11 zeigt eine gute lineare Anpassung, und die Mathematica-Ausgabe führt zu
Die folgende Schlussfolgerung kann gezogen werden: wenn die Kosten von einem Service auf dem SCP größer sind als auf dem SDP, dann ist die lineare kleinste Quadrate Anpassung nicht gültig, und es muss eine besondere Sorgfalt betrieben werden.
Ein Probe-Eimer-Durchlauf wurde durchgeführt, wobei eine Multi-Box-Architektur vorhanden war, mit 2 SCP(C)s und einem Master-Slave SDP. Jede Box hat 2 CPUs. Aus dem letzten Abschnitt wurden die Eimer-Parameter erhalten: Tziel = 11,15 × nr + 53,60 × nw + (11,10 × nr + 16,21 × nw)/(nr + nw)und Strafe = 0,16 + 2,4 × nr + 9,06 × nw
Der Verkehr hatte den folgenden Anruf-Mix:
Tabelle 7
Tabelle 8
Die Resultate sind in 12 und 13 gezeigt. Die Aufgenommen/Angeboten-Kurve folgt dem Muster, wie durch das ITU eingestellt. Die Antwortzeit steigt mit zunehmendem Verkehr stark an, bis der Verkehr anfängt abgelehnt zu werden, wo er ein Maximum von etwa 400 Anrufe/Sekunde erreicht, und beginnt abzusinken. Die SLP-Belegung steigt auf ein Maximum und bleibt anschließend etwa konstant.
Sowohl Simulation als auch Durchläufe auf dem (Single-Box) SCP-Modell lassen schließen, dass die folgende Formel gültig ist. (Es sei angemerkt, dass hier die Anzahl der Ausfälle n_f in den Formeln enthalten ist, um dem Algorithmus zu entsprechen, wenn er auf dem SCP kodiert ist): TZiel(nr, nw, nf) = Tr(nr) + Tw (nw) + Tf (nf) + C(nr, nw, nf)wobei T_Ziel die 95%-Antwortzeit ist, wenn der Prozessor eine spezielle maximale Belegung hat, n_r die Anzahl von Lesevorgängen in dem Service ist, n_w die Anzahl von Schreibvorgängen und n_f die Anzahl von fehlerhaften Lese- oder Schreibvorgängen ist. In den meisten Fällen können T_r, T_w und T_f als lineare Funktionen von n_r, n_w bzw. von n_f angenommen werden.
Das heißt: Tr(nr) = tr × nr, Tw(nw) = tw × nw, Tf(nf) = tf × nf wobei t_r, t_w und tf Konstanten sind, die unter Verwendung der alternativen Formel später berechnet werden können. C(n_r, n_w, n_r) ist ein "durchschnittlicher Messwert" (der konstant oder nahezu konstant sein sollte): C(nr, nw, nf) = nrcr + nwcw + nfcf)/(nr + nw + nf)wobei c_r, c_w und c_f später auch durch das kleinste-Quadrate-Programm gegeben werden. Die lineare Beziehung zwischen der Ziel-Antwortzeit und der Anzahl von Lese- und Schreibvorgängen scheint unter den beiden nachfolgenden Bedingungen abzubrechen:

1) Wenn der Verkehr Anrufe mit einer großen durchschnittlichen Anzahl von Lese- oder Schreibvorgängen auf der Single-Box-Architektur enthält.
2) Wenn der Verkehr Anrufe mit einer kleinen durchschnittlichen Anzahl von Lesevorgängen (nahe 1) der der Multi-Box-Architektur enthält.

In diesen beiden Fällen scheinen die Antwortzeiten größer zu sein als die, die durch die Formel vorhergesagt werden, und somit sind einige "Einstellungen von Hand" erforderlich.
Wie vorstehend argumentiert, muss die Größe der Strafpunkte, die in dem Eimer nach einer langen Antwort verbleiben, von dem Service abhängig sein. Die Formel für die Strafe ist: Strafe = n_rk_r + n_wk_w + n_fk_f + k₀
wobei k_r, k_W, k_r und k₀ wieder aus Messungen auf den SCP-Modellen unter Verwendung der alternativen Formel in dem nachfolgenden Programm gefunden werden müssen.
Das Mathematica-Programm, das gleichermaßen in C geschrieben werden kann, nimmt als Eingabedaten-Dateien Lesen, Lesen2, ... Schreiben1, Schreiben2, ..., die alle Anruf-Raten, Belegungen und 95%-Antwortzeiten für verschiedene Services enthalten. Beispielsweise kann die Datei Lesen3 die folgende Form haben:

die alle Anruf-Raten, CPU-Belegung und 95%-Antwortzeit für mehrere verschiedene Durchläufe bei einem 2-Lesen-Service sind. Das Programm berechnet dann für jeden Service die Strafe und die 95%-Antwortzeit für diesen Service bei der gewünschten maximalen Belegung (maxocc) gemäß der Formel für T_Ziel. Es verwendet dann diese Werte, um die am besten passende lineare Formel für T_Ziel und für die Strafe zu finden. Speziell gibt sie k₀, k_f, k_W, und die (lineare Approximation) T_Ziel-Formel. In den meisten Fällen können die Parameter, die durch dieses Verfahren erhalten werden, direkt in die Konfigurationsdaten für das SCP eingegeben werden.
Die Daten aus den numerischen SCP-Modell-Durchläufen werden unter Verwendung der kleinste-Quadrate-Methode analysiert, um die am besten passende Kurve zu finden.
Es werden n Datenpunkte betrachtet:
(x₁, y₁), (x₂, y₂), ... (x_i, y_i), ... (x_n, y_n)
Es wird angenommen, dass die Variablen x und y eine lineare Beziehung haben y = a + bx, wobei a und b Konstanten sind. Die individuellen Datenpunkte, die Messungen sind, bei denen Fehler aufgetreten sind, liegen nicht notwendigerweise auf einer geraden Linie, sondern haben ein kleines Ausmaß an zufälliger Streuung (14).
Die am besten passende Kurve, die diejenige ist, die die Summe der Quadrate der Distanzen von den Punkten zu der Kurve minimiert, ist durch y = a + bx gegeben, wobei a und b gegeben sind durch: a = y – bx,
wobei die gestrichenen Werte die normalen Durchschnittswerte der x- und y-Werte sind.
Die Antwortzeit T_R, die die Zeit zwischen einer ausgegebenen Datenbank-Anfrage-Nachricht und der empfangenen Antwortnachricht ist, kann in drei Teile unterteilt werden. Der erste Teil ist eine feste Zeit in Folge der Reisezeit der Anfrage/Antwort. Die zweite Zeit ist die (variierende) Zeit, die durch den Datenbank-Zugriff in Anspruch genommen wird. Es kann angenommen werden, dass die Zugriffszeit eine Poisson-Verteilung mit einem festen Mittelwert beinhaltet. Drittens gibt es eine Warteschlangen-Verzögerung: wenn die Datenbank mehr als einen Anruf zu einem Zeitpunkt handhabt, muss eine Anfrage warten, während jene an der Spitze der Warteschlange verarbeitet werden. Wenn diese drei Verzögerungen T₁, T₂, T₃ sind, dann: (mittlere Antwortzeit) = T(MR) = T1 + T2 + T3 T₁ und T₂ sind konstant und können gemessen werden. Das Interessante ist die Abschätzung von T₃, das von der Länge der Warteschlange abhängt.
Es wird ein allgemeines Warteschlangen-System betrachtet. Kunden treffen ein, warten in einer Schlange und werden bedient. Wenn angenommen wird, dass es Poisson-Eintreffpunkte mit Rate λ und eine Poisson-verteilte Service-Zeit mit Rate μ gibt, dann ist die Warteschlangen-Zeit gegeben durch TWarteschlange = {1/μ}{λ/μ/(1 – λ/μ)
Aber für Poisson-verteilten Verkehr sind die Raten λ und μ gleich dem Kehrwerten der Zwischen-Ankunftszeit bzw. der Service-Zeit. Daher wird die Formel zu TWarteschlange = TS{Ts/Tein/(1 – TsTein)
Für dieses System ist T₃ die durchschnittliche Zeit eines Datenbank-Zugriffs und T_ein ist die Zwischen-Ankunftszeit der Anfragen. Es wird angenommen, dass der Prozessor lediglich einen Datenbank-Zugriff und sonst nichts durchführt, wobei T_S/T_ein einfach der Anteil der Zeit des arbeitenden Prozessors ist ... das heißt, die Belegung. Daher beträgt die Warteschlangen-Zeit T3 = TWarteschlange = TS Belegung/(1-Belegung).
Wenn T₁ und T₂ = T₀ ist und T_S durch T_q ersetzt wird, dann lautet die Formel: TR= T0(m, n) + Tq(m, n)\ × Belegung/(1-Belegung).
Obwohl die Abweichung auf die mittlere Verzögerung angewendet wird, scheint sie ebenfalls zumindest ungefähr für die 95% Verzögerung gültig zu sein.
Hier wird eine vollständige Erläuterung angegeben, wie die Größe von dem Strafpunkt für einen Service berechnet werden kann. Es wird angenommen, dass die gewünschte maximale Belegung der CPU gleich maxocc ist (in den obigen Beispielen auf 66% eingestellt). Für einen individuellen Service wird die Anruf-Rate, die einer CPU-Belegung von maxocc entspricht, aus der kleinste-Quadrate-Analyse der Daten abgeschätzt. (Es sei angemerkt, dass die Belegung nicht einfach proportional zur Anruf-Rate ist, da es Hintergrund-Aufgaben gibt, die die CPU auch bei Nicht-Vorhandensein von Anrufen belegen.) Aus der Anfangsformel ergibt sich, dass der Strafpunkt umgekehrt proportional zur Anruf-Rate ist. Daher gilt: (Strafe für n-Lesen)/(Strafe für 1-Lesen) = (Max. Anruf-Rate für 1-Lesen)/(Max. Anruf-Rate für n-Lesen)
Die Strafe kann gleichermaßen in Begriffen der "Kosten" von dem Service ausgedrückt werden, die die Zeit in Millisekunden ist, die der Service in der CPU in Anspruch nimmt. Die Anruf-Rate, die Kosten und die Belegung stehen miteinander in Beziehung durch: Anruf-Rate × (Kosten/1000) = Belegung/100wobei Belegung in Prozent ausgedrückt ist (zwischen 0,0 und 100,0). Gegeben ist die obige Formel: Strafe = Leck-Rate × (max. Belegung)/100 × (Kosten/1000)wobei Kosten in Millisekunden und max. Belegung zwischen 0,0 und 100,0 angegeben ist. Es scheint intuitiv offensichtlich, dass die Kosten eine lineare Funktion der Anzahl von. Lesevorgängen des Service n_r sind, was zu folgendem führt: Strafe = k0 + krnr wobei k₀ und k_r zu messende Konstanten sind. Aus der obigen Formel ist k_r: kr = Leck-Rate × (max. Belegung/100) × (Kosten für einmal Lesen/1000)
K₀ ist (etwa) die Strafe, die mit den Kosten von einem Service ohne Datenbank-Zugriff berechnet ist. Es ist nicht notwendig, das k_s direkt zu messen, aber es aus Messungen oder der Belegung über der Anruf-Rate für verschiedene Services zu berechnen.
Das obige ist auf Services mit n_r Lesevorgängen konzentriert, aber das Argument kann auf einen allgemeineren Service mit Lesevorgängen, Schreibvorgängen und Fehlern erweitert werden. Die endgültige Formel wird: Strafe = nrkr + nwkw + nfkf + k0

Claims

Transaktions-Verarbeitungssystem (SCP) mit einem Leaky-Bucket und einem Ablauf-Steuermittel (i_sw, o_sw), wobei das Ablauf-Steuermittel dazu angeordnet ist die Antwortzeit von jeder Transaktion zu überwachen und jede Antwortzeit mit einer vorbestimmten Antwortzeit zu vergleichen, wobei zumindest zwei unterschiedliche Werte der vorbestimmten Antwortzeit für unterschiedliche Transaktionen verwendet werden, und die Inhalte des Leaky-Bucket zu erhöhen, wenn eine Antwortzeit von einer Transaktion die vorbestimmte Antwortzeit in Zusammenhang mit der bestimmten Transaktion übersteigt, und wobei das Ablauf-Steuermittel dazu angeordnet ist, den Inhalt des Leaky-Bucket zu überwachen und Transaktionen im Verhältnis zu den Inhalten des Leaky-Bucket abzulehnen.
Transaktions-Verarbeitungssystem (SCP) nach Anspruch 1, bei welchem die Erhöhung eine Funktion der jeweiligen Transaktion ist.
Transaktions-Verarbeitungssystem (SCP) nach Anspruch 1 oder Anspruch 2, bei welchem die Transaktionen Echtzeit-Transaktionen sind.
Verfahren zum Betreiben eines Transaktions-Verarbeitungssystems (SCP), wobei das Verarbeitungssystem ein Leaky-Bucket und ein Ablauf-Steuermittel (i_sw, o_sw) enthält, wobei das Verfahren die Schritte enthält: (a) Überwachen der Antwortzeit von jeder Transaktion; (b) Vergleichen von jeder Antwortzeit mit einer vorbestimmten Antwortzeit, wobei zumindest zwei unterschiedliche Werte der vorbestimmten Antwortzeit für unterschiedliche Transaktionen verwendet werden; (c) Erhöhen der Inhalte des Leaky-Bucket, wenn eine Antwortzeit von einer Transaktion die vorbestimmte Antwortzeit in Zusammenhang mit der bestimmten Transaktion übersteigt; und (d) Überwachen der Inhalte des Leaky-Bucket und Ablehnen von Transaktionen im Verhältnis zum Inhalt des Leaky-Bucket.
Verfahren nach Anspruch 4, bei welchem die Erhöhung eine Funktion der jeweiligen Transaktion ist.
Verfahren nach Anspruch 4 oder Anspruch 5, bei welchem die Transaktionen gleich Echtzeit-Transaktionen sind.