Monday, February 7, 2011

Plain old Stan on the road to Google engine. Part 2.

This time I wanted to
- integrate some kind of a client side (javascript) view engine
- look at app execution through a dashboard. Understand what takes CPU cycles or other resources. May be provide some early stage adjustments

I also just newly read about Model 2 of jsp – it is when your servlet plays a role of a controller, serving a view for presentation, like:

doPost(...) {
  session.setAttribute("teachers", teachers);
  RequestDispatcher dispatcher = request.getRequestDispatcher("/admin.jsp");
  dispatcher.forward( request, response); 
} source

So I’m quite unsure if I should continue with StringTemplate or better switch to that Model 2 of jsp thingy. That would be probably too speculative to decide at this point.

But back to the plan, that’s javascript view engine. Back in time, when I was serving for Valtera, my brilliant colleague Konstantin Nalimov ran into one that is actually around 700 bytes of formatted code long and comes from John Resig himself – microtemplating. We gave it a run, and never had to look into anything else.

So here is what my default StringTemplate template looked like in order to integrate jQuery, jQueryUI and microtemplating.js (and yes, I had to go to google again to see how to integrate static files in gae app):

<script src="" type="text/javascript"></script>
<script src="" type="text/javascript"></script>
<script src="/js/microtemplating.js" type="text/javascript"></script>
<p id="helloP">Hello world!</p>
<script type="text/javascript">
jQuery('#helloP').click(function() {
t = new sd.Templating();
data = {"links": [
        {"description": "First link", "url": ""},
        {"description": "Second link", "url": ""},
        {"description": "Third link", "url": ""}
jQuery('#helloP').html(t.parseTemplate(t.getTemplateFromURL('/templates/Links.htm'), data));

I prepare some fake data for a template as you can see and then parsing the template into element with “helloP” id.

Here is the microtemplating template:

<table id="linksTable" style="width: 100%">
<th style="text-align:left">Description</th>
<th style="text-align:left">URL</th>
        <# for(var i=0; i < links.length; i++) { var link = links[i]; #>
                <#= link.description #>
                <#= link.url #>
        <# } #>

And the result:


Now to look at the dashboard:


Unfortunately, I didn’t take the screenshot before I fixed the issue with favicon. So let return a bit back.

That favicon.ico was taking ~60% of CPU with average of ~20 CPU cycles per download attempt. The picture above shows the corrected state, obviously last column for favicon will go to zero as well in 14 hours.

Here is the log for that favicon to confirm:


Yellow entries are those corresponding to the app startup. You can see favicon taking 0 CPU cycles after the fix. What was the fix? Just provide favicon.ico into your war directory! I should confess to my shame, it was the first time I ran into what favicon.ico actually is. So one could tell you better avoid false file lookups against your gae server, at least in case of favicon.ico…

This is it for my progress right now. Yours Stan.

No comments: