Hello Sebb, My responses below. Regards Philippe On Mon, Jan 23, 2012 at 1:02 PM, sebb <seb...@gmail.com> wrote:
> On 23 January 2012 06:49, Philippe Mouawad <philippe.moua...@gmail.com> > wrote: > > Regarding logging, > > It CAN Go fast if we share work and each of us takes one SRC folder. > > It's à matter f search replace for 90%. > > It's still the same amount of work, no matter how many people do it. > [Possibly more, if you allow for co-ordination overheads] > > Generally it's the last 10% that takes all the effort. > => I agree , I volunteer to do it if you agree after release. > > Definitely not something to be started just before a release. > > => It was not my intention, it is just after the release. > Also, we would still need to keep the jars unless we rewrote > OldSaveService - or made it optional. > > > > > Regarding pool i am not sure to there is an datasourceelemnt That has à > > Maxpool property and looking at code it seemed the excalibur datasource > > was using this property. > > Commons jdbc BasicDatasource was looking very close to it. > > > > Regards > > Philippe > > On Monday, January 23, 2012, 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. > >> > >> 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. > >> > > > > -- > > Cordialement. > > Philippe Mouawad. > -- Cordialement. Philippe Mouawad.
