Long Loading Requests in App Engine for Java

In this post, I revisit the loading requests in Google App Engine for Java. The test results are shown below. The following modes are:

Skeleton

Plain-vanilla skeleton webapp with SDK (1.8.2) dependencies.

With Spring Framework Web

Skeleton webapp plus Spring Framework Web (3.2.4.RELEASE) dependencies. This adds almost 3 MB of JARs.

spring-aop-3.2.4.RELEASE.jar	335455
spring-beans-3.2.4.RELEASE.jar	607755
spring-context-3.2.4.RELEASE.jar	863688
spring-core-3.2.4.RELEASE.jar	869674
spring-expression-3.2.4.RELEASE.jar	196807
spring-web-3.2.4.RELEASE.jar	625875

With Spring Web MVC

Webapp with Spring Framework Web MVC. This add one additonal JAR.

spring-webmvc-3.2.4.RELEASE.jar

636993

With Spring Web MVC and applicationContext

Webapp with Spring Framework Web MVC and running an empty (zero beans) application context on startup via ContextLoaderListener.

With Google Guice

Skeleton webapp with Google Guice (3.0) dependencies.

With Google Guice (one servlet module)

Webapp with Google Guice servlet context listener, filter, loading a servlet module.

With Google Guice (one servlet module)

Same as before, but built without AOP. The following dependency declaration was used:

        <dependency>
            <groupId>com.google.inject</groupId>
            <artifactId>guice</artifactId>
            <version>${guice.version}</version>
            <classifier>no_aop</classifier>
            <exclusions>
             <exclusion>
              <groupId>aopalliance</groupId>
              <artifactId>aopalliance</artifactId>
             </exclusion>
            </exclusions>
        </dependency>
        <dependency>
            <groupId>com.google.inject.extensions</groupId>
            <artifactId>guice-servlet</artifactId>
            <version>${guice.version}</version>
            <exclusions>
             <exclusion>
              <groupId>com.google.inject</groupId>
              <artifactId>guice</artifactId>
             </exclusion>
            </exclusions>
        </dependency>  
  

Test Results (Summarized)

Times are measured by shutting down instance, hitting a URL, looking at request time in logs. All using a frontend instance class of F1 (600MHz, 128MB).

Mode	Average Time (ms)
Skeleton	4322.6
With Spring Web	4836.0
With Spring Web MVC	4819.0
With Spring Web MVC and applicationContext	8845.6
With Google Guice (no modules)	4437.6
With Google Guice (one servlet module)	8260.8
With Google Guice (one servlet module, no AOP)	5332.2

Observations

• Adding some JARs (dependencies) to the web application (even without using any of its classes) increases the time it takes to complete a loading request.
• Adding an empty (zero beans) application context to the web application increases the time by about 4 seconds.
• Using Google Guice to load servlets and provide dependency injection can add about 4 seconds (similar to using Spring Framework).
• Removing AOP from the use of Google Guice can lower the additional loading request time.

Test Results (Raw)

Mode	Try	Time (ms)
Skeleton	1	4050
Skeleton	2	4384
Skeleton	3	4305
Skeleton	4	4609
Skeleton	5	4265
Skeleton	Average	4322.6
With Spring Web	1	5001
With Spring Web	2	5115
With Spring Web	3	4783
With Spring Web	4	4724
With Spring Web	5	4557
With Spring Web	Average	4836.0
With Spring Web MVC	1	5205
With Spring Web MVC	2	4900
With Spring Web MVC	3	4486
With Spring Web MVC	4	5164
With Spring Web MVC	5	4340
With Spring Web MVC	Average	4819.0
With Spring Web MVC and applicationContext	1	9187
With Spring Web MVC and applicationContext	2	8946
With Spring Web MVC and applicationContext	3	8417
With Spring Web MVC and applicationContext	4	8777
With Spring Web MVC and applicationContext	5	8901
With Spring Web MVC and applicationContext	Average	8845.6
With Google Guice (no modules)	1	4578
With Google Guice (no modules)	2	4473
With Google Guice (no modules)	3	4480
With Google Guice (no modules)	4	4223
With Google Guice (no modules)	5	4434
With Google Guice (no modules)	Average	4437.6
With Google Guice (one servlet module)	1	7845
With Google Guice (one servlet module)	2	8426
With Google Guice (one servlet module)	3	8476
With Google Guice (one servlet module)	4	8394
With Google Guice (one servlet module)	5	8163
With Google Guice (one servlet module)	Average	8260.8
With Google Guice (one servlet module, no AOP)	1	5702
With Google Guice (one servlet module, no AOP)	2	5020
With Google Guice (one servlet module, no AOP)	3	6036
With Google Guice (one servlet module, no AOP)	4	5223
With Google Guice (one servlet module, no AOP)	5	4680
With Google Guice (one servlet module, no AOP)	Average	5332.2

Related Links

• Reducing Google App Engine Cold-Start Time When Using JPA
• Java instance startup time out of control - Google Groups

Early UI, Early Feedback, Better Results

A few months back, I was reviewing some internal apps we had in our organization, and this thing we humbly call the "library app" got my attention. We have a lot of books (physical copies) lying around, and we encourage everyone in the organization to read and apply/share what they've read. So far, it seems to be working.

A group of young developers was learning Grails, and they built this "library app". I wanted to learn too, so I pushed myself to do something that ran on Google's App Engine, and I ended up learning more.

UI and User Experience

I started looking at the current user interface of the one built using Grails. Here's what I saw — a login page.

After logging in, I get the following.

Thanks to PJ for the screenshots.

I asked myself, "What would a typical user do if s/he was greeted with this landing page?" My first response was, I wouldn't even think of clicking any of the two icons. And here's what I saw after clicking on the "Book Listing" icon/link.

There was nothing there that "entices" me to explore and look at the available titles. So, I set out to create a landing page that would make we want to look at what's available.

Early Feedback

Here's what I came up with (largely inspired by iBooks and other similar apps).

libraryapp.onb-demo.appspot.com

I didn't build the code behind it (at least, not yet). I just started with some static HTML, deployed it to the cloud, and asked some colleagues to try it out. I was pleasantly surprised with their reaction. They asked if the app was a modified version of the one built using Grails. They also asked if I got help from our creatives team, and if it was written using Grails. Anyway, the early UI allowed me to get early feedback. And letting the landing page be seen without the need to login also helped (I guess everyone is too lazy busy to login).

Learning users’ unarticulated needs through a process of keen observation and interpretation often leads to breakthrough designs.

http://en.wikipedia.org/wiki/Empathic_design

So, I proceeded to turn the static HTML into something more dynamic. I started populating the database with book titles. Then, it occurred to me that I was spending so much time entering the titles, authors, publishers, etc. Even though we have about 50+ titles, it was taking too much time. So, I asked around how the current version was being maintained. I was surprised that they did it pretty much the same way I did (adding titles one by one, and typing everything in while looking at the physical copy). I started thinking of improving this. (Seems like an unarticulated need here)

I saw myself Googling the book's title every time I needed to enter its details. Light bulb moment! Why don't I enhance the entry form and allow the user to Google it up, and populate the entry form?

After some rough JavaScript, here's what I ended up with.

I added a "Search" button that would do the search (using Google Books API). The results are shown, and a button is added to use the book information to populate the form.

After I added this, I was able to add titles in no time! This would not have been possible for a user to articulate or express as a requirement. How would they know that APIs exist to help with finding book information? It's critical to observe and experience what the user goes through when using your app to achieve their goals and/or perform their tasks.

I'm no design guru. This simple enhancement is far from a breakthrough. I hardly observed our office admin team use the existing library app. But I'm glad I had this experience, and I hope sharing it here would help others. I indeed learned more than just building apps!

Future Enhancements

As you can see from the screenshot, I have not implemented the borrowing part of the app (yet). But I'm thinking of ways to add a "comments" section to allow users to post their comments about the book. I'm hoping that these comments shall further "entice" others to grab a copy, read, apply, and share.

Model-View-Controller (MVC) Done Right?

I was pleasantly reminded of how I, as a budding junior software engineer (a couple of years back), misunderstood MVC and application architecture, and how others may misunderstand this too. So, please allow me to explain my journey in understanding MVC better.

MVC and Application Architecture

Martin Fowler provides a good explanation of MVC in his Patterns of Enterprise Application Architecture.

When developing applications, one application architecture I'm usually exposed to is the layered architecture (also known as multi-layered, or multi-tiered). Each layer would usually be dependent on layers underneath it, but not above it. These layers provided abstraction (via interfaces), which is useful in tackling complex systems and allowing concurrent development.

A multilayered software architecture is a software architecture that uses many layers for allocating the different responsibilities of a software product.

- Wikipedia

Presentation Layer

Business Layer

Data Access (or Infrastructure) Layer

Missing Link Between MVC and Layered Architecture

So, I started thinking that MVC was mapped to layers like this:

Layer	MVC Component
Presentation	View
Business (or Domain)	Controller
Data Access	Model

But that's the wrong way! A crucial point that I missed is that MVC is a presentation layer pattern. It is really intended for the user interface. So, what did I end up doing?

Any fool can know. The point is to understand.

- Albert Einstein

Because of this poor understanding of MVC, I ended up exposing domain entities as models to my views. This resulted in entities that exposed setters and getters, which made it difficult to implement invariants and DDD. This also resulted in business rules that were mixed with UI-related implementations. So, what is a better understanding of MVC?

Layer	Content
Presentation	MVC
Business (or Domain)	Services / Domain Objects
Data Access	DAO / Repository Implementations / Gateways

As it was originally intended, MVC is found inside the presentation layer. It's important to note that the Model in MVC is not your Service Layer or the Domain Objects. It's the user interface's state (or View state).

If your application is simple enough, you could choose to have domain objects (usually entities) as your view state for simplicity. But please don't confuse MVC's Model with the Domain Objects.

If you find yourself asking the question of whether to add business logic in the model or not, then re-clarify what you mean by model. Is it MVC's model, or domain model object?

If you find yourself having difficulty dealing with entities (or domain objects) in the presentation layer, perhaps you can consider converting domain objects to more portable DTOs that can be tailored to specific use cases (or specific UIs) and add an application service (typically using a facade pattern) that would handle the DTO-serializing responsibilities before exposing them to the presentation layer.