1 2 Previous Next


22 posts
In Eric Schmidt's presentation "How Google Works", he asks and answers the question "What's Different Now?" for businesses in the 21st century. And the answers he gives are: 1. Cloud computing puts a supercomputer in your pocket. 2. Mobile devices mean anyone can reach anyone, anywhere, anytime. 3. All the world's information and media is online. It's worth asking how this applies to me and you, how we work and what we do; I'll try to give some answers from a personal perspective. And as I'm a Java performance guy, I'll consider it from that point of view too and also considerations for every IT professional.

1. "Cloud computing puts a supercomputer in your pocket"

Starting with this first one, I (and most of you) sadly will NOT have a cloud virtual machine on standby for random tasks. Well not right now anyway, though when you combine with the second observation (2 above) the implication is probably that ultimately we'll have exactly that - an always-on online personal supercomputer which my personal devices will become an interface to. Literally the interface to your personal supercomputer, in your pocket. But for the next five years, that's not most people's reality. For most people in the next five years, personal cloud computing means access to a lot of storage online - so much that it's the bandwidth between your device and that storage which restricts how much you can use rather than the storage available (as far as non-storage services are concerned on a personal basis, you don't really care whether a service is in the cloud or not, so there's not much direct benefit to you of cloud computing other than storage). On a professional IT basis, the cloud means that you have access to resources in a far more elastic way than you used to. But low latency doesn't mix well with the cloud (as opposed to high throughput which works brilliantly in the cloud), and if your resource requirements are relatively constant then dedicated servers are more cost-effective; so you need to consider carefully which services you run in the cloud. Though you should probably have some sort of cloud exposure on your CV. With regard to Java performance, the consideration starts with the same issues - low latency, elastic vs constant resource requirements; but you have far more to consider such as multi-tenancy vs isolation; how to monitor elastic resources consistently; time drift across virtual machines; handling instance spin-up and initialization without impacting other services or request latencies; etc. The summary is that for Java performance, the cloud is a new environment with it's own very specific challenges that need independent consideration for testing, monitoring and analysis - you can't just take the techniques you use on a server or browser or client application or mobile app and transfer those to cloud services, you actually have to use different techniques, it's a completely new environment class to add to those four: it has a server-like environment, but resource competition similar to a browser and mobile app type unpredictability of uptime.

2. "Mobile devices mean anyone can reach anyone, anywhere, anytime."

Would you turn your phone off for a full day, to test how much you need it? We now use our phone almost as a cybernetic device that's part of us. Why would you turn that off? You wouldn't. So that means the above statement is pretty true - you are accessible anywhere, anytime. The only thing preventing anyone or anything actually using that reach is security by obscurity - they don't all know your number. So on a personal basis, be careful who you give you number to, it's relatively spam free if you control that. On a professional IT basis, the mobile device is the user interface that will grow and grow. If your application doesn't take into account telecom systems and mobile devices, you will start to suffer; possibly not right away, but definitely within 5 years. Telecom enabling an application is fantastically straightforward using a company like Nexmo, where I work, and as we're intending to support all mobile device communication channels as they evolve, your telecom capability gets to be future-proofed. The mobile device is more and more involved in the identification process - right now the phone number is the ultimate user id (which is why you're getting verification by SMS); at Nexmo we provide additional capabilities to easily let you perform two-factor authentication, verification and send one-time-passwords to initiate new users, reset passwords,  verify transactions and similar tasks. On the Java performance side, optimizing for mobile devices is well understood, just follow the tips I extract on a regular basis in my monthly newsletter, eg   Matthew Carver's "Six Ways You're Using Responsive Design Wrong",   Tim Hinds's "Beginner's Guide to Mobile Performance Testing",   Caroline de Lacvivier's "FAQ: Testing mobile app performance",   Steve Weisfeldt's "Best Practices for Load Testing Mobile Applications".

3. "All the world's information and media is online"

You already know this and use it. From the IT perspective, the important thing is that you integrate or at least connect to anything that's relevant. An agent that processes the world's information for your particular application is an inevitable component, you're ahead of the curve if you have one already (well done you), but in five years you'll be behind if you don't. From the Java performance perspective, integrating with multiple external sources is a massive headache that needs to be handled with care. You have to assume every type of network connection failure will happen: of course the usual non-connectivity; but also the more obscure connection that doesn't do anything (it's not really connected but doesn't tell your socket); connections that get enough bytes trickling in to prevent any timeout but so slow and with so many retries that your read goes on for hours; connections returning the data in an unexpected format; incorrect data (you must corroborate external data if you're relying on it to make a decision). The last two aren't really performance issues, but just illustrate how flakey the world's information is - can't work with it, but increasingly you can't work without it. I think it's clear that Eric Schmidt's three answers are relevant considerations for your future plans, it's worth keeping them in mind.
There are occasions when you need to know how much space a particular data structure is taking. You may have seen my recent newsletter about Java "sizeof" implementations which allow you to do that. Finding which sizeof to use was one of my first tasks after joining Nexmo, a telecom startup (though seeing as it's already one of the global leaders in SMS volume and application-to-person messaging, "startup" probably gives the wrong impression :-). At Nexmo, we use sizeof to check on the retained memory held on by some of our caches. It's an expensive operation for a large data structure, so we only apply the sizeof check when we need to investigate a process using up quite a lot of heap. Of course if all the cache elements were fairly similar simple objects then just getting the size() of the cache object would be sufficient to infer the memory used, but some of our caches hold disparate objects that can be of several types holding different amounts of memory - which is fairly common amongst caches I've seen. So we need sizeof to measure the cache retained size. Looking through all the Java sizeof implementations, I mentioned three main types (reflection, agent, unsafe) but there were some I didn't list in my newsletter: those based on native calls (JNI, JVMPI for older ones, JVMTI more recently), and one I listed in the tools section but didn't bother to mention as a "type" of implementation which inferred sizes by using the Runtime class to do a GC and measuring the heap used before creating an object, then again after creation. That last one is obviously limited in usefulness. What is quite interesting is the evolution of these implementations. The "Use the Runtime class to measure heap and infer size" technique was probably the first, it's simple to create and understand, but very limited. Next came the technique of estimating very very approximate sizes by serializing objects and subtracting overhead bytes - a technique which is easily accessible but inaccurate and oh so limited, as you can imagine! And after that we used reflection to access every field accessible from an object and guessed the size by using some rules of thumb about primitive data sizes and overheads. Fairly quickly, anyone in the know would have also started using the -Xrunhprof option to get object sizes. I can't remember when that was added to the JVM distribution, I think at 1.2, but the hprof profiler has been there for a long time (and it still is part of the JDK distribution). It was introduced as a demonstration profiler for using the JVMPI. It's always been a little fiddly to use, and prone to crashing the JVM, but it was free and better than anything else that was free. JHat was created to handle the memory dumps generated by the hprof profiler. By 1.5 the JVMPI was showing it's limitations and Sun redesigned the interface as the JVMTI. At this point, profilers had to migrate to the new interface, but Sun also introduced the management beans in 1.5 giving access to some internal data, and then in 1.6 it all came together with the new Java agent API and the "instrument" package which gave you full access to the size of an object. Now finally it was time for the Java agent (plus reflection) technique to obtain fairly reliable object sizes. More recently, developers playing around with sun.misc.Unsafe created an alternative sizeof that didn't require using the agent API. These sizeof implementations tend to be fast and accurate but, quite obviously, unsafe. Although my experience so far is that the ones I listed in my newsletter are relatively safe for "unsafe" implementations (ie no crashes so far :-). If you want to use the fastest lowest cost one, it's the Lucene sizeof - more details are in my "sizeof" newsletter. So after a little bit of Java history and some useful tools, I'll finish by mentioning that Nexmo is looking for engineers (and others too), so if you feel like joining me at a pretty cool growing startup, apply!

Java IDE comparison Blog

Posted by jacksjpt Aug 26, 2004

I go to the occassional meeting or trade show where vendors are displaying their wares. I look at what interests me, and sometimes give feedback to the vendors when I have appropriate expertise. Some are interested in my suggestions, some aren't. Not so long ago, I was being given a demo by two guys about their company's leading product.

"What features do you have that your competitors don't?" I asked.

"We don't have any competitors" was the reply.

Admittedly, these two guys were young, despite their impressive sounding titles of "senior something" and "something else seniorish". But even so you would think they would know better. So in the hope that they or their spiritual bretheren are reading this blog, let me give you a few words of advice.

The statement "We don't have any competitors" does NOT tell your potential customers that you have a fantastic new product which no-one has ever thought of. It tells potential customers that your product must be one they don't need. After all, if you have no competitors, the market must be so small that no-one else thinks it worthwhile to build a competing product.

So listen guys, get to know at least a couple of your biggest competitors. And find some weakness in their product which yours addresses. Then when I ask my question, you'll have an answer that doesn't suggest to me that you are working for a company that is going down the tubes because it can't train it's reps decently. Because "We don't have any competitors" is synonymous with "we have nothing of interest here".


Sun, bullets, and feet Blog

Posted by jacksjpt Feb 3, 2004

Filter Blog

By date: