jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: Excalibur pooling [was: Apache Excalibur Logger]
Date Thu, 09 Jan 2014 13:54:36 GMT
No-one seems to have addressed one of the main issues: why should
JMeter use JDBC pooling at all?

JMeter threads generally represent independent users.
Would such users share a JDBC pool?

Isn't any pooling likely to be done by the server anyway?

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 <ra0077@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 <sebbaz@gmail.com>
>
>> On 8 January 2014 23:07, Philippe Mouawad <philippe.mouawad@gmail.com>
>> wrote:
>> > On Wednesday, January 8, 2014, sebb wrote:
>> >
>> >> On 8 January 2014 22:10, Philippe Mouawad <philippe.mouawad@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 <sebbaz@gmail.com> wrote:
>> >> >
>> >> >> On 22 August 2012 21:43, Philippe Mouawad <
>> philippe.mouawad@gmail.com>
>> >> >> wrote:
>> >> >> > On Wed, Aug 22, 2012 at 7:21 PM, sebb <sebbaz@gmail.com>
wrote:
>> >> >> >
>> >> >> >> On 22 August 2012 17:52, Milamber <milamber@apache.org>
wrote:
>> >> >> >> > On Wed, Aug 22, 2012 at 4:34 PM, Philippe Mouawad
<
>> >> >> >> > philippe.mouawad@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.
>>

Mime
View raw message