On 23 January 2012 03:22, Anthony Johnson <ans...@gmail.com> wrote: > 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.
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.
