jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philippe Mouawad <philippe.moua...@gmail.com>
Subject Re: New DataSet implementation
Date Wed, 13 Nov 2013 21:59:57 GMT
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 <philippe.mouawad@gmail.com
> wrote:

> Hello Sebb,
> My answers below.
>
> On Sat, Nov 2, 2013 at 10:35 AM, sebb <sebbaz@gmail.com> wrote:
>
>> On 2 November 2013 08:28, Philippe Mouawad <philippe.mouawad@gmail.com>
>> 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 <sebbaz@gmail.com> wrote:
>> >>> > On 26 October 2013 20:23, Philippe Mouawad <
>> philippe.mouawad@gmail.com>
>> >>> 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.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message