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.
