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: Apache Excalibur Logger
Date Mon, 23 Jan 2012 12:39:02 GMT
Hello Sebb,
My responses below.
Regards
Philippe

On Mon, Jan 23, 2012 at 1:02 PM, sebb <sebbaz@gmail.com> wrote:

> On 23 January 2012 06:49, Philippe Mouawad <philippe.mouawad@gmail.com>
> wrote:
> > Regarding logging,
> > It CAN Go fast if we share work and each of us takes one SRC folder.
> > It's à matter f search replace for 90%.
>
> It's still the same amount of work, no matter how many people do it.
> [Possibly more, if you allow for co-ordination overheads]
>
> Generally it's the last 10% that takes all the effort.
>
=> I agree , I volunteer to do it if you agree after release.

>
> Definitely not something to be started just before a release.
>
> => It was not my intention, it is just after the release.


> Also, we would still need to keep the jars unless we rewrote
> OldSaveService - or made it optional.
>
> >
> > Regarding pool i am not sure to  there is an datasourceelemnt That has à
> > Maxpool property and looking at code it seemed the  excalibur datasource
> > was using this property.
> > Commons jdbc BasicDatasource was looking very close to it.
> >
> > Regards
> > Philippe
> > On Monday, January 23, 2012, Anthony Johnson <ansoni@gmail.com> wrote:
> >> On Sun, Jan 22, 2012 at 9:28 PM, sebb <sebbaz@gmail.com> wrote:
> >>> On 23 January 2012 01:46, Anthony Johnson <ansoni@gmail.com> wrote:
> >>>> On Sun, Jan 22, 2012 at 8:29 PM, sebb <sebbaz@gmail.com> wrote:
> >>>>>
> >>>>> On 22 January 2012 13:04, Philippe Mouawad <
> philippe.mouawad@gmail.com>
> > wrote:
> >>>>> > Hello,
> >>>>> > I noticed there was some plan to remove Excalibur logger
> dependency.
> >>>>> > What is the new selected component to replace it ?
> >>>>> >
> >>>>> >   - log4j
> >>>>> >   - slf4J+logback
> >>>>>
> >>>>> Given that the main focus of JMeter is HTTP, and we use Apache
> >>>>> HttpClient, if we do replace logging it will be sensible to use
the
> >>>>> same, i.e. Commons Logging.
> >>>>>
> >>>>> But it is a huge job to do this; every single file that uses logging
> >>>>> will need to be updated.
> >>>>>
> >>>>> As well as changing all the documentation, config files etc.
> >>>>>
> >>>>> >
> >>>>> > When do we plan this migration ?
> >>>>>
> >>>>> Not yet.
> >>>>>
> >>>>> > Working on 41788
> >>>>> > <https://issues.apache.org/bugzilla/show_bug.cgi?id=41788>I
> noticed
> >>>>> > javadocs for excalibur where no more available on internet.
> >>>>> >
> >>>>> > I suppose the same question will arise regarding DataBase Sampler
> > pool.
> >>>>> > What are the candidates:
> >>>>> >
> >>>>> >   - Tomcat JDBC Pool :
> >>>>> >   http://people.apache.org/~fhanik/jdbc-pool/jdbc-pool.html
> >>>>> >   - Commons DBCP ?
> >>>>>
> >>>>> I wonder whether there's really any point supporting database pooling
> >>>>> at all, given that the focus of JMeter is on independent test
> threads.
> >>>>>
> >>>>
> >>>> JMeter definitely needs persistent database connections which is
> >>>> easily accomplished with database pooling.  JMeter loses usefulness
if
> >>>> it has to open a connection at sample time since this is a lot more
> >>>> expensive than running optimized SQL.
> >>>>
> >>>> Also, some database features rely on persistent connections to be
> >>>> optimized such as PreparedStatement caches.
> >>>
> >>> JMeter uses persistent connections; the connection is established by:
> >>>
> >>>
> >
> http://jmeter.apache.org/usermanual/component_reference.html#JDBC_Connection_Configuration
> >>>
> >>> This is a different matter from sharing connections between threads.
> >>>
> >>> The per-thread (non-shared) pool is currently implemented as a pool
> >>> size of 1 per thread.
> >>>
> >>
> >> The preferred way(per the sarcastic "why use pooling" in the docs:-)
> >> is not very nice code-wise.  If I have a 1,000 thread test then I will
> >> have a 1,000 excaliber thread pool objects in memory and 1,000
> >> per-thread poolMap objects.  Getting rid of pooling in JMeter would
> >> definitely make this code better.
> >>
> >> On the other hand, their are nice features from the pooling such as
> >> connection testing, keep-alives and such.  Some of those would need to
> >> be implemented if you guys decided to rip out pooling.
> >>
> >> Regardless, you responded to my only concern and I learned
> >> something(despite having written several JDBC Test Plans in the
> >> past:-/)
> >>
> >>>>> Adding pooling effectively means that JMeter is testing the pooling
> as
> >>>>> well as the database.
> >>>>>
> >>>>> > I made some Load tests for an ECommerce site comparing the
2 pools
> > and the
> >>>>> > first one seems to be a little better performing (specially
in
> > exhaustion
> >>>>> > cases)
> >>>>> >
> >>>>> > although Commons DBCP quality is great.
> >>>>>
> >>>>> I don't think database pooling is really necessary for JMeter, so
the
> >>>>> performance is not a big issue; tests that want to exercise a
> database
> >>>>> should not be using pooling - or at least should not be using a
> >>>>> pooling solution which is fixed by JMeter.
> >>>>>
> >>>>> I don't know whether it's possible to create a datasource which
> >>>>> includes pooling, if so, then that is the way to go - i.e. support
> >>>>> data sources (I don't think we do currently).
> >>>>>
> >>>>> >
> >>>>> > --
> >>>>> > Cordialement.
> >>>>> > Philippe Mouawad.
> >>
> >
> > --
> > Cordialement.
> > Philippe Mouawad.
>



-- 
Cordialement.
Philippe Mouawad.

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