This presentation shows why and how to use DataGate connection pooling with your AVR Web applications. With effective connection pooling your apps will run much faster and your IBM i will have a much reduced workload.
Using connection pooling for better AVR Web performance
1. ASNApalooza2007ASNApalooza2007
by Roger Pence
ASNA Education Director
Maximum velocity: How to get theMaximum velocity: How to get the
most performance from your AVRmost performance from your AVR
appsapps
Paying attention to just a few details
can make your programs faster and
more efficient
1
4. ASNApalooza2007ASNApalooza2007
What is connection pooling?What is connection pooling?
• Connection pooling is DataGate’s ability to
“reuse” database server jobs between
stateless IO requests
• Connection pooling applies mostly to stateless
Web applications or Web services.
• Rarely is connection pooling helpful to
Windows-based programs
– It’s not likely to hurt anything, but connection
pooling is especially suited for stateless apps
5. ASNApalooza2007ASNApalooza2007
Connection pooling: the System iConnection pooling: the System i
• Effective connection pooling is especially
important if the System i is your database
platform
• Without connection pooling, a new OS/400 job
must be created for each request. This can take
3-10 seconds—depending on System i load and
configuration
• With connection pooling, an OS/400 job is made
available to a request in a matter of milliseconds
6. ASNApalooza2007ASNApalooza2007
Connection pooling: SQL ServerConnection pooling: SQL Server
• Although instancing a database connection isn’t
quite the performance drain on SQL Server that it
is on the System i, it’s still a drain
• It may also positively effect SQL Server licensing
– Because you are in effect also pooling licensing (for
CAL-based licenses)
– Connection pooling keeps any one connection is play
for the minimum amount of time
• This discussion is primarily System i-centric, but
everything said here about connection pooling
also applies to DataGate for SQL Server
7. ASNApalooza2007ASNApalooza2007
Enabling connection poolingEnabling connection pooling
• Connection pooling can be enabled statically
through database name attributes
• Or set dynamically through changing the
database object’s PoolingTimeOut property
prior to connecting that object
9. ASNApalooza2007ASNApalooza2007
Enabling connection poolingEnabling connection pooling
dynamicallydynamically
• Connection pooling can also be controlled by
setting the database object’s PoolingTimeout
value.
• Any value greater than zero sets the connection
pooling timeout value (in minutes); zero disables
connection pooling
10. ASNApalooza2007ASNApalooza2007
What’s a good time-out value?What’s a good time-out value?
• That depends.
• For many shops, something in the range of 20
minutes or so works well
• However, we have customers that use much
larger values if the latency between pages is
extreme
– Shop floor browser-based applications for
example
11. ASNApalooza2007ASNApalooza2007
How does connection pooling it work?How does connection pooling it work?
• Red zone= inactive pooled jobs
• Green zone = active jobs
• At this point, application has no jobs pooled
12. ASNApalooza2007ASNApalooza2007
Blue and pink: cool and warmBlue and pink: cool and warm
• For purposes of this discussion:
– Blue users get new, previously unpooled jobs.
These uses wait 3-7 seconds for their page.
– Blue jobs are new, previously unpooled jobs.
– Pink users get a pooled job. These users wait just
a few milliseconds for their page.
– Pink jobs are previously pooled jobs.
Think of it this way, blue users/jobs are cool;
pink users/jobs are warm!
13. ASNApalooza2007ASNApalooza2007
A user request occursA user request occurs
• DataGate first looks in the red job zone for a
previously pooled job. There isn’t one. DataGate
starts a new one.
14. ASNApalooza2007ASNApalooza2007
The job is now pooledThe job is now pooled
• When the server is done servicing the user’s request,
the job is “moved” to the pooled zone
• Pooled jobs have no open files, no activity, and
consume very few OS/400 resources
16. ASNApalooza2007ASNApalooza2007
The job is put back in the poolThe job is put back in the pool
• When the server is done servicing the user’s request,
the job is “moved” to the pooled zone again
17. ASNApalooza2007ASNApalooza2007
Two users request a page within 1 MSTwo users request a page within 1 MS
of each otherof each other
• The first user gets the previously pooled job
• The second user has to wait for OS/400 to create a
new job
19. ASNApalooza2007ASNApalooza2007
Three users request a page within aThree users request a page within a
couple of MS of each othercouple of MS of each other
• Two user get a pooled job; the third user waits for a new job
• For most Web apps, jobs aren’t unique to a user, so the two
pooled jobs are avaiable to the first two users—independent
of who previously used the two pooled jobs
20. ASNApalooza2007ASNApalooza2007
Now three jobs are pooledNow three jobs are pooled
• The inactive job pool is now somewhat populated
• Lots of users can come and go through these
three jobs
21. ASNApalooza2007ASNApalooza2007
The benefit of a populated pooledThe benefit of a populated pooled
zonezone
• As the pooled zone gets populated, it less
likely that new jobs will be needed
• After get five or six pooled, what are the
chances that five or six users will each request
a page within a few hundred or so
milliseconds of each other?
• Of course, it could happen. And if it does, a
new job is added and the pooled zone grows
by one
22. ASNApalooza2007ASNApalooza2007
20 or 30 to one!20 or 30 to one!
• ASNA benchmarks show that you can expect
at least 20 or 30 users able to do “normal”
work using a single pooled job
• As the load grows, so grows the pooled zone
• But pooled jobs have a very low impact on the
System i
22
Lots of users busy with few jobs
23. ASNApalooza2007ASNApalooza2007
How does the pooled zone get clearedHow does the pooled zone get cleared
outout
• By job timeout value
– First in, first out
• For example with no activity, a job drops out of the
pooled zone when its timeout value expires
24. ASNApalooza2007ASNApalooza2007
How to tell if it’s workingHow to tell if it’s working
• Performance is a very good way to tell if
connection pooling is working
• However, another wau to ensure it’s working
is to test you’re app, through several pages,
knowing only one user is using it
• If, after using the app for a while you have
more than one OS/400 job active, something
is amiss
24
25. Something is wrong here!
There are three jobs for a
application with a single user!
26. ASNApalooza2007ASNApalooza2007
Something else to watch forSomething else to watch for
• It’s possible to be using connection pooling
correctly and still get more than one job active
• This can happen when a Web page uses one
or more secondary classes where each of
which establishes its own DB connection
• This topic is out of the scope of this
presentation, but if you think this is happening
to you, ask me offline for a copy of the
Singleton DB pattern explanation
26
27. ASNApalooza2007ASNApalooza2007
The rules of connection poolingThe rules of connection pooling
• Enable it either statically or dynamically
• The next point is very important!
• Each page must following this cycle:
– Connect the DB
– Open files
– Do work
– Close files
– Disconnect the DB
27
28. ASNApalooza2007ASNApalooza2007
Your app must disconnect for everyYour app must disconnect for every
page!page!
• A job gets moved back to the pooled zone
when it’s disconnect
• If you don’t disconnect, you aren’t pooling
jobs!
• The Page’s Unload event is a good place to put
your closes and disconnect
28
30. ASNApalooza2007ASNApalooza2007
Don’t forget to close files!Don’t forget to close files!
• If you disconnect but don’t close files, you
cause lots of files
to be opened!
• Close *All
• then disconnect
30
31. ASNApalooza2007ASNApalooza2007
Remember this!Remember this!
• If you don’t close files and disconnect the DB
object before the page goes out of scope, you
are not using connection pooling!
• The same advice applies to Web methods.
Close files and disconnect the DB after every
Web method call
31
32. ASNApalooza2007ASNApalooza2007
Your app must disconnect for everyYour app must disconnect for every
page!page!
• A job gets moved back to the pooled zone
when it’s disconnected
• If you don’t disconnect, it’s an orphan active
job
32
33. ASNApalooza2007ASNApalooza2007
Pooled connection scopePooled connection scope
• Pooled connections are uniquely identified by
all of the properties of a database name.
• Thus, if each user is signing on to your Web
app with her user profile and password, you
are negating the scalable benefits of
connection pooling
– You are however, letting users get their jobs back
quickly
33
34. ASNApalooza2007ASNApalooza2007
Pooled connection scopePooled connection scope
• Some shops can’t use a single database name
for all users (ie, a single user ID and
password). Thanks SOX.
• Consider using three or database names to
group users (perhaps by security or function)
• This way you’re at least getting some
scalability by letting each group share pooled
jobs
34
35. ASNApalooza2007ASNApalooza2007
Limiting database platform jobsLimiting database platform jobs
• When you instance a class that has a DB
object, and that class connects, that class gets
its own job on the database platform
• This means that it’s very easy for any one
program (Windows or Web) to have several
jobs in play for that one program
• This… is not good!
35
37. ASNApalooza2007ASNApalooza2007
An example with two classesAn example with two classes
• Two classes, two DBs, two connects = two jobs
37
This is especially
troubling on the
System i.
Scalability goes
out the window
if you aren’t
careful!
38. ASNApalooza2007ASNApalooza2007
The solution: the singleton DB patternThe solution: the singleton DB pattern
• A parent class
passes its job
to its children,
the children to
their children
• Results in just
one job for the
instance of the
program
38
40. 40
To limit the database platform one job, the parent
class needs to pass its DB object around to its
children (and them to their children if they have any.
41. ASNApalooza2007ASNApalooza2007
There are just a few rulesThere are just a few rules
• The parent, top level class, must pass its DB
object on
• The parent must disconnect the DB
• Child can never disconnect
– Others might want the job
• Children can connection the DB, but should
check to see if it needs to be
– Others might have previously connected it
41
42. ASNApalooza2007ASNApalooza2007
The singleton DB pattern is well-The singleton DB pattern is well-
documenteddocumented
• The downloads for Palooza (associated with
this session) includes a detailed description of
the singleton DB pattern
• Factor it into all of your programs!
• If you don’t, you are risking scalability on your
database server
42
43. ASNApalooza2007ASNApalooza2007
Beware shared DB connections!Beware shared DB connections!
• Do not share DB connections in Web
applications
• This forces all users to wait on a single thread
for DB connections
• This is guaranteed to make you stay up late at
night
43
44. ASNApalooza2007ASNApalooza2007
Consider (carefully) if using threadingConsider (carefully) if using threading
can help your application performancecan help your application performance
• Spinning off certain processes can help
application performance
• One place where using threading is effective is
to cause Web services to fire off a thread (to
start a long-running process) and quickly
return
• Here is an abbreviated example…
46. ASNApalooza2007ASNApalooza2007
In summaryIn summary
• Use connection pooling. Properly!
• Dispatch the KeyList where it makes sense
• Use SetRange/ReadRange instead of
SETLL/READE
• Populate lists from read-only files
• Don’t persist record locks longer than
necessary
46
Editor's Notes
You could argue that connection pooling isn’t directly related to file IO. We in ASNA’s tech support know better. We deal with issues nearly weekly that are reported as poor file IO and the culprit is almost always found to be improper use of connection pooling. Without effective connection pooling, your Web applications will wait several unnecessary seconds for their pages to appear.
In most cases, less than 5 milliseconds.
CAL = client access license where SQL Server use is licensed to a client
Each time this database name is connected, it has connection enabled and has a 20 connection pooling timeout value.
For a shop floor application, the operator returns to the screen infrequently during the day. If you want to pool jobs for the best performance for this type of user, you probably want something longer than 20 minutes.
Let’s consider a typical Web application. It’s early in the morning, and there having been any users on the Web app for quite a while. Nothing is currently in memory for the Web app and it has no pooled System i jobs available. The jobs in the green “eggcrate” are active pooled jobs; the jobs in the red “eggcrate” are inactive pooled jobs.
Let’s see how it works.
This user waits 4-7 seconds for her first page.
This user waits 4-7 seconds for her first page.
There just barely a wait for this page for this pink (warm) user.
This user waits 4-7 seconds for her first page.
Given typical database connections for Web apps, the concept of the “first” user is a little interesting. In this case, it means the first of the two to request a job. In other words, the pooled job goes to asks for it first, not who used it last.
The pinkt user gets her page very quickly, the
While you get a job back in a matter of milliseconds, there is still other work to be done for any given page. Most pages will complete in a matter of a few hundred milliseconds, at the most.
Each job expires after x minutes of inactivity from when it was last active.
Something is wrong here!
If you forget to close files do disconnect, the opened files are not closed for you. And. those open file handles aren’t reused across job instances. Close files, too!
It’s even worse than that! Not only are you creating orphan jobs—the user is always cool and always has to wait for a new job! These orphan jobs sit unused in the active job zone until they timeout.
If each user uses a unique user ID and password, each user gets her own privately pooled job.
SOX refers to the Sarbanes Oxley Act which, driven by the Enron fiasco, imposes very strict accountability on public businesses.