Java I/O

This presentation gives a good overview of Java I/O, from which I have learned:

• FileInputStream/FileOutputStream: for sequential I/O and simple to buffer
• RandomAccessFile: for full random-access
• FileChannel: adds support for NIO byte buffers
• MappedByteBuffer: for memory-mapped I/O
• Buffering: for instance, use BufferedOutputStream for buffering FileOutputstream
• Forcing I/O, e.g. flush() or FileChannel.force(), equals to the "fsync" system call
  
• No direct I/O in Java

Google File System

The Google File System is a scalable distributed file system for large distributed data-intensive applications, being used within Google. The paper, published in the 19th ACM Symposium on Operating Systems Principles, is a well written computer engineering paper. System builders should read it.

Quoted from its conclusion:

"We started by reexamining traditional file system assumptions in light of our current and anticipated application workloads and technological environment. Our observations have led to radically different points in the design space. We treat component failures as the norm rather than the exception, optimize for huge files that are mostly appended to (perhaps concurrently) and then read (usually sequentially), and both extend and relax the standard file system interface to improve the overall system."

Lesson learnt:

• Application driven.
• Base on the technological environment. Base on the facts of performance characteristics. Performance benchmark is the foundation for system design.
  
• Application/file system (or OS, or underlying infrastructure, etc.) co-design.
• Optimize for what should be optimized.
  

"Our system provides fault tolerance ..."

Lesson learnt:

• Reliability is a must for any system. System must work. Never forget reliability, persistence, fault tolerance during system design.
  

"... This makes possible a simple, centralized master that does not become a bottleneck. ..."

Lesson learnt:

• Down to earth.
• ...I had already come to the conclusion that in the practise of computing, where we have so much latitude for making a mess of it, mathematical elegance is not a dispensible luxury, but a matter of life and death. - Edsger Wybe Dijkstra ["My hopes of computing science" (EWD 709)]

elegant: [...]ingeniously simple and effective. - Concise Oxford Dictionary

This elegance makes perfect sense in the domain of system design. May we say in system design, elegance is not a dispensible luxury, but a matter of life and death.

A Very Interesting Story

Copied from Ian Foster's blog.

<CopiedContent>

Hadoop on EC2

Here's something neat (and details here).

Hadoop, an open source clone of Google FS and MapReduce, can be run on top of Amazon EC2, a hosting service that allows leasing servers on an hourly basis.

As Greg Linden goes on to say:

Developers may now be able to rapidly bring up hundreds of servers, run a massive parallel computation on them using Hadoop's MapReduce implementation, and then shut down all the instances, all with low effort and at low cost. Very cool.

My colleague Tim Freeman points out that you can run those same VMs on your own resources using the Globus Workspace service.

</CopiedContent>

I got a feeling that parallel computing becomes more and more available, and has better and better programmability.

The Outcome of MPT

Here is a visualized outcome of MPT. The x-axis is the number of processors used in the throuthput test (1 - 32). The y-axis is the number of threads per processor (1 - 16). The z-axis is the measured throughput. More precisely, it is the number of service discovery (by name) requests served in 30 minutes when there are 5000 service descriptions registered in GRIMOIRES. When 32 processors and 16 threads per processor are used, GRIMOIRES can serve 62,877 service discovery requests in 30 minutes , i.e., 34.9 per second. Each request costs 28.6 milliseconds.

Monitor the Blog and Benchmark the Program

I am using Google Analytics to monitor visits to my blog. See the picture, in which the dots indicates where somebody has visited my blog. There is even one returning visitor. Not bad!

It is a good practice to start monitoring since the website is established. Just like it is a good practice to start benchmarking since the program is prototyped.

Monitoring is an inherent requirement of a website. Thus it should become a part of website infrastructure. I.e., when you establish a website, your website is automatically being monitored. No webmaster effort is involved.

Just like benchmarking is an inherent requirement of a program. Benchmarking should become a part of development environment. When you prototype a program, it costs you zero or little effort to benchmark the program. Some benchmark specific code should be automatically added into your program. Thus according to the benchmark data, you can make a decision on whether to take a certain refactoring or not. Will Aspect-Oriented Programming help on this?

Use VMware to Release Server-Side Software

I am using WMware's free VMware Server to create a GRIMOIRES virtual appliance. I admit it is not very easy to install GRIMOIRES. And I believe it is not easy to install any server-side software, probably because of the tedious and error prone procedure to configure, for instance, backend database, and security.

While VMware is able to relieve this pain. We create a VMware virtual appliance, which includes OS and our software. Our customer simply downloads it, and is able to play it, thus avoiding the painful installation procedure. The size of the VMware virtual appliance could be much much bigger than the size of our software. But who cares. Our computer spends more time in downloading, but we spend much less time in installation.

Massive Parallel Test Kit

I have implemented a Massive Parallel Test Kit (MPT) whose major goal is to measure the throughput of a server. While in my case, MPT is used to measure the throughput of our web service registry, GRIMOIRES.

MPT has the following features:

• MPT is an MPI program. So it is able to create a large number of real parallel clients on a computer cluster to generate a large number of requests simultaneously. That is why it is claimed to be "massive parallel". By the way, it is really convenient to program a cluster using MPI.
  
• Each MPI process invokes a Java program, ThroughputTest. ThroughputTest provides basic functionalities required to run a throughput test. Above all, it supports user provided plug-in, called Worker, which implements the actual test business logic.
  
• In fact, Worker extends Thread. Thus two forms of parallelism are leveraged in MPT: multi-processing at the MPI level, and multi-threading in at the Java level.
  
• MPT has a single control point. The degree of multi-processing, the degree of multi-threading, and the test time are all set as the parameters for the MPI program. The latter two are then passed as environment variables to ThrouputTest.
• The fairness of the service can be revealed by calculating the deviation of the throughputs measured by individual MPI processes.

I believe MPT is a useful tool to conduct a stress test for web services. A cluster is useful for a building and testing environment for web services. After more tests of MPT, I will release it at the GRIMOIRES project website.