Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.java.programmer > #14744

Re: multithreaded cache?

From Robert Klemme <shortcutter@googlemail.com>
Newsgroups comp.lang.java.programmer
Subject Re: multithreaded cache?
Date 2012-05-21 21:15 +0200
Message-ID <a1vijnFv1jU1@mid.individual.net> (permalink)
References (2 earlier) <4fb69812$0$6849$e4fe514c@news2.news.xs4all.nl> <a1nu7sFnnpU1@mid.individual.net> <jp6iji$n6m$1@dont-email.me> <a1pb7oFpc0U1@mid.individual.net> <jp932s$r59$1@news.albasani.net>

Show all headers | View raw


On 19.05.2012 23:24, Lew wrote:

> First off, thank you for the very professional and elegant code.
>
> I shall study it frequently.

Thank you!

> I had experience with CHM on an Enterprise Java project a few years back
> that involved processing documents up to 1GB or so at millions of
> documents per hour.
>
> As you can imagine, concurrency was a consideration there, but due to
> bureaucracy was not properly managed for a few years. I was hired around
> the time they started to pay attention to such issues.
>
> The code involved a properly but naively synchronized Map at one point.
> Detailed profiling revealed that lock contention for the Map was the
> number one throughput chokepoint in the whole system. Even above
> database concurrency and I/O.
>
> Boy howdy, the pundits are right to recommend hard measurement.
>
> Lock contention has a cascade effect. In modern JVMs, like IBM's
> mainframe-level ones that we used, uncontended locks process quite
> quickly. Contention introduces roadblocks that delay threads, allowing
> more to queue up, causing more contention, slowing things down still
> more, causing more, yada. It only takes one skunk in the middle of the
> main road to completely tie up rush hour everywhere.
>
> CHM by default partitions lock space (though I'm not clear it uses locks
> exactly) into sixteen independent slices. This meant far more than
> sixteen times faster for us. Writes tend to happen in a solitary thread
> without a whole lot of fight while reads run like greased pigs through
> the other fifteen. With our mix of reads and writes, and transaction
> volume, CHM pretty near eliminated lock contention. YMMV, as always, but
> in this case that chokepoint went from number one to off the list.
>
> It was still the wrong solution, since a simple, effortless,
> non-concurrent better one that would also have eliminated a raft of
> other problems was available, but had no political traction. However,
> good enough to eliminate the throughput impact was good enough, so I
> didn't raise a fuss when they decided against it.

Thanks for sharing that story.  What I find amazing about this is that 
what you did isn't exactly rocket science and yet they didn't do it 
before.  You would guess that it's just what every engineer would do but 
no: something prevents this from happening.

And it is true for a number of other techniques I would consider bread 
and butter tools:

- Ensuring requirements are gathered properly and understood before 
starting to code (and design of course).

- Testing code _before_ shipping.

- When writing unit tests, making sure to also include tests for 
critical values (usually corner cases such as -1, 0, 1, limit, limit - 
1, limit + 1, null, "", etc.).

- Thinking about the person who must use what you produce, regardless 
whether it's a document, a configuration file layout, a DSL, a class, a 
library.  It seems many people in software development are far more 
concerned with the inner workings of what they create instead of 
considering how it will be used.  Maybe it's easier or it is because 
making it work takes the largest part of coding - still the outcome 
often is dissatisfying and a little more thought upfront goes a long way 
at avoiding maintenance headaches and worse things.

...

This can't be so difficult, can it?

Kind regards

	robert


-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

Back to comp.lang.java.programmer | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

multithreaded cache? bugbear <bugbear@trim_papermule.co.uk_trim> - 2012-05-15 10:14 +0100
  Re: multithreaded cache? Silvio Bierman <silvio@moc.com> - 2012-05-15 11:41 +0200
    Re: multithreaded cache? Roedy Green <see_website@mindprod.com.invalid> - 2012-05-15 15:57 -0700
      Re: multithreaded cache? Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-05-15 16:13 -0700
        Re: multithreaded cache? Silvio Bierman <silvio@moc.com> - 2012-05-16 01:22 +0200
      Re: multithreaded cache? Silvio Bierman <silvio@moc.com> - 2012-05-16 01:19 +0200
        Re: multithreaded cache? Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-05-15 20:26 -0400
          Re: multithreaded cache? Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-05-15 21:41 -0300
          Re: multithreaded cache? Silvio Bierman <silvio@moc.com> - 2012-05-16 09:26 +0200
            Re: multithreaded cache? "Mike Schilling" <mscottschilling@hotmail.com> - 2012-05-26 14:54 -0700
        Re: multithreaded cache? Roedy Green <see_website@mindprod.com.invalid> - 2012-05-16 22:03 -0700
          Re: multithreaded cache? Silvio Bierman <silvio@moc.com> - 2012-05-21 15:25 +0200
  Re: multithreaded cache? Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-05-15 08:22 -0400
  Re: multithreaded cache? Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-05-15 09:56 -0700
  Re: multithreaded cache? bugbear <bugbear@trim_papermule.co.uk_trim> - 2012-05-16 14:33 +0100
  Re: multithreaded cache? Robert Klemme <shortcutter@googlemail.com> - 2012-05-17 11:54 +0200
    Re: multithreaded cache? Robert Klemme <shortcutter@googlemail.com> - 2012-05-17 12:06 +0200
      Re: multithreaded cache? Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-05-17 09:51 -0700
        Re: multithreaded cache? Robert Klemme <shortcutter@googlemail.com> - 2012-05-17 20:48 +0200
      Re: multithreaded cache? Sebastian <sebastian@undisclosed.invalid> - 2012-05-20 01:35 +0200
        Re: multithreaded cache? Sebastian <sebastian@undisclosed.invalid> - 2012-05-20 01:48 +0200
          Re: multithreaded cache? Lew <noone@lewscanon.com> - 2012-05-19 18:11 -0700
    Re: multithreaded cache? Silvio Bierman <silvio@moc.com> - 2012-05-18 20:42 +0200
      Re: multithreaded cache? Robert Klemme <shortcutter@googlemail.com> - 2012-05-18 23:45 +0200
        Re: multithreaded cache? Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-05-18 18:31 -0400
          Re: multithreaded cache? Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-05-18 22:15 -0700
            Re: multithreaded cache? Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-05-19 07:09 -0400
          Re: multithreaded cache? Robert Klemme <shortcutter@googlemail.com> - 2012-05-19 12:33 +0200
            Re: multithreaded cache? Lew <noone@lewscanon.com> - 2012-05-19 14:24 -0700
              Re: multithreaded cache? Robert Klemme <shortcutter@googlemail.com> - 2012-05-21 21:15 +0200
                Re: multithreaded cache? Lew <noone@lewscanon.com> - 2012-05-23 23:11 -0700
                Re: multithreaded cache? Robert Klemme <shortcutter@googlemail.com> - 2012-05-24 23:05 +0200
                Re: multithreaded cache? Gene Wirchenko <genew@ocis.net> - 2012-05-24 20:11 -0700
                Re: multithreaded cache? Robert Klemme <shortcutter@googlemail.com> - 2012-05-25 17:42 +0200
                Re: multithreaded cache? Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-05-25 07:09 -0300
        Re: multithreaded cache? Silvio Bierman <silvio@moc.com> - 2012-05-21 15:21 +0200
  Re: multithreaded cache? Kevin McMurtrie <mcmurtrie@pixelmemory.us> - 2012-05-24 23:22 -0700
    Re: multithreaded cache? Robert Klemme <shortcutter@googlemail.com> - 2012-05-25 17:36 +0200
      Re: multithreaded cache? Kevin McMurtrie <mcmurtrie@pixelmemory.us> - 2012-06-02 12:27 -0700
        Re: multithreaded cache? Robert Klemme <shortcutter@googlemail.com> - 2012-06-02 21:54 +0200

csiph-web