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, 27 Nov 2013 21:21:39 GMT
On Tue, Nov 26, 2013 at 1:05 AM, sebb <sebbaz@gmail.com> wrote:

> On 23 November 2013 13:48, Philippe Mouawad <philippe.mouawad@gmail.com>
> wrote:
> > Hello sebb,
> > What's your decision on this point ?
>
> I don't make the decisions - they are ideally arrived at by consensus;
> failing that, majority.
>
> > Still having objection to code commit ?
>
> Yes, because it seems wrong to include code for a specific database
> implementation.
> We should be implementing generic solutions.
>
> So would you be ok to go for Spring-data based implementation ?
It will impact number of embedded libraries.


> > Thanks
> > Regards
> > Philippe
> >
> >
> > On Fri, Nov 15, 2013 at 10:37 PM, Philippe Mouawad <
> > philippe.mouawad@gmail.com> wrote:
> >
> >> We could sue Spring-Data but it would introduce a lot of dependencies.
> >>
> >>
> >> On Fri, Nov 15, 2013 at 12:54 AM, sebb <sebbaz@gmail.com> wrote:
> >>
> >>> On 13 November 2013 21:59, Philippe Mouawad <
> philippe.mouawad@gmail.com>
> >>> wrote:
> >>> > Hello sebb,
> >>> > Shall I commit this development or do we wait for 2.10.1 to be
> released
> >>> ?
> >>>
> >>> I am still concerned that this addition is specific to the Redis
> server.
> >>> I would much prefer to see a generic solution that can use various
> >>> different kinds of servers.
> >>>
> >>> > When do you plan to commit your devs on keytool ?
> >>>
> >>
> >> If I have time I will do it , I plan the following, if you want more let
> >> me know:
> >> - Add keytool path property
> >> - Add popup to be clear about error
> >> - Add info about how to fix it
> >>
> >>>
> >>> Sorry, have not been able to spend any time on this recently.
> >>>
> >>> > 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.
> >>>
> >>
> >>
> >>
> >> --
> >> Cordialement.
> >> Philippe Mouawad.
> >>
> >>
> >>
> >
> >
> > --
> > Cordialement.
> > Philippe Mouawad.
>



-- 
Cordialement.
Philippe Mouawad.

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