…similar solutions for addressing the scalability challenges:

On the Data Tier we see the following:

1. Adding a caching layer to take advantage of memory resources availability and reduce I/O overhead

2. Moving from a database-centric approach to partitioning, aka shards

On the Business Logic Tier:

3. Adding parallelization semantics to the application tier (e.g., MapReduce)

4. Moving to scale-out application models to achieve linear scalability

5. Moving away from the classic two-phase commit and XA for transaction processing (See: Lessons from Pat Helland: Life Beyond Distributed Transactions)

… a repository of information collected from one run and used on another run is on the list for things we want to do in Dolphin. It’s actually on the runtime groups list but we will certainly take advantage of it. There has also been talk of using annotations to give the jit a hint. This actually isn’t too popular since it is too much like “register” declarations in C. It’s only a hint and is too often abused.

…this program below does nothing visible on Solaris, but prints “hello” with Sun Java SE on Linux and Windows:
public class Foo {
public static void main(String[] args) {
Thread.currentThread().interrupt();
System.out.println(“hello”);
}
}
First impressions of this program’s behavior on Solaris roughly translate to “The hell you say!” followed by “Java is broken on Solaris!” There are a number of “symptoms” of interruptible I/O that catch users off guard and in a few cases one is led to wonder if it might be best to do without this feature whose flip side is that it allows “breaking out” of I/O operations that folks really want to be able to escape from.

…consider the strengths in performance and reduction in development that can be added by leveraging a high-quality CMP container as opposed to developing data access logic using a BMP architecture. I guarantee you’ll be happy with the results.

Excellent post! I couldn’t agree more, the debate mirrors the one around the merits and usefulness of automatic garbage collection. Sure you can manage memory yourself, but how much are you willing to pay for that vs. the performance hit you’d take in a garbage collected environment.

One issue that comes up often in this debate is the quality of the underlying SQL generated by CMP containers. The problem stems from the fact that one has very little, if any, opportunity to tune the generated SQL, and that it’s usually an all or nothing proposition. Hibernate, and to some extent Toplink, have attempted to address this but there’s still a long way to go for CMP containers to bridge this gap.

The amount of live data that is in the tenured generation is too large. Specifically, there is not enough free space in the tenured generation to support the rate of allocation into the tenured generation.

The libjit library implements Just-In-Time compilation functionality. Unlike other JIT’s, this one is designed to be independent of any particular virtual machine bytecode format or language. The hope is that Free Software projects can get a leg-up on proprietry VM vendors by using this library rather than spending large amounts of time writing their own JIT from scratch.This JIT is also designed to be portable to multiple architectures.

Most scaling and performance challenges are almost always related to the data layer, and are common across all language platforms. Even as a self-proclaimed PHP evangelist, I was very startled to find out that all of the theories I was subscribing to were true. There is simply no truth to the idea that Java is better than scripting languages at writing scalable web applications. I won’t go as far as to say that PHP is better than Java, because it is never that simple. However it just isn’t true to say that PHP doesn’t scale, and with the rise of Web 2.0, sites like Digg, Flickr, and even Jobby are proving that large scale applications can be rapidly built and maintained on-the-cheap, by one or two developers.

Let’s not confuse the Java runtime with the language itself, I’m sure one can write “scalable” apps in Logo as well as long as the deployment is horizontal.
The truth is the comparisons are bogus, Java and scripting languages are more complimentary than competitive. Now if/when Java runtimes will add support for dynamically typed languages (the ‘Invokeddynamic’ bytecode), we’ll probably see a noticeable rise in adoption of hosted (JRuby, Jython) scripting languages within the “enterprise”, as RAS and deployment issues will no longer be the (biggest?) stumbling blocks they are now.

When a production system performance issue is reported resist the temptation to study system wide statistics and extrapolate, particularly if they are historic smoothed averages with no indication of standard deviation (e.g. historic sar data taken by five minute samples in cron). It is usually far more fruitful to identify the thread of execution which is the basis of the complaint (e.g. the report is running slowly, my screen is updating slowly, etc.).

If you want to keep producing high-performance software, you must be able to run reproducible, comparable performance tests. Ideally, you’ll have dedicated, standard hardware on which to run these tests; this should be representative of, if not directly comparable with, what your customers run in production. You’ll run a basic set of performance tests as part of your release cycle, plus more comprehensive benchmarks as required.So what should you test? What is important? You need to find a balance between the time it takes to run the tests and the information they actually give you. A large set of complex tests can tell you a huge amount about your application and even help you track down areas that have caused performance degradation, but that might be too time consuming to run for every release. Simpler tests that can run automatically in less than an hour would be better. Furthermore, your tests need to measure something using public interfaces that are stable between releases; otherwise, maintaining the tests will become an overhead.
Of course, the tests must exercise the operations and code paths that are important to your customers. They must measure the throughput of the common transactions or queries, based on the types of datasets and loadings seen on production systems. If practical, a captured production workload that can be rerun on demand would be ideal.

Chances are your algorithm is good, so you should do some hunting elsewhere. Use the tools you have today, such as DTrace or VTune. Ask where the application is spending its time. If it is in the code, you’re back to where you started, but I would be willing to bet if you’re having massive performance problems, it’s not directly in your code or more precisely, what you think is your code.