On 23 January 2012 01:46, Anthony Johnson <ans...@gmail.com> wrote: > On Sun, Jan 22, 2012 at 8:29 PM, sebb <seb...@gmail.com> wrote: >> >> On 22 January 2012 13:04, Philippe Mouawad <philippe.moua...@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. >> 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.
