Hello sebb, Shall I commit this development or do we wait for 2.10.1 to be released ?
When do you plan to commit your devs on keytool ? Thank you Regards Philippe On Sat, Nov 2, 2013 at 3:05 PM, Philippe Mouawad <[email protected] > wrote: > Hello Sebb, > My answers below. > > On Sat, Nov 2, 2013 at 10:35 AM, sebb <[email protected]> wrote: > >> On 2 November 2013 08:28, Philippe Mouawad <[email protected]> >> wrote: >> > Hello, >> > Can I proceed with commit these up coming days ? >> >> I'm not sure that the discussion was completed. >> >> As far as I can tell, the proposal only suits some types of >> cloud-based test, and relies on 3rd party servers to hold the data. >> > > No in my opinion if fits many scenarios: > - Cloud based tests, this one seems to me an important one, as Cloud based > usage are increasing > - Distributed tests, even if it is possible to do it with CSV, having the > data in a remote server is much easier to manage than having to > split/distribute on servers. Even it is true it requires some skills to > manage correctly the Redis server > - Continuous integration tests where also having the data in a centralised > , remote servers is easier than managing CSVs. In this case Redis server > plays the same role as a JDBC repository > - Compared to a database it should perform better for high load tests > since it's an in-memory repo (although this can be done in SQL databases), > see http://redis.io/topics/benchmarks > > >> I'm not yet convinced that this is how we should be extending JMeter. >> > > I don't understand this argument, it would be another string for JMeter, > my implementation is only 2 classes + properties for I18N ? > > What do you propose in this case ? > > > >> > Thanks >> > Regards >> > Philippe >> > >> > On Monday, October 28, 2013, Philippe Mouawad wrote: >> > >> >> >> >> >> >> On Monday, October 28, 2013, sebb wrote: >> >> >> >>> On 28 October 2013 01:26, sebb <[email protected]> wrote: >> >>> > On 26 October 2013 20:23, Philippe Mouawad < >> [email protected]> >> >>> wrote: >> >>> >> Hello, >> >>> >> These days Cloud based testing is becoming popular and having to >> >>> distribute >> >>> >> test data accross many servers through CSV can become painful if >> not >> >>> >> impossible. >> >>> >> >> >>> >> Even without Cloud, when using distributed testing you always have >> to >> >>> >> replicate your data on all servers, which is a painful manual step. >> >>> >> >> >>> >> Shouldn't we introduce a new DataSet more suitable for these use >> cases >> >>> ? >> >>> >> >> >>> >> We could do it in many different ways: >> >>> >> - Integrate an automatic CSV replicator, this would remain simple >> and >> >>> would >> >>> >> not introduce any tier, but with cloud based it would not >> horizontally >> >>> >> scale easily >> >>> > >> >> >> >> >> >> >> >> >> >> >> >>> > Not sure I follow the scaling argument. The file would only have to >> be >> >>> > copied once before the test proper starts. >> >>> > From then on, the data is accessed locally. >> >>> > >> >> >> >> >> >> The scale word was not good, In my thinking the issue is more about >> >> deploying/copying/splitting the file among nodes or cloud members. A >> >> centralized access makes it far easier. >> >> >> >> >> >>> > However, with a database, each node will need at least one >> connection >> >>> > to the database, and every time more data is needed there will be >> >>> > network traffic. >> >>> > Or the database has to be running on the server node. >> >>> > >> >> >> >> >> >> Agree, I was not saying anything different. But as I said this can be >> >> useful for middle or low volume >> >> >> >> >> >>> >> - Use a JDBC DataSet, but we would need to ensure it performs >> fine, and >> >>> >> jdbc protocol is not well suited for cloud based deployment (But it >> >>> could >> >>> >> also be an interesting feature for Continuous Integration) >> >>> >> - Use a NOSQL repository (Redis seems to me the best choice) , see >> >>> this >> >>> >> high level summary which I find interesting >> >>> >> >> >>> >> http://www.journaldunet.com/developpeur/outils/comparatif-des-bases-nosql/comparatif-des-bases-nosql-tableau-de-synthese.shtml >> >>> >> >> >>> >> I have implemented a new Redis (based on Java library for Redis) >> >>> DataSet >> >>> >> which I plan to commit if no objection. >> >>> >> >> >>> >> It will introduce 2 new dependencies with Apache License: >> >>> >> - Jedis (http://code.google.com/p/jedis/) >> >>> >> - commons-pool >> >>> > >> >>> > There is also a dependency on Redis, but I guess that would not be >> >>> bundled. >> >>> >> >>> >> >> no need to anything else than jedis + commons-pool >> >> >> >> >> >>> I've just noticed that Redis is provided as source which needs to be >> >>> built before use. >> >>> If it's difficult to copy CSV files to cloud nodes, it seems to me >> >>> it's going to be much harder to install Redis. >> >>> In which case additional network traffic will be needed to access the >> >>> database. >> >>> >> >>> Also there is no official Windows release. >> >>> >> >>> >> Thoughts ? >> >>> > >> >>> > Is MongoDB not suitable? >> >>> > We already include a jar for it. >> >>> > >> >> >> >> >> >> Mongodb is more document oriented and has another type of use cases. >> One >> >> interesting feature of redis is lists where you can pop a line it will >> not >> >> be available to next calls, it is suitable for tests that need >> uniqueness >> >> accross all nodes. >> >> >> >>> >> -- >> >>> >> Regards. >> >>> >> Philippe M. >> >>> >> @philmdot <https://twitter.com/philmdot> >> >>> >> >> >> >> >> >> -- >> >> Cordialement. >> >> Philippe Mouawad. >> >> >> >> >> >> >> >> >> > >> > -- >> > Cordialement. >> > Philippe Mouawad. >> > > > > -- > Cordialement. > Philippe Mouawad. > > > -- Cordialement. Philippe Mouawad.
