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 Sat, 02 Nov 2013 14:05:57 GMT
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.

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