The answer, in fact, is straightforward: Multibindings.

What is particularly neat about multi-bindings (aside from the fact they can inject a set of objects) is that they will accept bindings from multiple modules into the final aggregate set that is injected. Both sets and maps can be injected in this way. This example will use the MapBinder, as the base Guice example for Sets is fairly straightforward in its own right. Consider a music decoding application, for example. You might have simple decoder API that looks like this:

public interface AudioDecoder {
    String getAudioTypeName();
    void decode(InputStream encodedIn, OutputStream pcmOut);
}

Individual modules can inject their own audio decoding algorithm:

public class Mp3AudioDecoder {
  public String getAudioTypeName() { "MP3"; }
  public void decode(InputStream mp3In, OutputStream pcmOut) {
    // Run through LAME (or similar Fraunhofer) decoding here.
  }
}

// ...

public class Mp3AudioModule extends AbstractModule {
  public void configure() {
    Multibinder<String,AudioDecoder> decoderBinder
      = MapBinder.newMapBinder(binder(), AudioDecoder.class);
      decoderBinder.addBinding("mp3").to(Mp3AudioDecoder.class);
  }
}

What this does is register a binding with the multibinder from AudioDecoder to Mp3AudioDecoder; effectively registering that type as part of the total set of audio decoders. Consuming these via injection requires no special sauce; simply declaring you want to receive the map is all that is required:

public class RootModule extends AbstractModule {
  public void configure() {
    bind(AudioDecodingThingy.class);
  }
}
        
public class AudioDecodingThingy {

  private final Map<String,AudioDecoder> decoders;
    
  @Inject
  public AudioDecodingThingy(Map<String,AudioDecoder> decoders) {
    this.decoders = decoders;
  }

  public void run(String inputFile, String outputFile) {
    // Basic error handling.
    File in = new File(inputFile);
    File out = new File(outputFile);
    String extension = getExtension(inputFile);

    if(!in.exists()) throw new IllegalArgumentException("File " + inputFile + " not found.");
    if(!decoders.containsKey(extension)) throw new IllegalArgumentException("No decoder found for extension: " + extension);
    if(!out.exists() && !out.createNewFile()) throw new IllegalArgumentException("Unable to create output file: " + outputFile);

    AudioDecoder decoder = decoders.get(extension);

    // Do the decoding.
    try(
      InputStream in = new FileInputStream(in);
      OutputStream out = new FileOutputStream(out)) {
        decoder.decode(in, out);
    }
  }
}
        
public class Main {
  public static void main(String[] args) {
    Injector i = Guice.createInjector(
      new RootModule(), new Mp3Module(), new OggModule());

    AudioDecodingThingy thingy
      = i.getInstance(AudioDecodingThingy.class);

    thingy.run(args[0], args[1]);
  }
}

While this particular example (and the example on the Guice site) have the modules to snap-in defined directly in the code, it is not a stretch of the imagination to envision the possible modules to install coming from:

• A configuration file
• The built-in JAR service-provider and ServiceLoader facilities.
• A scan for all particular annotated types; something like @PluginModule

As a final disclaimer (one that is reiterated on the Guice site) Multibindings are not a replacement for a full modular architecture, like that which can be achieved with OSGi (in fact, Guice has support for OSGi as well). However, sometimes OSGi can be a power-drill, when sometimes all you need is a plain ol' screwdriver.

Multibindings, which are an extension to Guice, are shipped as a separate integration JAR file. All of the official extensions are available in the core Maven repositories under com.google.inject.extensions.

private Map<String,List<Something>> stuff = new HashMap<String,List<Something>>();

// ...

public void add(String key, Something item) {
  if(!stuff.containsKey(key)) {
    stuff.put(key, new ArrayList<Something>());
  }
  stuff.get(key).add(item);
}

public List<Something> get(String key) {
  return new ArrayList<Something>(stuff.get(key));
}

Google's Guava Libraries provide a few collections to help with this common case: com.google.common.collect.Multimap, and the more specific variants ListMultimap, SetMultimap, and SortedSetMultimap. The above code can be re-written with Guava like this:

private ListMultimap<String,Something> stuff = ArrayListMultimap.create();

// ...

public void add(String key, Something item) {
  stuff.put(key, item);
}

public List<Something> get(String key) {
  // might as well use the Lists convenience API while we're at it.
  return Lists.newArrayList(stuff.get(key));
}

The multi-map has a variety of fancy features that can be used as well. Here are just a few examples:

// returns a composite of all values from all entries.
Collection<Something> allSomethings = stuff.values(); 

// A more traditional map that can be edited.
Map<String, Collection<Something>> mapView = stuff.asMap();

// remove an individual entry for a key.
boolean removed = stuff.remove(key, someVal);

// remove all for a key
List<Something> removedSomethings = stuff.remove(key);

// One for each value in the map. Updating this collection updates the map.
Collection<Map.Entry<String,Something>> allEntries = stuff.entries();

All of the collections returned by the various API are views of the multimap. This can make it particularly easy to work with the map in a variety of ways. It does mean you should probably perform defensive copying anywhere you might be exposing these APIs (generally good practice in most cases, anyway).

• PHP is surprisingly hard to host scalably and efficiently.
• WordPress needs a rack of plugins installed to be even remotely performant - most of it gross caching schemes.
• I rather despise maintaining relational database installations.

I've never been a fan of PHP in any shape or form, so I think it says a lot about how burnt out I had become on trying to build a one-man CMS, that I was using WP, and singing its praises.

A post over at Nesbot.com inspired me to revisit my embargo on personal blog coding, as Brian Nesbitt detailed how he migrated his blog with Play 2.0. What struck me in particular was, not so much that he was using Play!, nor that he was now using the shiny 2.0 beta, but that he had built his site without any complex data-store on the back-end.

Suddenly: lightbulb! This triggered me to explore the ideas he so graciously shared with his public site code on github: https://github.com/briannesbitt/nesbot.com. Of particular note:

• His blog entries are simply Play! UI templates.
• The entire blog-entry history is loaded in memory at startup, and cross-indexed for the various navigation.
• The comment system is provided by Disqus.
• Blog entries are committed to GitHub, and ostensibly pulled to his server where he then simply restarts the server to load the new article.

I didn't spend much time actually digesting his code, but I appreciate that he posted his approach online, as it immediately got my gears turning. While I'm not quite ready to share the source of my site (more on this in a moment), I will share some details on the approach I've taken:

• Each of my blog posts is a template file, and has a "meta" comment on the top. This defines things like the title, a short summary, the publish date, tags (comma-separated), the category (journal or article), and optionally some additional compatibility bits, like a legacy id (see below). The comment is YAML formatted so I have some leniency as I'm authoring, and good error reporting if I get the formatting wrong.
• The file name represents the blog "slug".
• On startup, I spin through the entire post directory recursively, reading the header comments one-by-one, and tossing them into a series of in-memory indexes for traversal. The collections are sorted in date descending order, as that's the most generally useful ordering for the site.
• The re-load process can also be triggered by an administrative call through the HTTP interface. The reload is completely free of locks via some judicious use of atomic references.
• I'm also using Disqus for my comment system, like Brian. Importing from my existing wordpress site was, for the most part painless. I simply installed the Disqus plugin into my WP install, and did an export. The hardest part was supporting legacy identifiers. Turns out the IDs that it uses are: [wpid] http://[site-address]?p=[wpid] - this is where the legacy ID entry comes in to play above.
• I have a private git repo on my server, and every time I write an article, I simply push to the git repo. The server then pulls from the git repo, and I run the administrative reload.
• I'm using SyntaxHighlighter for code highlighting. The highlighters that are declared in the post are loaded in "on-demand", so the included JS is kept to a minimum.
• I have a few custom Play! tags to make writing blogs easier - they do things like reverse routes to other blog posts into anchor tags, create captioned image markup, and dynamically generate series blocks (as seen in my Distilling JRuby series).
• I'm using a Play profile ID on my server, and %prod. prefixes to support dev and prod properties concurrently in the same file.
• I'm using a variant of This Ubuntu up-start script to bootstrap my Play! Framework runtime.
• Thanks to the expressiveness of the the Play routes system, I was able to effectively model my URLs without any change in pathing to match the existing WordPress site. There are some exceptions, but they are only places where I felt a change was for the best.

I have immediately noticed a complete lack of latency on page loads, which I find quite refreshing. Occasionally one of the Javascript chunks blocks the page-load a bit (whether it be Google Analytics, Disqus, the syntax highlighter, or the Twitter widget, I can't say). I am keeping my eye out for this, and hopefully will figure it out with Firebug, and I can squash it. Overall, this has been a minimalist's dream as compared to something chunky like WP.

Before I globally share the blog code, I really wanted to get a few things tidied up (call me vain):

• Right now the administrative reload is a bit of a shim. I'd really like this to be an automated "on-git-update" event, so my involvement is simply a matter of avoiding malformed posting, and pushing the content.
• My error handling is pretty weak-sauce right now - I was slapping this together pretty quickly; the majority of my time was in converting my blog entries (which I did by hand, like an idiot).
• Right now I'm using Play 1.2.4 - I want to move to 2.0, but unlike Brian, I plan to wait until it's final before converting.

Once I get through those hurdles, I'll throw out a follow-up, and hopefully some public mirrors so folks can get some value (however small) out of my derivative journey. If you have any questions in the mean-time, send me a note.

A few weeks ago I posted that I had just moved to CloudFlare for my Media Temple hosted site. I received a good bit of feedback on the post, so I thought it would be good to do a follow-up that covers the things I've learned and my overall impression since I first enabled this service.

The first thing I will note is that I have had no technical issues with the service as of yet. It has run flawlessly since I turned it on and started tinkering. As you can see from the above graph, a steady flow of traffic has been sent through their system for my site, and I've had no complaints or known issues over the past several days. So far so good on that front.

I received some skepticism about the performance of CloudFlare from folks on Twitter, and although I admittedly didn't share any particular specs regarding the performance, it was clear from the seat of my pants that everything was faster. I decided to go ahead and do some analysis with a dumped cache, Firebug, and some hosts file editing so I could bypass CloudFlare.

Here is a snippet of the network downloads of my site running directly against my WordPress install:

From My Server

Here is a similar snapshot as pulled from CloudFlare:

From CloudFlare

As you can see - the latency from the CloudFlare servers is perceptibly better. Also note that while there is a built-in "wait" against my site (the purple section), there is effectively no wait from CloudFlare. Feel free to try this yourself against www.realjenius.com using the IP addresses above, if you'd like.

Now, to be completely fair, this isn't entirely apples to apples. One of the CloudFlare features I didn't tout when I did the initial write-up that I have since enabled is the automatic minification of resources. CloudFlare can automatically minify Javascript, CSS, and HTML in your site markup, and cache the result. This is even part of the free service. While I use some minified resources already, my basic site markup is not compressed (nor is the generated HTML markup for my posts), so there is definitely some benefit to be gained here.

When connected to my server directly, without a cache, the initial download was 417.4 KB. When connected through CloudFlare, the initial download was 293.4 KB. That's a pretty significant difference.

One other interesting metric: over the past month CloudFlare has delivered hundreds of MB of cached resources on my behalf; effectively free bandwidth for me. Here is a bandwidth graph for my server over the past three months from within the MediaTemple monitoring tools - as you can see, there is a clear reduction (and stabilization) of the bandwidth consumption once August hits.

Overall, after the better part of a month, my opinion of CloudFlare is still a very favorable one. I haven't made the jump to paid service as of yet, but am considering it much more strongly as the days progress.

Today, Media Temple announced a partnership with CloudFlare, a content delivery network and security layer for websites. This is an interesting partnership for a number of reasons:

• CloudFlare performs content caching and delivery. This means that static content will be distributed regionally, and from (ideally) faster and more redundant hardware than your own. CDN distribution is almost always a good thing.
• Additionally, CloudFlare shields your system from many malicious attacks, and also monitors for malicious activity (think botnets, spam, email scraping, etc).
• The CloudFlare integration is, generally speaking, completely transparent. This is possible because CloudFlare is actually a site proxy. Unlike many CDN platforms, where you must route static content to some staticcdn.url.somewhere, CloudFlare is the top-level destination for your DNS, and then internally routes traffic from their system to yours, anywhere it need be dynamic.
• For your first personal site, CloudFlare is free!

As of early yesterday morning (just after it was announced), RealJenius.com has been running on CloudFlare. Over time, most of the traffic has migrated; since it relies entirely on DNS propagation, it takes a little time. I experienced a blip with my local router's DNS cache that temporarily made my site in-accessible, but that had nothing to do with the process, and aside from that it has "just worked". It took me no more time than it takes to brew a single Keurig cup of coffee.

This site runs on a Media Temple (ve) with Nginx, and I had to perform no manual intervention. I clicked through the wizard to set up my site, and despite hosting several sites on my VPS, Media Temple suggested options, and choosing the correct domain re-wired the correct ANames, and everything has seemed to run along perfectly fine.

The Traffic Starts!

Since then, I've logged in to CloudFlare, and I'm just starting to see pretty graphs of traffic. The lines indicate different information:

• Green indicates valid requests.
• Purple indicates requests from addresses flagged as spam generators.
• Red indicates threat traffic: bots and other malicious requests looking for vulnerabilities.

CloudFlare also shows bandwidth and traffic savings, and as it stands now, nearly 40% of the traffic to my site has been reduced thanks to the service, and multiple MB of bandwidth. This is prior to full DNS propagation, so I only expect it to increase. Other stats are available about how often search engines have scanned your site, unique visitor counts, and a bevy of information about visitor locality. A lot of the information provides a good corollary to Google Analytics (another service that is surprisingly free).

Up to this point, my description of the service has probably made you think "what's the catch?" - admittedly, I wondered the same thing when I took the blue pill. In reality, there isn't one, other than hooking you with free candy. CloudFlare is a tiered service. The free version, which is what is offered out of the gates to Media Temple hosted folks, is free even directly through their site; Media Temple has just seamlessly integrated the services so it's easier to enable (which it definitely is). They also have a Pro and Enterprise tier - from which there are a number of benefits:

• More control over threat level management - The free version runs with a default threat level, of which you have limited control.
• Real-time traffic statistics - The reason I'm just now seeing traffic stats for my site is simply that they are delayed 24 hours on the free version.
• Better caching - The pro mode promises "faster subsequent page loads" via the use of prioritized/optimized caching (most important resources) and a smart pre-fetching system.
• Other features can be found on their Pricing & Features page.

CloudFlare's pro plan is currently $20 a month for the first site, and $5 a month for each additional site. Overall, two thumbs up from me regarding ease-of-installation, price, and (at least so far) performance. I'll probably report back when I've had more time under this new umbrella.

It's no surprise Java developers are trying to branch out: Java 7, which was nearly five years in the making, barely evolves the language features at all; most of the promised game-changers for the language (lambdas, extension methods, modules) were deferred to Java 8 due to lack of consensus and time. Java has become stagnant, too verbose, and too crufty for developers that have seen the greener grass on the other side.

Unfortunately, most JVM developers in the wild are still using the Java language in some capacity, and it seems to be fairly common in companies that there is a distinct reason that an alternative VM language hasn't been adopted in its place. The reasons may not satiate the idealists of the JVM-based community, but they do exist. Just to name a few:

• Corporate restrictions
• Concerns about code maintainability
• Team skill-sets and strengths
• Stability and performance of the various language platform
• Lack of top-grade IDE support

Frameworks, on the other hand, often seem to be an easier pill to swallow. The barrier to entry for developers is often lower, the scope of impact on your application can be less pervasive, and your tools and team skill-sets are not stretched nearly so far. In reality, some frameworks (*cough*Spring*cough*) actually add more complexity than any language shift would, but this is unfortunately a game of perception. As it pertains to frameworks in the post-Java JVM world, those of you that follow my blog or Twitter account know that I'm a big fan of the Play! Framework, as it re-imagined what it means to write a Java web application, and it also provides an easy gateway into Scala. It shows that while Java the language is falling behind, it isn't a complete wasteland for developers craving more.

A co-worker recently pointed out another intriguing Java framework that, while not being as full-featured or targeted for large applications as Play!, has a lot to offer to this neo-Java world: enter Spark.

Those of you who have worked with (or at least seen) Ruby's Sinatra framework will instantly feel home (and perhaps vaguely disgruntled) with Spark. Spark is effectively the Sinatra-style of web-binding, using Java syntax. Here is an example from their home-page:

import static spark.Spark.*;
import spark.*;

public class HelloWorld {

   public static void main(String[] args) {
      
      get(new Route("/hello") {
         @Override
         public Object handle(Request request, Response response) {
            return "Hello World!";
         }
      });

   }

}

The general idea behind Spark is to make the binding between a URL to the actual code being run as thin as possible - allowing you to focus on servicing the request. When compared to many frameworks, the list of features it doesn't have may be disconcerting; but, there is a certain power and portability in the simplicity. The self-coined term "micro-web-framework" is really only true due to the sheer volume of complexity and features that Java web frameworks have decided to provide (or impose) in the last few years.

Like Play!, Spark focuses on using very human-readable API design. The central component of Spark is the callback which handles the request. As seen in the above example, this is provided by the developer via a subclass of "Route". What happens inside the callback to build the result is entirely up to you.

While Spark doesn't get involved in the "manipulating data" part, there are a handful of features and utilities available to help with the control of HTTP-level web-flow. Some of these include:

• Filters - These are callbacks just like the routes that can be run based on certain URL patterns, allowing for functionality to be applied orthogonal to a set of requests.
• Request/Response Wrappers - The servlet request and response classes are well known (and often loathed) for their design. Spark, like many frameworks, wraps these to help conceal the suck.
• Halt Commands - This is an increasingly popular API design in web frameworks: methods that set an HTTP status code, and fail with an exception immediately.
• Redirects - Browser redirects are made particularly simple.

All of these features are shown in more detail on the Spark Readme Page.

Spark's main facility for running is to start up an embedded Jetty server to automatically handle requests. This is right in-line with how Sinatra functions by default, and provides a quick and easy process for developers to get their application going to test and do development. While not documented on the site, Spark does support a deployed mode where it can be run inside of an already-deployed application server as a WAR with a web.xml file. This is done via the spark.servlet.SparkFilter class, which is a servlet filter that can route requests to your application.

In summary: it's unlikely you would want to implement your entire enterprise on Spark, but that's not really its goal. Spark is really targeted for quick-to-live "scrapplications"; getting something together in a short amount of time, and in the hands of users, without the pomp and circumstance of importing 900 JARs, and creating 35 configuration files. It explicitly avoids imposing a particular application model, data model, or really any dependencies at all on the developer, instead offering a small expressive Java API (as expressive as Java gets anyway), that allows you to quickly map blocks of Java code to RESTful HTTP routes. Overall - definitely worth checking out.

Enjoy!

In concept I have no problem with this sort of support. There are innumerable examples on the web of absurd Java try/catch/finally block hierarchies to properly managing input streams and output streams; something that is the norm, not the exception to the rule.

InputStream in;
try {
  in = loadInput(...);
    OutputStream out;
  try {
    out = createOutput(...);
    copy(in, out);
  }
  finally {
    if(out != null) {
      try {
        out.close();
      }
      catch(IOException ioe) {
        // Problem closing the output stream.
      }
    }
  }
}
catch(IOException e) {
  // Problem reading or writing with streams.
  // Or problem opening one of them.
}
finally {
  if(in != null) {
    try {
      in.close();
    }
    catch(IOException ioe) {
      // Problem closing the input stream.
    }
  }
}

I'm not even showing here how you handle the situation where reading/writing caused an error, and closing one or both of the streams caused an error. You want a way to cleanly collect all of these up into one exception bundle that can be properly logged/handled, but short of rolling your own wrapper exception to potentially hold all conditions, there simply is no way.

This abhorrent pile of braces can be cleanly tightened up with the new facilities in Java 7 like so:

try (InputStream in = loadInput(...); 
     OutputStream out = createOutput(...) ){
  copy(in, out);
}
catch (Exception e) {
  // Problem reading and writing streams.
  // Or problem opening one of them.
  // If compound error closing streams occurs, it will be recorded on this exception 
  // as a "suppressedException".
}

Java will know how to close items in the try parenthesis by those elements implementing the "AutoCloseable" interface. This is much like the "Iterable" interface that was added to support the enhanced-for loops in Java 5.

Clearly this code is much cleaner, and automatic resource management is a facility that Java has needed (for a lonnnnnngg time) - so why am I miffed?

This feature, which is consuming a non-trivial amount of draft specification time and development time to get right, is being implemented as a language feature via the use of compiler changes - again, much in the same way as enhanced-for was implemented. For the record, I was miffed about enhanced-for as well (although I do use it regularly).

Adding this as a language feature, rather than a library feature, bloats the compiler specification and implementation, and completely hides the real implementation in generated code. It's functional to a point, but is not extensible by developers. Sadly, none of this would be necessary at all if Java 7 shipped with lambda/closure support, and I think the syntax is more natural. Here is a naive Ruby file copy/transform algorithm.

begin
  File.open("myInput.txt", "r") do |in|
    File.open("myOutput.txt", "w") do |out|
      in.each_line do |line|
        out << line.upcase << "\n"
      end
    end
  end
rescue exc
  # Exception occurred reading/writing!
end

Now, admittedly the syntax is very different than the Java version - the most notable difference is that the Ruby version is actual three nested lambas, where as the Java version is sort-of two lambdas (one to open the resources, one to work with them). I say sort-of, because the first is this special quasi-code-block that also magically accumulates opened resources for later closure.

I find the lambda version to be much less hand-wavy - the syntax is naturally intuitive and more flexible. I should also note that the inner-most lambda, which iterates over lines in the file, shows that the enhanced for loop in Java is completely unnecessary as well if you have lambdas.

Using one of the proposed syntaxes for Java lambda support (as ugly as they can be), let's take a shot at this same idea with Java:

try {
  File.read("myInput.txt", { in ->
    File.write("myOutput.txt", { out ->
      in.eachLine( { line ->
        out.write(line.toUpperCase() + "\n");
      });
    });
  });
}
catch(IOException e) {
  // handle as appropriate. Can still have suppressed exceptions on it.
}

This is just one way this could be implemented; because it only relies on functions, how expressive the APIs are is up to the library designer, not the language designer. An important distinction. Why build special scenarios into the compiler when one language feature can provide the flexibility you need?

Now - is this as short and tab-friendly as the Java 7 feature? Admittedly no. However, the goal of the try-with-resources is not to save on typing, but rather, to ensure resource management is as accurate as possible, relying as little as possible on the developer to dial-in boilerplate, and error-prone exception management.

Here is a short run-down of the library changes that would be required to support this particular code:

• java.io.File needs a new method called "read" which takes a String file name, and also takes a function that accepts a java.io.FileReader, and returns nothing. The code block may throw an IOException. This method does all of the resource management for the FileReader it provides to the function. If the code block throws an exception and closing the file reader also throws an exception, the method would add the close exception to the main exception as a suppressedException (just like the language feature would).
• java.io.File also needs a new method called "write" which takes a String file name, and also takes a function that accepts a java.io.FileWriter, and again, returns nothing. This can also throw and IOException, and just like the read method, it handles all of the minutia of exception suppression and resource-closing.
• java.io.FileReader needs a new method called "eachLine" that simple scans for line-terminators and lets a provided function see the string representation of each line. The function may throw IOException, and the method simply lets IOException propagate.

Just to circle back around - Java today could support the "eachLine" method on FileReader via enhanced-for loop, if the "eachLine" method returned an Iterable (as opposed to accepting a block of code) - it could look something like this:

for(String line : in.eachLine()) {
  out.write(line.toUpperCase() + "\n");
}

If you're as lured by the (ve) as I was, let me give you some details from my experience:

• Provisioning is lightning-quick. I ordered the server, and it was available within 5 minutes.
• It is truly as they say: just a Linux box with SSH. For my install, I was given a stripped down Ubuntu 10.04 server instance and told "Go Play!".
• For that reason I would recommend, if you are migrating from somewhere else, that you practice the migration on a VM somewhere, like with VirtualBox. Since you're responsible for the "whole shootin' match", it's in your best interest to have everything inline to make your transition as seamless as possible.
• Post-install configurations are everything! I have been using pre-packaged VPS solutions for so long, I forgot that they spend a lot of time tweaking and tuning software to fit in a box the size they choose. Software like PHP, Apache, MySQL, Java, Tomcat, etc - all comes with default values and selections that, I guarantee you, are different than most VPS's are running.
• Aptitude is your friend! I chose Ubuntu because I knew how blindingly simple the package manager was to use. The installation of Apache, PHP and MySQL support (while not tuned) was literally only bound by the time to download the packages. My job was to sit and watch it work.

I chose to do a number of things to tune my installation after I got it up and running. There are a lot of things to consider when you are your own sys-admin!

Tuning Apache Memory

First - tell Apache to calm down on memory usage. The default Apache install will use massive amounts of room in each thread stack (mostly because Linux tells it to). In reality, unless you're expecting to handle some pretty impressive load while shipping some pretty impressive HTML, you probably don't need 8MB per stack. To detune Apache in Ubuntu 10.04 to use less memory, you can edit '/etc/init.d/apache2' and put a stack-ulimit adjustment at the top of the file:

ulimit -s 256

Lowering my stack for Apache to 256k (which coincidentally is Java's default stack size), lowered my memory usage for Apache and whatever else was on the box at the time (running standard pre-fork) from 750MB, to 280MB. Now, that includes virtual memory and everything else - but when you've only got 1GB to work with, that's a pretty significant savings.

Switching Apache's Multi-Processing Module

The next thing I did to trim the Apache fat was to switch to mpm-worker threads instead of mpm-prefork. Now, most folks may comment here that mpm-worker actually uses more memory at idle, and while that's technically true, it is much more predictable and scales much better from a memory perspective (think threads vs. processes if you are a Java or Ruby developer). It also generally happens to be faster, which is a nice benefit.

Unfortunately, when you move away from pre-fork, you also move away from easy PHP installations. To get PHP to work with mpm-workers, you have to use something like FastCGI, which acts as a PHP worker process pool that runs outside of the Apache process. Now - I made this a lot harder on myself by trying to host sites outside of /var/www - I wanted all of the folks sites I host to be under their respective home folder: /home/guy-who-mooches/guys-site.com/yadaydayada (just kidding people who I host!). I'll point you to several articles on the net about it:

• http://www.howtoforge.com/how-to-set-up-apache2-with-mod_fcgid-and-php5-on-ubuntu-8.10
• http://www.chriswiegman.com/2010/06/running-apachefastcgisuexec-in-ubuntu-10-04-without-varwww/
• http://www.unixguru.biz/howto-apache2-suexec-php5-and-fastcgi-for-virtual-domains/
• http://www.linode.com/forums/viewtopic.php?t=2982

All of these sites have different (albeit similar) approaches. The key things to double check in this effort are:

• Install apache-suexec-custom  (the 'custom' is key!). Some sites suggest that you have to compile your own apache-suexec install; this is no longer true (that's what the custom is for).
• Leave Apache running (or make Apache run) as 'www-data' - I made the mistake of switching it to the user apache/apache, and getting suexec-custom to work with that user was a fool's errand for me.
• With 10.04, you have to edit the file in /etc/init.d/apache2/suexec called 'www-data' and change the first line from '/var/www' to wherever you want suexec to be allowed to run from (for me it had to be '/home').
• You'll need to create a wrapper script for each user. Don't use symbolic links. This wrapper script must have that user as the owner/group (whatever user is going in the suexec directive, anyway).
• Pay attention to the properties you set in the wrapper script! They have drastic impacts on both performance and resource utilization. You need to have a feel for your site's intended usage to be able to tune these.
• The suxec directive and FCGI wrapper directives in the Virtual Host file vary in every article I read about this (there is more than one way to skin a cat) - I tried both the Action/AddHandler combo approach, and the FCGIWrapper approach. FCGIWrapper is simpler, but Action/AddHandler is more flexible. I'd start with FCGIWrapper to get it working, and when you are feeling more confident, try action/addhandler if you think you need it.

Anyway - rather than rehash a full walk-through, I felt it would be better to provide some bullet-points. Until I embraced understanding how FastCGI actually worked, I found I was struggling to properly implement it. So take your time, read the articles, try to understand the scripts, and come back here and read my tips. I think you'll be better off for it!

Best Apache Tuning Tip

Many folks say the best Apache tuning tip is to use Nginx. That may be true - I wanted to move fast, and I know very little about administering Nginx. I know that I will have to do some .htaccess file conversion... so maybe in a couple weeks.

User Management

I highly recommend creating a non-root user for yourself. Giving that non-root user sudo access gives you enough of a barrier to be careful, but still gives you the flexibility you need to administer. In Ubuntu, sudo-ing requires that your user be in the "sudo" group. That's as simple as:

usermod -G sudo [username]

Use Identity Files

This is a huge boon in my opinion. Identity files are much more secure than passwords, and can make your login process faster (if you're willing to trade-off the security of a passphrase). Here is a great article about it: http://www.csua.berkeley.edu/~ranga/notes/ssh_nopass.html

Learn to SSH Tunnel

SSH tunneling is secure. If you know how to tunnel, there is no reason to want to install PHP My Admin for example. It's a security risk (don't believe me? scan the Apache access logs of any decently popular domain, and you will see hack-attempts against dozens of phpmyadmin common URLs), and it's not a very awesome administration tool. Meanwhile, MySQL administrator and MySQL Query Browser are awesome and just need an HTTP port. Here is one way to do it:

ssh -L 1234:127.0.0.1:3306 myuser@myfakeserver.com

This forwards the port 1234 on your machine to port 3306 on your server (which is the default port for MySQL). Then, when you open MySQL Administrator/Query Browser, just try to connect to 127.0.0.1 on port 1234. Now you have full administrative access to MySQL (bells and whistles abounding) and you can be comfortable that the traffic is encrypted.

Tunneling with -D (dynamic SOCKS proxy) is also an excellent way to monitor a Java instance as well, using VisualVM and JMX (http://stackoverflow.com/questions/1609961/visualvm-over-ssh). Again, totally secure monitoring of a running JVM - hard to beat.

Conclusion

Media-Temple's (ve) offering is excellent in my estimation. The servers are fast, the memory #s are phenomenal (especially considering you can run whatever you want), and you have total unadulterated control. Two-thumbs-up MT!

gem install bundler

mkdir testapp
cd testapp
edit Gemfile

source :rubygems
gem "sinatra"
gem "glassfish"

require "rubygems"
require "bundler"
Bundler.setup

require "sinatra"

get '/hi' do
	"Hello World!"
end

realjenius$ bundle exec hello.rb
== Sinatra/1.0 has taken the stage on 4567 for development with backup from WEBrick
[2010-07-17 11:24:46] INFO  WEBrick 1.3.1
[2010-07-17 11:24:46] INFO  ruby 1.8.7 (2010-06-06) [java]
[2010-07-17 11:24:46] INFO  WEBrick::HTTPServer#start: pid=44490 port=4567

realjenius$ bundle exec glassfish
Log file /Users/realjenius/Projects/testapp/log/development.log does not exist. Creating a new one...
Starting GlassFish server at: 0.0.0.0:3000 in development environment...
Writing log messages to: /Users/realjenius/Projects/testapp/log/development.log.
Press Ctrl+C to stop.

Running sinatra