IBM E02HMLL-I Implementation Guide - Page 291

Performance, tuning

Page 291 highlights

Chapter 14. Performance tuning This chapter describes how to implement various techniques and configurations to improve system performance. It contains the following sections: v "Implementing concurrent processing of event-triggered flows" v "Caching static relationships" on page 281 v "Using database connection pools" on page 281 v "Using the memory checker thread" on page 281 Implementing concurrent processing of event-triggered flows You can configure collaboration objects and connector controllers to process multiple event-triggered flows at the same time. This can significantly improve the performance for event-triggered interfaces. Concurrent event-triggered flow processing in Collaborations Collaborations can be configured to process multiple event-triggered flows concurrently. System throughput and response time to event processing improve when concurrent event processing is properly used (see tip below). By default, a collaboration processes one event-triggered flow at a time. When a collaboration is processing concurrent event-triggered flows, the collaboration identifies dependencies among those flows and processes them in the order that they were sent from the connector controller. Concurrent processing of event-triggered flows is performed on flows that do not have data conflicts, while flows with data conflicts are processed in the order received. To configure a collaboration to handle multiple event-triggered flows, see "Maximum number of concurrent events" on page 167. Tip: Concurrent processing of event-triggered flows in collaborations requires additional system resources. To maximize performance, ensure that system resources used to handle concurrent events are not idle. For example, do not set the value for the Maximum number of concurrent events to 10 if the number of events in the collaboration queue never reaches 10. If a collaboration's inbound ports are bound only to receive external calls through the Server Access Interface, and are not bound to any connectors, you can improve performance by setting the value of Maximum number of concurrent events to zero. But do not set this value to zero if the collaboration is being used for bidirectional exchanges with connectors. Concurrent event-triggered flow processing in collaboration-object groups Each collaboration in a collaboration-object group can be configured independently for processing a number of concurrent event-triggered flows. It is recommended that you set the same value for the number of concurrent event-triggered flows for all of the collaborations in a group, so that a collaboration with a low concurrency rate does not become a bottleneck. © Copyright IBM Corp. 2001, 2004 279

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46
  • 47
  • 48
  • 49
  • 50
  • 51
  • 52
  • 53
  • 54
  • 55
  • 56
  • 57
  • 58
  • 59
  • 60
  • 61
  • 62
  • 63
  • 64
  • 65
  • 66
  • 67
  • 68
  • 69
  • 70
  • 71
  • 72
  • 73
  • 74
  • 75
  • 76
  • 77
  • 78
  • 79
  • 80
  • 81
  • 82
  • 83
  • 84
  • 85
  • 86
  • 87
  • 88
  • 89
  • 90
  • 91
  • 92
  • 93
  • 94
  • 95
  • 96
  • 97
  • 98
  • 99
  • 100
  • 101
  • 102
  • 103
  • 104
  • 105
  • 106
  • 107
  • 108
  • 109
  • 110
  • 111
  • 112
  • 113
  • 114
  • 115
  • 116
  • 117
  • 118
  • 119
  • 120
  • 121
  • 122
  • 123
  • 124
  • 125
  • 126
  • 127
  • 128
  • 129
  • 130
  • 131
  • 132
  • 133
  • 134
  • 135
  • 136
  • 137
  • 138
  • 139
  • 140
  • 141
  • 142
  • 143
  • 144
  • 145
  • 146
  • 147
  • 148
  • 149
  • 150
  • 151
  • 152
  • 153
  • 154
  • 155
  • 156
  • 157
  • 158
  • 159
  • 160
  • 161
  • 162
  • 163
  • 164
  • 165
  • 166
  • 167
  • 168
  • 169
  • 170
  • 171
  • 172
  • 173
  • 174
  • 175
  • 176
  • 177
  • 178
  • 179
  • 180
  • 181
  • 182
  • 183
  • 184
  • 185
  • 186
  • 187
  • 188
  • 189
  • 190
  • 191
  • 192
  • 193
  • 194
  • 195
  • 196
  • 197
  • 198
  • 199
  • 200
  • 201
  • 202
  • 203
  • 204
  • 205
  • 206
  • 207
  • 208
  • 209
  • 210
  • 211
  • 212
  • 213
  • 214
  • 215
  • 216
  • 217
  • 218
  • 219
  • 220
  • 221
  • 222
  • 223
  • 224
  • 225
  • 226
  • 227
  • 228
  • 229
  • 230
  • 231
  • 232
  • 233
  • 234
  • 235
  • 236
  • 237
  • 238
  • 239
  • 240
  • 241
  • 242
  • 243
  • 244
  • 245
  • 246
  • 247
  • 248
  • 249
  • 250
  • 251
  • 252
  • 253
  • 254
  • 255
  • 256
  • 257
  • 258
  • 259
  • 260
  • 261
  • 262
  • 263
  • 264
  • 265
  • 266
  • 267
  • 268
  • 269
  • 270
  • 271
  • 272
  • 273
  • 274
  • 275
  • 276
  • 277
  • 278
  • 279
  • 280
  • 281
  • 282
  • 283
  • 284
  • 285
  • 286
  • 287
  • 288
  • 289
  • 290
  • 291
  • 292
  • 293
  • 294
  • 295
  • 296
  • 297
  • 298
  • 299
  • 300
  • 301
  • 302

Chapter
14.
Performance
tuning
This
chapter
describes
how
to
implement
various
techniques
and
configurations
to
improve
system
performance.
It
contains
the
following
sections:
v
“Implementing
concurrent
processing
of
event-triggered
flows”
v
“Caching
static
relationships”
on
page
281
v
“Using
database
connection
pools”
on
page
281
v
“Using
the
memory
checker
thread”
on
page
281
Implementing
concurrent
processing
of
event-triggered
flows
You
can
configure
collaboration
objects
and
connector
controllers
to
process
multiple
event-triggered
flows
at
the
same
time.
This
can
significantly
improve
the
performance
for
event-triggered
interfaces.
Concurrent
event-triggered
flow
processing
in
Collaborations
Collaborations
can
be
configured
to
process
multiple
event-triggered
flows
concurrently.
System
throughput
and
response
time
to
event
processing
improve
when
concurrent
event
processing
is
properly
used
(see
tip
below).
By
default,
a
collaboration
processes
one
event-triggered
flow
at
a
time.
When
a
collaboration
is
processing
concurrent
event-triggered
flows,
the
collaboration
identifies
dependencies
among
those
flows
and
processes
them
in
the
order
that
they
were
sent
from
the
connector
controller.
Concurrent
processing
of
event-triggered
flows
is
performed
on
flows
that
do
not
have
data
conflicts,
while
flows
with
data
conflicts
are
processed
in
the
order
received.
To
configure
a
collaboration
to
handle
multiple
event-triggered
flows,
see
“Maximum
number
of
concurrent
events”
on
page
167.
Tip:
Concurrent
processing
of
event-triggered
flows
in
collaborations
requires
additional
system
resources.
To
maximize
performance,
ensure
that
system
resources
used
to
handle
concurrent
events
are
not
idle.
For
example,
do
not
set
the
value
for
the
Maximum
number
of
concurrent
events
to
10
if
the
number
of
events
in
the
collaboration
queue
never
reaches
10.
If
a
collaboration’s
inbound
ports
are
bound
only
to
receive
external
calls
through
the
Server
Access
Interface,
and
are
not
bound
to
any
connectors,
you
can
improve
performance
by
setting
the
value
of
Maximum
number
of
concurrent
events
to
zero.
But
do
not
set
this
value
to
zero
if
the
collaboration
is
being
used
for
bidirectional
exchanges
with
connectors.
Concurrent
event-triggered
flow
processing
in
collaboration-object
groups
Each
collaboration
in
a
collaboration-object
group
can
be
configured
independently
for
processing
a
number
of
concurrent
event-triggered
flows.
It
is
recommended
that
you
set
the
same
value
for
the
number
of
concurrent
event-triggered
flows
for
all
of
the
collaborations
in
a
group,
so
that
a
collaboration
with
a
low
concurrency
rate
does
not
become
a
bottleneck.
©
Copyright
IBM
Corp.
2001,
2004
279