Results on my computer: - HashMapput:693 - ConcurrentHashMapput:981 - ConcurrentReaderHashMapput:845 - HashMap get:63 - ConcurrentHashMap get:162 - ConcurrentReaderHashMap get:63
Of course this sample is not multithreaded to see impact when no conc download is used. In multithreaded mode, concurrent reader hash map has the reputation to be the most performing. Regards Philippe On Sat, Oct 1, 2011 at 3:33 PM, Philippe Mouawad <philippe.moua...@gmail.com > wrote: > A little additional note, > There is an implementation of Concurrent map by doug lea in concurrent.jar > called ConcurrentReaderHashMap > that has same performance as HashMap in read and a little less on write. > But performances are much better than ConcurrentHashMap. > So maybe a better alternative but requires concurrent-1.3.4.jar from: > > - > http://g.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html > > > > package org.apache.jmeter.protocol.http.control; > > import java.util.HashMap; > import java.util.Map; > import java.util.concurrent.ConcurrentHashMap; > > import org.apache.commons.lang.time.StopWatch; > > import EDU.oswego.cs.dl.util.concurrent.ConcurrentReaderHashMap; > > public class TestMap { > > public static void main(String[] args) { > StopWatch timer = new StopWatch(); > > Map map = new HashMap(); > testPut(timer, map, "HashMap"); > timer.reset(); > > map = new ConcurrentHashMap(); > testPut(timer, map, "ConcurrentHashMap"); > timer.reset(); > > map = new ConcurrentReaderHashMap(); > testPut(timer, map, "ConcurrentReaderHashMap"); > timer.reset(); > > > map = new HashMap(); > testGet(timer, map, "HashMap"); > timer.reset(); > > map = new ConcurrentHashMap(); > testGet(timer, map, "ConcurrentHashMap"); > timer.reset(); > > map = new ConcurrentReaderHashMap(); > testGet(timer, map, "ConcurrentReaderHashMap"); > timer.reset(); > } > > /** > * @param timer > */ > private static void testGet(StopWatch timer, Map map, String type) { > timer.start(); > for (int i = 0; i < 1000000; i++) { > map.get(i); > } > timer.stop(); > System.out.println(type+" get:"+timer.getTime()); > } > > /** > * @param timer > */ > private static void testPut(StopWatch timer, Map map, String type) { > timer.start(); > for (int i = 0; i < 1000000; i++) { > map.put(i,i); > } > timer.stop(); > System.out.println(type+"put:"+timer.getTime()); > } > > /** > * @param timer > */ > private static void testGet(StopWatch timer, Map map) { > timer.start(); > for (int i = 0; i < 1000000; i++) { > map.get(i); > } > timer.stop(); > System.out.println("ConcurrentHashMap get:"+timer.getTime()); > > } > } > > > On Sat, Oct 1, 2011 at 1:53 PM, sebb <seb...@gmail.com> wrote: > >> On 1 October 2011 12:38, Philippe Mouawad <philippe.moua...@gmail.com> >> wrote: >> > On Sat, Oct 1, 2011 at 12:57 PM, sebb <seb...@gmail.com> wrote: >> > >> >> On 1 October 2011 10:53, Philippe Mouawad < >> p.moua...@ubik-ingenierie.com> >> >> wrote: >> >> > Hello Milamber, Sebb, All, >> >> > Regarding 51919 < >> >> https://issues.apache.org/bugzilla/show_bug.cgi?id=51919>, >> >> > I wonder if there is not an issue in JMeterVariables access >> introduced by >> >> > concurrent download. >> >> > Initially I think JMeterVariables were not supposed to be shared so >> >> object >> >> > not thread safe, today they are due to Conc download. >> >> > Maybe JMeterVariables#variables should be replaced by a >> >> ConcurrentHashMap. >> >> > If so CONTEXT_VARIABLES_LOCK should be removed in my patch. >> >> > What do you think? >> >> >> >> Yes, a lot of JMeter code assumes that samplers and thread variables >> >> are not shared. >> >> >> >> So either we remove those assumptions, which might prove more >> >> expensive in the non-concurrent case; >> > >> > >> > => Performance impact is around 3 times more between ConcurrentHashMap >> and >> > HashMap >> > when only one thread is using Map (ie case when no concurrent downloads >> > occur) but maybe >> > it is not that important regarding other parts of code, needs some >> study. >> >> Indeed, study is needed. >> >> > >> >> or we change the way the >> >> concurrent downloads are handled so they don't directly access the >> >> main thread variables. >> >> >> >> => Don't you think code will be hard to maintain ? today AsyncSampler >> uses >> > same sample() method as others >> >> That is presumably broken as well, then. >> >> > won't there be lot of special cases ? >> > >> >> Potentially yes, but the alternative is to revisit and potentially >> rewrite large chunks of JMeter code. >> >> That needs a proper strategy first, as well as loads of tests to check >> the behaviour. >> >> >> One way might be to clone the sampler so it effectively becomes a new >> >> JMeterThread; I don't know how easy that would be, we would also need >> >> to recover the updates at the end of the sub-samples. >> >> >> >> Another way would be to intercept the writes to the objects that are >> >> not thread-safe and store them up for the main sample thread to do at >> >> the end. >> >> >> >> Either way, at present the concurrent downloads unfortunately have >> >> problems with cookie handling (and with buffer handling, but that is >> >> trivial to fix). >> >> >> >> So a short-term approach might be to ignore cookies when performing >> >> sub-samples - I think it is only the cookies that require updates to >> >> the thread variables. >> >> >> >> Are there any use-cases where the web application relies on cookies >> >> that are set by resources embedded in the main page? >> >> I know some sites set cookies on embedded resources, but is that >> >> necessary, or is it a by-product? >> >> >> > >> > => I agree, I have never met this case in my load tests but if it is met >> > load testing application will be hard >> > >> >> >> >> If not, then ignoring such cookies would be a long-term solution. >> >> >> >> > Regards >> >> > Philippe >> >> > >> >> > >> >> > On Sat, Oct 1, 2011 at 9:34 AM, <bugzi...@apache.org> wrote: >> >> > >> >> >> https://issues.apache.org/bugzilla/show_bug.cgi?id=51919 >> >> >> >> >> >> --- Comment #2 from Milamber <milam...@apache.org> 2011-10-01 >> 07:34:04 >> >> UTC >> >> >> --- >> >> >> A better way is to synchronize only the code section referred to the >> >> >> variables >> >> >> from JMeterContext >> >> >> (in add() and removeMatchingCookies() methods, I thinks) >> >> >> >> >> >> -- >> >> >> Configure bugmail: >> >> >> https://issues.apache.org/bugzilla/userprefs.cgi?tab=email >> >> >> ------- You are receiving this mail because: ------- >> >> >> You are on the CC list for the bug. >> >> >> You reported the bug. >> >> >> >> >> > >> >> > >> >> > >> >> > -- >> >> > Cordialement. >> >> > Philippe Mouawad. >> >> > Ubik-Ingénierie >> >> > >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org >> >> For additional commands, e-mail: dev-h...@jakarta.apache.org >> >> >> >> >> > >> > >> > -- >> > Cordialement. >> > Philippe Mouawad. >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org >> For additional commands, e-mail: dev-h...@jakarta.apache.org >> >> > > > -- > Cordialement. > Philippe Mouawad. > > > > -- Cordialement. Philippe Mouawad.
