1
00:00:00,080 --> 00:00:03,760
In dieser Folge tauchen wir in 
das Thema Load Testing ein. 

2
00:00:04,000 --> 00:00:06,840
Wir klären, warum es so wichtig 
ist, was die verschiedenen 

3
00:00:06,840 --> 00:00:11,040
Testarten wie Stress oder Spike 
Testing bringen und welche 

4
00:00:11,040 --> 00:00:13,280
zentralen Metriken du kennen 
musst. 

5
00:00:13,440 --> 00:00:15,840
Außerdem sprechen über 
praktische Open Source und 

6
00:00:15,840 --> 00:00:19,440
Enterprise Tools Monitoring 
Strategien, Fehler, die du 

7
00:00:19,440 --> 00:00:23,520
vermeiden solltest und wie du 
Load Testing in cicd Pipelines 

8
00:00:23,520 --> 00:00:25,200
und vielleicht auch deinen 
Alltag integrierst. 

9
00:00:25,440 --> 00:00:28,640
Lass uns gemeinsam Performance 
Probleme schon vor dem Release 

10
00:00:28,640 --> 00:00:36,240
aufführen. 
Hallo und herzlich Willkommen zu

11
00:00:36,240 --> 00:00:43,440
Folge 131 des To do Developer 
Podcasts mit Robin Manuel Thiel 

12
00:00:43,440 --> 00:00:49,280
und mir malte Lantin. 
Robin Manuel ist Cloud und AI 

13
00:00:49,360 --> 00:00:52,560
Architekt bei Microsoft und Ich 
bin Solutions Engineer bei 

14
00:00:52,560 --> 00:00:54,960
github. 
Den Podcast machen wir natürlich

15
00:00:54,960 --> 00:00:59,200
privat in unserer Freizeit und 
geben hier unsere persönliche 

16
00:00:59,200 --> 00:01:03,000
Meinung und Erfahrung an euch 
weiter und tauschen uns 

17
00:01:03,000 --> 00:01:06,880
natürlich ganz viel 
untereinander aus und auch in 

18
00:01:06,880 --> 00:01:09,920
dieser Folge haben wir wieder 
ein Thema, was dich Robin Manuel

19
00:01:09,920 --> 00:01:13,760
in den letzten Wochen intensiv 
beschäftigt hat, nämlich das 

20
00:01:13,760 --> 00:01:16,280
Thema Low Testing, das. 
Ich habe mich natürlich in das 

21
00:01:16,280 --> 00:01:19,840
Thema auch eingelesen, aber ich 
hoffe, dass ich auch aus deiner 

22
00:01:19,840 --> 00:01:23,840
Praxiserfahrung, die ganz frisch
ist, extrem viel lernen kann. 

23
00:01:24,000 --> 00:01:27,920
Und ich denke auch für unsere 
Zuhörerinnen und Zuhörer ist das

24
00:01:28,480 --> 00:01:30,800
Thema super spannend. 
Genau. 

25
00:01:30,800 --> 00:01:34,120
Bevor wir aber einsteigen, 
müssen wir noch danke sagen und 

26
00:01:34,120 --> 00:01:36,080
zwar an euch. 
Wir haben wieder Kaffee von euch

27
00:01:36,080 --> 00:01:38,920
bekommen und das erste 
Dankeschön ist ein ganz 

28
00:01:38,920 --> 00:01:41,920
Besonderes. 
Die Julia hat nämlich Jubiläum, 

29
00:01:41,920 --> 00:01:46,480
die hat uns seit einem Jahr. 
Jetzt schon mit einem Kaffee Abo

30
00:01:46,480 --> 00:01:48,160
unterstützt. 
Man kann bei uns bei bei mir 

31
00:01:48,160 --> 00:01:50,880
Coffee auch quasi so einfach 
regelmäßig einen Kaffee ausgeben

32
00:01:51,280 --> 00:01:53,560
und das wollen wir natürlich 
nicht unvergessen lassen, da ist

33
00:01:53,560 --> 00:01:55,840
Julia ja seit einem Jahr dabei. 
Ganz ganz herzlichen Dank. 

34
00:01:56,000 --> 00:01:58,560
Vielen Dank dafür. 
Das ist ganz super. 

35
00:01:59,160 --> 00:02:03,440
Ansonsten hat uns der Sebastian 
noch 3 Kaffee ausgegeben diese 

36
00:02:03,440 --> 00:02:07,240
Woche und er hat uns einen 
kleinen Gruß dagelassen und sich

37
00:02:07,240 --> 00:02:11,520
für den Podcast bedankt, der ihm
die Skills gibt, um mit gesundem

38
00:02:11,720 --> 00:02:16,880
Ai Halbwissen jederzeit seinen 
CTO in den Wahnsinn zu treiben. 

39
00:02:17,040 --> 00:02:21,680
Von daher sind wir super happy, 
dass wir Mehrwert stiften können

40
00:02:21,680 --> 00:02:24,560
und in eurer Firma zum 
Entertainment der 

41
00:02:24,560 --> 00:02:26,560
Führungsmannschaft beitragen 
können. 

42
00:02:27,440 --> 00:02:29,840
Sehr, sehr gerne. 
Ja, dann steigen wir mal ein Low

43
00:02:29,840 --> 00:02:31,360
Testing, warum macht man das 
eigentlich? 

44
00:02:31,360 --> 00:02:34,720
Also der Hauptgrund ist so ein 
bisschen, dass die meisten 

45
00:02:34,720 --> 00:02:37,520
Performance Probleme oft 
unentdeckt bleiben, bis so eine 

46
00:02:37,520 --> 00:02:40,080
Applikation wirklich mal unter 
Last steht und das liegt 

47
00:02:40,080 --> 00:02:43,160
natürlich zum einen daran, dass 
wenn man eine Applikation 

48
00:02:43,160 --> 00:02:45,520
entwickelt, entweder alleine 
oder in einem kleinen Team 

49
00:02:45,800 --> 00:02:48,000
natürlich die Last erstmal 
überschaubar ist, weil ich dann 

50
00:02:48,000 --> 00:02:51,000
vielleicht irgendwie ein 2 Tests
dagegen schieße und mal so ein 

51
00:02:51,000 --> 00:02:53,520
bisschen in. 
Ja, so ein bisschen Smoke 

52
00:02:53,520 --> 00:02:55,520
Testing eigentlich mache was da 
genau die Unterschiede sind. 

53
00:02:55,520 --> 00:02:57,720
Kommen wir noch mal zu, aber 
eigentlich so ein bisschen das 

54
00:02:57,720 --> 00:03:01,280
ja nur als Einzelperson 
austesteste und es oft nur 

55
00:03:01,280 --> 00:03:05,040
Theorie ist wie sich mein System
eigentlich verhält, wenn da mal 

56
00:03:05,040 --> 00:03:07,840
wirklich hunderte oder tausende 
User gleichzeitig darauf 

57
00:03:07,840 --> 00:03:11,120
zugreifen und genau das wird 
beim Low Testing jetzt mal 

58
00:03:11,120 --> 00:03:13,200
simuliert. 
Und wir wollen natürlich 

59
00:03:13,200 --> 00:03:18,400
sicherstellen, dass unser System
auch jederzeit die Erwartung 

60
00:03:18,400 --> 00:03:21,520
unserer Nutzer erfüllt. 
Wir haben dort. 

61
00:03:21,880 --> 00:03:24,320
Nicht nur die Erwartungshaltung,
die irgendwie alle von uns 

62
00:03:24,320 --> 00:03:27,280
haben, dass irgendwie die 
Anwendung funktioniert, sondern 

63
00:03:27,280 --> 00:03:30,000
wir haben auch vielleicht 
vertraglich vereinbarte 

64
00:03:30,800 --> 00:03:34,720
Garantien, die wir unseren 
Kunden gegeben haben, was halt 

65
00:03:34,720 --> 00:03:38,320
Response Zeiten betrifft. 
Was SL as für die Verfügbarkeit 

66
00:03:38,320 --> 00:03:42,480
betrifft, und die wollen wir 
natürlich nicht verletzen. 

67
00:03:43,480 --> 00:03:44,480
Genau. 
Man kann also sagen, dass 

68
00:03:44,480 --> 00:03:46,920
eigentlich so Low Testing eine 
Teilmenge von Performance 

69
00:03:46,920 --> 00:03:49,400
Testing ist, weil eigentlich 
testen wir die Performance, das 

70
00:03:49,400 --> 00:03:51,440
ist ja dann auch das, wo wir die
SL AS wahrscheinlich drauf 

71
00:03:51,440 --> 00:03:55,520
haben, also dass wir quasi eine 
gewisse gewisse Antwortzeiten 

72
00:03:56,240 --> 00:03:58,720
einhalten, aber natürlich auch 
eine gewisse Up Time einhalten 

73
00:03:58,720 --> 00:04:02,720
können, also eine gewisse 
Fehlerrate niedrig halten, denn.

74
00:04:03,080 --> 00:04:05,200
Es kann ja sein, dass wir 
schnell antworten, aber halt nur

75
00:04:05,200 --> 00:04:08,840
für 99% der User und der eine 
Prozent der User, der jetzt 

76
00:04:08,840 --> 00:04:10,480
vielleicht irgendwie noch 
zusätzlich dazu kommt, der 

77
00:04:10,480 --> 00:04:12,840
kriegt dann halt extrem viele 
Fehler, weil unsere Systeme 

78
00:04:12,840 --> 00:04:18,360
überlastet, überlastet sind und 
eigentlich dieses Wissen, 

79
00:04:18,360 --> 00:04:20,079
wieviel Last man eigentlich 
erträgt. 

80
00:04:20,079 --> 00:04:23,920
Das erlangt man am Ende vom Low 
Testing aber natürlich auch so 

81
00:04:23,920 --> 00:04:27,120
ein bisschen Hilfe bei der 
Skalierbarkeit und der 

82
00:04:27,120 --> 00:04:30,560
Kapazitätsberechnung. 
Bei dem Thema Low Testing, da 

83
00:04:30,560 --> 00:04:32,560
kommen ja auch relativ schnell 
andere. 

84
00:04:33,040 --> 00:04:37,440
Begriffe aus dem Bereich des 
Performance Testings ins Spiel. 

85
00:04:37,680 --> 00:04:40,240
Vielleicht sprechen wir die mal 
ganz kurz durch, um einfach auch

86
00:04:40,240 --> 00:04:43,040
die Unterscheidung noch mal klar
zu machen. 

87
00:04:43,360 --> 00:04:46,640
Ich glaube ein paar Sachen 
hattest du gerade am Anfang 

88
00:04:46,640 --> 00:04:48,560
schon genannt, aber ich glaube 
es macht Sinn, das noch mal ein 

89
00:04:48,560 --> 00:04:53,520
bisschen zu erklären, was da die
Unterschiede sind zwischen jetzt

90
00:04:53,600 --> 00:04:58,640
Low Testing und anderen 
Performance testing Arten. 

91
00:04:59,880 --> 00:05:01,600
Zunächst einmal vielleicht 
Stress. 

92
00:05:01,600 --> 00:05:03,920
Testing, was ist denn der 
Unterschied zwischen Load und 

93
00:05:03,920 --> 00:05:06,960
Stress Testing, weil beides hat 
ja mit Last zu tun. 

94
00:05:07,040 --> 00:05:09,880
Ja, genau, es ist auch, glaube 
ich, alles so Arten von Load 

95
00:05:09,880 --> 00:05:12,800
Testing unter dem normalen Load 
Testing versteht man es erst mal

96
00:05:12,800 --> 00:05:15,200
so, die Anwendung unter der 
normalen Last. 

97
00:05:15,200 --> 00:05:18,160
Also ich schaue so okay was habe
ich, wie viele Anwender habe ich

98
00:05:18,160 --> 00:05:21,560
ungefähr gleichzeitig auf meiner
Plattform, das kann ja sich auch

99
00:05:21,560 --> 00:05:24,000
bei einer globalen Plattform zum
Beispiel verteilen, dadurch, 

100
00:05:24,000 --> 00:05:26,640
dass einfach Tag und Nachtzeiten
und Zeitzonen unterschiedlich 

101
00:05:26,640 --> 00:05:28,200
sind, so. 
Es kann sein, dass ich eine 

102
00:05:28,200 --> 00:05:30,920
Business Anwendung habe, die am 
Wochenende viel weniger genutzt 

103
00:05:30,920 --> 00:05:32,760
wird als unter der Woche. 
Das heißt, ich gucke mir so ein 

104
00:05:32,760 --> 00:05:36,320
bisschen aus, was ist denn so 
die normale erwartete Last, also

105
00:05:36,320 --> 00:05:38,560
vielleicht auch so die höchste 
normale erwartete Last, die ich 

106
00:05:38,560 --> 00:05:42,080
irgendwie habe und teste mein 
System unter dieser Last. 

107
00:05:42,320 --> 00:05:45,720
Und beim Stresstesting wird 
diese normale Lastgrenze jetzt 

108
00:05:45,720 --> 00:05:47,720
einfach mal überschritten, das 
heißt, wir gucken, wie verhält 

109
00:05:47,720 --> 00:05:50,600
sich mein System denn wenn 
morgen doppelt so viele Leute 

110
00:05:50,600 --> 00:05:54,000
auf meine Plattform gehen, das 
kann im E Commerce Fonds können 

111
00:05:54,000 --> 00:05:57,040
das Sachen sein die die absehbar
sind, teilweise sowas wie. 

112
00:05:57,360 --> 00:05:59,760
Das ist Black Friday. 
Oder steht das 

113
00:05:59,760 --> 00:06:02,160
Weihnachtsgeschäft an und dann 
muss ich natürlich gucken, wie 

114
00:06:02,160 --> 00:06:04,160
verhält sich meine Anwendung 
darauf hin. 

115
00:06:04,720 --> 00:06:06,280
Es kann aber auch Dinge sein, 
die ich vielleicht gar nicht 

116
00:06:06,280 --> 00:06:08,640
abschätzen kann. 
Irgendein Influencer hat sich 

117
00:06:08,720 --> 00:06:13,120
über mein Produkt gesprochen und
auf einmal habe ich eine völlig 

118
00:06:13,440 --> 00:06:15,360
unerwartete Last auf meinem 
SARS. 

119
00:06:15,360 --> 00:06:16,960
Tool vielleicht auch oder sowas 
und. 

120
00:06:17,440 --> 00:06:20,680
Oder hier in diesem 
weltberühmten To do Cast haben 

121
00:06:20,680 --> 00:06:24,560
wir irgendwie ein Tool erwähnt 
und auf einmal muss der 

122
00:06:24,560 --> 00:06:26,560
Hersteller oder die Herstellerin
natürlich mit extrem viel mehr 

123
00:06:26,560 --> 00:06:30,080
Last rechnen und diese Dinge, 
quasi das System, eigene Systeme

124
00:06:30,080 --> 00:06:33,160
unter Stress zu setzen und zu 
gucken, wo sind die Bruchpunkte,

125
00:06:33,160 --> 00:06:36,480
das testet man dann halt im 
Stresstesting das ist nichts was

126
00:06:36,480 --> 00:06:40,120
ich normalerweise brauche, weil 
normalerweise gucke ich ja, wie 

127
00:06:40,120 --> 00:06:41,920
verhält sich mein System unter 
der normalen Last. 

128
00:06:42,080 --> 00:06:44,560
Ich will aber trotzdem wissen, 
was würde denn passieren? 

129
00:06:44,960 --> 00:06:49,960
Wenn morgen 3040 100% mehr User 
und Userinnen auf meine 

130
00:06:49,960 --> 00:06:51,240
Plattform kommen. 
Ja, und das ist ja eng 

131
00:06:51,240 --> 00:06:54,560
verbunden, auch mit dem 
sogenannten Spike Testing, wo 

132
00:06:54,720 --> 00:06:59,280
wir plötzliche Lastspitzen 
haben, das heißt im üblichen Low

133
00:06:59,280 --> 00:07:01,680
Testing nehmen wir unsere 
normalen. 

134
00:07:02,080 --> 00:07:05,640
Nutzungspatterns, die wir 
kennen, von unserer Plattform 

135
00:07:05,640 --> 00:07:09,760
und testen dagegen beim Spike 
Testing testen wir, was 

136
00:07:09,760 --> 00:07:12,480
passiert, wenn jetzt wirklich 
ganz plötzlich die Last 

137
00:07:12,480 --> 00:07:15,240
hochgeht, das kann so was sein, 
was du gerade erwähnt hattest, 

138
00:07:15,240 --> 00:07:18,800
dass irgendwo mein Produkt 
erwähnt wird, vielleicht, dass 

139
00:07:18,800 --> 00:07:22,720
auch irgendwo in der Presse, in 
den Medien irgendwas auftaucht 

140
00:07:22,960 --> 00:07:28,200
und dann ganz unerwartet extrem 
viel Last auf der Plattform ist.

141
00:07:28,200 --> 00:07:31,280
Und da kommt nämlich noch 
zusätzlich halt der Zeitfaktor 

142
00:07:31,520 --> 00:07:32,960
mit rein und. 
Werden, das heißt, es ist eine 

143
00:07:32,960 --> 00:07:36,160
plötzliche Lastspitze und nicht 
das, was wir gerade besprochen 

144
00:07:36,160 --> 00:07:37,560
hatten. 
Genau das ist dann vor allem 

145
00:07:37,560 --> 00:07:40,440
auch das, wo ich meine, die 
Skalierung meines Systems teste,

146
00:07:40,440 --> 00:07:43,040
und zwar nicht kann mein System 
skelieren, sondern wie schnell 

147
00:07:43,040 --> 00:07:45,280
kann mein System skelieren, wie 
schnell kann ich diese 

148
00:07:45,440 --> 00:07:49,680
plötzliche Last abfangen? 
Dann gibt es noch das Thema, was

149
00:07:49,680 --> 00:07:54,000
halt eher auf die lange Zeit 
ausgelegt, sogenanntes Endurance

150
00:07:54,000 --> 00:07:57,440
Testing. 
Da haben wir hohe Last über 

151
00:07:57,440 --> 00:08:01,520
einen langen Zeitraum und da 
achten wir halt plötzlich auf 

152
00:08:01,520 --> 00:08:03,720
andere Dinge. 
Dinge vielleicht weniger die 

153
00:08:03,720 --> 00:08:06,400
klassischen Fehler, die 
auftreten, wenn ein System 

154
00:08:06,400 --> 00:08:09,120
überlastet ist, sondern wir 
schauen uns vor allen Dingen an,

155
00:08:09,120 --> 00:08:11,840
wie zum Beispiel die 
Speicherauslastung aussieht, 

156
00:08:11,840 --> 00:08:15,000
weil wir haben unsere Anwendung 
jetzt wirklich über Monate und 

157
00:08:15,000 --> 00:08:18,640
Jahre laufen, und es kommt immer
wieder vor, dass wir dann auch 

158
00:08:18,640 --> 00:08:21,920
irgendwo kleine Memory Leaks 
haben und dann irgendwie uns der

159
00:08:21,920 --> 00:08:24,920
Speicher vollläuft und wir dann 
irgendwann in fehlerverhalten 

160
00:08:24,920 --> 00:08:28,240
Reinlaufen, was wir aber nur 
sehen, wenn wir über einen 

161
00:08:28,240 --> 00:08:30,880
längeren Zeitraum die Anwendung 
auch beobachten. 

162
00:08:31,280 --> 00:08:33,760
Genau und ähnlich dazu ist so 
ein bisschen das Volume Testing.

163
00:08:33,760 --> 00:08:35,840
Das ist das Gegenteil, da müssen
wir gar nicht unbedingt auf 

164
00:08:35,840 --> 00:08:37,679
einen längeren Zeitraum testen, 
sondern dann testen wir auf 

165
00:08:37,679 --> 00:08:39,760
einmal mit sehr hohem Volumen, 
das sind hauptsächlich dann 

166
00:08:40,080 --> 00:08:42,559
große Datenmengen, also das ist 
ja, wenn ich jetzt irgendwie 

167
00:08:42,559 --> 00:08:44,840
eine Speicherlösung anbiete und 
jemand lädt da Petabytes an 

168
00:08:44,840 --> 00:08:47,680
Daten hoch und ich habe auf 
einmal sehr, sehr, sehr, sehr 

169
00:08:47,680 --> 00:08:50,720
große Datenmengen, die in meine 
Datenbank geschrieben werden, so

170
00:08:50,720 --> 00:08:53,360
was testet man auch, und das ist
natürlich alles Last fürs 

171
00:08:53,360 --> 00:08:56,760
System, deswegen fällt das auch 
alles so unter diese Load 

172
00:08:56,760 --> 00:09:00,320
testing Kategorie. 
Und in der Regel ist es so, also

173
00:09:00,320 --> 00:09:01,920
bei uns. 
Ich kann ja mal ein bisschen ein

174
00:09:01,920 --> 00:09:05,200
bisschen ausholen, wo jetzt bei 
mir auch das Interesse dafür 

175
00:09:05,200 --> 00:09:07,000
herkam. 
Ich war in einem Projekt, da 

176
00:09:07,000 --> 00:09:10,600
haben wir Lasttests eingeführt, 
eben auch aus den Gründen, die 

177
00:09:10,600 --> 00:09:12,440
du eben genannt hast. 
Malte, wir mussten, müssen eben 

178
00:09:12,440 --> 00:09:16,800
gewisse SL AS quasi einhalten, 
und wir müssen sicherstellen 

179
00:09:16,800 --> 00:09:20,200
können, dass wir mit dem System,
was wir gebaut haben, auch die 

180
00:09:20,200 --> 00:09:22,240
erwartete Last, die dann 
irgendwann auf uns zukommt, wenn

181
00:09:22,240 --> 00:09:25,040
das System live ist, abdecken 
können, und das müssen wir halt 

182
00:09:25,040 --> 00:09:28,040
immer wieder garantieren, auch 
regelmäßig garantieren und. 

183
00:09:28,160 --> 00:09:31,680
Und wir haben halt uns für einen
Low Testing Service entschieden.

184
00:09:31,680 --> 00:09:32,800
Wir machen das nicht alles 
selber. 

185
00:09:32,800 --> 00:09:35,600
Kommen wir nachher noch mal zu 
was es da für Services gibt und 

186
00:09:35,600 --> 00:09:38,640
innerhalb dieses Low Testing 
Services haben wir verschiedene 

187
00:09:38,640 --> 00:09:42,080
Arten von Tests, das heißt Wir 
haben mal einen Spike Test. 

188
00:09:42,080 --> 00:09:45,200
Wir haben einen Stresstest und 
so weiter gebaut, das heißt es 

189
00:09:45,200 --> 00:09:48,080
fällt glaube ich schon alles in 
diese Low Testing Kategorie mit 

190
00:09:48,080 --> 00:09:51,680
rein, sind aber einfach 
unterschiedliche Tests die man 

191
00:09:51,680 --> 00:09:52,720
baut. 
Wir. 

192
00:09:52,800 --> 00:09:56,600
Damit kommt man ja auch so ein 
bisschen zu den Gründen, warum 

193
00:09:56,600 --> 00:09:57,800
man das auf jeden Fall machen 
sollte. 

194
00:09:57,800 --> 00:10:00,080
Du hattest es ja gerade erwähnt,
ihr habt da Performance 

195
00:10:00,080 --> 00:10:03,760
Garantien für eure Kunden und 
das macht man ja nicht irgendwo 

196
00:10:03,760 --> 00:10:06,320
aus Nettigkeit, sondern man hat 
da auch finanzielle 

197
00:10:06,320 --> 00:10:09,840
Verpflichtungen dahinter und man
möchte natürlich Kosten 

198
00:10:09,840 --> 00:10:16,200
vermeiden, wenn man bestimmte. 
Zu sagen bricht, und das ist 

199
00:10:16,200 --> 00:10:20,680
teilweise wirklich auch teuer. 
Es gibt zahlen aus der 

200
00:10:20,680 --> 00:10:25,040
Industrie, die Halt von 
irgendwie einem fünfstelligen 

201
00:10:25,040 --> 00:10:29,800
Betrag pro Stunde rechnen, wenn 
eine Anwendung ausfällt. 

202
00:10:29,800 --> 00:10:32,560
Das hängt natürlich davon ab, 
was für eine Art von Anwendung 

203
00:10:32,720 --> 00:10:35,160
ich habe und wie viele Kunden 
ich habe, aber da kommen 

204
00:10:35,160 --> 00:10:37,920
natürlich verschiedene Faktoren 
dazu, wenn ich eine E Commerce 

205
00:10:37,920 --> 00:10:40,280
Plattform habe, habe ich 
vielleicht keine SL as, aber auf

206
00:10:40,280 --> 00:10:42,760
der anderen Seite gehen mir dann
will ich massiv umsetzen. 

207
00:10:42,880 --> 00:10:46,320
Verloren, wenn gerade in Zeiten 
steigender Last plötzlich meine 

208
00:10:46,320 --> 00:10:49,600
Plattform für Kunden nicht 
verfügbar ist, weil im E 

209
00:10:49,600 --> 00:10:51,520
Commerce kommt es dann ganz 
schnell vor, wenn ich jetzt 

210
00:10:51,520 --> 00:10:54,320
irgendwie nicht Amazon bin, wo 
die Leute immer wieder kommen, 

211
00:10:54,400 --> 00:10:56,240
dass die Leute dann, wenn die 
Seite nicht richtig 

212
00:10:56,240 --> 00:10:58,960
funktioniert, dann halt zum 
nächsten Händler wechseln und 

213
00:10:58,960 --> 00:11:02,800
daher kommen halt auch diese 
hohen Zahlen, die man da 

214
00:11:02,800 --> 00:11:06,960
ermittelt und gerade auch bei 
größeren Unternehmen kann das 

215
00:11:06,960 --> 00:11:09,200
auch. 
Auch schon dann relativ schnell 

216
00:11:09,200 --> 00:11:14,040
in die Millionen gehen, wenn es 
regelmäßig wirklich zu fehlender

217
00:11:14,040 --> 00:11:15,680
Verfügbarkeit der Anwendung 
kommt. 

218
00:11:15,840 --> 00:11:22,960
Ja, Amazon hat mal gesagt, dass 
sie $13000000 pro Stunde Ausfall

219
00:11:22,960 --> 00:11:25,520
verlieren würden. 
Allein an Umsatz ist natürlich 

220
00:11:25,520 --> 00:11:29,040
schon Crazy, wahrscheinlich auch
der Grund warum ich, warum ich 

221
00:11:29,040 --> 00:11:31,360
Amazon noch nie offline gesehen 
habe, wäre ja auch glaube ich 

222
00:11:31,360 --> 00:11:33,280
sehr schlechtes Marketing für 
ADAV US. 

223
00:11:33,800 --> 00:11:37,200
Aber auch halt Sachen, die jetzt
gar nicht, gar nicht in einen 

224
00:11:37,200 --> 00:11:39,600
genauen Euro oder einen Dollar 
umzurechnen sind, sondern auch 

225
00:11:39,600 --> 00:11:41,480
so. 
Es gibt Studien, die sagen, man 

226
00:11:41,480 --> 00:11:45,880
kann, man kann diese Conversion 
Verluste messen mit jeder 

227
00:11:45,880 --> 00:11:48,800
Sekunde ladezeitverzögerung zum 
Beispiel, die ich habe, einfach 

228
00:11:48,800 --> 00:11:52,240
weil Leute, die Lust verlieren, 
auf meiner Plattform unterwegs 

229
00:11:52,240 --> 00:11:54,560
zu sein oder tatsächlich auch 
einfach das Vertrauen in die 

230
00:11:54,560 --> 00:11:56,600
Plattform verlieren. 
Ich finde, es wirkt immer so ein

231
00:11:56,600 --> 00:11:59,040
bisschen ja. 
So ein bisschen merkwürdig 

232
00:11:59,040 --> 00:12:01,760
bisschen fishy, wenn eine 
Plattform irgendwie sehr lange 

233
00:12:01,760 --> 00:12:03,520
lädt, dann wird das immer so ein
bisschen altbacken. 

234
00:12:03,520 --> 00:12:07,000
Also neben den wirklich zahlen, 
die man messen kann an Umsatz, 

235
00:12:07,000 --> 00:12:09,480
der verloren geht, wenn eine 
Plattform offline oder langsam 

236
00:12:09,480 --> 00:12:10,920
ist, fand ich das auch spannend,
dass es da auch so eine 

237
00:12:10,920 --> 00:12:14,080
psychologische Komponente gibt 
und dass man sich das eigentlich

238
00:12:14,080 --> 00:12:17,120
nicht leisten kann, weil auch 
gerade so langsame oder 

239
00:12:17,120 --> 00:12:20,480
unresponsive Apps, es muss ja 
gar nicht immer nur e Commerce 

240
00:12:20,480 --> 00:12:24,560
sein, aber auch natürlich Kunden
wieder auf, ja vielleicht dazu 

241
00:12:24,560 --> 00:12:26,720
motivieren, sich mal 
Alternativen oder die Konkurrenz

242
00:12:26,720 --> 00:12:29,600
anzuschauen. 
Und eine gute Performance kann 

243
00:12:29,600 --> 00:12:30,920
auch zu einer höheren 
Kundenbindung führen. 

244
00:12:30,920 --> 00:12:33,000
Also es gibt wie gesagt, es gibt
diese psychologische Komponente,

245
00:12:33,000 --> 00:12:36,000
dass wir alle natürlich Apps, 
die, die gut funktionieren mögen

246
00:12:36,000 --> 00:12:38,160
und auf der anderen Seite 
natürlich auch wirklich 

247
00:12:38,160 --> 00:12:41,160
messbarer Umsatz uns durch die 
Lappen geht, oder oder halt 

248
00:12:41,160 --> 00:12:42,600
nicht nur Umsatz, sondern wir 
wirklich teilweise auch 

249
00:12:42,600 --> 00:12:45,840
Vertragsstrafen zahlen müssen, 
wenn wir zum Beispiel für andere

250
00:12:45,840 --> 00:12:48,240
hosten oder sowas, dann haben 
wir natürlich auch mit SL AS, 

251
00:12:48,240 --> 00:12:50,160
die wir auch vertraglich 
vereinbart haben, wir. 

252
00:12:51,000 --> 00:12:53,560
Das heißt, wir haben die 
finanziellen Aspekte und dann 

253
00:12:53,560 --> 00:12:56,720
natürlich indirekt auch so 
Themen wie Kundenzufriedenheit, 

254
00:12:56,800 --> 00:12:59,440
die zu finanziellen Ausfällen 
führen können. 

255
00:12:59,600 --> 00:13:03,400
Und dann kommen wir natürlich zu
den ganz praktischen technischen

256
00:13:03,400 --> 00:13:05,160
Gründen, die am Ende natürlich 
auch irgendwelche 

257
00:13:05,160 --> 00:13:07,200
wirtschaftlichen Hintergründe 
haben. 

258
00:13:07,360 --> 00:13:10,040
Aber ich glaube, gerade für uns,
die wir uns mit der Technik 

259
00:13:10,040 --> 00:13:13,480
beschäftigen, gibt es halt dann 
auch noch ganz klare technische 

260
00:13:13,480 --> 00:13:17,040
Gründe, warum man mal einen 
Loadtest machen muss und den 

261
00:13:17,040 --> 00:13:20,600
regelmäßig wiederholt. 
Weil man natürlich auch die 

262
00:13:20,600 --> 00:13:24,040
Skalierbarkeit, die technische 
Skalierbarkeit der Anwendung 

263
00:13:24,040 --> 00:13:26,400
auch planen muss. 
Das heißt, ich kann jetzt 

264
00:13:26,400 --> 00:13:30,080
irgendwie mir akademisch 
Gedanken machen, wie ich meine 

265
00:13:31,120 --> 00:13:35,200
Infrastruktur aufbaue, dass sie 
möglichst skalierbar ist, aber 

266
00:13:35,280 --> 00:13:39,160
wie konkret ich diese dann in 
der Praxis skaliere, in welcher 

267
00:13:39,160 --> 00:13:43,040
Geschwindigkeit, bis zu welchen 
Grenzen, sehe ich halt nur unter

268
00:13:43,120 --> 00:13:46,400
realer oder simulierter Last 
während eines Lasttests. 

269
00:13:46,880 --> 00:13:50,480
Und nur dann kann ich auch meine
Kapazitätsgrenzen erkennen. 

270
00:13:50,560 --> 00:13:54,560
Mein Infrastrukturbedarf auch 
entsprechend konfigurieren, 

271
00:13:54,720 --> 00:13:57,840
damit meine Anwendung dann auch 
im Ernstfall entsprechend 

272
00:13:57,840 --> 00:13:59,600
skaliert. 
Das heißt, auf der technischen 

273
00:13:59,600 --> 00:14:04,480
Ebene brauche ich das natürlich 
hier, um das ganze Vorzuplanen. 

274
00:14:04,720 --> 00:14:06,560
Ja, bis dahin ist es halt nur 
theoretisch. 

275
00:14:06,800 --> 00:14:08,880
Und jetzt, wenn ich eine 
richtige Last mal drauf setze, 

276
00:14:08,880 --> 00:14:10,640
dann erkenne ich vielleicht auch
irgendwelche Fehler, die ich 

277
00:14:10,640 --> 00:14:14,080
vorher gar nicht gesehen habe 
und auch hier, je früher ich 

278
00:14:14,080 --> 00:14:16,120
natürlich so eine 
Fehlererkennung habe, je früher 

279
00:14:16,120 --> 00:14:18,080
ich natürlich irgendwie merke, 
ich habe irgendwo Performance 

280
00:14:18,080 --> 00:14:21,440
Bottle next und die jetzt einmal
idealerweise auch noch vor dem 

281
00:14:21,440 --> 00:14:23,600
Go Life oder sowas 
identifizieren kann oder 

282
00:14:23,600 --> 00:14:25,440
irgendwelche Memory Leaks oder 
vielleicht auch Code 

283
00:14:25,440 --> 00:14:28,560
ineffizienten Aufdecke, die halt
ich halt nur unter Last sehen 

284
00:14:28,560 --> 00:14:31,280
kann, zeigen ja auch schon 
gerade wo wir vorhin aber über 

285
00:14:31,280 --> 00:14:33,000
die Zahlen gesprochen haben, wie
wichtig ist das, ist das 

286
00:14:33,000 --> 00:14:35,120
vielleicht auch schon. 
Recht früh in den 

287
00:14:35,120 --> 00:14:37,000
Entwicklungsprozess mit 
einzubinden. 

288
00:14:37,000 --> 00:14:39,680
Also wir haben jetzt bei unseren
Lasttests zum Beispiel 

289
00:14:40,000 --> 00:14:45,080
herausgefunden, dass die Systeme
und für sich allein gesehen alle

290
00:14:45,080 --> 00:14:47,760
ganz gut funktioniert haben, 
aber dann natürlich auch unter 

291
00:14:47,760 --> 00:14:50,080
Lastabhängigkeiten wieder auf 
andere Systeme haben. 

292
00:14:50,080 --> 00:14:53,200
Also wir machen auch Micro 
Services, und da hatten zum 

293
00:14:53,200 --> 00:14:56,640
Beispiel viele Systeme. 
Eine Abhängigkeit auf einen 

294
00:14:56,640 --> 00:14:59,600
rechtszentralen Service, der für
sich ganz gut funktioniert. 

295
00:14:59,680 --> 00:15:02,240
Aber wenn diese ganzen Systeme 
gleichzeitig unter Last stehen, 

296
00:15:02,240 --> 00:15:04,560
halt alle auf diesen einen 
Service, das heißt der hat 

297
00:15:04,560 --> 00:15:06,840
eigentlich eine überdimensionale
Last, weil die alle auf diesen 

298
00:15:06,840 --> 00:15:10,000
einen zentralen Service 
irgendwie zugegriffen haben und 

299
00:15:10,000 --> 00:15:12,160
damit zum Beispiel dann eine 
Code Ineffizienz erkennen können

300
00:15:12,160 --> 00:15:13,920
und sowas. 
Und diese frühe Fehlererkennung 

301
00:15:13,920 --> 00:15:16,360
bevor man irgendwie. 
Einen Go live hat, bevor man 

302
00:15:16,360 --> 00:15:18,120
sich jetzt irgendwie den Markt 
mit seiner neuen Plattform 

303
00:15:18,120 --> 00:15:19,880
präsentiert. 
Also einmal würde ich diesen 

304
00:15:19,880 --> 00:15:22,120
Lasttest auf jeden Fall vorher 
fahren und wie du gerade schon 

305
00:15:22,120 --> 00:15:23,880
gesagt hast, die Skalierbarkeit 
auch entsprechend so 

306
00:15:23,880 --> 00:15:25,840
dimensionieren. 
Ich glaube ich würde, wenn ich 

307
00:15:25,840 --> 00:15:29,120
in einer in so einer Hyperskala 
Cloud bin, auch vor dem Go live 

308
00:15:29,120 --> 00:15:33,560
gerne mal deutlich über 
überskalieren, dass zumindest so

309
00:15:33,560 --> 00:15:35,960
der Erste der Ersteindruck von 
meiner Plattform sehr sehr gut 

310
00:15:35,960 --> 00:15:36,880
ist. 
Und da kann ich ja immer noch 

311
00:15:36,880 --> 00:15:39,360
hinten raus, dann gucken, wie 
ist denn die tatsächliche Last 

312
00:15:39,360 --> 00:15:41,360
das? 
Kann man sich ja sogar in den 

313
00:15:41,360 --> 00:15:44,000
meisten Clouds kann ich ja für 
wenige Tage einfach ein paar wms

314
00:15:44,000 --> 00:15:45,880
dazu buchen. 
Für meinen Go Life oder für 

315
00:15:45,880 --> 00:15:48,440
meine Marketing Kampagne, weil 
ich es mir eben nicht erlauben 

316
00:15:48,440 --> 00:15:50,800
kann. 
Und am Ende sind wir ja hier 

317
00:15:50,800 --> 00:15:55,360
auch in einem developer Podcast.
Und auch das Thema Load Testing 

318
00:15:55,360 --> 00:15:59,120
hängt so ein bisschen mit der 
Entwicklerzufriedenheit 

319
00:15:59,120 --> 00:16:01,360
zusammen, weil ich glaube 
niemand. 

320
00:16:01,600 --> 00:16:04,720
Niemandem macht es Spaß, 
irgendwie firefighting zu 

321
00:16:04,720 --> 00:16:07,840
betreiben. 
Im Ernstfall dann Logs 

322
00:16:07,840 --> 00:16:10,800
durchzugehen und zu sagen, Hey, 
wo sind jetzt hier die Bottle 

323
00:16:10,800 --> 00:16:13,840
next, weil irgendwo im laufenden
Betrieb die Anwendung 

324
00:16:14,240 --> 00:16:16,720
zusammengebrochen ist. 
Wir in Memory Leaks reinlaufen, 

325
00:16:16,720 --> 00:16:20,320
sondern wir wollen halt uns auf 
die Entwicklung von neuen 

326
00:16:20,320 --> 00:16:24,120
Funktionalitäten konzentrieren 
und da auch als Team möglichst 

327
00:16:24,120 --> 00:16:27,080
effizient arbeiten und nicht 
immer wieder rausgerissen werden

328
00:16:27,080 --> 00:16:30,720
wegen irgendwelchen Problemen in
Produktion und dementsprechend. 

329
00:16:31,040 --> 00:16:34,640
Vorsorgen mit Low Testing, um 
nachher weniger Probleme zu 

330
00:16:34,640 --> 00:16:36,720
haben. 
Und da kommt natürlich das ganze

331
00:16:36,720 --> 00:16:41,000
Thema Integration in den 
Entwicklungsprozess ins Spiel. 

332
00:16:41,000 --> 00:16:43,360
Wir haben nachher noch mal ein 
bisschen mehr Informationen, wie

333
00:16:43,360 --> 00:16:47,200
ich das Ganze dann auch in meine
cicd Pipelines reinbringe, um 

334
00:16:47,200 --> 00:16:50,280
halt auch wirklich regelmäßig 
diese Tests durchführen zu 

335
00:16:50,280 --> 00:16:53,640
können, damit es einfach ein 
integrierter Teil meiner 

336
00:16:53,640 --> 00:16:55,760
Entwicklung ist. 
Es gehört halt einfach dazu, 

337
00:16:55,760 --> 00:16:57,920
dass. 
Dass die Funktionalitäten, die 

338
00:16:57,920 --> 00:17:01,920
ich die Fahr auch entsprechend 
skalierbar sind, so dass ich 

339
00:17:02,160 --> 00:17:04,480
zumindest die Normallast im 
besten Fall auch 

340
00:17:04,480 --> 00:17:07,440
außergewöhnliche Last problemlos
abwickeln kann. 

341
00:17:07,440 --> 00:17:10,839
Ja, das ist doch mal so ein low 
Test bauen, also zumindest 

342
00:17:10,839 --> 00:17:14,720
soweit das hier irgendwie Audio 
only in so einem Podcast möglich

343
00:17:14,720 --> 00:17:16,119
ist. 
Und dafür ist es glaube ich 

344
00:17:16,160 --> 00:17:19,480
wichtig, dass wir uns erstmal so
ein bisschen die Anatomie von so

345
00:17:19,480 --> 00:17:21,200
einem Low Test angucken und so 
ein bisschen die. 

346
00:17:21,640 --> 00:17:25,480
Uns die Konzepte anschauen, da 
wird von Virtual Usern von Rent 

347
00:17:25,480 --> 00:17:29,440
Times gesprochen, von through 
pod, von Test engines und so. 

348
00:17:29,880 --> 00:17:31,520
Deswegen lass uns doch mal kurz 
die Zeit nehmen, da so ein 

349
00:17:31,520 --> 00:17:33,840
bisschen durchzugehen. 
Also es gibt, das ist, glaube 

350
00:17:33,840 --> 00:17:36,480
ich ganz wichtig, es gibt alles,
startet mit so einem virtuellen 

351
00:17:36,480 --> 00:17:39,280
User oder Virtual User, wenn man
es irgendwie in Englisch macht 

352
00:17:39,280 --> 00:17:43,240
und dieser dieser virtuelle 
User, dem gibt man quasi ein 

353
00:17:43,240 --> 00:17:45,760
bestimmtes Verhalten mit, das 
heißt man definiert wie man das 

354
00:17:45,760 --> 00:17:47,560
vielleicht auch bei einem End to
End Test oder sowas machen 

355
00:17:47,560 --> 00:17:49,680
würde, einfach welche Endpunkte 
werden in welcher? 

356
00:17:50,240 --> 00:17:53,080
Reihenfolge aufgerufen in der 
Regel in den meisten Loadtests 

357
00:17:53,080 --> 00:17:55,200
sind es halt eben irgendwelche 
Endpunkte, die über das Web 

358
00:17:55,200 --> 00:17:57,040
aufgerufen werden. 
So ein User muss sich 

359
00:17:57,040 --> 00:17:59,880
wahrscheinlich erst mal 
irgendwie einloggen und ja quasi

360
00:18:00,080 --> 00:18:03,280
seine Credentials gegen den 
Token eintauschen und dann habe 

361
00:18:03,280 --> 00:18:06,960
ich eben diesen User, der der 
eine einzelne Verbindung 

362
00:18:06,960 --> 00:18:09,200
simuliert, warum virtueller User
a? 

363
00:18:09,200 --> 00:18:11,280
Weil es natürlich kein echter 
User ist und b weil wir nachher 

364
00:18:11,280 --> 00:18:13,520
noch so ein bisschen sehen 
werden, dass das innerhalb der 

365
00:18:13,520 --> 00:18:16,120
Infrastruktur auch noch mal 
verteilt wird, da kann ich dann 

366
00:18:16,120 --> 00:18:17,600
mal so Entscheidungen treffen 
wie. 

367
00:18:18,200 --> 00:18:19,800
Kriegt jeder von diesen 
virtuellen Usern wirklich auch 

368
00:18:19,800 --> 00:18:24,160
eine eigene virtuelle Maschine 
oder teilen die sich teilweise 

369
00:18:24,160 --> 00:18:26,080
auch eine virtuelle Maschine? 
Das hat Netzwerktechnik 

370
00:18:26,080 --> 00:18:29,000
natürlich auch Auswirkungen, ob 
die beide über die gleiche IP 

371
00:18:29,000 --> 00:18:31,880
Adresse zum Beispiel auf meinen 
Service zugreifen oder ob die 

372
00:18:31,880 --> 00:18:34,800
Hardware auf der dieser Low Test
dann läuft, vielleicht auch 

373
00:18:34,800 --> 00:18:36,920
irgendwann mein bottle net ist 
und gar nicht mehr genug 

374
00:18:36,920 --> 00:18:39,520
Netzwerk Requests rausschicken 
kann, weil vielleicht. 

375
00:18:39,800 --> 00:18:41,720
Die Netzwerkleitung, wo meine 
Hardware dann angeschlossen ist,

376
00:18:41,720 --> 00:18:42,960
das ist das gar nicht mehr 
hergibt. 

377
00:18:43,200 --> 00:18:45,920
Aber deswegen man wird, wenn man
so Loadtests baut oder sich dann

378
00:18:45,920 --> 00:18:49,120
mit dem Thema informiert 
beschäftigt, immer auf das 

379
00:18:49,120 --> 00:18:51,120
Konzept von virtuellen Nutzern 
stoßen. 

380
00:18:52,000 --> 00:18:55,600
Und wenn wir jetzt hier über die
Nutzer und die Last der Nutzer 

381
00:18:55,600 --> 00:19:00,040
nachdenken, sind es zum einen 
natürlich die ganz menschlichen 

382
00:19:00,040 --> 00:19:02,240
Nutzer, die wir am Ende auf 
unserer Anwendung haben. 

383
00:19:02,240 --> 00:19:04,000
Das sind die Kunden unserer E 
Commerce. 

384
00:19:04,320 --> 00:19:07,680
Webseite oder irgendwelche 
anderen User unserer Apps. 

385
00:19:08,000 --> 00:19:10,640
Aber natürlich muss ich auch 
andere Dinge ein bisschen im 

386
00:19:10,640 --> 00:19:14,480
Hinterkopf haben und das hier in
meinen Tests mit Abbilden. 

387
00:19:14,480 --> 00:19:18,080
Das können dann irgendwelche 
Bots sein, die meine Seite 

388
00:19:18,080 --> 00:19:21,920
parsen, irgendwelche Search 
engine Crawler, die durch meine 

389
00:19:21,920 --> 00:19:24,400
Seite durchgehen und zusätzliche
Last erzeugen. 

390
00:19:24,520 --> 00:19:27,600
Ich habe letztens von einem Fall
gehört, wo auf einer E Commerce 

391
00:19:27,600 --> 00:19:31,120
Seite die jemand in Europa 
aufgesetzt hat, regelmäßig 

392
00:19:31,120 --> 00:19:34,200
irgendwelche Crawler aus Asien 
kamen und den gesamten Wahnsinn.

393
00:19:34,320 --> 00:19:38,880
Katalog Gecrawlt haben. 
Ob das jetzt etwas ist, was 

394
00:19:38,880 --> 00:19:42,760
vielleicht dazu führt, dass ich 
am Ende irgendwie asiatische 

395
00:19:42,760 --> 00:19:46,240
Billigkonkurrenz habe, weiß ich 
nicht, aber mit solchen Dingen 

396
00:19:46,240 --> 00:19:49,920
muss ich rechnen, das heißt, ich
habe nicht nur die menschlichen 

397
00:19:49,920 --> 00:19:54,160
User, sondern ich habe erwartete
und unerwartete Maschinen, User,

398
00:19:54,160 --> 00:19:56,560
die nachher auch auf meine 
Webseite zugreifen, wir hatten 

399
00:19:56,560 --> 00:19:59,840
in der Vergangenheit auch über 
die entsprechenden. 

400
00:20:00,240 --> 00:20:04,160
Agents der ganzen Ki Anbieter 
gesprochen, die irgendwie 

401
00:20:04,160 --> 00:20:07,280
regelmäßig das Webcrawlen und 
auch solche Dinge muss ich 

402
00:20:07,280 --> 00:20:11,440
natürlich für meine Grundlast 
mitberücksichtigen, weil gerade 

403
00:20:11,440 --> 00:20:14,320
in so einer. 
Preproduction Umgebung, wo ich 

404
00:20:14,320 --> 00:20:17,760
das häufig teste, da greifen 
meistens solche Bots ja nicht 

405
00:20:17,760 --> 00:20:19,720
zu. 
Das heißt, ich muss das dann 

406
00:20:19,720 --> 00:20:22,400
natürlich mitberücksichtigen, 
aber wenn wir so einen 

407
00:20:22,400 --> 00:20:25,200
virtuellen User haben, ist das 
tatsächlich meistens eher so das

408
00:20:25,200 --> 00:20:28,560
Äquivalent der Menschen, aber 
das andere kommt natürlich noch 

409
00:20:28,560 --> 00:20:31,040
dazu und das muss ich natürlich 
mitberücksichtigen. 

410
00:20:31,280 --> 00:20:34,000
Ja genau das ist dann natürlich 
auch noch mal ein anderer Case. 

411
00:20:34,000 --> 00:20:36,360
Also das sind beides virtuelle 
User, wenn ich das Halt erlauben

412
00:20:36,360 --> 00:20:39,120
möchte, dass irgendwelche 
Crawler Bots da ist, allein 

413
00:20:39,160 --> 00:20:41,040
schon irgendwie der Google 
Search. 

414
00:20:41,760 --> 00:20:44,600
Indexer, der ab und zu auf meine
Seite kommt, den den will ich ja

415
00:20:44,600 --> 00:20:46,880
wahrscheinlich haben und die 
haben natürlich aber auch noch 

416
00:20:46,880 --> 00:20:48,880
mal ein anderes Nutzerverhalten,
also die werden ja nichts in den

417
00:20:48,880 --> 00:20:52,000
Warenkorb legen oder 
irgendwelche Zahlungsdaten 

418
00:20:52,000 --> 00:20:54,960
angeben, sondern die werden ja 
wahrscheinlich erlesend auf 

419
00:20:54,960 --> 00:20:57,280
meine Anwendung zugreifen und so
habe ich natürlich eben diese 

420
00:20:57,280 --> 00:20:59,360
beiden Pattern, und die muss ich
natürlich auch, wie du richtig 

421
00:20:59,360 --> 00:21:02,080
gesagt hast, beide als virtuelle
User simulieren. 

422
00:21:02,240 --> 00:21:04,800
Dann. 
Schauen wir, was machen die 

423
00:21:04,800 --> 00:21:08,320
virtuellen User auf meiner Seite
und in der Regel ist es nicht 

424
00:21:08,320 --> 00:21:12,480
so, dass User alle gleichzeitig 
von einer Sekunde auf die andere

425
00:21:12,480 --> 00:21:15,720
auf diese Seite gehen, sondern 
die verteilen sich so ein 

426
00:21:15,720 --> 00:21:21,120
bisschen über einen Zeitrahmen 
und wir simulieren so eine 

427
00:21:21,120 --> 00:21:25,760
sogenannte Ramp Up Time, das 
heißt von den ersten Usern oder 

428
00:21:25,760 --> 00:21:30,080
unserer Grundlast bis hinzu der 
erwarteten Spitzenlast. 

429
00:21:30,400 --> 00:21:34,080
Bauen wir das nach und nach auf,
um wirklich auch beobachten zu 

430
00:21:34,080 --> 00:21:38,320
können, wie sich unsere 
Anwendung verhält, während die 

431
00:21:38,320 --> 00:21:41,360
Last langsam ansteigt. 
Das ist insbesondere dann 

432
00:21:41,360 --> 00:21:43,760
interessant, wenn meine 
Anwendung auch automatisch 

433
00:21:43,760 --> 00:21:46,440
skaliert bei einer Anwendung, 
die keine skalierende 

434
00:21:46,440 --> 00:21:49,280
Infrastruktur hat, ist es 
natürlich auch wichtig zu sehen,

435
00:21:49,280 --> 00:21:52,280
wie im Laufe der Zeit sich das 
Verhalten meiner Anwendung 

436
00:21:52,280 --> 00:21:54,200
verändert und ob es dann 
irgendwo vielleicht so einen 

437
00:21:54,200 --> 00:21:58,000
Punkt gibt, wo die Anwendung die
Last nicht mehr bedienen kann, 

438
00:21:58,080 --> 00:22:00,280
aber gerade wenn ich irgendwie 
skalierbare und. 

439
00:22:00,480 --> 00:22:03,280
Komponenten habe. 
Dann ist natürlich wichtig zu 

440
00:22:03,280 --> 00:22:08,800
beobachten, wie während dieser 
Ramp Zeit von meinem ersten User

441
00:22:08,800 --> 00:22:13,120
oder einer Basislast, die ich 
auf der Plattform habe bis zu 

442
00:22:13,120 --> 00:22:17,440
der Maximalanzahl der User, die 
ich konfiguriert habe, wie sich 

443
00:22:17,440 --> 00:22:19,920
das ganze System in diesem 
Zeitraum verhält. 

444
00:22:20,840 --> 00:22:22,880
Genau da denke ich natürlich 
einfach einen realistischen 

445
00:22:23,200 --> 00:22:25,560
Lastwachstum ab. 
Also wenn ich jetzt keine 

446
00:22:25,600 --> 00:22:29,200
Ahnung, ich habe 20 virtuelle 
User und ich mache eine Ramp 

447
00:22:29,200 --> 00:22:33,200
time von 2 Minuten, also von 120
Sekunden, dann würde es 120 

448
00:22:33,200 --> 00:22:35,880
Sekunden dauern bis alle 20 
virtuellen User aktiv sind und 

449
00:22:35,880 --> 00:22:40,640
dann eben diese diese Skripte 
und patterns halt ja Daten 

450
00:22:40,640 --> 00:22:43,840
abzuarbeiten die ich da eben 
definiert habe und das soll eben

451
00:22:43,840 --> 00:22:45,560
eine realistische Last 
darstellen, das kann man auch 

452
00:22:45,560 --> 00:22:47,120
wieder umgekehrt machen, man 
kann auch so eine. 

453
00:22:47,360 --> 00:22:49,840
So eine Ramp down Time machen, 
wo man irgendwie sagt gleich 

454
00:22:49,840 --> 00:22:52,880
gegen Abend hin, wo mehr und 
mehr Leute dann irgendwie meine 

455
00:22:52,880 --> 00:22:56,040
Plattform wieder verlassen, 
skaliert da meine Plattform 

456
00:22:56,040 --> 00:22:57,080
gleich wieder auch richtig 
zurück. 

457
00:22:57,080 --> 00:22:58,800
Also du hast ja gerade schon 
richtigerweise Skalierung 

458
00:22:58,800 --> 00:23:01,120
angesprochen, vielleicht habe 
ich ja keine Ahnung, ich gehe 

459
00:23:01,120 --> 00:23:03,600
davon davon aus, ich mache ein 
kubuliertes Cluster oder sowas, 

460
00:23:04,000 --> 00:23:06,040
wo ich natürlich auch Kosten 
sparen will, wenn abends weniger

461
00:23:06,040 --> 00:23:08,520
Leute auf meiner Plattform ist 
und das heißt auch sowas kann 

462
00:23:08,520 --> 00:23:10,880
ich dann natürlich messen, 
skaliert die Plattform wieder 

463
00:23:10,880 --> 00:23:14,200
anständig zurück mit einem 
Abfall von Usern die ich da 

464
00:23:14,200 --> 00:23:16,640
drauf habe. 
Und dann gehe ich natürlich hin 

465
00:23:16,640 --> 00:23:20,080
und muss schauen, wie verhält 
sich die Anwendung für meine 

466
00:23:20,080 --> 00:23:24,480
virtuellen User, also was sind 
zum Beispiel die Response Times,

467
00:23:24,480 --> 00:23:30,720
also die Antwortzeiten, also wie
lange dauert es, bis ein User 

468
00:23:31,040 --> 00:23:35,960
nach seinem Request seine 
Antwort erhält und du hast es 

469
00:23:35,960 --> 00:23:38,320
gerade angesprochen, irgendwie 
Anwendungen die. 

470
00:23:39,000 --> 00:23:42,800
Lange Response Zeiten haben die 
sind per se so ein bisschen 

471
00:23:42,800 --> 00:23:44,920
fragwürdig für die User in der 
Regel. 

472
00:23:45,040 --> 00:23:47,320
Von daher ist es natürlich 
wichtig, wenn User auf die 

473
00:23:47,320 --> 00:23:51,840
Webseite geht, dass dann 
entsprechend niedrige Response 

474
00:23:51,840 --> 00:23:55,280
Zeiten auch bei hohen User 
zahlen ermöglicht sind. 

475
00:23:56,000 --> 00:23:58,240
Ja, dagegen über steht so ein 
bisschen die Latency, das wird 

476
00:23:58,240 --> 00:24:00,640
auch oft mitgemessen, also 
werden die Response Zeit so ein 

477
00:24:00,640 --> 00:24:03,040
bisschen wie lange braucht denn 
mein Gesamtrequest, also bis der

478
00:24:03,040 --> 00:24:05,840
letzte der letzte Teil der 
Antwort da ist, ist die Latency 

479
00:24:05,840 --> 00:24:09,760
so ein bisschen was ist. 
Wie lange braucht es, bis das 

480
00:24:09,760 --> 00:24:11,560
erste Mal antwortet? 
Das ist vor allem, wenn 

481
00:24:11,560 --> 00:24:14,960
vielleicht Antworten gestreamt 
werden oder sowas relevant bei 

482
00:24:14,960 --> 00:24:16,960
unseren Low Tests haben wir 
jetzt aber in der Regel fast 

483
00:24:16,960 --> 00:24:19,880
immer nur die komplette Response
Time gemessen, also wie lange 

484
00:24:19,880 --> 00:24:22,880
dauert es bis ein request 
vollständig abgearbeitet ist und

485
00:24:22,880 --> 00:24:25,280
wieder da ist, weil wir dadurch 
natürlich auch so ein bisschen 

486
00:24:25,280 --> 00:24:28,160
inkludieren wie lange Rödel das 
Backend. 

487
00:24:29,000 --> 00:24:31,480
An der Antwort also da kannst du
dann halt auch eben so Code, 

488
00:24:31,480 --> 00:24:33,760
Ineffizienzen oder irgendwelche 
Überlastungen des Backends 

489
00:24:33,760 --> 00:24:35,840
besser mit tracken. 
Legacy ist glaube ich eher was, 

490
00:24:35,840 --> 00:24:37,880
was man auch was auf der 
Netzwerkebene relevant ist. 

491
00:24:37,880 --> 00:24:42,160
Also wenn ich da irgendwie mal 
mein Bottleneck vermute, würde 

492
00:24:42,160 --> 00:24:44,040
ich wahrscheinlich eher auf die 
Latency gucken, aber für uns ist

493
00:24:44,040 --> 00:24:49,360
jetzt die Response Time spannend
und ja das alles kombiniert. 

494
00:24:49,720 --> 00:24:51,280
Gibt mir dann eigentlich den 
Three pod. 

495
00:24:51,280 --> 00:24:54,040
Das ist das was ich wissen will.
Also Three pod ist requests per 

496
00:24:54,040 --> 00:24:57,680
second. 
Wie viele von diesen Requests 

497
00:24:57,680 --> 00:25:02,560
kann ich denn wirklich jetzt pro
Sekunde gleichzeitig stellen und

498
00:25:02,560 --> 00:25:06,160
abarbeiten und das ist dann eben
genau das, was halt für mich 

499
00:25:06,160 --> 00:25:08,480
dann am Ende relevant ist. 
Was ich in der Regel auch Messe,

500
00:25:09,440 --> 00:25:12,800
dass ich schaue wieviel wieviel 
Last kann ich denn pro Sekunde 

501
00:25:12,800 --> 00:25:16,160
aushalten, wie viele User 
gleichzeitig können meine 

502
00:25:16,160 --> 00:25:20,080
Anwendung benutzen? 
Letzter Begriff, der häufig 

503
00:25:20,080 --> 00:25:23,360
auftaucht und genannt wird, ist 
die sogenannte Test Engine. 

504
00:25:23,480 --> 00:25:25,800
Das ist die entsprechende 
Infrastruktur, auf der dann 

505
00:25:25,800 --> 00:25:30,600
meine Testskripte ausgeführt 
werden, und im Idealfall ist 

506
00:25:30,600 --> 00:25:32,640
diese auch. 
Weltweit verteilt. 

507
00:25:32,640 --> 00:25:35,520
Wenn ich eine weltweite Userbase
habe oder zumindest über 

508
00:25:35,520 --> 00:25:38,600
verschiedene Standorte im 
gleichen Land im gleichen 

509
00:25:38,600 --> 00:25:43,360
Kontinent, um halt dann halt 
auch realistisches Userverhalten

510
00:25:43,360 --> 00:25:45,440
zu simulieren. 
Das heißt, ich führe das dann 

511
00:25:45,440 --> 00:25:48,200
jetzt nicht von dem gleichen 
Server aus, auf dem irgendwie 

512
00:25:48,200 --> 00:25:50,720
meine Anwendung gehostet wird, 
weil das natürlich kein 

513
00:25:50,880 --> 00:25:54,080
realistisches Szenario ist und 
auch von meiner Clientmaschine 

514
00:25:54,080 --> 00:25:56,920
ich kann natürlich auch diese 
Skripte von meinem Developer 

515
00:25:56,920 --> 00:26:00,160
Client laufen lassen, aber am 
Ende ist das ja auch kein 

516
00:26:00,560 --> 00:26:02,880
realistisches Land. 
Lastverhalten, sondern ich 

517
00:26:02,880 --> 00:26:06,400
sollte das in der Regel über 
vielleicht irgendeinen Low 

518
00:26:06,400 --> 00:26:10,160
Testing Service auf verschiedene
Systeme ausrollen und dann von 

519
00:26:10,160 --> 00:26:14,000
da aus durchspielen und dann die
Metriken wiederum einsammeln. 

520
00:26:14,560 --> 00:26:17,520
Viele der Services, die ich auch
vielleicht als saas Dienst 

521
00:26:17,520 --> 00:26:20,120
nutzen kann, bieten das Out of 
the Box an, ansonsten auch mit 

522
00:26:20,120 --> 00:26:22,960
Open Source Tools kann ich das 
dann selber aufsetzen, indem ich

523
00:26:22,960 --> 00:26:28,240
mir halt einfach. 23 locations 
buche und dann meine Tests halt 

524
00:26:28,240 --> 00:26:32,320
verteilt ausführe und dann 
nachher die Metriken 

525
00:26:32,560 --> 00:26:35,720
zusammenführe. 
Vielleicht bei den Metriken, da 

526
00:26:35,720 --> 00:26:39,280
ist ein paar Erfahrungswerte, 
was sinnvoll ist, wenn man 

527
00:26:39,280 --> 00:26:41,440
erfolgreiches Low Testing machen
möchte. 

528
00:26:42,000 --> 00:26:43,640
Genau das ist ein bisschen der 
nächste Punkt. 

529
00:26:43,640 --> 00:26:45,320
Ich habe das jetzt alles 
aufgesetzt, meine virtuellen 

530
00:26:45,320 --> 00:26:49,240
User laufen los und setzen jetzt
Last auf mein System und. 

531
00:26:49,560 --> 00:26:51,440
Und deswegen ist es wichtig, 
dass man sich natürlich, bevor 

532
00:26:51,440 --> 00:26:53,640
man sich so einen, bevor man so 
einen Test macht, jetzt in den 

533
00:26:53,640 --> 00:26:56,080
Metriken überlegt, die ja, wann 
ist denn so ein Test 

534
00:26:56,080 --> 00:27:01,640
erfolgreich, was ist auch eine 
Failure kriteria und da schaut 

535
00:27:01,640 --> 00:27:04,240
man sich eigentlich so immer die
durchschnittliche Antwortzeit an

536
00:27:04,240 --> 00:27:07,360
und die längste Antwortzeit. 
Aber wichtig hier für eine 

537
00:27:07,600 --> 00:27:09,800
realistische Bewertung würde ich
immer auf die durchschnittliche 

538
00:27:09,800 --> 00:27:15,360
Antwortzeit gucken, also auf das
weiß nicht 90 9599 perzentil. 

539
00:27:17,560 --> 00:27:21,120
Also gucken, wo, wo bewegen sich
denn so 99% meiner Requests, 

540
00:27:21,120 --> 00:27:23,840
weil die Erfahrung hat gezeigt, 
du hast immer mal irgendwie 

541
00:27:23,840 --> 00:27:27,800
einen Ausreißer oder einen 
Netzwerk request irgendwo hängen

542
00:27:27,800 --> 00:27:30,560
geblieben und hat irgendwie 
unerwartet viele Hobbs gemacht. 

543
00:27:30,560 --> 00:27:32,920
Das ist dann ja auch, wenn man 
sich da wirklich da Tausende 

544
00:27:32,920 --> 00:27:34,560
Requests gleichzeitig drauf 
setzt, nicht immer 

545
00:27:34,560 --> 00:27:36,880
aussagekräftig. 
Was war denn der längste, den 

546
00:27:36,880 --> 00:27:38,640
darf ich mir meistens auch 
irgendwie anzeigen, aber ich 

547
00:27:38,640 --> 00:27:42,160
gucke natürlich was an, wie ist 
die Erfahrung für 99% meiner 

548
00:27:42,160 --> 00:27:45,080
User in dieser response Zeit 
und. 

549
00:27:45,080 --> 00:27:46,720
Und darüber hinaus natürlich 
aber auch so ein paar 

550
00:27:46,720 --> 00:27:49,840
Systemressourcen dann von meinen
Systemen, also in meinem Cluster

551
00:27:49,840 --> 00:27:52,160
ist das natürlich gerade so, 
Speicherverbrauch und CPU 

552
00:27:52,160 --> 00:27:55,680
Auslastung, das ist aber auch 
die Netzwerklatenz zwischen 

553
00:27:55,680 --> 00:27:59,080
meinen Systemen, also zwischen 
meinem meinem Backend System und

554
00:27:59,080 --> 00:28:02,480
der Datenbank, oder ich habe 
noch irgendwelche API Gateways 

555
00:28:02,480 --> 00:28:04,480
und so weiter und. 
Und natürlich dann die 

556
00:28:04,480 --> 00:28:07,200
Errorrate. 
Die sollte natürlich relativ 

557
00:28:07,440 --> 00:28:09,560
gering bleiben, das sind 
irgendwelche Errors, die im 

558
00:28:09,560 --> 00:28:11,120
Backend natürlich immer 
auftreten können. 

559
00:28:11,120 --> 00:28:13,440
Kein System ist perfekt, die 
dann auch der User vorne 

560
00:28:13,440 --> 00:28:18,160
mitkriegt, also alles was kein 
200 er Response auf meiner auf 

561
00:28:18,160 --> 00:28:22,560
meinem Rest Layer ist, wo die 
API dann eben irgendwas wie ein 

562
00:28:22,800 --> 00:28:25,760
500 er Fehler oder sowas 
zurückgibt, die will ich 

563
00:28:25,760 --> 00:28:28,800
natürlich gering halten. 
Du hattest gerade schon gesagt, 

564
00:28:28,800 --> 00:28:31,840
wir müssen uns jetzt überlegen, 
wann schlägt unser Low Test 

565
00:28:31,840 --> 00:28:34,080
fehl. 
Natürlich, wie bei allen anderen

566
00:28:34,080 --> 00:28:37,520
Tests, die wir durchführen, 
haben wir so einen Erfolgsfall 

567
00:28:37,520 --> 00:28:40,400
und müssen entsprechend 
reagieren, wenn der Test 

568
00:28:40,400 --> 00:28:41,960
fehlschlägt. 
Und dann sollten wir den 

569
00:28:41,960 --> 00:28:45,040
natürlich nicht fehlschlagen 
lassen, sobald irgendwie nur ein

570
00:28:45,040 --> 00:28:49,200
Fehler auftritt, sondern ich 
muss mir realistische Grenzwerte

571
00:28:49,200 --> 00:28:52,160
setzen, das heißt, ich kann zum 
Beispiel sagen, irgendwie, dass 

572
00:28:52,480 --> 00:28:56,560
95% der Requests bei so und so 
vielen Millisekunden. 

573
00:28:57,240 --> 00:29:00,720
Response Zeit abgehandelt werden
oder ich habe eine bestimmte 

574
00:29:00,720 --> 00:29:05,440
Fehlerrate unter zum Beispiel 
0,5% und dann muss ich mich 

575
00:29:05,520 --> 00:29:07,600
entscheiden, wie viele meiner 
Kriterien müssen fehlschlagen, 

576
00:29:07,600 --> 00:29:12,000
damit der gesamte Test 
fehlschlägt, damit ich natürlich

577
00:29:12,560 --> 00:29:15,520
auch rechtzeitig abbreche und 
hier nicht unnötig Ressourcen 

578
00:29:15,520 --> 00:29:19,560
verschwende und im richtigen 
Zeitpunkt dann auch schauen 

579
00:29:19,560 --> 00:29:22,080
kann. 
Woran hat es gelegen um dann 

580
00:29:22,080 --> 00:29:25,840
auch nachzubessern? 
Woran hattet ihr lehren? 

581
00:29:27,360 --> 00:29:28,880
Ja genau, also wirklich, kann 
ich mal sagen, so. 

582
00:29:28,880 --> 00:29:31,320
Also wir haben so die Werte, die
wir genommen haben, ist so, wir 

583
00:29:31,320 --> 00:29:35,240
haben also diese was du gesagt 
hast, diese Fehlerrate von 0,5%,

584
00:29:35,240 --> 00:29:37,520
die haben wir uns auch so 
gesagt, wir möchten eigentlich 

585
00:29:37,520 --> 00:29:40,640
dass von, dass ich das einer aus
200 Requestern natürlich 

586
00:29:40,640 --> 00:29:43,760
irgendwie auch mal fehlschlagen 
darf, wir. 

587
00:29:46,040 --> 00:29:49,240
Wir haben gesagt, dass wir 95% 
aller Requests immer unter 300 

588
00:29:49,240 --> 00:29:51,000
Millisekunden abgearbeitet haben
wollen. 

589
00:29:51,000 --> 00:29:53,000
Das ist auch so ein bisschen so,
gerade so im Web, so eine 

590
00:29:53,000 --> 00:29:56,560
magische Grenze ab, wo sich das 
noch smooth für so einen 

591
00:29:56,560 --> 00:29:59,440
Menschen anfühlt, so ungefähr so
einer Drittelsekunde, dann muss 

592
00:29:59,440 --> 00:30:02,280
die Antwort da sein, ganz 
wichtig, da wird natürlich jetzt

593
00:30:02,280 --> 00:30:04,280
nicht mit Reinberechnet wie 
lange noch, meine Frontend 

594
00:30:04,280 --> 00:30:06,880
Technologie braucht um da 
irgendwas zu rendern oder sowas,

595
00:30:06,880 --> 00:30:09,280
das ist rein, da werden 
Netzwerkrequests abgesetzt bis 

596
00:30:09,280 --> 00:30:11,680
die Antwort da ist. 
Das haben wir uns 300 als 300 

597
00:30:11,680 --> 00:30:14,880
Millisekunden gesetzt. 
Ich will, dass die CPU Last von 

598
00:30:14,880 --> 00:30:18,240
meinen Systemen eigentlich 
konstant unter 75% ist. 

599
00:30:18,720 --> 00:30:22,400
Wenn sie höher ist, mal ganz 
kurz okay, aber eigentlich, wir 

600
00:30:22,400 --> 00:30:25,120
skalieren schon etwas früher 
hoch, das heißt meine Systeme 

601
00:30:25,120 --> 00:30:28,760
sollen eigentlich nie über 75% 
CPU Last gehen und bei so 

602
00:30:28,760 --> 00:30:32,400
Datenbank Queries haben wir uns 
gesagt, die sollen ja alle, ist 

603
00:30:32,400 --> 00:30:35,760
immer so ein großes Wort, aber 
deswegen ja auch hier 95% dieser

604
00:30:35,760 --> 00:30:38,840
Datenbank queries. 
Sollen unter 100 Millisekunden 

605
00:30:38,840 --> 00:30:42,320
abgearbeitet werden, sodass ich 
200 Millisekunden noch übrig 

606
00:30:42,320 --> 00:30:44,840
habe. 
Für den Netzwerk Layer und für 

607
00:30:44,840 --> 00:30:47,880
den Computer Layer. 
Und bei uns fehlt ein Test. 

608
00:30:47,880 --> 00:30:50,720
Wenn 2 von diesen Metriken 
gleichzeitig gerissen werden. 

609
00:30:50,720 --> 00:30:53,800
Also wenn ich sage. 
Keine Ahnung, ich habe diese 0,5

610
00:30:53,800 --> 00:30:56,320
Fehlerrate vielleicht gehabt, da
habe ich vielleicht 0,6 oder 

611
00:30:56,320 --> 00:30:58,680
sowas gehabt oder vielleicht 
sogar 1%, aber alles andere hat 

612
00:30:58,680 --> 00:31:00,640
irgendwie gepasst. 
Dann würde in unserem Fall der 

613
00:31:00,880 --> 00:31:02,160
Test auch noch auch noch 
erfolgreich sein. 

614
00:31:02,320 --> 00:31:05,000
Man muss sich aber natürlich 
auch Gedanken machen, dass wenn 

615
00:31:05,000 --> 00:31:06,560
ich eine Fehlerrate von 80% 
habe, aber alles andere 

616
00:31:06,560 --> 00:31:09,360
funktioniert, also dieser 
Fehler, dieser Fehler 

617
00:31:09,360 --> 00:31:12,240
ultraschnell zurückkommt, weil 
es vielleicht schon ganz, ganz 

618
00:31:12,240 --> 00:31:13,920
früh in meinem in meinem Stack 
auftritt, dann muss ich 

619
00:31:13,920 --> 00:31:16,240
natürlich trotzdem den den Test 
fehlschlagen lassen, das heißt, 

620
00:31:16,240 --> 00:31:18,840
wir haben für die jeweiligen 
Metriken max wert. 

621
00:31:21,520 --> 00:31:23,920
Der, wenn er alleine 
überschritten wird, schon den 

622
00:31:23,920 --> 00:31:27,760
Test fehlschlagen lässt und halt
so Werte die noch im Ok Bereich 

623
00:31:27,760 --> 00:31:29,120
sind. 
Aber wenn da 2 gleichzeitig über

624
00:31:29,120 --> 00:31:32,800
diesen ok Bereich hinausgehen, 
aber noch nicht den Max Wert 

625
00:31:32,800 --> 00:31:35,400
getroffen haben, dann betrachten
wir den Test auch als 

626
00:31:35,400 --> 00:31:37,240
fehlgeschlagen. 
Aber das ist vielleicht so ein 

627
00:31:37,240 --> 00:31:39,840
bisschen mal so diverse die wir 
da genommen haben, wir halten 

628
00:31:39,840 --> 00:31:42,800
die für Recht realistisch, ihr 
könnt aber auch gerne noch mal 

629
00:31:42,800 --> 00:31:45,520
irgendwie wenn ihr sagt Ey cool,
dann übernehmen wir die auch mal

630
00:31:45,520 --> 00:31:48,240
oder ihr könnt sagen das ist ja 
kompletter Quatsch, da haben wir

631
00:31:48,280 --> 00:31:51,520
eine viel bessere Idee. 
Lasst uns das gerne auch solltet

632
00:31:51,520 --> 00:31:53,760
ihr schon low Tests machen, auch
gerne mal irgendwie in den 

633
00:31:53,760 --> 00:31:56,640
Kommentaren oder so wissen, was 
ihr da für für für Werte nehmt, 

634
00:31:56,880 --> 00:31:58,640
weil das ist so ein bisschen so 
der Heilige Gral. 

635
00:31:58,640 --> 00:32:00,320
Was sind da die Werte die ich 
haben will? 

636
00:32:00,720 --> 00:32:02,640
Wie gesagt, Wir haben gesagt 
unter 300 Millisekunden wollen 

637
00:32:02,640 --> 00:32:04,400
wir 95% aller Requests 
beantworten können und intern 

638
00:32:04,400 --> 00:32:07,680
nicht mehr als 75% CPU Last 
haben und nicht mehr als 0,5% 

639
00:32:07,680 --> 00:32:09,240
Fehler und Datenbank Queries 
unter 100 Millisekunden 

640
00:32:09,240 --> 00:32:15,200
abarbeiten können. 
Und die Sachen, die wir gerade 

641
00:32:15,200 --> 00:32:18,560
durchgesprochen haben, sowohl 
die verschiedenen. 

642
00:32:19,000 --> 00:32:21,920
Parameter wie virtuelle User als
auch die entsprechenden 

643
00:32:21,920 --> 00:32:25,680
Metriken, die ich Messe, die 
konfiguriere ich natürlich in 

644
00:32:25,680 --> 00:32:30,080
einem Load Testing Tool. 
Da gibt es diverse Möglichkeiten

645
00:32:30,080 --> 00:32:32,080
und Tools die ich dann nutzen 
kann. 

646
00:32:32,080 --> 00:32:35,760
Zum einen auf dem Open Source 
Markt, es gibt ganz viele 

647
00:32:36,000 --> 00:32:41,120
Lösungen die ich nutzen kann, 
Beispiele ganz populär Jay Meter

648
00:32:41,520 --> 00:32:45,880
von der Apache Foundation, Wir 
haben gadling, Wir haben Locals,

649
00:32:45,920 --> 00:32:50,240
wir haben k 6 mit. 
Diversen Vor und Nachteilen, so 

650
00:32:50,240 --> 00:32:53,760
wie ich es aus der aus der 
Praxis und vielen Gesprächen 

651
00:32:53,760 --> 00:32:57,560
kenne, ist JM tatsächlich so ein
bisschen die Standard O 2 

652
00:32:57,600 --> 00:33:01,600
Lösung, wenn man das ganze auch 
Open Source Technologiebasierend

653
00:33:01,600 --> 00:33:05,920
selber aufsetzt, unterstützt 
auch diverse Protokolle http web

654
00:33:05,920 --> 00:33:09,520
sockets rest. 
Also was man alles so braucht um

655
00:33:10,240 --> 00:33:13,280
klassische Webanwendungen. 
Testen zu können. 

656
00:33:13,440 --> 00:33:16,960
Es gibt aber, je nachdem welche 
speziellen Anforderungen man 

657
00:33:16,960 --> 00:33:19,600
hat, natürlich dort auch andere 
Möglichkeiten. 

658
00:33:20,240 --> 00:33:23,200
Aber wie gesagt, das so die 
Lösung die man am häufigsten 

659
00:33:23,200 --> 00:33:26,880
sieht. 
Jamieter ist, wie der Name ja 

660
00:33:26,880 --> 00:33:28,560
schon sagt, sehr, sehr Java 
Lastig. 

661
00:33:28,560 --> 00:33:30,400
Deswegen haben wir uns für Locus
entschieden. 

662
00:33:30,400 --> 00:33:33,800
Das ist so ein Python basiertes 
Tool was das ist glaube ich 

663
00:33:33,800 --> 00:33:36,080
nicht ganz so mächtig wie 
Jamieter, aber auch ein bisschen

664
00:33:36,080 --> 00:33:37,560
leicht, viel wichtiger zu 
schreiben, gerade weil wir auch 

665
00:33:37,560 --> 00:33:39,480
irgendwie Leute im Team hatten, 
die sich damit wohlgefühlt 

666
00:33:39,480 --> 00:33:41,360
haben. 
Ich glaube k 6, wie du gerade 

667
00:33:41,360 --> 00:33:45,040
gesagt hast, ist von Graphana, 
das heißt, es hat eine sehr 

668
00:33:45,040 --> 00:33:48,440
coole Integration schon direkt 
in deren Dashboards und freut 

669
00:33:48,440 --> 00:33:50,040
sich gerade noch starker 
Popularität. 

670
00:33:50,040 --> 00:33:52,880
Aber weil wir nirgendwo sonst im
Stack Java hatten, haben wir da 

671
00:33:52,880 --> 00:33:55,680
jetzt von Jamie hinter die 
Finger von gelassen, aber es ist

672
00:33:55,680 --> 00:33:58,040
glaube ich auch glaube ich sagen
auf jeden Fall das populärste, 

673
00:33:58,040 --> 00:34:01,400
so ein bisschen so der Veteran 
unter den Low Testing Tools, der

674
00:34:01,400 --> 00:34:02,960
eigentlich auch so ein bisschen 
alles kann. 

675
00:34:03,120 --> 00:34:06,160
Und diese Open Source Tools, die
muss ich dann natürlich auf 

676
00:34:06,160 --> 00:34:08,080
meine eigene Infrastruktur 
aufsetzen. 

677
00:34:08,080 --> 00:34:09,679
Das heißt, ich brauche 
irgendwelche. 

678
00:34:10,199 --> 00:34:12,400
Virtuellen Maschinen, die 
irgendwo laufen, am besten 

679
00:34:12,400 --> 00:34:14,560
verteilt. 
Wo ich das ganze dann aufsetze 

680
00:34:14,560 --> 00:34:16,800
und da muss ich natürlich auch 
die Kommunikation zwischen 

681
00:34:16,800 --> 00:34:21,360
meinen einzelnen Low Testing 
Agents etablieren und die Daten 

682
00:34:21,600 --> 00:34:24,080
sammeln. 
Das hat natürlich eine gewisse 

683
00:34:24,400 --> 00:34:26,679
technische Komplexität, das 
heißt, da muss ich mich erstmal 

684
00:34:26,679 --> 00:34:29,679
ein bisschen reinarbeiten, muss 
die entsprechende Infrastruktur 

685
00:34:29,679 --> 00:34:33,280
aufsetzen und wenn ich das. 
Nicht möchte, gibt es natürlich 

686
00:34:33,280 --> 00:34:37,280
auch Software Service Lösungen 
die ich da nutzen kann. 

687
00:34:37,280 --> 00:34:41,040
Die gibt es von diversen 
kleineren Firmen oder auch 

688
00:34:41,040 --> 00:34:43,679
natürlich den großen 
Hyperscalern. 

689
00:34:43,679 --> 00:34:47,120
Das heißt, egal ob ich jetzt 
irgendwie auf WS oder Asher oder

690
00:34:47,120 --> 00:34:51,360
Google unterwegs bin, finde ich 
dort eingebaute Low Testing 

691
00:34:51,360 --> 00:34:54,320
Lösungen, die sich natürlich 
optimal in die. 

692
00:34:54,960 --> 00:34:58,240
Eigenen Plattform Services 
integrieren und wo ich dann ein 

693
00:34:58,240 --> 00:35:01,520
super integriertes Monitoring 
habe, der Services aus der Cloud

694
00:35:01,520 --> 00:35:04,600
Plattform selber, wo ich aber 
auch klassisch Anwendungen 

695
00:35:04,600 --> 00:35:08,000
testen kann, die jetzt nicht in 
dieser Infrastruktur gehostet 

696
00:35:08,000 --> 00:35:12,480
werden, wo ich dann einfach die 
Vorteile eines Saar Services 

697
00:35:12,480 --> 00:35:15,280
habe, wo ich nicht eigene 
Infrastruktur aufsetzen muss, 

698
00:35:15,280 --> 00:35:17,760
die Konfiguration 
gegebenenfalls. 

699
00:35:18,320 --> 00:35:22,160
Leichter ist also, da habe ich 
wirklich eine sehr breite 

700
00:35:22,160 --> 00:35:24,240
Auswahl. 
Ich muss auch nicht zu einem der

701
00:35:24,240 --> 00:35:27,840
großen Anbieter geben, da gibt 
es auch andere kleinere Anbieter

702
00:35:28,240 --> 00:35:31,440
mit Liste mal erstellt, wir 
können ein paar Links unten auch

703
00:35:31,440 --> 00:35:33,200
in die Show Notes für euch 
packen. 

704
00:35:33,840 --> 00:35:35,240
Genau. 
Wir haben uns jetzt ist ja 

705
00:35:35,240 --> 00:35:36,640
wahrscheinlich keine 
Überraschung für die, die den 

706
00:35:36,640 --> 00:35:39,200
Podcast hier schon länger hören,
wir haben das Projekt of Azure 

707
00:35:39,200 --> 00:35:42,960
aufgesetzt und da gibt es eben 
Azure App Testing, ich glaube 

708
00:35:42,960 --> 00:35:44,680
das hieß früher Azure Load 
Testing, kann jetzt auch noch 

709
00:35:44,680 --> 00:35:46,600
irgendwie so Frontend sein, 
deswegen haben die das umbenannt

710
00:35:46,800 --> 00:35:48,840
und. 
Da ist natürlich einer der 

711
00:35:48,840 --> 00:35:52,440
großen Vorteile, also A in dem 
Fall werden jetzt auch irgendwie

712
00:35:52,440 --> 00:35:55,800
glaube ich Apache JM und Locus 
als Technologien unterstützt. 

713
00:35:55,800 --> 00:35:58,160
Ich habe ja vorhin gesagt, wir 
haben das Skript in in der locus

714
00:35:58,160 --> 00:36:01,080
Python Sprache geschrieben, wir 
konnten das dann einfach 

715
00:36:01,080 --> 00:36:04,040
hochladen und der zweite große 
Vorteil ist einfach, dass ich 

716
00:36:04,040 --> 00:36:06,720
einfach sagen kann, ey, wenn ich
einen Test ausführe aus dem 

717
00:36:06,720 --> 00:36:08,800
System. 
Dann schalten wir für diesen 

718
00:36:08,800 --> 00:36:11,360
Test eine ddos Protection ab. 
Da kann ich sagen, das ist jetzt

719
00:36:11,360 --> 00:36:14,480
keine ddos Attacke, sondern das 
ist ein low Test den ich mache 

720
00:36:14,640 --> 00:36:16,640
und das musst du sonst, wenn du 
halt irgendwie normalerweise so 

721
00:36:16,640 --> 00:36:20,960
eine ddos Attacken Erkennung 
oder so einen Schutz dazu 

722
00:36:20,960 --> 00:36:23,160
gebucht hast, natürlich dann 
auch extra für diesen Test 

723
00:36:23,160 --> 00:36:24,840
sagen, sonst sieht das natürlich
sehr sehr schnell aus, wenn da 

724
00:36:24,840 --> 00:36:28,040
sehr sehr viele Requests von 3 
bis 4 oder vielleicht auch 100 

725
00:36:28,040 --> 00:36:29,680
ähnlichen virtuellen Maschinen 
kommen. 

726
00:36:30,240 --> 00:36:32,000
Und der zweite Vorteil ist 
natürlich, dass ich da einfach 

727
00:36:32,000 --> 00:36:33,760
anklicken konnte. 
Was hatten wir sonst noch für 

728
00:36:33,760 --> 00:36:36,720
Services in der Azure Cloud, die
Teil von diesem Load Test sind? 

729
00:36:36,720 --> 00:36:39,600
Da wurden mir direkt die 
Grafiken und die die Metriken 

730
00:36:39,600 --> 00:36:44,320
und die die ganzen Logs und so 
was und wird direkt da mit rein 

731
00:36:44,320 --> 00:36:47,040
gestreamt, das war natürlich 
sehr angenehm, wer auf Adobe US 

732
00:36:47,040 --> 00:36:49,760
ist, da gibt es distributed Load
Testing, heißt der heißt der 

733
00:36:49,760 --> 00:36:53,840
Service da der läuft auch über 
mehrere Regionen ist Serverlist 

734
00:36:54,240 --> 00:36:57,360
und Google hat auch das Google 
Cloud Load Testing. 

735
00:36:58,320 --> 00:37:00,520
Stark, stark, koboniert ist 
basiert, kann ich auch noch mal 

736
00:37:00,520 --> 00:37:02,320
ganz speziell Container und 
sowas testen. 

737
00:37:02,320 --> 00:37:04,760
Also es gibt eigentlich in jedem
Hyperscaler sowas, aber malte 

738
00:37:04,760 --> 00:37:06,600
hat ja gerade gesagt, es gibt 
auch noch ganz ganz ganz viele 

739
00:37:06,600 --> 00:37:09,440
andere Tools da draußen, ich 
glaube da kann man noch mal, da 

740
00:37:09,440 --> 00:37:11,600
kann sich ja jeder irgendwie 
noch mal selber einlesen, was es

741
00:37:11,600 --> 00:37:14,160
da nicht alles gibt. 
Dann würde mich am Ende 

742
00:37:14,160 --> 00:37:16,320
interessieren, wie sind so ein 
bisschen so auch eure 

743
00:37:16,320 --> 00:37:20,080
Erfahrungen, wo sind so die 
Punkte, wo du gesagt hast, hey, 

744
00:37:20,080 --> 00:37:23,760
damit hatte ich nicht gerechnet,
insbesondere im Hinblick auf das

745
00:37:23,760 --> 00:37:26,960
ganze Thema Skalierung. 
Ich glaube, du hattest gerade 

746
00:37:26,960 --> 00:37:30,320
gesagt, dass die Anwendung, mit 
der du zu tun hast, auf 

747
00:37:30,320 --> 00:37:34,640
Cobanitis läuft und da auch eine
gewisse Autoskalierung dahinter 

748
00:37:34,640 --> 00:37:37,120
liegt. 
Was sind so deine Erfahrungen 

749
00:37:37,120 --> 00:37:38,880
und vielleicht auch 
Überraschungen, als du jetzt zum

750
00:37:38,880 --> 00:37:42,320
ersten Mal so einen low Test 
ausgeführt hast? 

751
00:37:43,280 --> 00:37:44,760
Überraschend ist natürlich 
immer, dass so eine 

752
00:37:44,760 --> 00:37:46,880
Infrastruktur gar nicht, also 
oft gar nicht so schnell 

753
00:37:46,880 --> 00:37:49,600
skaliert, wie man das sich 
eigentlich vorgestellt hat. 

754
00:37:49,600 --> 00:37:51,840
Also gerade im cobanitis Fall, 
irgendwann ist mein Cluster voll

755
00:37:51,840 --> 00:37:54,560
und dann muss ich eine neue 
virtuelle Maschine dazu buchen. 

756
00:37:55,160 --> 00:37:57,040
Ich sag mal, wenn der Cloud 
Provider schnell ist, dann 

757
00:37:57,040 --> 00:37:59,560
schafft er das in einer oder 2 
Minuten. 

758
00:37:59,560 --> 00:38:02,120
Mir da so eine WM hinzustellen. 
Das ist natürlich viel Zeit in 

759
00:38:02,120 --> 00:38:04,640
so einem Low Test. 
Das heißt ich muss deutlich 

760
00:38:04,640 --> 00:38:06,720
früher schon anfangen 
hochzuscrellen als wir das 

761
00:38:06,720 --> 00:38:09,160
gedacht haben. 
Das andere ist, dass so eine 

762
00:38:09,160 --> 00:38:12,440
Last verteilt, dass dann auch 
manchmal ungleich verteilt ist. 

763
00:38:12,440 --> 00:38:15,840
Das heißt, es kommt natürlich 
erst irgendwo, vielleicht auf 

764
00:38:15,840 --> 00:38:19,240
meiner Q oder in meinem API 
Gateway kommt diese Last an und.

765
00:38:20,080 --> 00:38:22,040
Und da könnte ich ja eigentlich 
schon mal anfangen, wenn ich da 

766
00:38:22,040 --> 00:38:23,760
erhöhte Laster erkenne. 
Meine Datenbank zum Beispiel 

767
00:38:23,760 --> 00:38:26,160
Hochzuskalieren oder meinen 
Cluster hochzuskalieren. 

768
00:38:26,160 --> 00:38:29,520
Also je früher ich irgendwie 
Traffic erkennen kann auf seinem

769
00:38:29,520 --> 00:38:32,360
Weg, da kann ich mir manchmal 
wichtige Sekunden sparen und 

770
00:38:33,280 --> 00:38:35,800
dass sie natürlich nicht alle 
gleich schnell und gleich 

771
00:38:35,800 --> 00:38:39,120
skalieren, gerade wenn es sich 
um irgendwelche SARS oder Pars 

772
00:38:39,120 --> 00:38:41,320
Systeme in der Cloud handelt, 
dann haben die vielleicht auch 

773
00:38:41,320 --> 00:38:42,960
unterschiedliche 
Skalierungsmechanismen 

774
00:38:42,960 --> 00:38:45,360
implementiert und wenn das nicht
einfach alles. 

775
00:38:45,760 --> 00:38:48,280
Vms sind die ich selber 
kontrolliere, dann skalieren die

776
00:38:48,280 --> 00:38:49,600
vielleicht einfach ganz 
unterschiedlich oder 

777
00:38:49,600 --> 00:38:52,160
unterschiedlich schnell oder 
unterschiedlich stark oder in 

778
00:38:52,160 --> 00:38:55,320
unterschiedliche große Pakete 
oder Kosten dann auf einmal 

779
00:38:55,320 --> 00:38:58,040
deutlich viel mehr und sowas 
also gerade in so einem 

780
00:38:58,040 --> 00:39:00,320
verteilten System hängt 
natürlich ganz ganz viel, da 

781
00:39:00,320 --> 00:39:04,880
irgendwie noch noch hinten dran,
was einem dann ja eigentlich 

782
00:39:04,880 --> 00:39:07,200
erst so gewahr wird, deswegen 
ist so ein low Test eigentlich 

783
00:39:07,200 --> 00:39:10,960
so so mächtig, weil es einem das
Halt zeigt. 

784
00:39:11,800 --> 00:39:14,360
Eine zweite Sache, die wir 
gemerkt haben, wo wir relativ 

785
00:39:14,360 --> 00:39:17,920
schnell dann irgendwie hinkamen,
ist ja Moment mal. 

786
00:39:18,800 --> 00:39:22,400
Unser System kann jetzt aber 
halt von 10 Usern gleichzeitig 

787
00:39:22,400 --> 00:39:25,520
1000000 Requests entgegennehmen,
aber wollen wir das überhaupt? 

788
00:39:25,520 --> 00:39:28,240
Sind das also wir müssen uns ja 
eigentlich Gedanken machen. 

789
00:39:28,480 --> 00:39:30,720
Wie? 
Ja, was ist denn so unsere 

790
00:39:30,720 --> 00:39:33,440
Strategie? 
Wie viele Requests erlauben wir 

791
00:39:33,440 --> 00:39:37,480
denn überhaupt pro User oder pro
Crawler, bevor wir irgendwie 

792
00:39:37,480 --> 00:39:40,320
sagen, ey, da ist ja jetzt 
irgendwas nicht mehr in dem 

793
00:39:40,320 --> 00:39:42,560
normalen Nutzerverhalten, du 
hast eben so e Commerce erwähnt,

794
00:39:42,560 --> 00:39:44,960
wenn ich jetzt irgendwie einen 
Shop habe, wo ich sage, da habe 

795
00:39:44,960 --> 00:39:47,680
ich wahrscheinlich so einen 
Klick pro Sekunde, wenn ich mir 

796
00:39:47,680 --> 00:39:49,920
irgendwie so durch die waren 
scrolle, dann klicke ich, ich 

797
00:39:49,920 --> 00:39:52,960
werde aber nicht auf einmal 
10000 Artikel in meinen 

798
00:39:52,960 --> 00:39:55,520
Warenkorb legen. 
Vor allem nicht in einer 

799
00:39:55,520 --> 00:39:57,440
Sekunde, oder? 
Ich werde da nicht irgendwie 500

800
00:39:57,440 --> 00:40:00,080
mal als der gleiche User auf 
bestellen klicken oder sowas. 

801
00:40:00,320 --> 00:40:02,440
Das heißt die zweite Strategie, 
die ich mir eigentlich nach oder

802
00:40:02,440 --> 00:40:04,640
schon vor der Skalierung 
irgendwie Gedanken machen muss 

803
00:40:04,640 --> 00:40:07,160
ist, wann blockiere ich denn 
auch eigentlich irgendwie 

804
00:40:07,160 --> 00:40:08,320
Traffic? 
Du hast ja eben schon mal 

805
00:40:08,320 --> 00:40:10,640
gesagt, vielleicht will ich 
bestimmte Crawler gar nicht 

806
00:40:10,640 --> 00:40:13,360
haben auf meiner Website, die 
blockiere ich dann ganz, aber 

807
00:40:13,360 --> 00:40:15,840
was ist denn vielleicht auch ein
Nutzerverhalten, wo ich ja 

808
00:40:16,200 --> 00:40:19,200
trotteln muss und sage okay du 
darfst. 

809
00:40:19,840 --> 00:40:23,040
Also ein Nutzer mit der gleichen
id oder jedenfalls jemand aus 

810
00:40:23,040 --> 00:40:26,800
der gleichen IP Adresse darf in 
einem gewissen Zeitraum diese 

811
00:40:26,800 --> 00:40:30,880
Aktion maximal x mal ausführen, 
bevor ich ihm sage, Hey beruhigt

812
00:40:30,880 --> 00:40:33,840
dich mal wieder dein Verhalten 
hier scheint gerade nicht normal

813
00:40:33,840 --> 00:40:36,960
zu sein. 
Ja, eigentlich gibt es da 2 

814
00:40:36,960 --> 00:40:40,400
verschiedene Kategorien, einmal 
das Raid Limiting, das heißt ich

815
00:40:40,400 --> 00:40:44,640
habe User oder Boards, die auf 
meine Plattform zugreifen und 

816
00:40:44,640 --> 00:40:47,120
ich erlaube Ihnen nur so und so 
viel request hat es ja gerade 

817
00:40:47,120 --> 00:40:48,880
beschrieben. 
Da gibt es verschiedene 

818
00:40:48,880 --> 00:40:50,760
Strategien, wie man das 
implementieren kann. 

819
00:40:50,760 --> 00:40:53,080
Das wird jetzt nicht im Detail 
drauf eingehen und dann gibt es 

820
00:40:53,080 --> 00:40:56,000
natürlich natürlich die 
Möglichkeit, wann blocke ich 

821
00:40:56,000 --> 00:40:58,880
komplett ab. 
Das natürlich wird es gerade 

822
00:40:58,880 --> 00:41:02,160
gesagt, in Cloud Plattform habe 
ich meistens eine Build in 

823
00:41:02,240 --> 00:41:04,880
Didors Protection, aber in 
bestimmten Fällen muss ich das 

824
00:41:04,880 --> 00:41:07,640
auch einfach selber bauen, ich 
muss erkennen, wenn ich in den 

825
00:41:07,640 --> 00:41:09,760
Bereich komme, der jetzt nicht 
mehr. 

826
00:41:10,880 --> 00:41:13,080
Dem normalen Userverhalten 
entspricht. 

827
00:41:13,080 --> 00:41:15,400
Das kann ich natürlich auch 
simulieren, über so eine Last 

828
00:41:15,400 --> 00:41:19,360
Test Software und dann muss ich 
in meiner Anwendung darauf 

829
00:41:19,360 --> 00:41:22,840
reagieren und dann entsprechend 
request auch einfach abweisen, 

830
00:41:22,840 --> 00:41:25,920
damit meine Anwendung für die 
anderen User weiterhin verfügbar

831
00:41:25,920 --> 00:41:27,680
bleibt. 
Das ist natürlich ganz wichtig 

832
00:41:27,680 --> 00:41:31,040
aus denen am Anfang. 
Genannten Gründen aber natürlich

833
00:41:31,040 --> 00:41:33,520
auch, wenn ich eine Anwendung 
habe, die automatisch skaliert, 

834
00:41:33,600 --> 00:41:36,880
muss ich mir auch überlegen, wie
weit skaliere ich und wann fange

835
00:41:36,880 --> 00:41:39,760
ich halt an, bestimmte 
Mechanismen in Gang zu setzen, 

836
00:41:39,760 --> 00:41:43,440
die halt einfach wirklich auch 
bestimmte Last abblockt, damit 

837
00:41:43,440 --> 00:41:46,000
mir nicht die Kosten aus dem 
Ruder laufen, weil auch wenn ich

838
00:41:46,000 --> 00:41:49,440
irgendwie jetzt die super 
skalierbare Infrastruktur habe, 

839
00:41:50,000 --> 00:41:52,960
weil ich zum Beispiel auf so 
einer Hyperskiller Cloud laufe, 

840
00:41:53,120 --> 00:41:56,240
dann möchte ich da jetzt nicht 
unendlich Geld nachschmeißen, 

841
00:41:56,240 --> 00:42:00,080
nur weil halt irgendwie. 
Gerade einen Crawler über meine 

842
00:42:00,080 --> 00:42:04,080
Seite läuft oder irgendwie eine 
potenzielle ddos Attacke läuft, 

843
00:42:04,720 --> 00:42:08,640
das ist natürlich schon schlimm 
genug für die User, die ich 

844
00:42:08,640 --> 00:42:11,520
bedienen möchte, aber wenn dann 
mir noch durch eine automatische

845
00:42:11,520 --> 00:42:14,160
Skalierung dann die Kosten 
völlig aus dem Ruder laufen, ist

846
00:42:14,160 --> 00:42:17,560
das natürlich der Worst Case. 
Ja genau, also dieses eine, 

847
00:42:17,560 --> 00:42:19,960
dieses Trade limiting, was sie 
da üblicherweise auf so einer 

848
00:42:19,960 --> 00:42:22,560
Netzwerk API Gateway Ebene und 
das andere sind eben die Limits,

849
00:42:22,560 --> 00:42:23,840
die ich mir selber setzen muss. 
Wieviel? 

850
00:42:24,480 --> 00:42:26,840
Server bin ich denn bereit, 
maximal überhaupt da 

851
00:42:26,840 --> 00:42:30,560
hinzustellen in diesen, in 
diesen Lastspitzen? 

852
00:42:30,560 --> 00:42:33,960
Und wenn ich dann was wegblocken
muss, dann muss ich vielleicht 

853
00:42:33,960 --> 00:42:38,160
unterscheiden, vielleicht blocke
ich erstmal allen Traffic, der 

854
00:42:38,160 --> 00:42:40,880
nicht menschlich ist. 
Oder ich kann bestimmte IP oder 

855
00:42:41,200 --> 00:42:43,720
irgendwelche PS oder manche 
Regionen und sowas dann noch mal

856
00:42:43,720 --> 00:42:46,080
wegfiltern, aber das ist glaube 
ich noch mal eine Wissenschaft 

857
00:42:46,080 --> 00:42:47,880
für sich. 
Ein Thema, das wir noch gar 

858
00:42:47,880 --> 00:42:49,600
nicht angesprochen hatten. 
Wir haben jetzt ganz viel 

859
00:42:49,600 --> 00:42:52,960
darüber gesprochen, was Messe 
ich eigentlich? 

860
00:42:53,760 --> 00:42:55,280
Woher kommen eigentlich die 
Informationen? 

861
00:42:55,280 --> 00:42:58,400
Weil ein paar Dinge, die Messe 
ich innerhalb meiner Anwendung, 

862
00:42:58,400 --> 00:43:01,600
innerhalb meiner Infrastruktur 
und andere Dinge Messe ich ja 

863
00:43:01,600 --> 00:43:04,360
von der Clientseite wie habt ihr
das implementiert, um diese 

864
00:43:04,360 --> 00:43:06,800
Informationen an einer Stelle 
zusammenzuführen? 

865
00:43:07,200 --> 00:43:08,880
Ja, wie wir das implementiert, 
ist ein großes Wort. 

866
00:43:08,880 --> 00:43:11,600
Wir haben, wie gesagt einfach 
den Azure App Tasting Service 

867
00:43:11,600 --> 00:43:14,440
benutzt, der Macht das schon für
uns, aber das ist das wichtige 

868
00:43:14,440 --> 00:43:16,720
ist natürlich, dass man dann auf
dieser observability Monitoring 

869
00:43:16,720 --> 00:43:20,240
Seite so die Korrelation erkennt
zwischen. 

870
00:43:21,360 --> 00:43:24,360
Ja, was passiert denn, wenn wenn
so ein Request geht, er über 

871
00:43:24,360 --> 00:43:27,200
ganz, ganz viele Ebenen, der 
kommt über das API Gateway rein,

872
00:43:27,200 --> 00:43:29,520
geht übers Netzwerk, kommt dann 
in ein Backend, dann wird dann 

873
00:43:29,520 --> 00:43:31,280
wird dein Backend vielleicht 
irgendwie über deine Datenbank 

874
00:43:31,280 --> 00:43:33,360
oder mit anderen Services 
sprechen und das Ganze geht 

875
00:43:33,360 --> 00:43:37,360
wieder zurück und dann 
gleichzeitig zu sehen wie wie da

876
00:43:37,360 --> 00:43:42,080
bestimmte bestimmte Werte 
bestimmte True pod Werte 

877
00:43:42,080 --> 00:43:44,480
gleichzeitig ansteigen, sich 
dafür irgendwelche coolen 

878
00:43:44,480 --> 00:43:47,920
Grafiken ausgeben zu lassen und 
das halt alles so übereinander 

879
00:43:47,920 --> 00:43:50,240
zu legen dann. 
Das hat schon irgendwie auch 

880
00:43:50,240 --> 00:43:52,400
Spaß gemacht das das Halt zu 
sehen, dass man wie ganz klar 

881
00:43:52,400 --> 00:43:55,520
sieht, ach guck mal, wir haben 
hier ein Problem, aber an der 

882
00:43:55,520 --> 00:43:57,760
Datenbank kann es nicht liegen, 
die langweilt sich eigentlich 

883
00:43:57,760 --> 00:43:59,640
gerade. 
Ja guck mal am API Gateway liegt

884
00:43:59,640 --> 00:44:01,440
es aber auch nicht, das hat ja 
noch hier lange nicht seine 

885
00:44:01,440 --> 00:44:04,920
Limits erreicht, das dümpelt da 
irgendwie bei 20% CPU rum, ja 

886
00:44:04,920 --> 00:44:07,280
dann muss es das und das sein 
und so und das hat schon Spaß 

887
00:44:07,280 --> 00:44:09,720
gemacht da so ein bisschen dann 
irgendwie auf die Reise zu gehen

888
00:44:09,720 --> 00:44:11,600
und dann das Ganze natürlich 
auch irgendwie diese. 

889
00:44:12,000 --> 00:44:14,240
Durch durch durch Tracing ja 
eigentlich so ein bisschen 

890
00:44:14,240 --> 00:44:16,320
dieses Bottle Neck zu 
identifizieren. 

891
00:44:16,480 --> 00:44:18,400
Was sind denn meine langsamen 
Endpunkte, was kriege ich denn 

892
00:44:18,400 --> 00:44:23,280
überhaupt zurück an an Fehlern, 
bei welchen genauen Endpunkten 

893
00:44:23,280 --> 00:44:25,040
und dann geht man so ein 
bisschen rein und guckt, woran 

894
00:44:25,040 --> 00:44:27,000
kann das denn liegen, kann also 
die Zeitfenster sich so ein 

895
00:44:27,000 --> 00:44:30,880
bisschen schieben, also man ist 
fast schon wieso ein ja wieso 

896
00:44:30,880 --> 00:44:33,160
ein Detektiv dann da unterwegs 
und kann sich die ganzen Sachen 

897
00:44:33,160 --> 00:44:34,680
angucken und kann das Dinge 
ausschließen, das hat schon 

898
00:44:34,680 --> 00:44:37,080
irgendwie Spaß gemacht dieses. 
Deswegen, ich glaube, dieses 

899
00:44:37,080 --> 00:44:40,240
Ergebnis lesen ist schon ein 
wichtiger Skill und natürlich 

900
00:44:40,240 --> 00:44:43,040
auch hilft Monitoring und so 
Observability nachher wieder zu 

901
00:44:43,040 --> 00:44:46,240
erkennen. 
Geht meine Last denn nachher 

902
00:44:46,240 --> 00:44:48,560
wieder auf ein normales Niveau 
runter, also so ein vorher 

903
00:44:48,560 --> 00:44:51,000
nachher vergleich? 
Wie war wieviel CPU und Memory 

904
00:44:51,000 --> 00:44:53,120
habe ich vorher verbraucht und 
jetzt dieser Lasttest vorbei, 

905
00:44:53,120 --> 00:44:55,200
ich bin vielleicht wieder auf 
der ganz normalen Last oder auf 

906
00:44:55,360 --> 00:44:57,960
0 Last ist irgendwas übrig 
geblieben? 

907
00:44:57,960 --> 00:44:59,840
Habe ich da irgendwelche 
Artefakte die da jetzt stehen? 

908
00:44:59,840 --> 00:45:04,000
Ist meine Datenbank jetzt doch? 
Doppelt so voll und wenn ich 

909
00:45:04,000 --> 00:45:06,400
diesen Test jetzt dreimal mache,
ist die ganz voll und stürzt ab.

910
00:45:06,400 --> 00:45:07,760
Und so. 
Also das muss ich natürlich auch

911
00:45:07,760 --> 00:45:11,080
ein bisschen messen und im Auge 
behalten, ob ich da irgendwelche

912
00:45:11,080 --> 00:45:14,440
Artefakte habe, ob irgendwas 
immer voller wird, immer voll 

913
00:45:14,440 --> 00:45:16,400
läuft, wir hatten ganz am Anfang
schon über Memory Leaks und 

914
00:45:16,400 --> 00:45:18,480
sowas gesprochen. 
Das heißt, eigentlich muss ich 

915
00:45:18,480 --> 00:45:21,560
so Tests immer immer wieder 
machen, um zu gucken, ob sich 

916
00:45:21,560 --> 00:45:24,120
die auch irgendwie verändern. 
Im Rahmen meiner, also im Laufe 

917
00:45:24,120 --> 00:45:26,320
meiner Entwicklung. 
Wir hatten vorhin auch gesagt, 

918
00:45:26,320 --> 00:45:29,120
nachdem ich das jetzt irgendwie 
alles aufgesetzt habe und das 

919
00:45:29,120 --> 00:45:32,960
alles funktioniert, soll ich das
natürlich regelmäßig machen, im 

920
00:45:32,960 --> 00:45:37,680
Idealfall irgendwo im Rahmen 
meiner normalen Development 

921
00:45:37,680 --> 00:45:42,480
Pipeline im Cicd. 
Wo ich dann so einen Last Test 

922
00:45:42,480 --> 00:45:44,360
durchführe? 
Ich mache das vielleicht nicht 

923
00:45:44,360 --> 00:45:48,880
bei jedem Pull request, bei 
jedem Verge von irgendwelchen 

924
00:45:48,880 --> 00:45:51,760
Änderungen, aber vielleicht 
immer wenn ich bestimmte 

925
00:45:51,760 --> 00:45:55,400
Releases habe, dann gehe ich auf
eine preport Umgebung in eine 

926
00:45:55,400 --> 00:46:00,560
staging Umgebung, die in. 
Der entsprechenden Skalierung 

927
00:46:00,560 --> 00:46:03,360
meiner Produktionsumgebung 
entspricht und mache dann einen 

928
00:46:03,360 --> 00:46:06,320
Last Test darauf. 
Gerade wenn ich signifikante 

929
00:46:06,320 --> 00:46:08,960
Änderungen in meiner Anwendung 
gemacht habe, die vielleicht 

930
00:46:08,960 --> 00:46:12,200
Auswirkungen auf das ganze 
Anwendungsverhalten unter Last 

931
00:46:12,200 --> 00:46:17,040
habe, dann sollte das ganze 
vollautomatisch durchlaufen, 

932
00:46:17,600 --> 00:46:20,160
wenn ich das nicht erreichen 
kann, kann ich natürlich auch 

933
00:46:20,160 --> 00:46:23,320
regelmäßig manuell so einen Last
Test starten, dann diese 

934
00:46:23,320 --> 00:46:26,480
Informationen rausziehen, aber 
noch besser ist es natürlich, 

935
00:46:26,480 --> 00:46:29,560
dass wenn ich eine. 
Ein neues Release plane das 

936
00:46:29,560 --> 00:46:33,520
Ganze dann automatisch getestet 
wird und nicht nur funktional 

937
00:46:33,520 --> 00:46:36,640
getestet wird, sondern auch 
unter Last getestet wird und ich

938
00:46:36,640 --> 00:46:39,280
dann direkt auch die Rückmeldung
bekomme, wenn es die 

939
00:46:39,280 --> 00:46:43,040
Qualitätskriterien, die wir vor 
ein paar Minuten besprochen 

940
00:46:43,040 --> 00:46:46,240
haben, nicht erfüllt, damit ich 
dann wirklich bevor ich das 

941
00:46:46,240 --> 00:46:50,320
Ganze in Produktion gebe, diese 
Probleme auch beseitigen kann. 

942
00:46:50,720 --> 00:46:52,040
Genau, wir testen komplett im 
QA. 

943
00:46:52,400 --> 00:46:55,760
Wir haben die Philosophie, dass 
unsere Quality Assurance 

944
00:46:55,760 --> 00:46:58,400
Umgebung. 
Genauso aufgebaut ist wie Prot. 

945
00:46:58,560 --> 00:47:01,400
Die ist natürlich nicht ganz so 
teuer wie prot, weil da generell

946
00:47:01,400 --> 00:47:03,600
weniger Last drauf ist. 
Aber bevor bei uns irgendwas in 

947
00:47:03,600 --> 00:47:07,640
Produktion geht, jetzt einmal in
QA, da wird dann ein last Test 

948
00:47:07,640 --> 00:47:09,040
gemacht. 
Wir machen halt jedes Mal wenn 

949
00:47:09,040 --> 00:47:11,720
wir über QA in Protolysen 
sondern Smoke Test, das heißt 

950
00:47:11,720 --> 00:47:14,160
wir machen mal eben kurz einen 
Last Test über so ein paar 

951
00:47:14,160 --> 00:47:16,320
Minuten lang gucken ob sich das 
noch alles so verhält, wie wir 

952
00:47:16,320 --> 00:47:19,480
das erwarten und machen aber 
auch wie du gesagt hast in 

953
00:47:19,480 --> 00:47:22,240
regelmäßigen Abständen die 
großen Last Tests. 

954
00:47:23,360 --> 00:47:26,000
Halt über längere Zeit, aber 
alles in der QA Umgebung. 

955
00:47:26,000 --> 00:47:27,760
Das ist halt vor allem deswegen 
wichtig, dass wir, damit wir 

956
00:47:27,760 --> 00:47:29,600
eben prot. 
Nicht überlasten, dass also das 

957
00:47:29,600 --> 00:47:32,320
nicht in der Produktivumgebung, 
wo wir schon diesen hohen 

958
00:47:32,320 --> 00:47:35,520
Traffic haben, dann noch der 
Lasttest oben drauf kommt und 

959
00:47:35,520 --> 00:47:37,760
wenn der dann nicht 
funktioniert, sondern dann reißt

960
00:47:37,760 --> 00:47:39,680
er ja alles mit runter, auch die
User, die ganz normal auf der 

961
00:47:39,680 --> 00:47:42,400
Plattform sind, deswegen machen 
wir diese Lasttests nie in 

962
00:47:42,400 --> 00:47:45,480
Produktion, sondern immer nur 
auf unserer gleichwertigen QA 

963
00:47:45,600 --> 00:47:48,160
Umgebung, die muss man sich 
natürlich leisten können, gerade

964
00:47:48,160 --> 00:47:50,920
wenn sie gleichwertig ist. 
Aber so haben wir eben das auch 

965
00:47:50,920 --> 00:47:54,240
in unsere Cicd mit Eingebacken. 
Wenn wir Releasen, wird erst auf

966
00:47:54,240 --> 00:47:57,120
QA release, da werden dann alle 
möglichen Quality Tests gemacht 

967
00:47:57,360 --> 00:47:59,720
und einer dieser 
Qualitätskriterien ist eben, 

968
00:47:59,720 --> 00:48:02,160
dass die Anwendung unter Last 
weiterhin so funktioniert, wie 

969
00:48:02,160 --> 00:48:04,800
wir uns das vorstellen. 
Und gerade wenn du die 

970
00:48:04,800 --> 00:48:07,360
Möglichkeit hast, weil du 
irgendwie auf einer Cloud 

971
00:48:07,360 --> 00:48:10,240
Plattform unterwegs bist, kannst
du natürlich diese QA Umgebung 

972
00:48:10,240 --> 00:48:12,560
relativ klein halten. 
Im Normalfall aber wenn du den 

973
00:48:12,560 --> 00:48:14,320
Last Test ausführst, skalierst 
du die. 

974
00:48:14,320 --> 00:48:17,640
Hochskalierbereiche. 
Im gleichen Maße wie bei der 

975
00:48:17,640 --> 00:48:21,160
Produktionsumgebung kannst. 
Einen wichtigen Aspekt, den ich 

976
00:48:21,160 --> 00:48:25,040
noch kurz einwerfen wollte, ist 
halt, wie verhalten sich Third 

977
00:48:25,040 --> 00:48:27,200
Party Services hier bei diesen 
Lasttests. 

978
00:48:27,200 --> 00:48:30,240
Weil heute haben wir häufig 
irgendwelche externen AP is die 

979
00:48:30,400 --> 00:48:33,920
wir nutzen in unserer Anwendung,
das muss ich natürlich auch noch

980
00:48:33,920 --> 00:48:37,840
berücksichtigen, dass die 
natürlich auch entsprechend 

981
00:48:37,840 --> 00:48:40,320
diese Last unserer Lasttests 
abdecken müssen. 

982
00:48:40,440 --> 00:48:43,440
Ich muss halt auch schauen, dass
wenn wir da Kosten entstehen 

983
00:48:43,440 --> 00:48:46,880
durch diese Zugriffe, dass nicht
durch meine Lasttests plötzlich.

984
00:48:47,480 --> 00:48:51,680
Unerwartet hohe Kosten für diese
Third Party Services auch 

985
00:48:51,760 --> 00:48:55,720
entstehen oder ich vielleicht 
sogar durch unnormales 

986
00:48:55,720 --> 00:49:00,320
Nutzungsverhalten dieser AP is, 
was auch immer dort Probleme 

987
00:49:00,320 --> 00:49:03,920
bekomme, dass ich dann irgendwie
selber geblockt werde, das ist 

988
00:49:03,920 --> 00:49:06,880
natürlich auch ein Aspekt. 
Nicht immer habe ich alles unter

989
00:49:06,880 --> 00:49:10,240
Kontrolle, sondern ich habe auch
Komponenten, die außerhalb 

990
00:49:10,240 --> 00:49:13,840
meiner eigenen Einflusssphäre 
liegen und die werden natürlich 

991
00:49:13,840 --> 00:49:17,080
bei so einem Lasttest in der 
Regel mitgetestet, aber ich kann

992
00:49:17,080 --> 00:49:18,960
natürlich. 
Natürlich diese auch gezielt 

993
00:49:18,960 --> 00:49:22,800
ausklammern, indem ich halt 
irgendwelche Mogs dort aufsetze,

994
00:49:23,000 --> 00:49:25,520
wo ich dann nur meinen eigenen 
Anwendungscode teste. 

995
00:49:25,520 --> 00:49:29,600
Aber diese Third Party AP is 
entsprechend in diesen last Test

996
00:49:29,600 --> 00:49:31,760
nur mocke. 
Wobei ich dann nicht so der 

997
00:49:31,760 --> 00:49:34,240
größte Fan davon bin das zu 
mocken, weil das ist ja dann 

998
00:49:34,240 --> 00:49:37,600
geht natürlich auch ein bisschen
weiter weg von der echten 

999
00:49:37,600 --> 00:49:39,760
Realität. 
Bei uns war es aber zum Beispiel

1000
00:49:39,760 --> 00:49:41,960
so, bei uns war genau dieser 
eine Service, wo ich vorhin 

1001
00:49:41,960 --> 00:49:44,720
erzählt habe, der länger dauert,
der redet mit einem Third 

1002
00:49:44,720 --> 00:49:46,800
Partyservice. 
Ja, und da kannst du dann auch 

1003
00:49:46,800 --> 00:49:48,240
einfach manchmal nicht viel 
machen. 

1004
00:49:48,240 --> 00:49:50,840
Ne, vielleicht kannst du gucken,
ob du da auf einen höheren 

1005
00:49:50,840 --> 00:49:53,880
pricing Tier kommst und dann da 
mehr Requests pro Sekunde 

1006
00:49:53,880 --> 00:49:56,520
hinschießen kannst. 
Aber wenn das eben nicht geht 

1007
00:49:56,520 --> 00:49:58,680
und wenn das eben dein Bottle 
neck ist, dann musst du dir halt

1008
00:49:58,680 --> 00:50:00,960
irgendwas überlegen, dann kannst
du das eben nicht mit Geld 

1009
00:50:00,960 --> 00:50:02,160
erschlagen. 
Das Problem. 

1010
00:50:02,560 --> 00:50:04,520
Sondern wir haben zum Beispiel 
ein Cashing eingeführt. 

1011
00:50:04,520 --> 00:50:07,680
Wir haben da jetzt einen Cash 
dazwischen, der, weil wir sehr, 

1012
00:50:07,680 --> 00:50:10,720
sehr viele sehr, sehr ähnliche 
bis hinzu gleiche Requests zum 

1013
00:50:10,720 --> 00:50:13,600
Beispiel hatten, die müssten wir
dann in unserem Fall irgendwie 

1014
00:50:13,600 --> 00:50:16,320
zwischen Cash, oder wir müssen 
uns was Cleveres überlegen auf 

1015
00:50:16,320 --> 00:50:19,320
Code Ebene, wie wir vielleicht 
weniger Requests gegen diesen 

1016
00:50:19,320 --> 00:50:23,280
Third Partyservice schießen, 
aber absolut realistisch, dass 

1017
00:50:23,280 --> 00:50:24,880
das vielleicht am Ende 
rauskommt, du kannst ja alles 

1018
00:50:24,880 --> 00:50:27,280
richtig gemacht haben, aber hast
nicht damit gerechnet, dass die.

1019
00:50:27,880 --> 00:50:30,640
Keiner der Identity Provider, 
den du verwendest oder dein 

1020
00:50:30,640 --> 00:50:32,680
Authentication System, was du 
verwendest oder was auch immer 

1021
00:50:32,680 --> 00:50:35,000
da irgendwie Teil von deinem 
großen Eco System ist. 

1022
00:50:35,120 --> 00:50:37,560
Dein Feature Flex Service, den 
du jedes Mal abfragst, ob der 

1023
00:50:37,560 --> 00:50:39,920
User dieses Feature sehen darf 
und dir vielleicht irgendwann 

1024
00:50:39,920 --> 00:50:41,760
sagt, Hey, sag mal spinnst du 
kannst mich hier nicht 10 mal 

1025
00:50:41,760 --> 00:50:45,920
pro Sekunde pro User Fragen, ob 
der User dieses Feature sehen 

1026
00:50:45,920 --> 00:50:48,720
darf, das kann durchaus sein, 
dass der irgendwas abblockt und 

1027
00:50:48,720 --> 00:50:50,560
dann sehe ich vielleicht auch, 
dass ich irgendwas falsch 

1028
00:50:50,560 --> 00:50:54,200
gemacht habe, dass ich dann ein 
Anti Pattern oder sowas für 

1029
00:50:54,200 --> 00:50:56,360
diesen Surf Body Service genutzt
habe und. 

1030
00:50:56,360 --> 00:50:57,520
Und manchmal kann ich einfach 
nichts machen. 

1031
00:50:57,520 --> 00:50:59,520
Da muss ich mir selber was 
überlegen und dann wie gesagt 

1032
00:50:59,520 --> 00:51:02,560
Cashing ist da wahrscheinlich so
der häufigste Schluss, zu dem 

1033
00:51:02,560 --> 00:51:04,760
man kommt, das haben wir jetzt 
irgendwie gemacht, das heißt, er

1034
00:51:04,760 --> 00:51:07,280
dümpelt jetzt noch irgendwo so 
ein Reddit Cash rum und seitdem 

1035
00:51:07,280 --> 00:51:09,640
haben wir auch wieder sehr viel 
bessere Ergebnisse, natürlich 

1036
00:51:09,640 --> 00:51:11,560
mit dem Nachteil den so ein Cash
auch mit sich bringt, dass 

1037
00:51:11,560 --> 00:51:14,800
vielleicht wir nicht immer top 
aktuelle Werte aus dem Surfparty

1038
00:51:14,800 --> 00:51:16,880
Service rauskriegen, sondern die
zumindest eine Zeit lang Cash 

1039
00:51:16,880 --> 00:51:19,400
und wenn der Surfparty Service 
die ändert, dann wir das 

1040
00:51:19,400 --> 00:51:21,080
vielleicht nicht sofort, sondern
erst nach ein paar Minuten 

1041
00:51:21,080 --> 00:51:23,120
mitbekommen, das war in unserem 
Fall jetzt okay aber. 

1042
00:51:23,640 --> 00:51:26,400
Das sind natürlich so Sachen, wo
man sich auch Gedanken zu machen

1043
00:51:26,400 --> 00:51:28,480
muss. 
Du hattest gerade schon gesagt, 

1044
00:51:28,560 --> 00:51:32,400
Anti Patterns und häufige 
Fehler, die man machen kann. 

1045
00:51:32,400 --> 00:51:34,880
Wir haben natürlich nicht nur 
aus eurer Erfahrung, sondern 

1046
00:51:34,880 --> 00:51:37,040
auch ein bisschen im Internet 
recherchiert, was sind so Dinge,

1047
00:51:37,040 --> 00:51:39,720
die. 
Häufig falsch gemacht werden, 

1048
00:51:39,720 --> 00:51:42,080
wenn man solche Lasttests 
aufsetzt. 

1049
00:51:42,080 --> 00:51:45,360
Und ich meine, das Erste ist 
natürlich, dass man irgendwie 

1050
00:51:45,360 --> 00:51:48,720
nicht realistisch testet, dass 
man zum Beispiel nur einen 

1051
00:51:48,720 --> 00:51:51,360
Endpunkt regelmäßig abfragt oder
vielleicht. 

1052
00:51:51,600 --> 00:51:54,880
Einen slash lasttest so Ding 
Ding Ding. 

1053
00:51:55,360 --> 00:51:57,960
Und das ist natürlich kein 
Lasttest, sondern es ist 

1054
00:51:57,960 --> 00:52:00,000
irgendwie ein 
Verfügbarkeitstest. 

1055
00:52:00,000 --> 00:52:02,840
Also da muss man genau schauen, 
was mache ich da eigentlich und.

1056
00:52:03,120 --> 00:52:07,520
Und natürlich muss ich in dem 
Lastest auch ein realistisches 

1057
00:52:07,600 --> 00:52:11,280
Userverhalten simulieren und 
nicht einfach auf irgendwelche 

1058
00:52:11,280 --> 00:52:15,720
Endpunkte drauf hämmern, die 
halt am Ende von einem realen 

1059
00:52:15,720 --> 00:52:17,920
Nutzer ganz anders genutzt. 
Werden ja die vielleicht einfach

1060
00:52:17,920 --> 00:52:19,480
gecasht werden. 
Also bei uns gehören ja auch 

1061
00:52:19,480 --> 00:52:22,040
super viele Requests, die bei 
uns schon im API GAP gecasht 

1062
00:52:22,040 --> 00:52:23,280
werden, wenn es genau dieselben 
sind. 

1063
00:52:23,280 --> 00:52:25,920
So und dann kannst du mich halt 
300 mal fragen, ob die verfügbar

1064
00:52:25,920 --> 00:52:28,600
sind, wenn ich verfügbar bin. 
Das wird mein Backend oder meine

1065
00:52:28,600 --> 00:52:29,840
Datenbank gar nicht erst 
treffen. 

1066
00:52:30,080 --> 00:52:32,600
Und es gibt halt ganz, ganz 
viele von diesen Sachen, die man

1067
00:52:32,600 --> 00:52:34,200
vermeiden sollte. 
Eine andere Sache ist, dass man 

1068
00:52:34,320 --> 00:52:37,560
kein Rampup macht, wir haben uns
erst mal gefragt, warum, warum 

1069
00:52:37,560 --> 00:52:40,760
machen wir diese rampup Phase, 
dass wir so langsam mehr mehr 

1070
00:52:40,760 --> 00:52:43,320
User drauf haben, ja weil das 
halt realistisch ist, weil du 

1071
00:52:43,320 --> 00:52:45,520
sonst irgendwie falsche Schlüsse
daraus ziehst, dass deine 

1072
00:52:45,520 --> 00:52:48,560
Plattform vielleicht irgendwas 
nicht kann, wo auf einmal von 

1073
00:52:48,880 --> 00:52:51,760
100 Usern auf 10000 usern du 
irgendwie hochskalierst. 

1074
00:52:52,160 --> 00:52:54,320
Ja, kann ich ja sagen, wird sehr
wahrscheinlich deine Skalierung 

1075
00:52:54,320 --> 00:52:56,320
nicht hinterher kommen, ist aber
auch sehr wahrscheinlich 

1076
00:52:56,320 --> 00:53:00,600
unrealistisch und das gleiche 
ist das natürlich auch gerade 

1077
00:53:00,600 --> 00:53:03,840
schon, dass du überhaupt erst 
mal definierst, was willst du 

1078
00:53:03,840 --> 00:53:06,000
denn überhaupt erreichen? 
Also wenn du keine Fail 

1079
00:53:06,000 --> 00:53:09,880
creatoria hast, dann sagst ja 
ja, wir haben jetzt diesen 

1080
00:53:09,880 --> 00:53:12,480
Lasttest gemacht, hat jetzt 
funktioniert, also ich konnte 

1081
00:53:12,480 --> 00:53:14,920
jetzt die Requests abschicken, 
aber was mache ich mit diesen 

1082
00:53:14,920 --> 00:53:17,920
Daten, dass das natürlich 
Quatsch, also ich muss mir da 

1083
00:53:17,920 --> 00:53:21,440
Anfang an Anfang an überlegen. 
Was will ich erreichen und dann 

1084
00:53:21,440 --> 00:53:23,480
auch sagen, dann ist der Test 
erfolgreich und dann ist der 

1085
00:53:23,480 --> 00:53:25,600
Test fehlgeschlagen. 
Und ich meine in dem 

1086
00:53:25,600 --> 00:53:27,600
Zusammenhang, wir hatten vorhin 
darüber gesprochen, muss ich mir

1087
00:53:27,600 --> 00:53:30,600
natürlich auch überlegen, wie 
definiere ich diese einzelnen 

1088
00:53:30,600 --> 00:53:33,120
Metriken und was man da auf 
keinen Fall machen sollte, sind 

1089
00:53:33,120 --> 00:53:36,440
irgendwie Durchschnittswerte 
annehmen, sondern die Best 

1090
00:53:36,440 --> 00:53:40,000
Practices sind da wirklich zu 
definieren, was sind die Werte 

1091
00:53:40,000 --> 00:53:44,400
für 95% meiner User 99% meiner 
User, je nachdem wie man seine 

1092
00:53:44,400 --> 00:53:48,080
Kriterien da angelegt hat und 
nicht jetzt zu sagen, ja im 

1093
00:53:48,080 --> 00:53:49,800
Schnitt passt das schon mit der 
Response. 

1094
00:53:49,920 --> 00:53:53,000
Zeit, aber es geht halt extrem 
weit auseinander und vielleicht 

1095
00:53:53,000 --> 00:53:55,440
die Hälfte meiner User haben 
nicht tolerierbare 

1096
00:53:55,440 --> 00:53:59,440
Antwortzeiten, daher auch ganz 
wichtig, wichtig, wie bereite 

1097
00:53:59,440 --> 00:54:03,440
ich die Daten am Ende auf für 
meine Kriterien, ob der Test 

1098
00:54:03,440 --> 00:54:05,960
fehlschlägt oder nicht und 
natürlich auch innerhalb meiner 

1099
00:54:05,960 --> 00:54:07,880
Dashboards, was schaue ich mir 
dann an? 

1100
00:54:07,880 --> 00:54:09,440
Du hast gerade gesagt, man kann 
dann so. 

1101
00:54:09,880 --> 00:54:12,880
Investigativ da durchgehen, aber
wenn die Informationen, die ich 

1102
00:54:12,880 --> 00:54:16,520
mir da Anzeige irgendwo wertlos 
sind und nicht dem realistischen

1103
00:54:16,520 --> 00:54:19,520
Userverhalten entsprechen, ist 
das natürlich etwas, was ich 

1104
00:54:19,600 --> 00:54:21,360
wenig nutzen kann. 
Genau. 

1105
00:54:21,360 --> 00:54:23,840
Und dann, wenn ich Ergebnisse 
habe, will ich die natürlich 

1106
00:54:23,840 --> 00:54:25,680
versionieren, damit ich die 
vergleichbar mache. 

1107
00:54:25,680 --> 00:54:27,360
Also oft mache ich auch eine 
Last Test um vielleicht eine 

1108
00:54:27,360 --> 00:54:29,600
Änderung in meinem System zu 
validieren, ob es jetzt immer 

1109
00:54:29,600 --> 00:54:32,600
noch gut läuft oder ob ich 
vielleicht auch, vielleicht kann

1110
00:54:32,600 --> 00:54:35,040
ich auch weniger aggressiv 
skalieren um Kosten zu sparen 

1111
00:54:35,040 --> 00:54:36,880
oder auf einen kleineren pricing
Tier gehen. 

1112
00:54:37,520 --> 00:54:40,320
Was hat das für eine Auswirkung 
auf meine Response Zeiten? 

1113
00:54:40,320 --> 00:54:42,080
So und deswegen muss ich 
natürlich Ergebnisse 

1114
00:54:42,080 --> 00:54:45,520
vergleichbar machen miteinander 
ja so ein bisschen der letzte 

1115
00:54:45,520 --> 00:54:48,360
Tipp, das hatte ich ja vorhin 
schon mal gesagt, nicht einfach 

1116
00:54:48,360 --> 00:54:51,120
gegen Produktion testen, 
zumindest nicht ohne Abstimmung,

1117
00:54:51,360 --> 00:54:53,800
sondern am besten irgendwie eine
eigene Umgebung haben, in der 

1118
00:54:53,800 --> 00:54:58,120
man testet und natürlich 
irgendwie auch irgendwann sich 

1119
00:54:58,120 --> 00:55:00,000
Gedanken darüber machen, welchen
Traffic will man eigentlich 

1120
00:55:00,000 --> 00:55:03,600
haben, so wie Wait Limits und so
was mit einführen. 

1121
00:55:04,200 --> 00:55:06,240
Das sind, glaube ich, so die 
besten Tipps, die man jetzt mal 

1122
00:55:06,240 --> 00:55:07,560
machen kann. 
Und ich glaube, damit und mit 

1123
00:55:07,560 --> 00:55:09,840
den Ressourcen, die wir noch 
zusätzlich unten in den in den 

1124
00:55:09,840 --> 00:55:12,960
Shownotes verlinken werden, kann
man glaube ich erstmal starten 

1125
00:55:12,960 --> 00:55:14,720
und ich kann nur sagen, uns hat 
das sehr viel Spaß gemacht, 

1126
00:55:14,720 --> 00:55:18,080
diese Lasttests irgendwie 
einzuführen und es ist schon 

1127
00:55:18,160 --> 00:55:20,160
sehr faszinierend zu sehen, wie 
die eigene Anbindung, der sich 

1128
00:55:20,160 --> 00:55:23,520
da verhält und dann auch auf 
Fehlersuche zu gehen, das war 

1129
00:55:23,520 --> 00:55:25,800
schon cool, und das ist auch 
irgendwie Teil der regelmäßigen 

1130
00:55:25,800 --> 00:55:28,640
Crcd Pipeline zu haben. 
Ich bin sehr happy damit, dass 

1131
00:55:28,640 --> 00:55:30,640
wir das gemacht haben und wie 
wir das gemacht haben und. 

1132
00:55:31,800 --> 00:55:35,440
Ich glaube, ein cooles Projekt. 
Super und wir hoffen auch, dass 

1133
00:55:35,520 --> 00:55:38,160
euch das weiter gebracht hat, 
dass wir das Thema heute 

1134
00:55:38,160 --> 00:55:40,640
intensiv diskutiert haben. 
Ich glaube, es war eine relativ 

1135
00:55:40,720 --> 00:55:44,800
lange Folge, aber durchaus super
spannend, ich habe auch viel von

1136
00:55:44,800 --> 00:55:48,320
Dir gelernt aus deiner 
Praxiserfahrung und wenn auch 

1137
00:55:48,320 --> 00:55:51,520
euch das ganze weiter gebracht 
hat, dann lasst uns gerne auch 

1138
00:55:51,520 --> 00:55:54,520
für diese Folge oder allgemein 
für den Podcast eine positive 

1139
00:55:54,520 --> 00:55:57,440
Bewertung da, das könnt ihr auf 
den üblichen Plattformen. 

1140
00:55:57,880 --> 00:56:00,920
Apple Podcast, Spotify oder auch
über Youtube machen. 

1141
00:56:00,920 --> 00:56:02,200
Da freuen wir uns natürlich 
sehr. 

1142
00:56:02,200 --> 00:56:04,080
Und wo wir uns natürlich auch 
sehr darüber freuen, ist, wenn 

1143
00:56:04,080 --> 00:56:07,920
ihr genauso cool sein wollt wie 
Julia oder der Sebastian und uns

1144
00:56:07,920 --> 00:56:10,320
einen Kaffee dalassen wollt für 
den Podcast. 

1145
00:56:10,560 --> 00:56:13,880
Da gibt es unter der Folge in 
der Beschreibung auch immer 

1146
00:56:13,880 --> 00:56:16,160
einen Link zu bei mir Coffee, da
könnt ihr uns einen Kaffee 

1147
00:56:16,160 --> 00:56:18,640
ausgeben. 
Da freuen wir uns immer sehr. 

1148
00:56:18,640 --> 00:56:20,320
Oder wenn ihr vielleicht zu 
eurem eigenen Kaffee die 

1149
00:56:20,320 --> 00:56:23,720
passende Gebrandete Nerd Tasse 
haben wollt, schaut euch gerne 

1150
00:56:23,720 --> 00:56:26,440
in unserem kleinen Shop vorbei. 
Links zu allem findet ihr wie 

1151
00:56:26,440 --> 00:56:28,800
immer in der Beschreibung. 
Und ansonsten freuen wir uns, 

1152
00:56:28,800 --> 00:56:30,800
wenn ihr auch nächste Woche 
wieder mit dabei seid. 

1153
00:56:30,800 --> 00:56:33,680
Beim to do Developer Podcast. 
Wir machen immer abwechselnd 

1154
00:56:33,680 --> 00:56:37,920
eine Folge, wo wir die aktuellen
Developer News zusammentragen 

1155
00:56:37,920 --> 00:56:42,720
und eine Themenfolge wie diese 
Woche und dementsprechend freuen

1156
00:56:42,720 --> 00:56:45,520
wir uns, wenn ihr uns treu 
bleibt, falls ihr noch nicht 

1157
00:56:45,520 --> 00:56:47,320
abonniert habt, macht das am 
besten. 

1158
00:56:47,520 --> 00:56:49,280
Genau jetzt. 
Damit ihr auch am nächsten 

1159
00:56:49,280 --> 00:56:50,960
Montag die News Folge 
mitbekommt. 

1160
00:56:51,200 --> 00:56:53,200
So, jetzt aber Schluss. 
Ist schon eine viel zu lange 

1161
00:56:53,200 --> 00:56:54,920
Folge geworden. 
Wir wünschen euch eine gute 

1162
00:56:54,920 --> 00:56:57,560
Woche bis zum nächsten Mal. 
Macht's gut, schreibt viel Code,

1163
00:56:57,560 --> 00:57:00,320
testet viel, vor allem 
Unterlasst und bis nächsten 

1164
00:57:00,320 --> 00:57:02,160
Montag ciao. 
Bis dahin.