Have anyone tried to port a java project with heavy framworks, such as struts and spring, to a pure jsp/servlet project?

[Tapir]

Is it worth dong it?

[Rafael]

Depends on the size of your project.

I started with plain java/jsp.

As the project grew the overhead of maintenance was so big that we opted to moving everything to spring-mvc.

That move increased the instance boot time from 7 to 35 seconds. In order to overcome cold startups we had to add 6 extra "resident" instances. It means a monthly $300 commitment just to run an MVC framework.

Yes. It's frustrating and expensive.

I wouldn't advising starting a java project in appengine. It seems they're investing much more on other languages.

Thanks
Rafa

On Feb 5, 2014 9:36 PM, "Tapir" <tapi...@gmail.com> wrote:

Is it worth dong it?

--
You received this message because you are subscribed to the Google Groups "Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-appengi...@googlegroups.com.
To post to this group, send email to google-a...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
For more options, visit https://groups.google.com/groups/opt_out.

[Tapir]

For the size of my project, I think it is impractical to port it to other languages. :(
I tried python and go, their warmup time is very short. For python, it is less than one second, for go, it is less than 0.5 second I think.
But Java still has a big advantage: large quantity of libraries.
So if GAE team can make the warmup time of a pure jsp/servelt project be less than 1.5 seconds, I will be still happy to stick to Java.

[Rafael]

Welcome to the club. People have been waiting for this for years.

[Warren Strange]

Google Compute Engine would probably be a better option for a large legacy Java code base.

[Nick]

Hi Tapir,

You could give porting your spring app over to the thundr framework a go:

http://3wks.github.io/thundr/ (usual disclaimer, I'm a maintainer)

The basic concepts are very similar to spring, so it should be relatively simple. Its designed specifically to have fast boot up times on appengine (i.e. no classpath scanning etc). The easiest way to check it out is to clone the sample app and run it in dev mode.

https://github.com/3wks/thundr-sample

Be aware that we're imminently coming up on the next major release version, so the sample is a little 'out of date'.

You can get in touch directly with any questions from the docs page (or join our google group)

To the point directly, I think its totally infeasible to maintain any reasonable sized java app without some framework. Besides Spring, i don't feel there are many viable options.

[Tapir]

I really like the basic part of your framework, the python route config style and the simple view files.

For it is also based on servlet, I think it can't solve the warmup problem.

Bit I would give it a try in my later new projects.

[Tapir]

On Tuesday, February 11, 2014 1:32:23 PM UTC+8, Tapir wrote:

I really like the basic part of your framework, the python route config style and the simple view files.

For it is also based on servlet, I think it can't solve the warmup problem.

Bit I would give it a try in my later new projects.

Typo here, "But".

BTW, I use struts 2 in my project now.

I don't like its configuration style.

And one thing I prefer pure jsp to frameworks is jsp supports hot deploy.

[PK]

Please define what is "a large legacy Java code base”…

PK
http://www.gae123.com

[Rafael]

Warren,

Compute engine wouldn't work with big table. Would it?

It would require a large migration. In that case people would probably go full aws.

[Vinny P]

On Wed, Feb 12, 2014 at 8:28 AM, Rafael <mufu...@gmail.com> wrote:

Compute engine wouldn't work with big table. Would it?

BigTable is available through the Cloud Datastore service. There's much more configuration involved than accessing it through App Engine, but it is possible: https://developers.google.com/datastore/docs/getstarted/start_java/

The only issue is that there are some increased costs because requests to the Cloud Datastore have to go through an App Engine layer: https://developers.google.com/cloud/pricing#cloud-datastore

 

 

-----------------

-Vinny P

Technology & Media Advisor

Chicago, IL

App Engine Code Samples: http://www.learntogoogleit.com

[Tapir]

On Thursday, February 13, 2014 7:17:18 AM UTC+8, Vinny P wrote:

On Wed, Feb 12, 2014 at 8:28 AM, Rafael <mufu...@gmail.com> wrote:

Compute engine wouldn't work with big table. Would it?

BigTable is available through the Cloud Datastore service. There's much more configuration involved than accessing it through App Engine, but it is possible: https://developers.google.com/datastore/docs/getstarted/start_java/

The only issue is that there are some increased costs because requests to the Cloud Datastore have to go through an App Engine layer: https://developers.google.com/cloud/pricing#cloud-datastore

 through an App Engine layer? My God!

[Tapir]

On Sunday, February 9, 2014 11:48:44 PM UTC+8, Warren Strange wrote:

Google Compute Engine would probably be a better option for a large legacy Java code base.

Haven't noticed your reply before.

Could you please explain more?

[Warren Strange]

If you have a very large and complex Java application, it might be easier to simply run it (unchanged) on GCE rather than attempt to shorehorn it in to App Engine's architecture.  You could migrate functionality to App Engine over time.  

You still have to "manage" GCE instances (they don't autoscale, etc.), but they do offer auto-migration across data centres (a pretty neat feature). If you can trim your instance size down in memory the small instances are very inexpensive. 

[Nick]

Hi Tapir, I'm not sure I understand what you mean by this 'I think it can't solve the warmup problem'.

Unfortunately (for everyone) there's no real avoiding waiting for startup of your app with appengine right now.

The best you can do is make it as quick as possible. The key is to avoid any classpath scanning, and have the lightest possible amount of initialisation code.

The online docs also suggest that number of files plays some part, but i've never really seen any evidence of this.

A basic thundr app has around a 4 second startup on appengine, obviously as you add in more initialisation that goes up.

In terms of having no choice but accepting a compromise, this is pretty fast IMO.

If anyone has experience in getting apps to start up quickly then I would love love love if they could write a separate post on the topic.

[Tapir]

On Friday, February 14, 2014 6:23:38 AM UTC+8, Nick wrote:

Hi Tapir, I'm not sure I understand what you mean by this 'I think it can't solve the warmup problem'.

Unfortunately (for everyone) there's no real avoiding waiting for startup of your app with appengine right now.

The best you can do is make it as quick as possible. The key is to avoid any classpath scanning, and have the lightest possible amount of initialisation code.

The online docs also suggest that number of files plays some part, but i've never really seen any evidence of this.

A basic thundr app has around a 4 second startup on appengine, obviously as you add in more initialisation that goes up.

I tried uploading a simplest java project with only 2 jsp files. The warmup needs 5-7 seconds. I think the project can't be simpler.

So, to stick to java, I plan to migrate my project to a dedicated server later. 

GAE instances are too expensive.

Big Table in App Engine is only feature I can't find a competitive alternative in services provided by other companies.

So I will still keep an app engine instance being used as Big Table proxy.

[Tapir]

On Friday, February 14, 2014 2:13:20 PM UTC+8, Tapir wrote:

On Friday, February 14, 2014 6:23:38 AM UTC+8, Nick wrote:

Hi Tapir, I'm not sure I understand what you mean by this 'I think it can't solve the warmup problem'.

Unfortunately (for everyone) there's no real avoiding waiting for startup of your app with appengine right now.

The best you can do is make it as quick as possible. The key is to avoid any classpath scanning, and have the lightest possible amount of initialisation code.

The online docs also suggest that number of files plays some part, but i've never really seen any evidence of this.

A basic thundr app has around a 4 second startup on appengine, obviously as you add in more initialisation that goes up.

I tried uploading a simplest java project with only 2 jsp files. The warmup needs 5-7 seconds. I think the project can't be simpler.

So, to stick to java, I plan to migrate my project to a dedicated server later. 

GAE instances are too expensive.

Another problem of GAE is the behavior of its instance scheduler is weird and unpredictable.

[Tapir]

On Friday, February 14, 2014 2:13:20 PM UTC+8, Tapir wrote:

On Friday, February 14, 2014 6:23:38 AM UTC+8, Nick wrote:

Hi Tapir, I'm not sure I understand what you mean by this 'I think it can't solve the warmup problem'.

Unfortunately (for everyone) there's no real avoiding waiting for startup of your app with appengine right now.

The best you can do is make it as quick as possible. The key is to avoid any classpath scanning, and have the lightest possible amount of initialisation code.

The online docs also suggest that number of files plays some part, but i've never really seen any evidence of this.

A basic thundr app has around a 4 second startup on appengine, obviously as you add in more initialisation that goes up.

I tried uploading a simplest java project with only 2 jsp files. The warmup needs 5-7 seconds. I think the project can't be simpler.

So, to stick to java, I plan to migrate my project to a dedicated server later. 

GAE instances are too expensive.

Here is the usage of my project at Feb 12.  

 

And here is the Google Analytics result of my website at the same day:

The advertisement revenue of the day is about 0.2$, I think.

Which means the money I paid to Google is more than I earned.

So I think my website is unsustainable if I stick to App Engine.

Maybe it is related to Java, or not.

[Tapir]

On Friday, February 14, 2014 2:37:02 PM UTC+8, Tapir wrote:

On Friday, February 14, 2014 2:13:20 PM UTC+8, Tapir wrote:

On Friday, February 14, 2014 6:23:38 AM UTC+8, Nick wrote:

Hi Tapir, I'm not sure I understand what you mean by this 'I think it can't solve the warmup problem'.

Unfortunately (for everyone) there's no real avoiding waiting for startup of your app with appengine right now.

The best you can do is make it as quick as possible. The key is to avoid any classpath scanning, and have the lightest possible amount of initialisation code.

The online docs also suggest that number of files plays some part, but i've never really seen any evidence of this.

A basic thundr app has around a 4 second startup on appengine, obviously as you add in more initialisation that goes up.

I tried uploading a simplest java project with only 2 jsp files. The warmup needs 5-7 seconds. I think the project can't be simpler.

So, to stick to java, I plan to migrate my project to a dedicated server later. 

GAE instances are too expensive.

Here is the usage of my project at Feb 12.  

 

And here is the Google Analytics result of my website at the same day:

The advertisement revenue of the day is about 0.2$, I think.

Which means the money I paid to Google is more than I earned.

So I think my website is unsustainable if I stick to App Engine.

Maybe it is related to Java, or not.

If Java has no the warmup problem, then I don't need keep a resident instance, which wastes me 24 hours every day.

[Tapir]

On Friday, February 14, 2014 2:37:02 PM UTC+8, Tapir wrote:

On Friday, February 14, 2014 2:13:20 PM UTC+8, Tapir wrote:

On Friday, February 14, 2014 6:23:38 AM UTC+8, Nick wrote:

Hi Tapir, I'm not sure I understand what you mean by this 'I think it can't solve the warmup problem'.

Unfortunately (for everyone) there's no real avoiding waiting for startup of your app with appengine right now.

The best you can do is make it as quick as possible. The key is to avoid any classpath scanning, and have the lightest possible amount of initialisation code.

The online docs also suggest that number of files plays some part, but i've never really seen any evidence of this.

A basic thundr app has around a 4 second startup on appengine, obviously as you add in more initialisation that goes up.

I tried uploading a simplest java project with only 2 jsp files. The warmup needs 5-7 seconds. I think the project can't be simpler.

So, to stick to java, I plan to migrate my project to a dedicated server later. 

GAE instances are too expensive.

Here is the usage of my project at Feb 12.  

 

And here is the Google Analytics result of my website at the same day:

The advertisement revenue of the day is about 0.2$, I think.

Which means the money I paid to Google is more than I earned.

Sometimes the embedded images in Google Groups don't show. Here is the image links:

Usage of my project at Feb 12.  (If there is no free front hours, my app will be changed at least $0.32 more)
https://lh3.googleusercontent.com/-mhy975rsUSc/Uv24PtADuXI/AAAAAAAAAEk/sW6FHrTMATc/s1600/gae8.png

And here is the Google Analytics result of my website at the same day:

https://lh6.googleusercontent.com/-LintFG9PREo/Uv243REzgpI/AAAAAAAAAEs/6ZZyxo-C64Y/s1600/gae9.png
 

[Emanuele Ziglioli]

Our warmup time was 15 seconds, then I looked at the hello world project that the GAE plugin generates with one servlet.

That took 2 seconds to startup (once the servlet was hit).

Then I added all the jars from our project but kept the same web.xml configuration.

Startup time went up to almost 10 seconds.

So I've done a lot of work to try and remove jars from my project and that helped a bit.

I've also disabled "warmup" so that no extra processing is done if a user hits a cold instance.

Everyone will suffer but just a bit.

Also, I've been suggested to have a look at "Modules" and also at a plugin called Proguard:

https://groups.google.com/forum/#!topic/vosao-cms-development/KK_nzMN4cyM

[Tapir]

On Tuesday, February 18, 2014 3:57:37 AM UTC+8, Emanuele Ziglioli wrote:

Our warmup time was 15 seconds, then I looked at the hello world project that the GAE plugin generates with one servlet.

That took 2 seconds to startup (once the servlet was hit).

On F2 instance?

 

Then I added all the jars from our project but kept the same web.xml configuration.

Startup time went up to almost 10 seconds.

So I've done a lot of work to try and remove jars from my project and that helped a bit.

I've also disabled "warmup" so that no extra processing is done if a user hits a cold instance.

Everyone will suffer but just a bit.

Also, I've been suggested to have a look at "Modules" and also at a plugin called Proguard:

https://groups.google.com/forum/#!topic/vosao-cms-development/KK_nzMN4cyM

My experience is the modules feature will spend your money.

[Tapir]

On Tuesday, February 18, 2014 4:04:16 AM UTC+8, Tapir wrote:

On Tuesday, February 18, 2014 3:57:37 AM UTC+8, Emanuele Ziglioli wrote:

Our warmup time was 15 seconds, then I looked at the hello world project that the GAE plugin generates with one servlet.

That took 2 seconds to startup (once the servlet was hit).

On F2 instance?

 

Then I added all the jars from our project but kept the same web.xml configuration.

Startup time went up to almost 10 seconds.

So I've done a lot of work to try and remove jars from my project and that helped a bit.

I've also disabled "warmup" so that no extra processing is done if a user hits a cold instance.

Everyone will suffer but just a bit.

Also, I've been suggested to have a look at "Modules" and also at a plugin called Proguard:

https://groups.google.com/forum/#!topic/vosao-cms-development/KK_nzMN4cyM

My experience is the modules feature will spend your money.

missed a more here, it should be "the modules feature will spend your more money."

[Emanuele Ziglioli]

Not sure where my reply went.

On Tuesday, February 18, 2014 3:57:37 AM UTC+8, Emanuele Ziglioli wrote:

Our warmup time was 15 seconds, then I looked at the hello world project that the GAE plugin generates with one servlet.

That took 2 seconds to startup (once the servlet was hit).

On F2 instance?

Haven't seen much difference between F1 and F2 when it comes to warmup time.

Most time seems to be spent actually loading jars. Initialization could be as little as 3s with our project, F2 would a bit better but not so much

My experience is the modules feature will spend your money.

I haven't seen many people using modules yet. Can't they be configured to be F1 like non default versions?

 

[Nick]

I think (and previous guidance supports this) that it isn't the loading of the jars that is taking time, its actually fetching your war (and the files in it, so downloading the jars) that is taking so much elapsed time. The smaller your overall artifact, the quicker it can be pulled in and started up.

Its interesting looking at some of my apps which jars are unusually large. Guava itself is surprisingly large (10% of my average war). Might be worth playing a little with to see how much this can be optimised.

[Emanuele Ziglioli]

On Tuesday, 18 February 2014 11:50:20 UTC+13, Nick wrote:

I think (and previous guidance supports this) that it isn't the loading of the jars that is taking time, its actually fetching your war (and the files in it, so downloading the jars) that is taking so much elapsed time. The smaller your overall artifact, the quicker it can be pulled in and started up.

That's what I meant with loading for lack of better terminology.

I'm glad there's more evidence supporting that, can you provide some links?

 

Its interesting looking at some of my apps which jars are unusually large. Guava itself is surprisingly large (10% of my average war). Might be worth playing a little with to see how much this can be optimised.

Maybe Proguard can help, haven't looked at it yet

[Tapir]

On Tuesday, February 18, 2014 4:33:16 AM UTC+8, Emanuele Ziglioli wrote:

Not sure where my reply went.

On Tuesday, February 18, 2014 3:57:37 AM UTC+8, Emanuele Ziglioli wrote:

Our warmup time was 15 seconds, then I looked at the hello world project that the GAE plugin generates with one servlet.

That took 2 seconds to startup (once the servlet was hit).

On F2 instance?

Haven't seen much difference between F1 and F2 when it comes to warmup time.

Most time seems to be spent actually loading jars. Initialization could be as little as 3s with our project, F2 would a bit better but not so much

why? looks not reasonable.

 

My experience is the modules feature will spend your money.

I haven't seen many people using modules yet. Can't they be configured to be F1 like non default versions?

should be.

 

 

[Nick]

Unfortunately no, i can't provide links. Working with appengine for a few years now, you tend to soak stuff up. Who knows whether it's current info.

If i get some time I might try a basic benchmark.

[Tapir]

Ok, I removed all core GAE jar files under SDK/lib/user

Now the warmup time dropped from 5-7 seconds to 3-4 seconds.

What is appengine-api-labs-1.x.x.jar? is it essential?

And must the appengine-api-1.0-sdk-1.x.x.jar be included in the project war directory?

[Rafael]

very interesting... 

can you tell me how you did that? in a maven build or only via eclipse?

--

[Tapir]

On Tuesday, February 18, 2014 4:56:51 PM UTC+8, Rafael Sanches wrote:

very interesting... 

can you tell me how you did that? in a maven build or only via eclipse?

neither, I did it manually.

ok, the new test result:

1. if I remove all jar files from the war/WEB-INF/lib, the warmup time is about 2.3 seconds.

2. if I put the only the core app engine sdk jar file in war/WEB-INF/lib, but doesn't reference it, the warmup time is about 2.9 seconds.

3. if I put "DatastoreService datastore = DatastoreServiceFactory.getDatastoreService();" in the jsp file but do nothing eslse, the warmup time is 3.5 seconds

4. if I put a query in the default jsp file, the warmup time is 4.7 seconds.

5. if I convert query result as list, the warmup time is 6 seconds.

so, I think it is very clear that the datastore API is main cause of long warmup time. A simple datastoe calling will increase the warmup time much. In above example, the total increased warmup caused by datastore APIs is more than 3 seconds.

Otherwaise, scanning the core app engine sdk jar will cost 0.5 second.

So, @GAE_team, please optimize your datastore APIs. Done!

[Tapir]

On Tuesday, February 18, 2014 6:43:56 PM UTC+8, Tapir wrote:

On Tuesday, February 18, 2014 4:56:51 PM UTC+8, Rafael Sanches wrote:

very interesting... 

can you tell me how you did that? in a maven build or only via eclipse?

neither, I did it manually.

ok, the new test result:

1. if I remove all jar files from the war/WEB-INF/lib, the warmup time is about 2.3 seconds.

2. if I put the only the core app engine sdk jar file in war/WEB-INF/lib, but doesn't reference it, the warmup time is about 2.9 seconds.

3. if I put "DatastoreService datastore = DatastoreServiceFactory.getDatastoreService();" in the jsp file but do nothing eslse, the warmup time is 3.5 seconds

4. if I put a query in the default jsp file, the warmup time is 4.7 seconds.

5. if I convert query result as list, the warmup time is 6 seconds.

so, I think it is very clear that the datastore API is main cause of long warmup time. A simple datastoe calling will increase the warmup time much. In above example, the total increased warmup caused by datastore APIs is more than 3 seconds.

I remember the python datastore doesn't increase the warmup time so much.

[Tapir]

On Tuesday, February 18, 2014 6:43:56 PM UTC+8, Tapir wrote:

On Tuesday, February 18, 2014 4:56:51 PM UTC+8, Rafael Sanches wrote:

very interesting... 

can you tell me how you did that? in a maven build or only via eclipse?

neither, I did it manually.

ok, the new test result:

1. if I remove all jar files from the war/WEB-INF/lib, the warmup time is about 2.3 seconds.

2. if I put the only the core app engine sdk jar file in war/WEB-INF/lib, but doesn't reference it, the warmup time is about 2.9 seconds.

3. if I put "DatastoreService datastore = DatastoreServiceFactory.getDatastoreService();" in the jsp file but do nothing eslse, the warmup time is 3.5 seconds

4. if I put a query in the default jsp file, the warmup time is 4.7 seconds.

5. if I convert query result as list, the warmup time is 6 seconds.

The above tests use the low level datastore APIs.

[Tapir]

On Tuesday, February 18, 2014 6:43:56 PM UTC+8, Tapir wrote:

On Tuesday, February 18, 2014 4:56:51 PM UTC+8, Rafael Sanches wrote:

very interesting... 

can you tell me how you did that? in a maven build or only via eclipse?

neither, I did it manually.

ok, the new test result:

1. if I remove all jar files from the war/WEB-INF/lib, the warmup time is about 2.3 seconds.

2. if I put the only the core app engine sdk jar file in war/WEB-INF/lib, but doesn't reference it, the warmup time is about 2.9 seconds.

3. if I put "DatastoreService datastore = DatastoreServiceFactory.getDatastoreService();" in the jsp file but do nothing eslse, the warmup time is 3.5 seconds

4. if I put a query in the default jsp file, the warmup time is 4.7 seconds.

5. if I convert query result as list, the warmup time is 6 seconds.

so, I think it is very clear that the datastore API is main cause of long warmup time. A simple datastoe calling will increase the warmup time much. In above example, the total increased warmup caused by datastore APIs is more than 3 seconds.

I almost can confirm the time increased doesn't related to remote bigtable servers, it is totally caused by the API design.

[Tapir]

On Tuesday, February 18, 2014 6:43:56 PM UTC+8, Tapir wrote:

On Tuesday, February 18, 2014 4:56:51 PM UTC+8, Rafael Sanches wrote:

very interesting... 

can you tell me how you did that? in a maven build or only via eclipse?

neither, I did it manually.

ok, the new test result:

1. if I remove all jar files from the war/WEB-INF/lib, the warmup time is about 2.3 seconds.

2. if I put the only the core app engine sdk jar file in war/WEB-INF/lib, but doesn't reference it, the warmup time is about 2.9 seconds.

3. if I put "DatastoreService datastore = DatastoreServiceFactory.getDatastoreService();" in the jsp file but do nothing eslse, the warmup time is 3.5 seconds

4. if I put a query in the default jsp file, the warmup time is 4.7 seconds.

5. if I convert query result as list, the warmup time is 6 seconds.

so, I think it is very clear that the datastore API is main cause of long warmup time. A simple datastoe calling will increase the warmup time much. In above example, the total increased warmup caused by datastore APIs is more than 3 seconds.

Otherwaise, scanning the core app engine sdk jar will cost 0.5 second.

So, @GAE_team, please optimize your datastore APIs. Done!

If the APIs is not redesigned, porting my project from framworks to pure jsp/servlet is helpless to decrease the warmup time under 2 seconds.

[Tapir]

Ok, it is the time to make the decision.

I will port my java project to go.

There is really part of the project depends on some java libraries which are hard to find in go world, but I can make the part as a java service on my VPS.

[Tapir]

On Tuesday, February 18, 2014 6:43:56 PM UTC+8, Tapir wrote:

On Tuesday, February 18, 2014 4:56:51 PM UTC+8, Rafael Sanches wrote:

very interesting... 

can you tell me how you did that? in a maven build or only via eclipse?

neither, I did it manually.

ok, the new test result:

1. if I remove all jar files from the war/WEB-INF/lib, the warmup time is about 2.3 seconds.

2. if I put the only the core app engine sdk jar file in war/WEB-INF/lib, but doesn't reference it, the warmup time is about 2.9 seconds.

3. if I put "DatastoreService datastore = DatastoreServiceFactory.getDatastoreService();" in the jsp file but do nothing eslse, the warmup time is 3.5 seconds

4. if I put a query in the default jsp file, the warmup time is 4.7 seconds.

5. if I convert query result as list, the warmup time is 6 seconds.

made some new tests today. The results are some different.

=======================================

First, the impact of number of lib jar files:

1. no lib jar files, warm up time = 3 seconds (slower than yesterday)

2. one core lib jar file, no refs, warm up time = 5 seconds (slower than yesterday)

3. four core lib jar files (the ones under sdk user folder), no refs, warm up time = 5.7 seconds

4. fifty-four jar files (used in my projects) , no refs, warm up time = 6.2 seconds

So, obviously,  the core GAE SDK lib files have a big impact on the warm up time.

========================================

Second, number of references of core sdk lib.

1. no refs, 3.5 seconds

2. fewer refs, 4.4 seconds, by adding "DatastoreService datastore = DatastoreServiceFactory.getDatastoreService();     Key guestbookKey = KeyFactory.createKey("Guestbook", guestbookName);"

3. more refs, 5.5 seconds, by adding "Query query = new Query("Greeting", guestbookKey).addSort("date", Query.SortDirection.DESCENDING);     List<Entity> greetings = datastore.prepare(query).asList(FetchOptions.Builder.withLimit(5));"

So, the first references to core lib class will also increase the warm up time. In this example, only part of core classes are refed, if there are more, the warmup time would be longer.

========================================

The performance of GAE instances varies much in the tests. So the result may be not very accurate, but I think the conclusions are reliable.

Final conclusion: using pure jsp/servlet will not save a GAE java project.

[Emanuele Ziglioli]

Great stuff

hope you don't move to Go too soon!

[Tapir]

On Thursday, February 20, 2014 6:26:52 AM UTC+8, Emanuele Ziglioli wrote:

Great stuff

hope you don't move to Go too soon!

Why?

It is a way of no ways.

[Rafael]

Have you tried playframework? They have optimizations to make your life easier when developing. 

My life is living hell right now when developing with maven and appengine. The play framework solves that by running their own thing. 

Read more: http://www.playframework.com/documentation/1.0/gae

[Emanuele Ziglioli]

As far as I understand, they run their own thing on the local server but on GAE is still deployed in the servlet container.

The PlayGae plugin is not maintained by its original authors so it could be a risky choice.

There are other active frameworks out there, here's one: http://www.ninjaframework.org/

Anyway. the big architectural problems with GAE won't be solved I'm afraid.

Here's a rant...

I've got a very low threshold for bullshit and I cannot stand arrogance. When they talk about the "google way", it's all bullshit.

The "Google Way" IMHO is having a shitload of money and throwing tons of hardware at problems.

It's ridiculous that an instance can barely service 3 reqs/s.

If they want to really scale, they should learn from Node and its truly asynchronous interface.

No matter what you say, when you talk to GAE fanboys it's always down to: "You should review your architecture", it's always down to the users, their fault for not getting "the Google Way" (Halleluja)

We're paying customers (ok, nowhere as big as Snapchat) but still we're entitled to criticise the platform.

We have to front both our employers and customers to justify embarrassing performances.

If the Google Way is something that forces you develop in weird, unintuitive way that defeats good software engineering practices and at the end of the day makes you write code that's both ugly and non portable, well, I wouldn't recommend anyway to go down this way, really

E

[Tapir]

On Friday, February 21, 2014 5:39:17 AM UTC+8, Rafael Sanches wrote:

Have you tried playframework? They have optimizations to make your life easier when developing. 

My life is living hell right now when developing with maven and appengine. The play framework solves that by running their own thing. 

Read more: http://www.playframework.com/documentation/1.0/gae

I don't think they can bypass the core GAE SDK lib.

The problem of GAE Java is at the core GAE SDK lib.

[Nick]

Emanuele, I'm not going to disagree with your points, I think there is validity to what you say. I would like to make a counter-point though.

I think that there are many standard 'good software engineering practices', which are only good in a historical and pragmatic sense. What i mean is that they do not necessarily scale, nor distribute well 

Those sorts of assumptions have found their way into standard frameworks and libraries over the last 15 years, and its an unfortunate position that GAE (which is sold as a scalable distributed platform) needs to prevent software from doing bad things.

I think that the low level APIs generally could be a little easier to consume in java land, but its clear from the apis they've provided and how billing works that they're trying to force people to build apps the 'right' (i.e. scalable) way.

As an aside

Regarding accepting 3 requests concurrently, my understanding is that each instance has effectively a threadpool of 10 threads, and as such you can perform approx 10 concurrent things - so async datastore/searchservice/urlfetches reduce your capacity to serve more concurrent client requests per instance. Maybe someone can confirm that as truth (or just test it).

[Rafael]

Can you try and let us all know? it may be the solution you're looking for. 

[Tapir]

On Sunday, February 23, 2014 1:47:28 PM UTC+8, Rafael Sanches wrote:

Can you try and let us all know? it may be the solution you're looking for. 

The Google App Engine module for Play has not been updated for 2 years! :(

For another one, Objectify , https://code.google.com/p/play-framework-objectify/, the showcase on this page need >15 seconds to load. :(

The decision is made, I will never use java for web development any more, for many reasons, such as not support hot deploy, large memory consumption, too many configurations, too many hidden elements, and too slow startup on GAE.

[Rafael]

Not being updated doesn't mean it doesn't work properly. 

GAE + java is definitely frustrating, but some of your statements are a bit too broad ;)

[de Witte]

We have been working with Java and GAE for several years now and so far no problems. 

AngularJs + ExtJS 4.0 is a good combo for the front end. Although I prefer GWT.

Spring+Maven is a headache even without GAE. We have been avoiding it and doing fine.

Op maandag 24 februari 2014 03:11:22 UTC+1 schreef Rafael Sanches:

[Rafael Sanches]

De Witte,

Do you have a multi module project?

How do you handle that without module? The eclipse plugin doesn't work with that setup.

thanks

rafa

[Rafael]

De Witte,

Do you have a multi module project?

How do you handle that without module? The eclipse plugin doesn't work with that setup.

thanks

rafa

On Wed, Feb 26, 2014 at 3:45 PM, de Witte <wd.de...@gmail.com> wrote:

[de Witte]

We don't use modules, why should you? Do you have a requirement which cannot be done without them?

Op donderdag 27 februari 2014 02:58:56 UTC+1 schreef Rafael Sanches:

[Tapir]

How long is the warmup time of your app?

Can you show the configuration file of your app? (appengine-web.xml)

[Rafael]

Hi De Witte, 

That would happen if you are successful. Imagine building a complex app using app engine. 

It's pretty difficult to stay away from modules. 

For example: 

imagine a social network scenario, where you have long running tasks competing with frontend requests. 

then put britney spears sending a message and blasting thousands of tasks for push notifications. 

Modules have two good things: 

1) different scaling and memory configuration. 

2) separate the code into chunks of smaller packages. (you don't need spring for everything)

Although, modules have big drawbacks: 

1) impossible to develop without throwing the mouse on the wall sometimes. 

2) hate maven integration. (half baked)

3) hate the appengine IDE integration (half baked)

4) hate the dispatch.xml (half baked)

thanks

rafa

[Rafael]

sorry, my last phrase was confusing, I meant: "That would happen if you are successful building a complex architecture using app engine"

[Jeff Schnitzer]

This is pretty much our experience of modules too - especially the
maven integration feels half-baked. But we have a couple batch
operations that run at midnight that require extra memory, and it
sucks to have to pay for that all day.

I think I've been one of the loudest people complaining about the
java/cold start/user facing issue, and yes, it's still a concern.
Every so often a request appears to hang, and that's not really
acceptable, especially for our low-traffic/high-value-per-request app.
But I will also say that it doesn't seem like it has been as much of a
problem as it has been in the past - maybe something got smarter? I
don't notice the hung requests much anymore, and it's been forever
since we've experienced the "startup latency > 60s thus instances
can't get off the ground" problem.

I would describe our java app as a success story, even if the history
has not been perfect. Neither Heroku nor CloudFoundry has been perfect
either.

Jeff

On Fri, Feb 28, 2014 at 1:00 AM, Rafael <mufu...@gmail.com> wrote:

[Rafael]

Hi Jeff,

I would describe mine as success too.

Although, the only point of using appengine was the ease of development and that it would scale as we grew.

1) Ease of development is out of question with a big code base.

2) scale comes at the highest cost.

Thanks
Rafa

[de Witte]

We have roughly the same technical requirements as your social cooking app.

Our biggest project is social game. It has his own fully functional forum, mail message service, friend system, leaders-board, a complex game world with more than 300.000 entities. It has AI tasks, admin services. Different clients for ios, android, facebook.

There are no problems in managing the code, there are no major flaws. Our strongest point is that we have built some key components our self. Simple and elegant request routing mechanism, data access classes and task management. 

We know that our code runs on 600Mhz/128mb instance. There is just no room for a Spring framework.

We keep our junit classes to a minimum to only ensure that A doesn't break if you modify B.

We are java re-factory junkie as we keep optimizing and simplifying our code.

Modules have two good things: 
1) different scaling and memory configuration. 
2) separate the code into chunks of smaller packages. (you don't need spring for everything)

We don't need it and seems like you have a lot of drawbacks. 

Op vrijdag 28 februari 2014 19:02:20 UTC+1 schreef Rafael Sanches: