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