On Thu, Jan 9, 2014 at 2:54 PM, sebb <seb...@gmail.com> wrote: > No-one seems to have addressed one of the main issues: why should > JMeter use JDBC pooling at all? >
It already exists sebb, so it means it is useful. > JMeter threads generally represent independent users. > Would such users share a JDBC pool? > Well the pool can be useful to simulate the behaviour of an application server. Users would want to load test to determine the minimum sizing of the pool to handle a set of SQL queries that are executed simulatenously. > > Isn't any pooling likely to be done by the server anyway? > Yes probably, but maybe user want's to isolate test on a set of queries, do optimizations on DB or SQL query and see effect. > > If pooling is supposed to be done by the client(s) - i.e. JMeter - > then surely the implementation should be configurable? > > Otherwise JMeter is making the choice for the user. > > On 9 January 2014 07:11, Antonio Gomes Rodrigues <ra0...@gmail.com> wrote: > > Hi, > > > > I am agree with Philippe, it will be great to remove Excalibur and put > > tomcat pool for 2 reasons : > > Better performance (see > > > http://www.tomcatexpert.com/blog/2010/03/22/understanding-jdbc-pool-performance-improvementsand > > > http://blog.ippon.fr/2013/03/13/improving-the-performance-of-the-spring-petclinic-sample-application-part-3-of-5/ > > ) > > have something which developer know and use > > > > Antonio > > > > > > 2014/1/9 sebb <seb...@gmail.com> > > > >> On 8 January 2014 23:07, Philippe Mouawad <philippe.moua...@gmail.com> > >> wrote: > >> > On Wednesday, January 8, 2014, sebb wrote: > >> > > >> >> On 8 January 2014 22:10, Philippe Mouawad < > philippe.moua...@gmail.com> > >> >> wrote: > >> >> > Reopening this thread after this bug report: > >> >> > > >> >> > - https://issues.apache.org/bugzilla/show_bug.cgi?id=55977 > >> >> > > >> >> > > >> >> > We have 2 options to fix this bug: > >> >> > > >> >> > Option 1): > >> >> > > >> >> > Upgrade excalibur libraries to 2.1 > >> >> > > >> >> > Option 2): > >> >> > > >> >> > Switch to a new pooling implementation like Tomcat Pool (or > >> >> commons-dbcp) . > >> >> > Tomcat pool is more recent than commons-dbcp and is supposed to > have > >> much > >> >> > better performances with high number of threads. > >> >> > > >> >> > It has all features currently available for excalibur. > >> >> > >> >> Not entirely true; Excalibur has quite sophisticated instrumentation > >> >> (logging). > >> >> That is how the log was generated and how the problem was found. > >> >> > >> >> > As I have said many times in the past, I personnally don't like the > >> fact > >> >> we > >> >> > have some (fortunately very few libraries of retired Apache > project > >> >> > (Excalibur) and would find it great to remove all excalibur related > >> jars, > >> >> > but we didn't get a consensus on this. > >> >> > >> >> I agree that it is unfortunate that Excalibur has been retired. > >> >> > >> >> However just because Commons Pool is newer does not necessarily make > >> >> it significantly better. > >> > > >> > > >> > I fully agree with you sebb , what i said was based on analysis by > tomcat > >> > team which I tend to trust but we could double check. > >> > > >> > I am speaking about tomcat pool vs commons-dbcp > >> > >> OK, but the same considerations apply. > >> > >> >> Have you compared performances? > >> > > >> > > >> > There are benchmarks between commons dbcp and tomcat-pool I remember I > >> read > >> > them, but I can't find them now. > >> > > >> > Also tomcat-pool relies on jdk5 concurrent apis. > >> > http://tomcat.apache.org/tomcat-7.0-doc/jdbc-pool.html > >> > > >> > I also made a comparison on a ecommerce website with the 2 pools and > it > >> > had better behaviour. > >> > But commons-dbcp is a great library also. > >> > > >> > I didn't compare perfs of excalibur vs others.My concern is the > >> deprecation > >> > state. > >> > >> It's not deprecated, just unmaintained. > >> But if it works, don't fix it. > >> > >> > > >> >> This time we have an opportunity which we should maybe jump at. > >> >> > >> >> Changing to an updated version of Excalibur is trivial, and does not > >> >> affect users who may be relying on its instrumentation. > >> > > >> > where is the doc ? > >> > >> >> > >> >> Changing to use Pool instead will require quite a lot of work. > >> >> We may then find another implementation that is even better and have > >> >> to go through it all again. > >> > > >> > > >> > commons dbcp is quite stable and tomcat pool is not that new > >> > >> I follow the Tomcat lists and there have been some recent fairly basic > >> bugs reported against it. > >> So I'm not sure how stable it is yet. > >> > >> >> > >> >> So if we do change, I think we need to do it in such a way that users > >> >> can plug in whatever pooling implementation they want > >> > > >> > > >> > not sure it is worth, also the aim is to drop excalibur, if we keep it > >> then > >> > it is not worth the effort. > >> > >> The point is that any pool implementation will have its advantages and > >> disadvantages. > >> > >> Even if we decided to drop Excalibr, I still think it would make sense > >> to ensure that the pooling code is pluggable. > >> We don't know what pooling system users will be installing for their > >> systems. > >> > >> > > >> >> > >> >> We should anyway do the version update because that is trivial (and > >> >> easily reversible). > >> > > >> > ok > >> > > >> >> > >> >> > > >> >> > My 2cts. > >> >> > > >> >> > Regards > >> >> > > >> >> > Philippe M. > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > On Thu, Aug 23, 2012 at 12:46 AM, sebb <seb...@gmail.com> wrote: > >> >> > > >> >> >> On 22 August 2012 21:43, Philippe Mouawad < > >> philippe.moua...@gmail.com> > >> >> >> wrote: > >> >> >> > On Wed, Aug 22, 2012 at 7:21 PM, sebb <seb...@gmail.com> wrote: > >> >> >> > > >> >> >> >> On 22 August 2012 17:52, Milamber <milam...@apache.org> wrote: > >> >> >> >> > On Wed, Aug 22, 2012 at 4:34 PM, Philippe Mouawad < > >> >> >> >> > philippe.moua...@gmail.com> wrote: > >> >> >> > >> >> >> <snip/> > >> >> >> > >> >> >> >> >> I think we should really remove dependency on Apache > Excalibur. > >> >> >> >> > >> >> >> >> We still use parts of Excalibur for JDBC pooling. > >> >> >> >> > >> >> >> >> I don't see the point of pooling if you are testing JDBC; it > then > >> >> >> >> becomes as much a test of the pool rather than JDBC. > >> >> >> >> > >> >> >> > Don't understand this > >> >> >> > >> >> >> JMeter threads are intended to represent independent users, so > >> sharing > >> >> >> JDBC connections between different threads is equivalent to > sharing > >> >> >> between different users. Does not make sense to me. > >> >> >> > >> >> >> But assumijng that there is a use case for sharing a pool between > >> >> threads: > >> >> >> If a JDBC performance test shows problems - is it the JDBC > database, > >> >> >> or the pooling implementation? > >> >> >> What if the pooling implementation is different from the one in > the > >> >> >> application one is simulating? > >> >> >> > >> >> >> >> > >> >> >> >> If we do want to support pooling, it should be selectable. > >> >> >> >> However I don't know if there is a standard Pooling API, so > that > >> >> might > >> >> >> >> not be possible. > >> >> >> >> > >> >> >> >> Why not use commons-dbcp or tomcat-pool for this ? > >> >> >> > >> >> >> They are just specific examples of pools; no different really from > >> >> >> sticking with Excalibur. > >> >> >> > >> >> >> If we truly want to allow users to test pooling, they should be > able > >> >> >> to use any pool they wish, so they can see which one meets their > >> needs > >> >> >> best. > >> >> >> > >> >> >> But I suspect this will be quite tricky to allow arbitrary pooling > >> >> >> implementations. > >> >> >> > >> >> > > >> >> > > >> >> > > >> >> > -- > >> >> > Cordialement. > >> >> > Philippe Mouawad. > >> >> > >> > > >> > > >> > -- > >> > Cordialement. > >> > Philippe Mouawad. > >> > -- Cordialement. Philippe Mouawad.
