Gaelyk + Spring MVC to avoid the Loading Request problem

[Sean Gilligan]

I was thinking the book could be titled "Gaelyk Development without
GTPL" (reference to J2EE w/o EJB book)

I've used both Gaelyk and SpringMVC with GAE. The simple Spring MVC
controllers I've written start up much faster than pages that use Groovy
Templates (.gtpl files)

So, I'm wondering if a solution might be the following:

1) Use Gaelyk for a groovy interface to GAE
2) Use a very lightweight Spring MVC container
3) Write SpingMVC controllers as reloadable Groovy Beans
4) Write SpringMVC views as reloadable Groovy Beans
5) Create a switchable config so that on deployment all beans are
pre-compiled

See:
http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/dynamic-language.html
(this chapter looks a little out-of-date -- talks about Spring 2.0 and
Groovy 1.5)

That way you can have rapid development with Groovy with GAE running the
devserver but deploy compiled POGOs to the production server.

Does this sound feasible? I'd be game for doing some coding if anyone
else is interested in helping (testing/using is helping) Although it
would be great if someone from Spring would at least be able to advise...

-- Sean

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes Gaelyk.
Pour envoyer un message à ce groupe, adressez un e-mail à gae...@googlegroups.com.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse gaelyk+un...@googlegroups.com.
Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/gaelyk?hl=fr

[Marc Fawzi]

I like it. Will help to test.

I am currently playing with JSP pages having taglibs in Scala that
compile prior to deployment

The startup time from cold state is still long relataively speaking
but not as long as in the current case for Gaelyk. It seems that when
the app is completely cold GAE unloads the servlet (associated with
JSP) and then loads it again when a request comes in and that takes a
little bit of time

The big concern for loading delay is that if your site has very little
traffic and you're hoping users will find about it via Google search
Google will rank it very low because they count speed of response in
determining Pagerank so then fewer people will find out about your site

> es Gaelyk.
> Pour envoyer un message à ce groupe, adressez un e-mail à gaelyk@googlegroups.c
> om.
> Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse gaelyk+unsubscribe@googlegroups.c

[Wilson MacGyver]

The loading problem is really for very low traffic site. Here is one possible solution.

Get a cheap hosting place to use as cache for a few pages, such as the front page,
And serve the front page of the website using it.

Whenever someone visit the front page, fire a GET to your gaelyk app to trigger load.

Or wait to see what's announced at google I/O in a week or so.

Sent from my iPad

On Apr 29, 2010, at 11:16 AM, Marc Fawzi <marc....@gmail.com> wrote:

> I like it. Will help to test.
>
> I am currently playing with JSP pages having taglibs in Scala that compile prior to deployment
>
> The startup time from cold state is still long relataively speaking but not as long as in the current case for Gaelyk. It seems that when the app is completely cold GAE unloads the servlet (associated with JSP) and then loads it again when a request comes in and that takes a little bit of time
>
> The big concern for loading delay is that if your site has very little traffic and you're hoping users will find about it via Google search Google will rank it very low because they count speed of response in determining Pagerank so then fewer people will find out about your site
>
>
> On Apr 29, 2010, at 12:51 AM, Sean Gilligan <se...@msgilligan.com> wrote:
>
>> I was thinking the book could be titled "Gaelyk Development without GTPL" (reference to J2EE w/o EJB book)
>>
>> I've used both Gaelyk and SpringMVC with GAE. The simple Spring MVC controllers I've written start up much faster than pages that use Groovy Templates (.gtpl files)
>>
>> So, I'm wondering if a solution might be the following:
>>
>> 1) Use Gaelyk for a groovy interface to GAE
>> 2) Use a very lightweight Spring MVC container
>> 3) Write SpingMVC controllers as reloadable Groovy Beans
>> 4) Write SpringMVC views as reloadable Groovy Beans
>> 5) Create a switchable config so that on deployment all beans are pre-compiled
>>
>> See: http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/dynamic-language.html (this chapter looks a little out-of-date -- talks about Spring 2.0 and Groovy 1.5)
>>
>> That way you can have rapid development with Groovy with GAE running the devserver but deploy compiled POGOs to the production server.
>>
>> Does this sound feasible? I'd be game for doing some coding if anyone else is interested in helping (testing/using is helping) Although it would be great if someone from Spring would at least be able to advise...
>>
>> -- Sean
>>
>> --

[Jeff Schwartz]

You can also use a static page for your home page. Google houses all static content separately from dynamic content on hot servers always ready to serve a request. I used this technique for my app and it works very well.

Jeff

--
--
Jeff

[Sean Gilligan]

Marc Fawzi wrote:
> I like it. Will help to test.

Thanks, Marc. I'm still deciding whether and/or how to proceed.

I was hoping for some feedback from Guillaume or someone else from
SpringSource. There doesn't seem to be an official build of a Groovy
View component. It seems like the right way to approach this would be
to write a general-purpose, reloadable Groovy view and then create a
Gaelyk enhanced version of it with the Gaelyk objects injected.

> Google will rank it very low because they count speed of response in
> determining Pagerank

Yikes! I've never heard that before. Good to know.


-- Sean

--

[Sean Gilligan]

Wilson MacGyver wrote:
> The loading problem is really for very low traffic site.

It also may show up if your site traffic is variable and you're right on
the threshold between 1 and 2 VMs.

I like Damon Oehlman's testing methodology of using the average response
time + 2 standard deviations
for performance measurement:
http://distractable.net/coding/google-appengine-language-performance-comparison-followup/

It is the outliers that will get you bad publicity.

> Or wait to see what's announced at google I/O in a week or so.
>

I'm sure Google will be able to help to an extent and hope they will
have some positive announcements at Google I/O. But the basic problem
is inherent in the Java VM and unless Google changes the architecture
dramatically there will always be loading requests. Eliminating the
Groovy compile will be a performance boost over and above any
optimizations that Google makes.

[Sean Gilligan]

Jeff Schwartz wrote:
> You can also use a static page for your home page. Google houses all
> static content separately from dynamic content on hot servers always
> ready to serve a request. I used this technique for my app and it
> works very well.

I'm using this technique for the iUI Demo site.
<http://iui-js.appspot.com> Since most of the samples, demos, and tests
are static, the problem only occurs upon certain operations. Like
"Stats" and "Search" in the Music Sample:
http://iui-js.appspot.com/samples/music/music.html

(Note: "Stats" is supposed to have a 2-second delay to demonstrate the
ajax-loading spinner, but more often than not seems to have a 10-second
delay instead)

Ceteris paribus, making more of the pages (requests) static, will
increase the likelihood of a loading request when the user finally hits
a dynamic page (or ajax request)

[Guillaume Laforge]

On Mon, May 3, 2010 at 23:57, Sean Gilligan <se...@msgilligan.com> wrote:
> [...]

> I was hoping for some feedback from Guillaume or someone else from
> SpringSource.  There doesn't seem to be an official build of a Groovy View
> component.  It seems like the right way to approach this would be to write a
> general-purpose, reloadable Groovy view and then create a Gaelyk enhanced
> version of it with the Gaelyk objects injected.

I don't really have much to say here, as I'm not a Spring MVC expert at all :-)
I'm not sure putting Spring into the mix would really help things
here, in that sense that Spring also adds some additional setup time,
increasing the loading requests a bit.
And since you'd still use Groovy views, you'd still have the
compilation overhead -- till we find some ways to have pre-compiled
templates but then you don't really need to add Spring anymore.

--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one

[Sean Gilligan]

Guillaume Laforge wrote:
> On Mon, May 3, 2010 at 23:57, Sean Gilligan <se...@msgilligan.com> wrote:
>> I don't really have much to say here, as I'm not a Spring MVC expert at all :-)
>>

I'm pretty comfortable with Spring MVC, but am a little nervous about
using dynamic beans, calling the Groovy interpreter directly, etc.

> I'm not sure putting Spring into the mix would really help things
> here,

Spring would provide the ability to configure the app differently for
the dev server and for the production server (script vs. compiled mode)
and would provide some support for reloading code. It would also
provide a simple MVC architecture.

> in that sense that Spring also adds some additional setup time,
>

I've used an extremely lightweight config of Spring/SpringMVC on GAE and
it loads about 4x a fast as a Gaelyk template. I should probably re-run
the test. I have seen complaints about Spring on GAE, but some Spring
apps do a tremendous amount of work on load time (e.g. Grails,
Hibernate, AOP, etc)

I will admit, that I have other reasons for wanting to use SpringMVC,
and the approach could be used with simple servlets and a custom config
layer.

One advantage to SpringMVC is that Grails supports integration of
SpringMVC controllers, so it should be possible to write some
controllers that work well in a simple #GAE environment but could also
be used in Grails.

> And since you'd still use Groovy views, you'd still have the
> compilation overhead -- till we find some ways to have pre-compiled
> templates but then you don't really need to add Spring anymore.
>

I was thinking that Spring might help with the pre-compiled templates,
but I could be wrong. I guess I could dive in and try to get a proof of
concept. (as soon as I have a free day...) I assume you'd be able to
help with any Groovy-specific questions I might have...

Any suggestions on anyone else to talk to before starting, or any other
projects (besides SpringMVC itself) I should talk to?

Thanks,

Sean

[Guillaume Laforge]

On Tue, May 4, 2010 at 09:26, Sean Gilligan <se...@msgilligan.com> wrote:
> [...]

> Any suggestions on anyone else to talk to before starting, or any other
> projects (besides SpringMVC itself) I should talk to?

Spring MVC is SpringSource's Keith Donalds' baby, so you may get in
touch with him, if you wish.

--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one

[Sean Gilligan]

Guillaume Laforge wrote:
> Spring MVC is SpringSource's Keith Donalds' baby, so you may get in
> touch with him, if you wish.
>
>

Thanks, I just emailed him and cc'ed you.

-- Sean

[Jeff]

Having first tried Grails on appengine I'd be apprehensive about using
Spring configuration due to overhead. IMO precompilation will provide
the greatest benefit to all gaelyk developers. Guillaume, what is the
timetable for adding precompilation to gaelyk?

Jeff

On May 4, 2:26 am, Guillaume Laforge <glafo...@gmail.com> wrote:

> On Mon, May 3, 2010 at 23:57, Sean Gilligan <s...@msgilligan.com> wrote:
> > [...]
> > I was hoping for some feedback from Guillaume or someone else from
> > SpringSource.  There doesn't seem to be an official build of a Groovy View
> > component.  It seems like the right way to approach this would be to write a
> > general-purpose, reloadable Groovy view and then create a Gaelyk enhanced
> > version of it with the Gaelyk objects injected.
>
> I don't really have much to say here, as I'm not a Spring MVC expert at all :-)
> I'm not sure putting Spring into the mix would really help things
> here, in that sense that Spring also adds some additional setup time,
> increasing the loading requests a bit.
> And since you'd still use Groovy views, you'd still have the
> compilation overhead -- till we find some ways to have pre-compiled
> templates but then you don't really need to add Spring anymore.
>
> --
> Guillaume Laforge
> Groovy Project Manager

> Head of Groovy Development at SpringSourcehttp://www.springsource.com/g2one

[Guillaume Laforge]

Hi Jeff,

On Tue, May 4, 2010 at 15:06, Jeff <jeffts...@gmail.com> wrote:
> Having first tried Grails on appengine I'd be apprehensive about using
> Spring configuration due to overhead. IMO precompilation will provide
> the greatest benefit to all gaelyk developers. Guillaume, what is the
> timetable for adding precompilation to gaelyk?

No precise timetable yet.
I'd like to do a couple of things first, like a very lightweight
plugin system, and perhaps even the query DSL I had envisionned
(started something but not finished).
There's also an issue with the blobstore conflicting with the routing
system. I'd like to have more feedback on it, and fix that.
But perhaps I'll try to reprioritize the precompilation as it's
something that impact us all.

Guillaume

[Jeff Schwartz]

Plugins and a query dsl would be 'nice' to have but in terms of priority and IMHO :) I'd rate them much lower than precompilation. Once precompilation is in then plugins and everything else added after that will all benefit from precompilation as well.

Jeff

--
--
Jeff

[Guillaume Laforge]

Well, let's still remember that loading requests will certainly be
handled by Google at some point somehow (reserving a JVM, diricting
trafic to warm instances first, etc), and that loading request only
really affect low trafic sites essentially :-)
But of course, a faster loading site helps getting more trafic :-D

[Jeff Schwartz]

Exactly, Guillaume. Reputation via word of mouth plays a large part in drawing users to a site. Perception is reality as far as users are concerned and if an application appears to be slow and unresponsive then that diminishes the value that application has in the user's mind regardless of the reason for the application's sluggishness.

Regarding Google, they may or may not chose to implement any of the items you mentioned. It would be a mistake, IMHO, to solely rely upon Google when it is obvious that precompilation will greatly benefit gaelyk apps now. Should Google chose to actually provide any of these services then precompiled gaelyk apps will then run that much faster and would give gaelyk bragging rights and attract a larger user base.

Jeff

[Sean Gilligan]

Jeff wrote:
> Having first tried Grails on appengine I'd be apprehensive about using
> Spring configuration due to overhead.

A very minimal SpringMVC configuration doesn't seem to add any
noticeable overhead to JVM startup. Here is what I used:

<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:p="http://www.springframework.org/schema/p"
xmlns:context="http://www.springframework.org/schema/context"
xsi:schemaLocation=" http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
http://www.springframework.org/schema/context
http://www.springframework.org/schema/context/spring-context-3.0.xsd">
<context:component-scan base-package="com.msgilligan.smvc3" />
</beans>

The key words being "seem" and "noticeable" - maybe I should rerun the
test. I will run the test before going too far.


-- Sean

[Sean Gilligan]

Jeff Schwartz wrote:
> Plugins and a query dsl would be 'nice' to have but in terms of
> priority and IMHO :) I'd rate them much lower than precompilation.
> Once precompilation is in then plugins and everything else added after
> that will all benefit from precompilation as well.

The loading request issue is a deal-killer for any production site that
will have real users (i.e. the impatient kind)

-- Sean

[Sean Gilligan]

Guillaume Laforge wrote:
> Well, let's still remember that loading requests will certainly be
> handled by Google at some point somehow (reserving a JVM, diricting
> trafic to warm instances first, etc), and that loading request only
> really affect low trafic sites essentially :-)
>

Google will reportedly charge for reserving a JVM. If rapid
cold-starting is possible so that the "freemium" modle is preserved
combined with simple, rapid development using a scripting language - the
combination will be very compelling for many small projects. Something
that has been the domain of PHP for years. I'm hoping that Google's
fixes plus precompilation might get us there.

-- Sean

[Wilson MacGyver]

I think you maybe over stating the problem . :)

Check out

http://www.infoq.com/articles/deadline-clojure-appengine

The app is pretty responsive.

--
Omnem crede diem tibi diluxisse supremum.

[Jeff Schwartz]

I don't think I am.

I snooped the page referenced in the article that you point to and it appears to be a static .html page backed by ajax whose calls may not even be served from appengine servers. My guess is that they are using the datastore and other services on appengine and are keeping their virtual server hot via cron or some ping service. I don't think having to jump through hoops to have even the simplest page (and that page is quite simple) appear to be responsive invalidates anything that I've said. In fact, I think it does the opposite :)

Jeff

--
--
Jeff