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 06:49:05 GMT
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%.


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.

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