Amazon EC2 now offers STATIC IPs
Posted by jonchase
This is great news for any Amazon EC2 (Elastic Compute Cloud) developer - up until this point, hosting web sites on EC2 has been a little tricky due to the fact that EC2 instances used dynamic IPs - making it tough to set up reliable load balancing and failover in the face of ever-changing IP addresses.
From the email I just received (below), it looks like this may no longer be an issue. Also in the email is the announcement of Availability Zones - groups of EC2 instances in different physical locations and networks, which will help ensure that if your site goes down in one availability zone, your instances in another zone won’t be affected.
Here’s the email:
Dear Amazon EC2 Developer,
This is a quick note to let you know about some exciting changes with Amazon EC2. We are happy to announce two significant new features - Elastic IP Addresses and Availability Zones - which help you to run reliable web sites and other applications within Amazon EC2.Elastic IP Addresses are static IP addresses designed for dynamic cloud computing, and now make it easy to host web sites, web services and other online applications in Amazon EC2. Elastic IP addresses are associated with your AWS account, not with your instances, and can be programmatically mapped to any of your instances. This allows you to easily recover from instance and other failures while presenting your users with a static IP address.
Availability Zones give you the ability to easily and inexpensively operate a highly available internet application. Each Amazon EC2 Availability Zone is a distinct location that is engineered to be insulated from failures in other Availability Zones. Previously, only very large companies had the scale to be able to distribute an application across multiple locations, but now it is as easy as changing a parameter in an API call. You can choose to run your application across multiple Availability Zones to be prepared for unexpected events such as power failures or network connectivity issues, or you can place instances in the same Availability Zone to take advantage of free data transfer and the lowest latency communication.
With these two new features, it now easier than ever for you to isolate your application from common failure scenarios and host high availability web sites in Amazon EC2.
For more information on how to best leverage this new functionality, please see our Feature Guides for Elastic IP Addresses and Availability Zones.
Sincerely,
The Amazon EC2 Team
Programming with Amazon’s Web Services? Buy this book.
Posted by jonchase
I know I’m going to, just for the cool fish on the cover and the unbelievably long title: Programming Amazon Web Services: S3, EC2, SQS, FPS, and SimpleDB.
Groovy Micro Benchmark Revisited (Groovy is fast…)
Posted by jonchase
Alright, no more Groovy posts for a while after this one. In fact, I hadn’t planned on posting about this again, but I thought it was worth mention.
From the last post, we saw the following results for parsing an XML dataset with about 450 simple elements in it 1,000 times:
- Java: ~9 seconds
- Groovy: ~28 seconds (with new results below…)
I decided to rerun the test for Groovy because of a comment John Wilson left on the first post. He suggested this more concise syntax for the Groovy implementation:
I reran the same benchmark, and I was very, very surprised at the results:
- Java: ~9 seconds
- Groovy:
~28~9 seconds
All I can say is wow. I’m not sure what is happening differently, but I’m happy:)
Any ideas what was taking up so much time in the original Groovy implementation?
Groovy Micro Benchmark
Posted by jonchase
Following on from the previous post (and here’s the last post), here’s a very quick and dirty, completely unscientific, prone to error, your mileage may vary micro benchmark I did using the code in the last post.
Date set: a String containing roughly 450 XML elements in the form <contact name=”some name” email=”some email” />
Methodology: I wrote driver programs in both Groovy and Java to run the test. Here’s the one from Java (the Groovy one is similar):
As you can see from the code, very quick and dirty. The test iterates 1,000 times and then prints out the time consumed.
I ran the test several times on my laptop (2Ghz, 2GB ram, blah blah blah it doesn’t really matter here) and here are the general results for total execution time for 1,000 iterations:
- Java: ~9 seconds
- Groovy: ~28 seconds
Quite a difference. I suspect part of that has to do with my inefficiency as a Groovy programmer. Certainly though, you can see that there is measurable difference in performance. I wonder what type of XML parser the Groovy implementation uses behind the scenes. The Java implementation uses SAX. If Groovy were using DOM with XmlSlurper, I could see that making a very large difference. Any experts care to chime in?
Now, before you decide to write off Groovy, another metric of interest might be seconds required to develop the code. It was something like this:
- Java: ~ 1,800 seconds - roughly 30 minutes. (First I had to decide what XML library I was going to use - JDOM? Dom4J? Xstream? Then I had to search and search for documentation on JDOM…and of course I had to download JDOM, well, that is, I have to add JDOM as a dependency in my Maven pom.xml (after I looked up the current version of JDOM at the ibiblio repo), and rebuild my Eclipse classpath with the new JAR on it, and then figure out how to use the JDOM API…) I’ve been writing Java for about 6 years, so I consider myself fairly adept.
- Groovy: ~300 seconds - roughly 5 minutes. (I had to find the page on the Groovy wiki that explained how to process XML.) I’ve been writing Groovy for less than 2 weeks.
So there you have it, my quick and dirty, completely unscientific, prone to error, your mileage may vary micro benchmark.
I’m not one to reserve judgment, so here goes:
- First, this is just one example. Comprehensively measuring performance is a complex thing, and this benchmark doesn’t claim to do that. There is no such thing as saying “Groovy is slow”.
- Second, I’d gladly trade the frustration and time requirement of the Java solution for the easier to read and write Groovy solution. Servers are cheap. I’ll almost always choose to pay the price in $$$ (which I can always get more of) rather than time (which I can never have enough of).
Update: here’s the final post in this series.
Groovy is Coming…
Posted by jonchase
I’ve been trying to slowly integrate some Groovy into my normal Java coding. Here’s just one of the reasons why:
Java code:
Groovy code:
Note that this reduction in complexity happens almost everywhere I choose to use Groovy over Java. Of course there are myriad other ways I could have done this in Java (I even tried Xstream but I couldn’t figure part out so I gave up). The point is that the first way I chose to do it in Groovy was natural, expressive, and easy.
Groovy is not going away any time soon. If you’re a Java developer and wish you could move faster, buy the book, read it, and then start integrating Groovy into your daily programming a little at a time. You’ll be happy you did.
And don’t even get me started on Grails…
Update: here are the second and third posts in this series (benchmarks included).
jQuery - THE JavaScript library to use?
Posted by jonchase
Is it me, or does it seem like jQuery has been picking up a lot of steam over the past 6 months or so?
It used to be that when I thought Javascript/AJAX library, I thought Prototype. Anymore, however, I think jQuery.
Running Jetty from Inside Ant…or Jetty + Ant = Crazy Delicious
Posted by jonchase
Want to speed up your Java web development? Read on…
Jetty is one of the best Java Servlet containers out there. I still don’t use it for production deployment (Tomcat has better monitoring capabilities I think), but it’s all I use for development. I’ve also been using Maven 2 a lot lately (although I’ve come to hate it and can’t wait to migrate back to Ant). One of the reasons I started using Maven was because of the awesome Jetty Maven plug in - by running something like “mvn jetty:run” on the command line, Maven will start a Jetty instance using your project’s POM and your web app will be up and running within seconds. I love it.
However, I hate Maven.
Enter the Jetty Ant plug in. It does the same thing as the Maven plug in above, except it’s easier to use, and it works in Ant.
I’m not going to walk through how to set it up - you can find that out here. This is just a heads up to let you know what you’re missing if you’re not developing with Jetty and Ant.
Amazon’s S3, JetS3t, MultiThreadedHttpConnectionManager, and Unable to get a connection
Posted by jonchase
Apologies for the long title.
This entry focuses on a recent issue when using Amazon’s S3 in combination with the popular JetS3t library (version 0.5.0). If that means absolutely nothing to you, you can stop reading this entry now:D.
Update: Amazon has reverted S3 back to its prior state, completely fixing this issue.
Update: new link added at bottom - a JetS3t developer has contributed an official fix.
On January 11th, Amazon apparently made some changes in S3 so that their servers do not explicitly release HTTP connections. As long as your code is explicitly closing the HTTP connection to S3 (i.e. connection.release()), this shouldn’t affect you (indeed, most people using S3 weren’t affected).
However, if you’re using the JetS3t library, you may have noticed an exception similar to the following after, oh, I don’t know, exactly 4 uploads to S3:
2008-01-13 16:12:55,753 DEBUG [org.apache.commons.httpclient.MultiThreadedHttpConnectionManager] - HttpConnectionManager.getConnection: config = HostConfiguration[host=https://s3.amazonaws.com], timeout = 0
2008-01-13 16:12:55,753 DEBUG [org.apache.commons.httpclient.MultiThreadedHttpConnectionManager] - enter HttpConnectionManager.ConnectionPool.getHostPool(HostConfiguration)
2008-01-13 16:12:55,753 DEBUG [org.apache.commons.httpclient.MultiThreadedHttpConnectionManager] - Unable to get a connection, waiting..., hostConfig=HostConfiguration[host=https://s3.amazonaws.com]
Why is this happening? It turns out that the REST implementation of JetS3t doesn’t explicitly close the HTTP connection after a successful operation. It also turns out that the max number of connections JetS3t uses by default is 4 (see “httpclient.max-connections”). Thus, once you do 4 uploads to S3, the above error starts appearing (”error” is misleading - I had to turn logging to DEBUG level to get the above message to print out).
The fix is to update the JetS3t RestS3Service.java code to explicitly release the connection, which is exactly what I did (add “httpMethod.releaseConnection();” on line 571). I’ve attached the code here for those interested. Note that I haven’t extensively tested this, and I’m sure there’s a better place to call the release method, but this works for now, and is provided on an AS IS basis (NO WARRANTIES - don’t hold me or Juliesoft LLC liable for anything that this code breaks). Hopefully the JetS3t developers integrate the needed fix into the next version.
- - removed - see update below
Update: looks like James Murty, the JetS3t library author, has taken care of the issue and posted all of the details.
Because of the post from James, I’ve removed my versions of the fix and will instead direct you to his.
On a side note, I have to say how impressed I am with the Amazon AWS community members, the Amazon staffers moderating the forums, and James Murty - the amount of communication and the speed of the resolution for this problem make me glad that I’ve been lucky enough to fall into such an active community!
New Book in March - Programming Amazon’s S3, EC2, SQS, and FPS
Posted by jonchase
Looks like there’s going to be a book coming out dedicated to development on Amazon’s suite of web services - S3 (Simple Storage Service), EC2 (Elastic Compute Cloud), SQS (Simple Queue Service), and FPS (Flexible Payments Service).
From the the O’Reilley site:
With this book, you’ll learn how companies can take advantage of Amazon Web Services (AWS) to “rent” computing power, data storage and bandwidth on Amazon’s vast network infrastructure. Programming Web Services gives developers the background and technical detail they need for using Amazon’s subscription-based Simple Storage Service (S3), Elastic Compute Cloud (EC2), Simple Queue Service (SQS), Flexible Payments Service (FPS), and SimpleDB to build web-scale business applications.
Trying to Decide on a Payment Processor for Credit Cards on Web Site?
Posted by jonchase
If you’re going to try to process credit card payments from your web site, you’ve got a lot of learning to do. On the one hand, there are the third party providers like PayPal, and there are the merchant account providers like Authorize.net. If you have no idea what I’m talking about, have a read of the following articles.
Solve the Payment Processing Problem - I found this particularly enlightening. Good description of the differences between a merchant account (like Authorize.net) and a third-party processor (like PayPal).
Put your Money where your Mouse Is: 6 Payment Gateways Reviewed - This one was great too - a good review of several payment gateways.
I’ve looked further into Authorize.net. On the plus side, you can do everything through an API, and no “Pay now with PayPal” button is required on your site. It also offers a nice looking package for recurring payments, and even handles trial periods to boot.
As for prices when using a merchant account, they’re not as clear cut as, say, PayPal is. There will be some calling around involved and prices are definitely negotiable.
I’m sure there’s going to be a lot of leg work involved as I go through the research process, so subscirbe to the RSS feed to get the updates I post to the blog.
Subscribe to Jon's Blog