jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philippe Mouawad <philippe.moua...@gmail.com>
Subject Re: Excalibur pooling [was: Apache Excalibur Logger]
Date Fri, 19 Feb 2016 23:57:39 GMT
Hello,
For follow up, fixed within bug 58786:
https://bz.apache.org/bugzilla/show_bug.cgi?id=58786

Regards

On Thu, Jan 9, 2014 at 10:22 PM, Philippe Mouawad <
philippe.mouawad@gmail.com> wrote:

>
>
>
> On Thu, Jan 9, 2014 at 10:04 PM, sebb <sebbaz@gmail.com> wrote:
>
>> On 9 January 2014 20:52, Philippe Mouawad <philippe.mouawad@gmail.com>
>> wrote:
>> > On Thu, Jan 9, 2014 at 2:54 PM, sebb <sebbaz@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.
>>
>> In which case, the user will surely want to be able to try different
>> pool implementations.
>>
>
> No I think he will want to configure his pool in a similar way as his J2EE
> Container (Tomcat, Weblogic, JBoss, Websphere)  .
> But you won't be able to have the exact pool implementation used by
> commercial containers. Although configuration parameters are very similar
> between implementations.
>
> I think having a pool configured in a similar way as Container would be
> enough
>
>
>> >
>> >>
>> >> 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.
>>
>> In which case, having pooling as well is going to complicate the testing.
>> But at least the JMeter pooling can be disabled.
>>
>
> I don't understand your argument. User will want to see with a pool
> configured in a certain way how his database reacts.
>
>
>> It makes little sense to have *any* pooling in JMeter.
>>
>
>
>
>> It makes no sense at all to have a fixed pooling implementation in JMeter.
>> But given that we have got it and it works and some people use it, it
>> should stay.
>>
>> If there really is a use-case for having (different) pooling, then the
>> pooling implementation should be selectable.
>>
>
> Why not if your really want it ?
>
>
>> >
>> >>
>> >> 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.
>> >> >>
>> >>
>> >
>> >
>> >
>> > --
>> > Cordialement.
>> > Philippe Mouawad.
>>
>
>
>
> --
> Cordialement.
> Philippe Mouawad.
>
>
>


-- 
Cordialement.
Philippe Mouawad.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message