On Sun, Jan 22, 2012 at 9:28 PM, sebb <seb...@gmail.com> wrote: > 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. >
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.
