Jake,
Thanks for giving me a heads up about this.
I have read that post in past but is there any official documentation
other then group posts which mentions something for this. I know we
can reduce the app start to 3-4 seconds but even that is something
which is not acceptable in various
My naive understanding of the problem is that it takes a long time to
initialize the jdo/jpa bridge over the datastore. I haven't had a
chance to try out slim3, but Thomas was stating that the startup time
for instances using slim3 is 1 to 3 seconds (I think). I believe this
is because slim3 is a
Hi Rahul:
For the official documentation please refer to
http://code.google.com/intl/en/appengine/kb/java.html#Should_I_Run_A_Cron_Job
On 6月15日, 下午11時27分, Rahul rahul.jun...@gmail.com wrote:
Jake,
Thanks for giving me a heads up about this.
I have read that post in past but is there any
Hey Rahul,
See
http://groups.google.com/group/google-appengine-java/browse_thread/thread/b57e6c4895333fa8/f5196d61f7f2
for an official discussion of this issue. The first post talks about
discouraged workarounds, but doesn't cite the 60-second ping
specifically. This was the result,
Hi, just joining in, trying to sum up:
In the best case (if we only use the low level datastore + no
frameworks on top) we can only hope that a fresh restart of our app
will take 4.5 seconds?
However if at least one user is hitting the site every 60 seconds from
somewhere in the world, then our
Hi Mark:
The 4.5 seconds is for struts 1.2 in my case. The startup time of
1.3~3.9 seconds is reported by using a more lightweight framework
(slim3). Please refer to
http://groups.google.com/group/slim3-user/browse_thread/thread/e9d2f7a52f3408
On 6月11日, 下午7時32分, Mark mar...@gmail.com wrote:
It would be great if JPA/JDO could be disabled in the Google eclipse
plugin.
I don't need it, but I've not yet figured out how to get rid of the
jars...
On 7 Jun., 17:59, Jake jbrooko...@cast.org wrote:
Hi all,
@Thomas: I will look into that, thank you. The way we generate our
pages in this
Hi Mark,
Yes, you can do better than 4.5 seconds without a framework. Also,
there are layers that can be placed over the low level datastore (e.g
Objectify) that add ease-of-use without noticeable additions to the
startup time.
The 60 second pinging thing is, indeed, done by some users and is
Jake,
Is there any official comments on this from google which says that it
discourage the pinging every 60 seconds or so.
Also if we have some framework which we will always like to have if
doing some production application then what is the way out.
Thanks,
Rahul
On Jun 11, 10:16 am, Jake
Hmm ok I see, so I'm just using JDO without any frameworks on top of that,
but as mentioned in the slim3 tests, JDO does add overhead (sometimes a
significant amount). I don't plan to be doing any large queries (the slim3
example fetches 10,000 objects which I don't plan on doing at any point),
Hi:
You can define the dao interfaces and write the implementation of
the interfaces with datastore low level api or some fast startup
framework other than JDO or JPA. If you need to migrate to other
platform which supports standard RDBMS, you implement the dao
interface with JDO, JPA or
Hey Tin,
Several people were using GAE's built in timing mechanism to ping the
server to accomplish the same thing. Google came out and officially
discouraged this as it tends to throw off any attempts they are
currently making to fix the problem. I can't tell people what to do,
but I opted to
Hi all:
We have found a temporary solution for this issue:
Try with an AJAX timer kicking the server (doing nothing), maybe one
request per minute (or less) and GAE will keep our site / users in the
same node.
In our testing it could avoid the GAE web instance reloaded, but if
the request
Hey,
The logs show what is being GET for any message. When loading some
pages, I noticed that, beyond the initial delay of the page, I saw an
8s delay on one of the javascript files that was referenced in the
code. When I checked the GAE logs, I saw a startup request for the
initial GET for the
Hey,
Here's a concrete example. One page load, 3 loading requests: one for
the library page, another for a CSS file for that page, and a third
for an image on that page. The end result, after a lot of
optimization, is 24 seconds from initial page arrival to full
display. And, it's likely that
Hi Jake:
By default, all css/image files should be treated as static files.
It seems that your css/image files were not served as static files. I
think you should check your static files setting. Please refer to
Hi Jack:
I suggest that maybe you can write a ServletContextListener to monitor
the web instance reloading issue, for our testing we just put a info
logging in the contextInitialized(..) method:
public void contextInitialized(ServletContextEvent evt) {
log.info(Web context inited.);
}
And
Hi all,
@Thomas: I will look into that, thank you. The way we generate our
pages in this framework, however, involves some interesting dynamic
generation of image URLs that are mounted within the application
itself. It ends up being a bit more complicated than just displaying
one string or
Hey Thomas,
I get it all the time - to the point where all of my demonstration
applications are using the development server hosted on a non-GAE
machine :) Anyways, Ikai is (was) aware of the issue from awhile
back, but I'm not sure it's taking priority.
Jake
On Jun 4, 1:33 am, Thomas
Hi Jake:
I am curious about how do you know there were 2 startup during one
request? Did you submit an issue about the phenomenon?
On 6月6日, 上午2時34分, Jake jbrooko...@cast.org wrote:
Hey Thomas,
I get it all the time - to the point where all of my demonstration
applications are using the
Hi all:
We have used this Slim3 framework to do the Counter testing, the
result still has the same problem, but we feel that Slim3 actually is
a very greate framework for GAE, if this performance issue can be
resolved we will use Slim3 to rewrite our project. Otherwise we need
changing to use
What about Gaelyk? (as you brought the topic on the Gaelyk google group too) :-)
http://gaelyk.appspot.com/
On Fri, Jun 4, 2010 at 10:20, Tin tin.c...@gmail.com wrote:
Hi all:
We have used this Slim3 framework to do the Counter testing, the
result still has the same problem, but we feel that
Hi all:
We extremity love the HOT reloading, annotation processing and junit
testing support (Kotori Web Runner integrated) features of Slim3.
If you plan to use GAE please consider this framework it will make
you
feel so happy.
Slim3 Home : http://goo.gl/urLV
--
You received this message
Dear Guillaume:
The GAE auto-restarting issue will make us give up using Gaelyk
because the TemplateServlet needs more time to init, if this issue
can't be resolved quickly we even consider to change to other
platform.
But we very hope the GAE team could pay more attention to this
critical issue
There are three common approaches.
1. Use App Engine for Business.
2. Wait for 'paid to reserve JVM feature'.
3. Use lightweight framework.
--
You received this message because you are subscribed to the Google Groups
Google App Engine for Java group.
To post to this group, send email to
Sorry! I made a mistake. The GAE for Business page (
http://code.google.com/intl/en/appengine/business/ ) doesn't mention
anything about loading request. The No#1 approach is void.
On 6月3日, 下午5時08分, Thomas mylee...@gmail.com wrote:
There are three common approaches.
1. Use App Engine for
Dear Thomas:
Thanks for your quickly reply very much !!!
2. Wait for 'paid to reserve JVM feature'.
Do you have more information about this ?
3. Use lightweight framework.
What lightweight framework did you mean for ?
In this testing we just using Servlet and JSP that's recommend by GAE.
Hello,
If you don't like this general behavior, please star this issue:
http://code.google.com/p/googleappengine/issues/detail?id=2931
I see comments like this pop up all the time, but we must be a rarity.
Anyways, regarding the pay to reserve JVM see this issue:
Hi Jack:
Thanks for your reply very much !!!
If you don't like this general behavior, please star this issue:
http://code.google.com/p/googleappengine/issues/detail?id=2931
YES I have stared this issue, I think every body who uses GAE
should star this issue ^^||
I personally don't like
IMHO, 'Pay to reserve a JVM' is much more reasonable. Although
everybody likes free lunch, but the resources will be wrongly
allocated eventually. For example, the rival company of Google can
legally eat up all its RAM by submitting tremendous amount of huge
size application if there is no
I use struts 1.2.x + Spring 2.0 initially. But quickly I realized
I had to get rid of Spring in order to decrease the startup time. So I
wrote a TidyDelegationProxy (tidy means TIny DependencY injector) to
replace Spring's struts proxy. I successfully reduced the startup CPU
time from 12+
I understand that there can be problems with everyone having a full-
time reserved JVM. My problem is simply that the instance restarts
too frequently. I mean, honestly, one SINGLE page request results in
TWO application restarts? Even if you get it down to 4 seconds,
that's 8-10 seconds just
Dear Thomas:
Correct some mistakes.
I use struts 1.2.x + Spring 2.0 + JDO initially. But quickly I
realized I had to get rid of Spring and JDO in order to decrease the
startup time. So I
used slim3 and wrote a TidyDelegationProxy to replace Spring's struts
proxy. I successfully
Dear Jack:
I understand that there can be problems with everyone having a full-
time reserved JVM. My problem is simply that the instance restarts
too frequently. I mean, honestly, one SINGLE page request results in
TWO application restarts? Even if you get it down to 4 seconds,
that's
Hi Tin:
I'm VERY VERY agree with this, the instance restarting is TOO
frequently, even we just use Servlet + JSP the performance still can't
be accepted. I don't think this'e a reasonable behavior of a
production web container.
In your case, the problem is due to JAP. If you want to have
On 6月4日, 下午12時02分, Jake jbrooko...@cast.org wrote:
I understand that there can be problems with everyone having a full-
time reserved JVM. My problem is simply that the instance restarts
too frequently. I mean, honestly, one SINGLE page request results in
TWO application restarts? Even if
Dear Thomas:
In your case, the problem is due to JAP. If you want to have quick
startup time, you MUST get rid of JPA/JDO and use some other
lightweight persistence api (Slim3, Objectify, Twig, ...) or use low
level datastore api directly to access the datastore.
Thanks for this important
37 matches
Mail list logo
