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 Thu, 09 Jan 2014 20:52:04 GMT
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.

>
> 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 <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.

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