Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #14744
| 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> |
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 | Next — Previous in thread | Next in thread | Find similar | Unroll 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