jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: Apache Excalibur Logger
Date Mon, 23 Jan 2012 11:55:35 GMT
On 23 January 2012 03:22, 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.

Even without Excalibur pool, we would still need per-thread data to
hold the connection(s) for a thread.
But it might well reduce the resource requirements if we used our own
holding object.

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

Mime
View raw message