Posted by Hari Shanmugadhasan on 13 March 2013 at 13:04
On page 89 in "Example 3-4 Recommended settings for the DB2JccConfiguration.properties" it has "db2.jcc.maxTransportObjects=1000" which seems to directly conflict with the page 87 "suggested value" for maxTransportObjects of "Set to the number of concurrent
transactions times the number of DB2 members".
The recommended setting on page 89 of 1000 would seem much higher than the CPU capacity of many sites and would tend to result in high host CPU contention and worse response times.
Posted by Hari Shanmugadhasan on 13 March 2013 at 13:05
The above comment makes the assumption is that effective connection pooling means many fewer connections than users.
Posted by Hari Shanmugadhasan on 14 March 2013 at 7:56
It would be good to discuss the appropriate Poisson (or other) distributions to model the transaction arrival rates during peak hour of the day, week, month and year of various Websphere/DB2 application/industry (web retail, web banking, B2B, CRM, ERP) transaction workload categories.
Posted by Hari Shanmugadhasan on 14 March 2013 at 7:58
It would be good to discuss how to relate prime shift average transaction rates to peak hour rates and the probability distribution of transaction arrival during peak hour for different workload categories.
Posted by Hari Shanmugadhasan on 14 March 2013 at 8:00
It would be good to discuss the appropriate queuing models to use to model the Websphere/DB2 environment during peak hour for the various workload categories, depending on the Websphere/DB2 options and parameter values used.
Posted by Hari Shanmugadhasan on 14 March 2013 at 8:02
It would be good to show with three industry examples, say web retail, web banking and web insurance, how to relate Service Level Agreement response time requirements, peak transaction arrival rates and queuing models to derive the appropriate configuration for the various Websphere/DB2 configuration options, parameters and features.
Posted by Hari Shanmugadhasan on 14 March 2013 at 8:04
It would be good to show with three industry examples, say web retail, web banking and web insurance, how to tune the various Websphere/DB2 configuration options, parameters and features, based on DB2 monitor data and specific fields.
No need to include the traditional non-DDF DB2 tuning aspects such as access paths and Buffer Pools.
Posted by Hari Shanmugadhasan on 14 March 2013 at 9:35
It would be good to have better examples of Websphere PMI monitoring screens with improved explanations.
Page 360 Figure 8-22 seems to show that the number of JDBC connections is more than twice as big as it should be, with AllocateCount never hitting 24, while CreateCount is at 50 most of the time and CloseCount is at 0.
No explanation is given of this pattern (other than why it doesn’t go pass 50), or why Maximum Connections shouldn’t be set to 25 or lower.
Posted by Hari Shanmugadhasan on 14 March 2013 at 9:37
Page 361 reports that “The discard rate is very high at 1400/sec.” without providing a context like the Websphere statement cache hit ratio or its miss ratio. If only 1% of statements miss then this is unlikely to be a problem.
The kinds of monitoring done for the DB2 for z/OS Dynamic Statement Cache would seem to be somewhat applicable to this Websphere cache, yet the example does not illustrate this when it could, with the appropriate PMI screens, assuming they exist.
Posted by Hari Shanmugadhasan on 14 March 2013 at 9:39
It would be good to better explain tuning decisions. Page 364 seems to arbitrarily decide to increase the size of the statement cache to 60 statements. Yet page 362 Fig 8-26 would seem to suggest starting with an increase to 10 + 20 = 30 statements.
There should be explanations given of the trade-offs made in such decisions to have twice as many JDBC connections as necessary and a statement cache twice the size it needs to be, in resource constrained or billing environments.
Posted by Hari Shanmugadhasan on 14 March 2013 at 9:40
Posted by Hari Shanmugadhasan on 14 March 2013 at 9:43
Then Figure 10 shows WaitTime of 8.2597 milliseconds, which is reduced to 0 in Figure 11, but UseTime has increased from 2.655 to 4.276 milliseconds, as if downstream contention has been created. Figure 12 shows seemingly large improvements that seem much bigger than those to be expected from an apparent net improvement of 6.6 milliseconds. It would seem that starting with an increase of the number of maximum JDBC pool connections from 10 to 30 would have made more sense than increasing to 70.
Posted by Hari Shanmugadhasan on 15 March 2013 at 8:27
In the two previous comments, Figures 10, 11 and 12 are in the developerWorks article at the URL referenced by the draft Redbook on page 364.
Continuing in that article, Figure 12 seems to show that having 7 times the max connections only improves EJB throughput by 13%! It would be good if this Redbook explained why this was and what developers should do about it. It would also be good if the Redbook explained the results for the other two runtime modes portrayed in Figure 12.
Posted by Hari Shanmugadhasan on 15 March 2013 at 8:40
It would also be good if this Redbook analyzed Figure 12 in the referenced developerWorks article to point out that even in the "best" runtime mode scenario, Direct, it appears that the results would have been as good or better with a JDBC connection pool configuration of 5/20 compared to 10/70.
Just doubling the maximum JDBC connections might well be better than the seven-fold overkill, non-scaling, self-contention creating maximum of 70.
Posted by Hari Shanmugadhasan on 15 March 2013 at 8:44
And it would be good if this Redbook pointed out the possibility that a JDBC connection pool config of 1/15 might be best of all, given that 10/70 only managed about a 50% throughput improvement over 1/10.
Proving once again that sometimes, "Less is more" - Mies van der Rohe, in a different context.
Posted by Hari Shanmugadhasan on 15 March 2013 at 8:50
The previous post was referring to the Direct case in Figure 12 in the developerWorks article referenced by the draft Redbook on page 364.
It would be even better if the Redbook showed tests for the 3 runtime modes comparing the JDBC connection pooling configurations 1/10, 1/15, 2/20, 10/70 to support a discussion of a thoughtful tuning methodology.
Posted by Hari Shanmugadhasan on 15 March 2013 at 8:58
Since the V10 Performance Topics Redbook has sections on distributed IRWW tests with JDBC and SQLJ implementations, it would be good if this Redbook provided the details on the HW, software, JDBC and DB2 Connect configurations used in the tests, along with the response times, ETR, ITR and total CPU utilization observed.
If this Redbook included the results of trial runs and how the runs were tuned then that would be even better.
Posted by Hari Shanmugadhasan on 18 March 2013 at 12:29
The March 16, 2013 draft Redbook doesn't affect my previous comments on the March 13 draft, other than changing some of the page references. So page 364 is now page 370, 361 is now 367, and 360 is now 366, in terms of my page references in my above posts.
Posted by Mr. Amr Khafagy on 9 September 2013 at 14:19
On page 65, I believe there is a typo.
Table 2-1 List of sections describing the JDBC type 4 implementation steps
but the table title is:
JDBC type 2 - Implementation step number and definition