Subscribe: See All. Hear All.
Added By: Feedage Forager Feedage Grade B rated
Language: English
application  article  code  cost  cpu  instrumentation  java  join  monitoring  new  part  precision  service  sleep  spin  string  time 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: See All. Hear All.

See All. Hear All.

Updated: 2016-10-24T06:03:53.954-04:00


Graphite - Great App, Laborious Install (Until now ?)


Fixed another stupid mistake in the pipeline factory. Noticed this testing data submission using bosun / scollector which uses gzipped JSON HTTP posts to submit data through OpenTSDB. Of course, the HttpContentDecompressor must be called after the HTTP decoding codec, because the HTTP wrapper is not compressed, just the body of the request. The corrected pipeline is:

Spin vs. Sleep vs. Join


As I was reading about why Esper sometimes implements Spin Locks instead of thread suspension, I wondered what the actual benefits were. I put together a quick and very simple test to measure elapsed time and CPU utilization of 3 different suspension operations:  (Using java version "1.6.0_21" on Windows 7)
  1. Spin: Capture until (the current time plus the suspend time in ms.) and loop until the current time is equal to or greater than until.
  2. Sleep: Call Thread.sleep()
  3. Join: Call Thread.currentThread().join(). 
This was a single thread, called in main, sleeping for 5 ms. in a loop of  100,000. As it turns out, Spin is the absolute most precise of the three, running with zero loss of precision, but at a cost of 499,905 ms. of CPU time.

Sleep lost the most precision with 1,358 ms. worth of latency and a cost of 31 ms. of CPU time.

Join seems to be the best compromise with zero CPU utilization and only 7 ms. loss of precision.

So the moral of the story, it seems to me, is to always use Join unless you need a hyper-precise wake-up time. Furthermore,  it would seem that Sleep is the worst way to achieve a suspension with much lower precision than Join at an infinitely higher CPU cost.


SpinLock vs. Sleep vs. Join
Warming Up....
Warm Up Complete
Starting Spin Test
Spin:   500000/499905204500
Starting Sleep Test
Sleep:  501358/31200200
Starting Join Test
Join:   500007/0

====  Update ====

Tested the exact same code using java version "1.6.0_24" on Ubuntu 10.10 X64 and the results were a little different. The Spin did have some precision loss (but not much). The biggest difference was that Join went from zero CPU cost to 3,970 ms cost, making it more expensive than Sleep and with slightly less precision. Not sure what to make of that, except that I need to rerun the tests to make sure there is no skew from background processes or something.

SpinLock vs. Sleep vs. Join
Warming Up....
Warm Up Complete
Starting Spin Test
Spin:   500034/499590000000
Starting Sleep Test
Sleep:  516430/3680000000
Starting Join Test
Join:   516650/3970000000

Java run-time monitoring, Part 3


Part 3 is not really about monitoring Java itself, but rather how to monitor other resources using Java, plus how to manage and visualize collected data. There are several examples I would have liked to put in the article, but with the PDF version running at 73 pages, it got a bit too long.

Postcompilation instrumentation and performance monitoring


Part 2 of my article series on Java run-time monitoring was published today. Last week I reviewed methods of instrumenting java classes at the source level. While not ideal in light of the ubiquity of AOP techniques to inject instrumentation at runtime, if you have or want to do it, take a page from Log4J's book and make sure that the instrumentation is externally configurable (i.e. you don't need to re-compile to tweak it). Here's a quick list of features you might look for in your Log4J instrumentation analog:
  • Verbosity: Yep, just like Log4J (and many other logging packages) the Level of loggers can be modified at runtime through JMX or simply by placing a watch on the XML configuration file.
  • Thresholds: Automatically trace incidents when measurements exceed externally defined thresholds.
  • Ranges: Automatically trace counts of measurements that fall into a value window as part of an externally defined and named range. (useful for SLAs where an operation's elapsed time might be classified as GOOD, WARN or CIRITCAL.)
  • Rollups: Maintain aggregated performance statistics all the way up a hierarchical tree.
So in this week's article, I review methods of instrumentation that can be used in the post-compilation phase, or more simply, without futzing with the source code.

  • Interceptors: J2EE and a bunch of other [not just] Java frameworks support the ability to inject interceptors into the application without ever touching the source code of your code application classes.
  • Class Wrapping: Implement instrumentation in a class wrapper and then wrap your target class. You get the same functionality and instrumentation to boot.
  • Byte Code Instrumentation: Inject instrumentation byte code directly into your already compiled classes. This can be done statically (i.e. you end up with the original jar and and instrumented jar) or it can be done dynamically at runtime when the classes are classloaded.
An additional approach which I did not really address in the article is the concept of class swapping. For example, if you wanted to know some low down performance and byte volume details of a network service, you could create a new class called com.myco.instrumentation.InstrumentedSocket which extends and adds in some basic instrumentation like counting byte transfer rates. At class load time, you could swap out the implementation of all instances of with your instrumented version.

Hopefully the article is useful to you.


Java Runtime Monitoring, Part 1


Part 1 of my developerWorks series on application monitoring was published today. My goal was to champion the use of fine grained monitoring of the JVM and application code instrumentation.

AutoDiscovery - [Trying to] Say No To Static Configuration


I am always on the lookout for ways to avoid configuration files and the like in favour of dynamic discovery. The JBoss HA-JNDI implementation is a great example where you can specify a set of properties and the ContextFactory will automatically discover a server matching your criteria.I recently tired of creating yet another user database with roles, passwords, expiration and all the rest of it, so on a new project we started recently for an internal web application, I decided I was going to use the company's Active Directory server. Seemed like a genius idea. Single sign on for my users and I get to delegate all the afformentioned to a bunch of LDAP servers that someone else maintains.Down the road a ways, I started thinking about which of 10 LDAP servers I should use. What if one of them goes down ? What if they change ? What if they add new servers ? It turns out (and perhaps you already knew this) that DNS will help you locate servers by service, not just by name. Sun provides a DNS Service Provider for JNDI which makes the process nice-n-easy. I could not get it to work exactly as advertised, but with a bit of jiggery pokery, it did the job admirably. In the example below, you simply pass in a peculiar looking string that specifies the service, protocol and domain you are looking for. In my case that string was /*** Returns an array of located hosts for the given service descriptor.* @param service String* @return LocatedHost[]* @throws NamingException*/public LocatedHost[] locateHosts(String service) throws NamingException { Properties dnsProperties = new Properties(); DirContext ctx = null; ArrayList locatedHosts = new ArrayList(); dnsProperties.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.dns.DnsContextFactory"); dnsProperties.put(Context.PROVIDER_URL, dnsList); String[] hostAttributes = new String[] {"A"}; LocatedHost locatedHost = null; try { ctx = new InitialDirContext(dnsProperties); DnsContext dnsContext = (DnsContext)ctx.lookup(service); Attributes attrs = dnsContext.getAttributes(""); int i = attrs.get("srv").size(); for(int c = 0; c < locatedhost =" [...]