Re: [appengine-java] Re: R: Re: New GWT/App Engine site

[Jeff Schnitzer]

On Tue, Jun 7, 2011 at 11:07 PM, Giorgio Riccardi  wrote:
> Hi Jeff,
>
> 1) Polishing the navigation, as you said, it kind thought with GWT,
> but I absolutely agree with you that it needs to be improved...
> already some changes have been done, but going back at the same
> position & level on the map is just a mystery ;-)

Just leave the old window intact (but invisible) and render the new
one on top.  When you restore the old window, it should be more or
less the same as it was.  If the map widget gives you trouble, you
don't even need to set it invisible... just layer it under the new
panel with z-index.

> 2) I did not quite understand well what do you mean in "just pick a
> random sample"... Are you suggesting to load a pre-configured map/kml
> with some markers?

When you arrive at the map, it's zoomed out all the way and blank.
Never show an empty map to the user.  Put some markers on there when
zoomed out all the way, or use the google javascript client stuff to
geoip the user and pick a reasonable level of zoom for them.

Jeff

-- 
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 google-appengine-java@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine-java+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine-java?hl=en.

[appengine-java] Timeout while fetching: Google spreadsheet api.

[Aswath Satrasala]

I am writing data using Google Spreadsheet data api
I am frequently getting the following error.

Timeout while fetching:

I have Googled for the above message, and there are few issues created on
the error.  There seems to be no fix.  Anyone has a workaround for this.

Note:  I am using Appengine TaskQueue to write the data.  Hence the timeout
is 10mins.  Still a Timeout??
Any special settings needs to be done to work with Appengine.

-Aswath
www.AccountingGuru.in .

-- 
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 google-appengine-java@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine-java+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine-java?hl=en.

[appengine-java] Re: Is the native API really so much faster than JDO and slim3?

[Erwin Streur]

Indeed Dennis's measurements are very suspicious. First you should do
a couple of warming ups on each of the implementations to prevent
pollution like the JDO classpath scan for enhanced classes (which is
one of the reasons for the high initial run). Then do a couple of run
to determine a range of measurements to spot outlyers. your low-level
API 2millis is definately one.

When I did the measurements I got the following results
low-level: 1150-1550
Slim3: 1150-1600
Objectify: 1950-2400
JDO: 2100-2700

These measurements confirm that GAE designed implementations are
faster then the GAE implementation of a generic data access layer
(JDO), but not so extrem as initially posted.

The initial response using JDO is a known issue and especially low
trafic website should not use it or use the always on feature (maybe
this will change in the new pricing model)

Regards,

Erwin

On Jun 7, 11:00 am, Ian Marshall  wrote:
> The low-level API does indeed look very fast.
>
> Just a comment on JDO: repeat runs roughly halve the JDO run time. I
> presume that this is because for repeat runs the JDO persistence
> manager factory has already been constructed.
>
> On Jun 6, 8:44 pm, DennisP  wrote:
>
> > I'm looking at this online demo:http://slim3demo.appspot.com/performance/
>
> > Sample run:
> > The number of entities: 1
> > low-level API:get: 2 millis
> > Slim3: 2490 millis
> > JDO: 6030 millis
>
> > Is the low-level API really that much faster?

-- 
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 google-appengine-java@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine-java+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine-java?hl=en.

Re: [appengine-java] Request was aborted after waiting too long to attempt to service your request.

[Ikai Lan (Google)]

IIRC, the loading request latency doesn't affect the average time. It's an
average, I believe, and it's a moving window.

A long startup time, however, will result in the scheduler almost always
favoring putting items in the pending queue instead of spinning up new
instances, though. When scheduling a request, we do the lesser of:

cold start time vs. sliding window of pending ms

So if your app takes 10 seconds to startup and requests are spending 5
seconds in the pending queue, we will send the requests to the pending queue
until the expected wait is 10+ seconds. If we decide to spin up new
instances, we only spin up one instance at a time. During the spin up time,
we continue to place new requests on the queue.

I'm thinking we need a new section about scheduling, auto scaling and
wallclock. The wallclock stuff is probably the most confusing ...

Ikai Lan
Developer Programs Engineer, Google App Engine
Blog: http://googleappengine.blogspot.com
Twitter: http://twitter.com/app_engine
Reddit: http://www.reddit.com/r/appengine



On Wed, Jun 8, 2011 at 1:50 PM, Jeff Schnitzer  wrote:

> Is this documented anywhere?  It's something I figured out from
> occasional comments I've seen on this list over the years, but I've
> never seen it mentioned in the official documentation.  And it's kinda
> important.
>
> In particular, I'd like to know what the bounds are for threaded java,
> and how the average time is computed - is it mean, median, or mode?  I
> have a GWT app that takes one major hit at startup (possibly seconds)
> and then performs lots of smaller hits as the user interacts with the
> app.  It would be nice to know if this will cause problems down the
> road...
>
> Jeff
>
> On Tue, Jun 7, 2011 at 6:41 PM, Ikai Lan (Google) 
> wrote:
> > You get this error when your request waits in a pending queue.
> > App Engine apps are autoscaled IF they can average under 1000ms. If they
> > cannot, we do not give you additional instances, and requests line up in
> a
> > pending queue. If your request waits in the pending queue for more than N
> > seconds (I think N is 9 at the moment but I don't know for sure off the
> top
> > of my head), this message is returned.
> > You'll need to look at the average latency and figure out how to drop it
> to
> > under 1000ms. Alternatively, if you enable concurrent Java requests,
> it'll
> > be a higher ceiling before this error appears if you have "Always On"
> since
> > you can serve a total of 3 (always on instances) * M (concurrency factor,
> I
> > think this is 40 at the moment) requests at one time without requiring
> > autoscaling.
> > Ikai Lan
> > Developer Programs Engineer, Google App Engine
> > Blog: http://googleappengine.blogspot.com
> > Twitter: http://twitter.com/app_engine
> > Reddit: http://www.reddit.com/r/appengine
> >
> >
> > On Wed, Jun 8, 2011 at 1:06 AM, holger 
> wrote:
> >>
> >> Hello everyone,
> >>
> >>
> >> i am running a java REST service in the appengine and get this:
> >>
> >> "Request was aborted after waiting too long to attempt to service your
> >> request. This may happen sporadically when the App Engine serving
> cluster is
> >> under unexpectedly high or uneven load. If you see this message
> frequently,
> >> please contact the App Engine team."
> >>
> >>
> >> I see this message frequently and customer requests fail because of it.
> >> Can anyone help me please! Thanks a lot.
> >>
> >> --
> >> You received this message because you are subscribed to the Google
> Groups
> >> "Google App Engine for Java" group.
> >> To view this discussion on the web visit
> >>
> https://groups.google.com/d/msg/google-appengine-java/-/X3E4cnhhblA3Z3dK.
> >> To post to this group, send email to
> >> google-appengine-java@googlegroups.com.
> >> To unsubscribe from this group, send email to
> >> google-appengine-java+unsubscr...@googlegroups.com.
> >> For more options, visit this group at
> >> http://groups.google.com/group/google-appengine-java?hl=en.
> >
> > --
> > 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
> google-appengine-java@googlegroups.com.
> > To unsubscribe from this group, send email to
> > google-appengine-java+unsubscr...@googlegroups.com.
> > For more options, visit this group at
> > http://groups.google.com/group/google-appengine-java?hl=en.
> >
>
> --
> 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
> google-appengine-java@googlegroups.com.
> To unsubscribe from this group, send email to
> google-appengine-java+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/google-appengine-java?hl=en.
>
>

-- 
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 google-appengine-java@googlegroups.com.
T

[appengine-java] Re: appengine-mapreduce: "Returning NOBODY because of SkipAdminCheck"... ??

[Cyrille Vincey]

All mappers return this log message.
Please note it's an INFO message, so you shouldn't worry about it.

On Apr 20, 7:49 am, Santosh kumar  wrote:
> Hi,
>
> I have a mapper which is running fine without errors,
> but finally it displaying "Returning NOBODY because of SkipAdminCheck"...
> continuously.
> What could be the reason ??
>
> Thanks in advance...**

-- 
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 google-appengine-java@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine-java+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine-java?hl=en.

Re: [appengine-java] Timeout while fetching: Google spreadsheet api.

[Ikai Lan (Google)]

I don't think you can do anything on the App Engine end. Have you asked for
tips in the GData groups? It could be that the data you are writing is
inherently slow. Are there methods for writing data in chunks?

Ikai Lan
Developer Programs Engineer, Google App Engine
Blog: http://googleappengine.blogspot.com
Twitter: http://twitter.com/app_engine
Reddit: http://www.reddit.com/r/appengine



On Wed, Jun 8, 2011 at 4:40 PM, Aswath Satrasala  wrote:

> I am writing data using Google Spreadsheet data api
> I am frequently getting the following error.
>
> Timeout while fetching:
>
> I have Googled for the above message, and there are few issues created on
> the error.  There seems to be no fix.  Anyone has a workaround for this.
>
> Note:  I am using Appengine TaskQueue to write the data.  Hence the timeout
> is 10mins.  Still a Timeout??
> Any special settings needs to be done to work with Appengine.
>
> -Aswath
> www.AccountingGuru.in .
>
> --
> 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
> google-appengine-java@googlegroups.com.
> To unsubscribe from this group, send email to
> google-appengine-java+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/google-appengine-java?hl=en.
>

-- 
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 google-appengine-java@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine-java+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine-java?hl=en.

Re: [appengine-java] Re: R: Re: New GWT/App Engine site

[ale]

On Wednesday, June 8, 2011 10:03:58 AM UTC+2, Jeff Schnitzer wrote:
>
> Just leave the old window intact (but invisible) and render the new
> one on top.  When you restore the old window, it should be more or
> less the same as it was.  If the map widget gives you trouble, you
> don't even need to set it invisible... just layer it under the new
> panel with z-index.
>
> This is a good idea... I didn't  thought about because I am always afraid to 
make pages too heavy.
On the search tab we manage better the history, and when you came back on a 
map, you should have the map exacly as you left (but we manage every thing 
in some variable on gwt, I'm not sure that is the best way...)

> 2) I did not quite understand well what do you mean in "just pick a
> > random sample"... Are you suggesting to load a pre-configured map/kml
> > with some markers?
>
> When you arrive at the map, it's zoomed out all the way and blank.
> Never show an empty map to the user.  Put some markers on there when
> zoomed out all the way, or use the google javascript client stuff to
> geoip the user and pick a reasonable level of zoom for them.
>
Right, never show an empty map! For now we show a loading dialog... 
We have optimized the loading, but unfortunately it is still slow ...

Jeff
>

Thanks again !
Alessandro 

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine for Java" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine-java/-/aFZ0VnhrTl9MTmNK.
To post to this group, send email to google-appengine-java@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine-java+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine-java?hl=en.

Re: [appengine-java] Timeout while fetching: Google spreadsheet api.

[Aswath Satrasala]

Yes, I am using the spreadsheet Batch to write the data in chunks.

-Aswath

On Wed, Jun 8, 2011 at 2:24 PM, Ikai Lan (Google)  wrote:

> I don't think you can do anything on the App Engine end. Have you asked for
> tips in the GData groups? It could be that the data you are writing is
> inherently slow. Are there methods for writing data in chunks?
>
> Ikai Lan
> Developer Programs Engineer, Google App Engine
> Blog: http://googleappengine.blogspot.com
> Twitter: http://twitter.com/app_engine
> Reddit: http://www.reddit.com/r/appengine
>
>
>
> On Wed, Jun 8, 2011 at 4:40 PM, Aswath Satrasala <
> aswath.satras...@gmail.com> wrote:
>
>> I am writing data using Google Spreadsheet data api
>> I am frequently getting the following error.
>>
>> Timeout while fetching:
>>
>> I have Googled for the above message, and there are few issues created on
>> the error.  There seems to be no fix.  Anyone has a workaround for this.
>>
>> Note:  I am using Appengine TaskQueue to write the data.  Hence the
>> timeout is 10mins.  Still a Timeout??
>> Any special settings needs to be done to work with Appengine.
>>
>> -Aswath
>> www.AccountingGuru.in .
>>
>> --
>> 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
>> google-appengine-java@googlegroups.com.
>> To unsubscribe from this group, send email to
>> google-appengine-java+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/google-appengine-java?hl=en.
>>
>
>  --
> 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
> google-appengine-java@googlegroups.com.
> To unsubscribe from this group, send email to
> google-appengine-java+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/google-appengine-java?hl=en.
>

-- 
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 google-appengine-java@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine-java+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine-java?hl=en.

Re: [appengine-java] Request was aborted after waiting too long to attempt to service your request.

[Jeff Schnitzer]

Sorry, when I said "I have a GWT app that takes one major hit at
startup (possibly seconds)" I meant the GWT client app itself, on
startup, has a login() call to the server that can take seconds to
process.  Synchronizing facebook data and all that jazz.

I'm not terribly concerned about this since the ratio of login()s to
"other queries" is low, browser refreshes will find mostly cached
data, and I am now hitting Facebook with multiple batches in
parallel... but since I don't really know the limits, it would suck to
find out my architecture doesn't work in-vivo.

Jeff

On Wed, Jun 8, 2011 at 1:50 AM, Ikai Lan (Google)  wrote:
> IIRC, the loading request latency doesn't affect the average time. It's an
> average, I believe, and it's a moving window.
> A long startup time, however, will result in the scheduler almost always
> favoring putting items in the pending queue instead of spinning up new
> instances, though. When scheduling a request, we do the lesser of:
> cold start time vs. sliding window of pending ms
> So if your app takes 10 seconds to startup and requests are spending 5
> seconds in the pending queue, we will send the requests to the pending queue
> until the expected wait is 10+ seconds. If we decide to spin up new
> instances, we only spin up one instance at a time. During the spin up time,
> we continue to place new requests on the queue.
> I'm thinking we need a new section about scheduling, auto scaling and
> wallclock. The wallclock stuff is probably the most confusing ...
> Ikai Lan
> Developer Programs Engineer, Google App Engine
> Blog: http://googleappengine.blogspot.com
> Twitter: http://twitter.com/app_engine
> Reddit: http://www.reddit.com/r/appengine
>
>
> On Wed, Jun 8, 2011 at 1:50 PM, Jeff Schnitzer  wrote:
>>
>> Is this documented anywhere?  It's something I figured out from
>> occasional comments I've seen on this list over the years, but I've
>> never seen it mentioned in the official documentation.  And it's kinda
>> important.
>>
>> In particular, I'd like to know what the bounds are for threaded java,
>> and how the average time is computed - is it mean, median, or mode?  I
>> have a GWT app that takes one major hit at startup (possibly seconds)
>> and then performs lots of smaller hits as the user interacts with the
>> app.  It would be nice to know if this will cause problems down the
>> road...
>>
>> Jeff
>>
>> On Tue, Jun 7, 2011 at 6:41 PM, Ikai Lan (Google) 
>> wrote:
>> > You get this error when your request waits in a pending queue.
>> > App Engine apps are autoscaled IF they can average under 1000ms. If they
>> > cannot, we do not give you additional instances, and requests line up in
>> > a
>> > pending queue. If your request waits in the pending queue for more than
>> > N
>> > seconds (I think N is 9 at the moment but I don't know for sure off the
>> > top
>> > of my head), this message is returned.
>> > You'll need to look at the average latency and figure out how to drop it
>> > to
>> > under 1000ms. Alternatively, if you enable concurrent Java requests,
>> > it'll
>> > be a higher ceiling before this error appears if you have "Always On"
>> > since
>> > you can serve a total of 3 (always on instances) * M (concurrency
>> > factor, I
>> > think this is 40 at the moment) requests at one time without requiring
>> > autoscaling.
>> > Ikai Lan
>> > Developer Programs Engineer, Google App Engine
>> > Blog: http://googleappengine.blogspot.com
>> > Twitter: http://twitter.com/app_engine
>> > Reddit: http://www.reddit.com/r/appengine
>> >
>> >
>> > On Wed, Jun 8, 2011 at 1:06 AM, holger 
>> > wrote:
>> >>
>> >> Hello everyone,
>> >>
>> >>
>> >> i am running a java REST service in the appengine and get this:
>> >>
>> >> "Request was aborted after waiting too long to attempt to service your
>> >> request. This may happen sporadically when the App Engine serving
>> >> cluster is
>> >> under unexpectedly high or uneven load. If you see this message
>> >> frequently,
>> >> please contact the App Engine team."
>> >>
>> >>
>> >> I see this message frequently and customer requests fail because of it.
>> >> Can anyone help me please! Thanks a lot.
>> >>
>> >> --
>> >> You received this message because you are subscribed to the Google
>> >> Groups
>> >> "Google App Engine for Java" group.
>> >> To view this discussion on the web visit
>> >>
>> >> https://groups.google.com/d/msg/google-appengine-java/-/X3E4cnhhblA3Z3dK.
>> >> To post to this group, send email to
>> >> google-appengine-java@googlegroups.com.
>> >> To unsubscribe from this group, send email to
>> >> google-appengine-java+unsubscr...@googlegroups.com.
>> >> For more options, visit this group at
>> >> http://groups.google.com/group/google-appengine-java?hl=en.
>> >
>> > --
>> > 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
>> > google-appengine-java@googlegroups.com.
>> > To unsubscribe from this gr

[appengine-java] Re: common reasons for compile jsp error

[yuvi]

Hi,

what is the error ?
Do you use static include in your jsp ?

On Jun 7, 1:16 pm, Shash Joshi  wrote:
> My app runs locally, but when I go to deploy to GAE I get an compile
> jsp error at line -1. I'm not doing anything fancy. Is there a do and
> don'ts for jsp in GAE which I can check my code against?

-- 
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 google-appengine-java@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine-java+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine-java?hl=en.

Re: [appengine-java] Request was aborted after waiting too long to attempt to service your request.

[Ikai Lan (Google)]

Yeah, that can potentially set things off, but I think you'll be fine.. If
the ratio is low, you will probably be okay, though. I'm saying this because
one way people have "cheated" the system if they had lots of slow requests
was by making lots and lots of essentially no-op requests via the task queue
to average out the latency such that they would be autoassigned more
instances. I'm not sure how we've dealt with that - if at all - but you have
a similar phenomenon, albeit as a result of a perfectly legitimate usage.

As a thought - what about sending something to a special task queue that
only handles these types of requests and returning that data to the client
via the Channel API?

I wish there were some way to make the Facebook JavaScript API play nicely
with server-side requests. I'm not aware of any at the moment.

Ikai Lan
Developer Programs Engineer, Google App Engine
Blog: http://googleappengine.blogspot.com
Twitter: http://twitter.com/app_engine
Reddit: http://www.reddit.com/r/appengine



On Wed, Jun 8, 2011 at 5:39 PM, Jeff Schnitzer  wrote:

> Sorry, when I said "I have a GWT app that takes one major hit at
> startup (possibly seconds)" I meant the GWT client app itself, on
> startup, has a login() call to the server that can take seconds to
> process.  Synchronizing facebook data and all that jazz.
>
> I'm not terribly concerned about this since the ratio of login()s to
> "other queries" is low, browser refreshes will find mostly cached
> data, and I am now hitting Facebook with multiple batches in
> parallel... but since I don't really know the limits, it would suck to
> find out my architecture doesn't work in-vivo.
>
> Jeff
>
> On Wed, Jun 8, 2011 at 1:50 AM, Ikai Lan (Google) 
> wrote:
> > IIRC, the loading request latency doesn't affect the average time. It's
> an
> > average, I believe, and it's a moving window.
> > A long startup time, however, will result in the scheduler almost always
> > favoring putting items in the pending queue instead of spinning up new
> > instances, though. When scheduling a request, we do the lesser of:
> > cold start time vs. sliding window of pending ms
> > So if your app takes 10 seconds to startup and requests are spending 5
> > seconds in the pending queue, we will send the requests to the pending
> queue
> > until the expected wait is 10+ seconds. If we decide to spin up new
> > instances, we only spin up one instance at a time. During the spin up
> time,
> > we continue to place new requests on the queue.
> > I'm thinking we need a new section about scheduling, auto scaling and
> > wallclock. The wallclock stuff is probably the most confusing ...
> > Ikai Lan
> > Developer Programs Engineer, Google App Engine
> > Blog: http://googleappengine.blogspot.com
> > Twitter: http://twitter.com/app_engine
> > Reddit: http://www.reddit.com/r/appengine
> >
> >
> > On Wed, Jun 8, 2011 at 1:50 PM, Jeff Schnitzer 
> wrote:
> >>
> >> Is this documented anywhere?  It's something I figured out from
> >> occasional comments I've seen on this list over the years, but I've
> >> never seen it mentioned in the official documentation.  And it's kinda
> >> important.
> >>
> >> In particular, I'd like to know what the bounds are for threaded java,
> >> and how the average time is computed - is it mean, median, or mode?  I
> >> have a GWT app that takes one major hit at startup (possibly seconds)
> >> and then performs lots of smaller hits as the user interacts with the
> >> app.  It would be nice to know if this will cause problems down the
> >> road...
> >>
> >> Jeff
> >>
> >> On Tue, Jun 7, 2011 at 6:41 PM, Ikai Lan (Google) 
> >> wrote:
> >> > You get this error when your request waits in a pending queue.
> >> > App Engine apps are autoscaled IF they can average under 1000ms. If
> they
> >> > cannot, we do not give you additional instances, and requests line up
> in
> >> > a
> >> > pending queue. If your request waits in the pending queue for more
> than
> >> > N
> >> > seconds (I think N is 9 at the moment but I don't know for sure off
> the
> >> > top
> >> > of my head), this message is returned.
> >> > You'll need to look at the average latency and figure out how to drop
> it
> >> > to
> >> > under 1000ms. Alternatively, if you enable concurrent Java requests,
> >> > it'll
> >> > be a higher ceiling before this error appears if you have "Always On"
> >> > since
> >> > you can serve a total of 3 (always on instances) * M (concurrency
> >> > factor, I
> >> > think this is 40 at the moment) requests at one time without requiring
> >> > autoscaling.
> >> > Ikai Lan
> >> > Developer Programs Engineer, Google App Engine
> >> > Blog: http://googleappengine.blogspot.com
> >> > Twitter: http://twitter.com/app_engine
> >> > Reddit: http://www.reddit.com/r/appengine
> >> >
> >> >
> >> > On Wed, Jun 8, 2011 at 1:06 AM, holger 
> >> > wrote:
> >> >>
> >> >> Hello everyone,
> >> >>
> >> >>
> >> >> i am running a java REST service in the appengine and get this:
> >> >>
> >> >> "Reques

[appengine-java] Why does the info messages stopped appearing in the Logs?

[Daniel]

Hi

I always was writing the info messages to the log (like described in
here :

http://code.google.com/appengine/docs/java/runtime.html#Logging)

I always used the .info method and the messages were perfectly shown
in the Admin Log page,


But recently i noticed the .info messages stopped to work, adn
only .warning and higher are written into the Log...


Why is that?

How can I write .info messages into the log?


import java.util.logging.Logger;

private static final Logger log =
Logger.getLogger(KeepSessionAliveServlet.class.getName());

log.info("KeepSessionAliveServlet");   <-- not working :(

log.warning("KeepSessionAliveServlet");   <-- does work :/

Any ideas?

-- 
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 google-appengine-java@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine-java+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine-java?hl=en.

Re: [appengine-java] Datastore Viewer - Server Error

[Amit Pandey]

I'm also getting the same error.

Any workarround for this???

Thanks,
Amit

On Fri, Apr 22, 2011 at 1:57 PM, Charms Styler wrote:

> I keep getting the following message when ever I Click on the *Datastore
> Viewer* link at the Admin Control Panel.  How can I view my App data??
>
>   
>  *
> *
>
>   Server Error
>
> A server error has occurred.
>
> Return to Applications screen » 
>
> --
> 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
> google-appengine-java@googlegroups.com.
> To unsubscribe from this group, send email to
> google-appengine-java+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/google-appengine-java?hl=en.
>

-- 
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 google-appengine-java@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine-java+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine-java?hl=en.

Re: [appengine-java] Re: Is the native API really so much faster than JDO and slim3?

[Dennis Peterson]

It's not my benchmark, it's Slim3's :) ...but you're right, it's bogus. I
asked on the main appengine group too, and it turns out the low-level
benchmark is doing lazy loading. With that fixed, their numbers come out
like yours.

I found this one too, which also gets results like yours:
http://gaejava.appspot.com/

On Wed, Jun 8, 2011 at 4:44 AM, Erwin Streur  wrote:

> Indeed Dennis's measurements are very suspicious. First you should do
> a couple of warming ups on each of the implementations to prevent
> pollution like the JDO classpath scan for enhanced classes (which is
> one of the reasons for the high initial run). Then do a couple of run
> to determine a range of measurements to spot outlyers. your low-level
> API 2millis is definately one.
>
> When I did the measurements I got the following results
> low-level: 1150-1550
> Slim3: 1150-1600
> Objectify: 1950-2400
> JDO: 2100-2700
>
> These measurements confirm that GAE designed implementations are
> faster then the GAE implementation of a generic data access layer
> (JDO), but not so extrem as initially posted.
>
> The initial response using JDO is a known issue and especially low
> trafic website should not use it or use the always on feature (maybe
> this will change in the new pricing model)
>
> Regards,
>
> Erwin
>
> On Jun 7, 11:00 am, Ian Marshall  wrote:
> > The low-level API does indeed look very fast.
> >
> > Just a comment on JDO: repeat runs roughly halve the JDO run time. I
> > presume that this is because for repeat runs the JDO persistence
> > manager factory has already been constructed.
> >
> > On Jun 6, 8:44 pm, DennisP  wrote:
> >
> > > I'm looking at this online demo:
> http://slim3demo.appspot.com/performance/
> >
> > > Sample run:
> > > The number of entities: 1
> > > low-level API:get: 2 millis
> > > Slim3: 2490 millis
> > > JDO: 6030 millis
> >
> > > Is the low-level API really that much faster?
>
> --
> 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
> google-appengine-java@googlegroups.com.
> To unsubscribe from this group, send email to
> google-appengine-java+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/google-appengine-java?hl=en.
>
>

-- 
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 google-appengine-java@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine-java+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine-java?hl=en.

[appengine-java] Eclipse plugin Vs stand alone GWT

[Amir]

Hi All,

I am a little confused whether to take the plugin path or the GWT one.
True the plugin has GWT built into it but it seems to miss on of the
feature that I am now looking into, which is the MPV pattern. guess
you can do it manually with the plugin but here you there's an auto
generated code which makes things very structured an easy.

so what's the difference between these options?
is it easier to use the one view many panels approach with the GWT
than with the plugin?
I have seen that with GWT the views are combined out of a java file
and an xml one while in the plugin there's only a java file. why is
there a difference and what is a better option?


would appriciate your support with these newbee questions.
Amir

-- 
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 google-appengine-java@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine-java+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine-java?hl=en.

Re: [appengine-java] Re: Is the native API really so much faster than JDO and slim3?

[Yasuo Higa]

It is not bogus.
LazyList#size() fetches all data as follows:
public int size() {
resolveAllData();
return results.size();
}

Yasuo Higa

On Wed, Jun 8, 2011 at 11:32 PM, Dennis Peterson
 wrote:
> It's not my benchmark, it's Slim3's :) ...but you're right, it's bogus. I
> asked on the main appengine group too, and it turns out the low-level
> benchmark is doing lazy loading. With that fixed, their numbers come out
> like yours.
> I found this one too, which also gets results like yours:
> http://gaejava.appspot.com/
>
> On Wed, Jun 8, 2011 at 4:44 AM, Erwin Streur  wrote:
>>
>> Indeed Dennis's measurements are very suspicious. First you should do
>> a couple of warming ups on each of the implementations to prevent
>> pollution like the JDO classpath scan for enhanced classes (which is
>> one of the reasons for the high initial run). Then do a couple of run
>> to determine a range of measurements to spot outlyers. your low-level
>> API 2millis is definately one.
>>
>> When I did the measurements I got the following results
>> low-level: 1150-1550
>> Slim3: 1150-1600
>> Objectify: 1950-2400
>> JDO: 2100-2700
>>
>> These measurements confirm that GAE designed implementations are
>> faster then the GAE implementation of a generic data access layer
>> (JDO), but not so extrem as initially posted.
>>
>> The initial response using JDO is a known issue and especially low
>> trafic website should not use it or use the always on feature (maybe
>> this will change in the new pricing model)
>>
>> Regards,
>>
>> Erwin
>>
>> On Jun 7, 11:00 am, Ian Marshall  wrote:
>> > The low-level API does indeed look very fast.
>> >
>> > Just a comment on JDO: repeat runs roughly halve the JDO run time. I
>> > presume that this is because for repeat runs the JDO persistence
>> > manager factory has already been constructed.
>> >
>> > On Jun 6, 8:44 pm, DennisP  wrote:
>> >
>> > > I'm looking at this online
>> > > demo:http://slim3demo.appspot.com/performance/
>> >
>> > > Sample run:
>> > > The number of entities: 1
>> > > low-level API:get: 2 millis
>> > > Slim3: 2490 millis
>> > > JDO: 6030 millis
>> >
>> > > Is the low-level API really that much faster?
>>
>> --
>> 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
>> google-appengine-java@googlegroups.com.
>> To unsubscribe from this group, send email to
>> google-appengine-java+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/google-appengine-java?hl=en.
>>
>
> --
> 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 google-appengine-java@googlegroups.com.
> To unsubscribe from this group, send email to
> google-appengine-java+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/google-appengine-java?hl=en.
>

-- 
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 google-appengine-java@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine-java+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine-java?hl=en.

Re: [appengine-java] Re: Is the native API really so much faster than JDO and slim3?

[Dennis Peterson]

Apologies, no offense meant. My impression was that if you wanted to, say,
display all that data, it's going to take around 1000 ms to get it, not 1
ms.

On Wed, Jun 8, 2011 at 10:55 AM, Yasuo Higa  wrote:

> It is not bogus.
> LazyList#size() fetches all data as follows:
> public int size() {
>resolveAllData();
>return results.size();
> }
>
> Yasuo Higa
>
> On Wed, Jun 8, 2011 at 11:32 PM, Dennis Peterson
>  wrote:
> > It's not my benchmark, it's Slim3's :) ...but you're right, it's bogus. I
> > asked on the main appengine group too, and it turns out the low-level
> > benchmark is doing lazy loading. With that fixed, their numbers come out
> > like yours.
> > I found this one too, which also gets results like yours:
> > http://gaejava.appspot.com/
> >
> > On Wed, Jun 8, 2011 at 4:44 AM, Erwin Streur 
> wrote:
> >>
> >> Indeed Dennis's measurements are very suspicious. First you should do
> >> a couple of warming ups on each of the implementations to prevent
> >> pollution like the JDO classpath scan for enhanced classes (which is
> >> one of the reasons for the high initial run). Then do a couple of run
> >> to determine a range of measurements to spot outlyers. your low-level
> >> API 2millis is definately one.
> >>
> >> When I did the measurements I got the following results
> >> low-level: 1150-1550
> >> Slim3: 1150-1600
> >> Objectify: 1950-2400
> >> JDO: 2100-2700
> >>
> >> These measurements confirm that GAE designed implementations are
> >> faster then the GAE implementation of a generic data access layer
> >> (JDO), but not so extrem as initially posted.
> >>
> >> The initial response using JDO is a known issue and especially low
> >> trafic website should not use it or use the always on feature (maybe
> >> this will change in the new pricing model)
> >>
> >> Regards,
> >>
> >> Erwin
> >>
> >> On Jun 7, 11:00 am, Ian Marshall  wrote:
> >> > The low-level API does indeed look very fast.
> >> >
> >> > Just a comment on JDO: repeat runs roughly halve the JDO run time. I
> >> > presume that this is because for repeat runs the JDO persistence
> >> > manager factory has already been constructed.
> >> >
> >> > On Jun 6, 8:44 pm, DennisP  wrote:
> >> >
> >> > > I'm looking at this online
> >> > > demo:http://slim3demo.appspot.com/performance/
> >> >
> >> > > Sample run:
> >> > > The number of entities: 1
> >> > > low-level API:get: 2 millis
> >> > > Slim3: 2490 millis
> >> > > JDO: 6030 millis
> >> >
> >> > > Is the low-level API really that much faster?
> >>
> >> --
> >> 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
> >> google-appengine-java@googlegroups.com.
> >> To unsubscribe from this group, send email to
> >> google-appengine-java+unsubscr...@googlegroups.com.
> >> For more options, visit this group at
> >> http://groups.google.com/group/google-appengine-java?hl=en.
> >>
> >
> > --
> > 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
> google-appengine-java@googlegroups.com.
> > To unsubscribe from this group, send email to
> > google-appengine-java+unsubscr...@googlegroups.com.
> > For more options, visit this group at
> > http://groups.google.com/group/google-appengine-java?hl=en.
> >
>
> --
> 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
> google-appengine-java@googlegroups.com.
> To unsubscribe from this group, send email to
> google-appengine-java+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/google-appengine-java?hl=en.
>
>

-- 
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 google-appengine-java@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine-java+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine-java?hl=en.

[appengine-java] Re: Is the native API really so much faster than JDO and slim3?

[Mike Lawrence]

I get...

The number of entities: 1
low level 1717 millis
slim3 1502 millis
objectify 2970 millis
jdo 3485 millis

probably should modify this example
to do an average of several runs

one important thing to note, is slim3 allows you
to update multiple entity types
in a single transaction.
not possible with the other 3 APIs



On Jun 7, 4:00 am, Ian Marshall  wrote:
> The low-level API does indeed look very fast.
>
> Just a comment on JDO: repeat runs roughly halve the JDO run time. I
> presume that this is because for repeat runs the JDO persistence
> manager factory has already been constructed.
>
> On Jun 6, 8:44 pm, DennisP  wrote:> I'm looking at 
> this online demo:http://slim3demo.appspot.com/performance/
>
> > Sample run:
> > The number of entities: 1
> > low-level API:get: 2 millis
> > Slim3: 2490 millis
> > JDO: 6030 millis
>
> > Is the low-level API really that much faster?

-- 
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 google-appengine-java@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine-java+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine-java?hl=en.

[appengine-java] Re: R: Re: New GWT/App Engine site

[Giorgio Riccardi]

Ok Jeff,
we'll try to sort it out also with your good suggestion
;-)

On Jun 8, 10:03 am, Jeff Schnitzer  wrote:
> On Tue, Jun 7, 2011 at 11:07 PM, Giorgio Riccardi  
> wrote:
> > Hi Jeff,
>
> > 1) Polishing the navigation, as you said, it kind thought with GWT,
> > but I absolutely agree with you that it needs to be improved...
> > already some changes have been done, but going back at the same
> > position & level on the map is just a mystery ;-)
>
> Just leave the old window intact (but invisible) and render the new
> one on top.  When you restore the old window, it should be more or
> less the same as it was.  If the map widget gives you trouble, you
> don't even need to set it invisible... just layer it under the new
> panel with z-index.
>
> > 2) I did not quite understand well what do you mean in "just pick a
> > random sample"... Are you suggesting to load a pre-configured map/kml
> > with some markers?
>
> When you arrive at the map, it's zoomed out all the way and blank.
> Never show an empty map to the user.  Put some markers on there when
> zoomed out all the way, or use the google javascript client stuff to
> geoip the user and pick a reasonable level of zoom for them.
>
> Jeff

-- 
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 google-appengine-java@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine-java+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine-java?hl=en.

Re: [appengine-java] Re: Is the native API really so much faster than JDO and slim3?

[Yasuo Higa]

Hi Dennis,

You can see all sources.
http://slim3demo.appspot.com/performance/

Java runtime reflections are very very slow.
If you don't think so, please try it by you.

Yasuo Higa

On Thu, Jun 9, 2011 at 12:00 AM, Dennis Peterson
 wrote:
> Apologies, no offense meant. My impression was that if you wanted to, say,
> display all that data, it's going to take around 1000 ms to get it, not 1
> ms.
>
> On Wed, Jun 8, 2011 at 10:55 AM, Yasuo Higa  wrote:
>>
>> It is not bogus.
>> LazyList#size() fetches all data as follows:
>> public int size() {
>>        resolveAllData();
>>        return results.size();
>> }
>>
>> Yasuo Higa
>>
>> On Wed, Jun 8, 2011 at 11:32 PM, Dennis Peterson
>>  wrote:
>> > It's not my benchmark, it's Slim3's :) ...but you're right, it's bogus.
>> > I
>> > asked on the main appengine group too, and it turns out the low-level
>> > benchmark is doing lazy loading. With that fixed, their numbers come out
>> > like yours.
>> > I found this one too, which also gets results like yours:
>> > http://gaejava.appspot.com/
>> >
>> > On Wed, Jun 8, 2011 at 4:44 AM, Erwin Streur 
>> > wrote:
>> >>
>> >> Indeed Dennis's measurements are very suspicious. First you should do
>> >> a couple of warming ups on each of the implementations to prevent
>> >> pollution like the JDO classpath scan for enhanced classes (which is
>> >> one of the reasons for the high initial run). Then do a couple of run
>> >> to determine a range of measurements to spot outlyers. your low-level
>> >> API 2millis is definately one.
>> >>
>> >> When I did the measurements I got the following results
>> >> low-level: 1150-1550
>> >> Slim3: 1150-1600
>> >> Objectify: 1950-2400
>> >> JDO: 2100-2700
>> >>
>> >> These measurements confirm that GAE designed implementations are
>> >> faster then the GAE implementation of a generic data access layer
>> >> (JDO), but not so extrem as initially posted.
>> >>
>> >> The initial response using JDO is a known issue and especially low
>> >> trafic website should not use it or use the always on feature (maybe
>> >> this will change in the new pricing model)
>> >>
>> >> Regards,
>> >>
>> >> Erwin
>> >>
>> >> On Jun 7, 11:00 am, Ian Marshall  wrote:
>> >> > The low-level API does indeed look very fast.
>> >> >
>> >> > Just a comment on JDO: repeat runs roughly halve the JDO run time. I
>> >> > presume that this is because for repeat runs the JDO persistence
>> >> > manager factory has already been constructed.
>> >> >
>> >> > On Jun 6, 8:44 pm, DennisP  wrote:
>> >> >
>> >> > > I'm looking at this online
>> >> > > demo:http://slim3demo.appspot.com/performance/
>> >> >
>> >> > > Sample run:
>> >> > > The number of entities: 1
>> >> > > low-level API:get: 2 millis
>> >> > > Slim3: 2490 millis
>> >> > > JDO: 6030 millis
>> >> >
>> >> > > Is the low-level API really that much faster?
>> >>
>> >> --
>> >> 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
>> >> google-appengine-java@googlegroups.com.
>> >> To unsubscribe from this group, send email to
>> >> google-appengine-java+unsubscr...@googlegroups.com.
>> >> For more options, visit this group at
>> >> http://groups.google.com/group/google-appengine-java?hl=en.
>> >>
>> >
>> > --
>> > 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
>> > google-appengine-java@googlegroups.com.
>> > To unsubscribe from this group, send email to
>> > google-appengine-java+unsubscr...@googlegroups.com.
>> > For more options, visit this group at
>> > http://groups.google.com/group/google-appengine-java?hl=en.
>> >
>>
>> --
>> 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
>> google-appengine-java@googlegroups.com.
>> To unsubscribe from this group, send email to
>> google-appengine-java+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/google-appengine-java?hl=en.
>>
>
> --
> 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 google-appengine-java@googlegroups.com.
> To unsubscribe from this group, send email to
> google-appengine-java+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/google-appengine-java?hl=en.
>

-- 
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 google-appengine-java@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine-java+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine-java?hl=en.

Re: [appengine-java] Re: Is the native API really so much faster than JDO and slim3?

[Yasuo Higa]

Hi Dennis,

The following document will help you about global transactions:
http://sites.google.com/site/slim3appengine/#gtx

Yasuo Higa

On Thu, Jun 9, 2011 at 12:33 AM, Dennis Peterson
 wrote:
> Those multi-entity transactions are definitely interesting to me. There's
> some overhead but no getting around that.
> A while back I was playing around with some adhoc  methods to do it in a
> specific case, but I suspect Slim3 is more solid and maybe faster than what
> I was doing. Definitely easier. When I get a chance I want to dig in and
> find out how it works.
>
> On Wed, Jun 8, 2011 at 10:26 AM, Mike Lawrence 
> wrote:
>>
>> I get...
>>
>> The number of entities: 1
>> low level 1717 millis
>> slim3 1502 millis
>> objectify 2970 millis
>> jdo 3485 millis
>>
>> probably should modify this example
>> to do an average of several runs
>>
>> one important thing to note, is slim3 allows you
>> to update multiple entity types
>> in a single transaction.
>> not possible with the other 3 APIs
>>
>>
>>
>> On Jun 7, 4:00 am, Ian Marshall  wrote:
>> > The low-level API does indeed look very fast.
>> >
>> > Just a comment on JDO: repeat runs roughly halve the JDO run time. I
>> > presume that this is because for repeat runs the JDO persistence
>> > manager factory has already been constructed.
>> >
>> > On Jun 6, 8:44 pm, DennisP  wrote:> I'm
>> > looking at this online demo:http://slim3demo.appspot.com/performance/
>> >
>> > > Sample run:
>> > > The number of entities: 1
>> > > low-level API:get: 2 millis
>> > > Slim3: 2490 millis
>> > > JDO: 6030 millis
>> >
>> > > Is the low-level API really that much faster?
>>
>> --
>> 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
>> google-appengine-java@googlegroups.com.
>> To unsubscribe from this group, send email to
>> google-appengine-java+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/google-appengine-java?hl=en.
>>
>
> --
> 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 google-appengine-java@googlegroups.com.
> To unsubscribe from this group, send email to
> google-appengine-java+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/google-appengine-java?hl=en.
>

-- 
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 google-appengine-java@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine-java+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine-java?hl=en.

Re: [appengine-java] Re: Is the native API really so much faster than JDO and slim3?

[Dennis Peterson]

Those multi-entity transactions are definitely interesting to me. There's
some overhead but no getting around that.

A while back I was playing around with some adhoc  methods to do it in a
specific case, but I suspect Slim3 is more solid and maybe faster than what
I was doing. Definitely easier. When I get a chance I want to dig in and
find out how it works.

On Wed, Jun 8, 2011 at 10:26 AM, Mike Lawrence wrote:

> I get...
>
> The number of entities: 1
> low level 1717 millis
> slim3 1502 millis
> objectify 2970 millis
> jdo 3485 millis
>
> probably should modify this example
> to do an average of several runs
>
> one important thing to note, is slim3 allows you
> to update multiple entity types
> in a single transaction.
> not possible with the other 3 APIs
>
>
>
> On Jun 7, 4:00 am, Ian Marshall  wrote:
> > The low-level API does indeed look very fast.
> >
> > Just a comment on JDO: repeat runs roughly halve the JDO run time. I
> > presume that this is because for repeat runs the JDO persistence
> > manager factory has already been constructed.
> >
> > On Jun 6, 8:44 pm, DennisP  wrote:> I'm
> looking at this online demo:http://slim3demo.appspot.com/performance/
> >
> > > Sample run:
> > > The number of entities: 1
> > > low-level API:get: 2 millis
> > > Slim3: 2490 millis
> > > JDO: 6030 millis
> >
> > > Is the low-level API really that much faster?
>
> --
> 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
> google-appengine-java@googlegroups.com.
> To unsubscribe from this group, send email to
> google-appengine-java+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/google-appengine-java?hl=en.
>
>

-- 
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 google-appengine-java@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine-java+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine-java?hl=en.

Re: [appengine-java] Re: R: Re: New GWT/App Engine site

[Felipe Teixeira]

Very good =D

2011/6/8 Giorgio Riccardi 

> Ok Jeff,
> we'll try to sort it out also with your good suggestion
> ;-)
>
> On Jun 8, 10:03 am, Jeff Schnitzer  wrote:
> > On Tue, Jun 7, 2011 at 11:07 PM, Giorgio Riccardi 
> wrote:
> > > Hi Jeff,
> >
> > > 1) Polishing the navigation, as you said, it kind thought with GWT,
> > > but I absolutely agree with you that it needs to be improved...
> > > already some changes have been done, but going back at the same
> > > position & level on the map is just a mystery ;-)
> >
> > Just leave the old window intact (but invisible) and render the new
> > one on top.  When you restore the old window, it should be more or
> > less the same as it was.  If the map widget gives you trouble, you
> > don't even need to set it invisible... just layer it under the new
> > panel with z-index.
> >
> > > 2) I did not quite understand well what do you mean in "just pick a
> > > random sample"... Are you suggesting to load a pre-configured map/kml
> > > with some markers?
> >
> > When you arrive at the map, it's zoomed out all the way and blank.
> > Never show an empty map to the user.  Put some markers on there when
> > zoomed out all the way, or use the google javascript client stuff to
> > geoip the user and pick a reasonable level of zoom for them.
> >
> > Jeff
>
> --
> 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
> google-appengine-java@googlegroups.com.
> To unsubscribe from this group, send email to
> google-appengine-java+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/google-appengine-java?hl=en.
>
>


-- 
*Felipe Teixeira*
*Desenvolvedor Java
*
IPNET Soluções
Tel.: 55 21 3553 2717 / 21-7805-6867
Rua Visconde de Inhaúma, 134, Sala 615
Centro - RJ - CEP: 20091-007
*http://www.ipnetsolucoes.com.br** *


**
*
*

-- 
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 google-appengine-java@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine-java+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine-java?hl=en.

Re: [appengine-java] Re: Is the native API really so much faster than JDO and slim3?

[Dennis Peterson]

No I agree, and slim3 looks very interesting to me. It was just the very
fast low-level times I was wondering about, but it looks like normally slim3
and low-level will be about the same speed.

On Wed, Jun 8, 2011 at 11:42 AM, Yasuo Higa  wrote:

> Hi Dennis,
>
> You can see all sources.
> http://slim3demo.appspot.com/performance/
>
> Java runtime reflections are very very slow.
> If you don't think so, please try it by you.
>
> Yasuo Higa
>
> On Thu, Jun 9, 2011 at 12:00 AM, Dennis Peterson
>  wrote:
> > Apologies, no offense meant. My impression was that if you wanted to,
> say,
> > display all that data, it's going to take around 1000 ms to get it, not 1
> > ms.
> >
> > On Wed, Jun 8, 2011 at 10:55 AM, Yasuo Higa  wrote:
> >>
> >> It is not bogus.
> >> LazyList#size() fetches all data as follows:
> >> public int size() {
> >>resolveAllData();
> >>return results.size();
> >> }
> >>
> >> Yasuo Higa
> >>
> >> On Wed, Jun 8, 2011 at 11:32 PM, Dennis Peterson
> >>  wrote:
> >> > It's not my benchmark, it's Slim3's :) ...but you're right, it's
> bogus.
> >> > I
> >> > asked on the main appengine group too, and it turns out the low-level
> >> > benchmark is doing lazy loading. With that fixed, their numbers come
> out
> >> > like yours.
> >> > I found this one too, which also gets results like yours:
> >> > http://gaejava.appspot.com/
> >> >
> >> > On Wed, Jun 8, 2011 at 4:44 AM, Erwin Streur 
> >> > wrote:
> >> >>
> >> >> Indeed Dennis's measurements are very suspicious. First you should do
> >> >> a couple of warming ups on each of the implementations to prevent
> >> >> pollution like the JDO classpath scan for enhanced classes (which is
> >> >> one of the reasons for the high initial run). Then do a couple of run
> >> >> to determine a range of measurements to spot outlyers. your low-level
> >> >> API 2millis is definately one.
> >> >>
> >> >> When I did the measurements I got the following results
> >> >> low-level: 1150-1550
> >> >> Slim3: 1150-1600
> >> >> Objectify: 1950-2400
> >> >> JDO: 2100-2700
> >> >>
> >> >> These measurements confirm that GAE designed implementations are
> >> >> faster then the GAE implementation of a generic data access layer
> >> >> (JDO), but not so extrem as initially posted.
> >> >>
> >> >> The initial response using JDO is a known issue and especially low
> >> >> trafic website should not use it or use the always on feature (maybe
> >> >> this will change in the new pricing model)
> >> >>
> >> >> Regards,
> >> >>
> >> >> Erwin
> >> >>
> >> >> On Jun 7, 11:00 am, Ian Marshall  wrote:
> >> >> > The low-level API does indeed look very fast.
> >> >> >
> >> >> > Just a comment on JDO: repeat runs roughly halve the JDO run time.
> I
> >> >> > presume that this is because for repeat runs the JDO persistence
> >> >> > manager factory has already been constructed.
> >> >> >
> >> >> > On Jun 6, 8:44 pm, DennisP  wrote:
> >> >> >
> >> >> > > I'm looking at this online
> >> >> > > demo:http://slim3demo.appspot.com/performance/
> >> >> >
> >> >> > > Sample run:
> >> >> > > The number of entities: 1
> >> >> > > low-level API:get: 2 millis
> >> >> > > Slim3: 2490 millis
> >> >> > > JDO: 6030 millis
> >> >> >
> >> >> > > Is the low-level API really that much faster?
> >> >>
> >> >> --
> >> >> 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
> >> >> google-appengine-java@googlegroups.com.
> >> >> To unsubscribe from this group, send email to
> >> >> google-appengine-java+unsubscr...@googlegroups.com.
> >> >> For more options, visit this group at
> >> >> http://groups.google.com/group/google-appengine-java?hl=en.
> >> >>
> >> >
> >> > --
> >> > 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
> >> > google-appengine-java@googlegroups.com.
> >> > To unsubscribe from this group, send email to
> >> > google-appengine-java+unsubscr...@googlegroups.com.
> >> > For more options, visit this group at
> >> > http://groups.google.com/group/google-appengine-java?hl=en.
> >> >
> >>
> >> --
> >> 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
> >> google-appengine-java@googlegroups.com.
> >> To unsubscribe from this group, send email to
> >> google-appengine-java+unsubscr...@googlegroups.com.
> >> For more options, visit this group at
> >> http://groups.google.com/group/google-appengine-java?hl=en.
> >>
> >
> > --
> > 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
> google-appengine-java@googlegroups.com.
> > To unsubscribe from this group, send email to
> > google-appengine-java+unsubscr...@googlegroups.com.
> > For more options, v

Re: [appengine-java] Re: Short-lived timer

[Weston Pace]

That's a great fix.

Thanks,

-Weston

On Tue, Jun 7, 2011 at 7:30 PM, Ikai Lan (Google)  wrote:
> Another possibility could be to lazily calculate turns. When a user has
> either a rich client or web browser open, it pings the server every N
> seconds. The server then evaluates whether it's a new turn or not and does
> the computations at this time. If M turns have passed, the server runs the
> game through M iterations to "catch up" the game.
> Depending on what you're doing, this may be a slightly better
> implementation. Eager updating has the tradeoff of not scaling well, as the
> amount of work is linearly dependent on the number of games. Lazy evaluation
> has the benefit of scaling linearly as a function of the number of *active*
> games (many games will be abandoned), and, you can also "collapse" RPC calls
> to the datastore into a single call instead of repeatedly making them every
> N seconds. For instance: let's say you need to save game state each time.
> Over 10 minutes, you have to make 30 saves per game if you update every 20
> seconds. If it's possible to collapse updating of game state lazily, if a
> user logs out and logs back in 10 minutes later, you can read the game
> state, run it through 10 minutes worth of iterations, and resave it - you've
> just improved your throughput in that scenario by a factor of 30, since
> in-memory local computations are incredibly cheap relative to off machine
> RPCs.
> One of the best practices of building App Engine is to minimize RPCs since
> these are the most expensive parts of your system.
> Ikai Lan
> Developer Programs Engineer, Google App Engine
> Blog: http://googleappengine.blogspot.com
> Twitter: http://twitter.com/app_engine
> Reddit: http://www.reddit.com/r/appengine
>
>
> On Tue, Jun 7, 2011 at 3:26 AM, Ian Marshall 
> wrote:
>>
>> Would queued tasks in general, and deferred tasks in particular, suit
>> you? You can set an ETA for these tasks, and GAE/J guarantees not to
>> fire these tasks before any ETA set.
>>
>> You could use a scheduled task for a "heartbeat" of interval 1 minute,
>> and use this to enqueue tasks for ETAs such that you could have queued
>> task "heartbeats" as desired between your 1 minute scheduled task
>> "heartbeats".
>>
>>
>> On Jun 4, 4:07 am, Weston Pace  wrote:
>> > I'm working on an interactive game.  I was hoping for turns to be on
>> > the order of 20 seconds or less.  It appears the cron framework can
>> > only schedule things in 1-minute intervals.  Is there any method for
>> > shorter timers in GAE?
>>
>> --
>> 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
>> google-appengine-java@googlegroups.com.
>> To unsubscribe from this group, send email to
>> google-appengine-java+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/google-appengine-java?hl=en.
>>
>
> --
> 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 google-appengine-java@googlegroups.com.
> To unsubscribe from this group, send email to
> google-appengine-java+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/google-appengine-java?hl=en.
>

-- 
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 google-appengine-java@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine-java+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine-java?hl=en.

[appengine-java] Does AppEngine support Servlet 3.0 ServletContainerInitializer

[Marcel Overdijk]

Does AppEngine support Servlet 3.0 ServletContainerInitializer for
code-based configuration of Servlet Container?

-- 
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 google-appengine-java@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine-java+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine-java?hl=en.

Re: [appengine-java] Re: Is the native API really so much faster than JDO and slim3?

[Jeff Schnitzer]

You are wrong.

Try adding getProperty() calls to your LL performance test, and the
speed advantage of the LL API goes away.  I don't know what to say
about Slim3, but here's my test case:

http://code.google.com/p/scratchmonkey/source/browse/#svn%2Fappengine%2Fperformance-test

I created 10,000 entities in the datastore that have the same format
as your test case - a single string property.  Here's what happens
(try it - and remember to reload the urls several times to get a
realistic median value):

## Low Level API with just .size()

http://voodoodyne.appspot.com/fetchLLSize

The code:

List things =
DatastoreServiceFactory.getDatastoreService()
.prepare(new 
Query(Thing.class.getAnnotation(javax.persistence.Entity.class).name()))
.asList(FetchOptions.Builder.withDefaults());
things.size();

Note that results are almost always under 2000ms.  Wild guess I'd say
the median elapsed is ~1900, just like your example.

## Low Level API with actual fetch of the data

http://voodoodyne.appspot.com/fetchLL

The code:

List things =
DatastoreServiceFactory.getDatastoreService()
.prepare(new 
Query(Thing.class.getAnnotation(javax.persistence.Entity.class).name()))
.asList(FetchOptions.Builder.withDefaults());
for (Entity ent: things)
{
ent.getKey();
ent.getProperty("value");
}

Note that the duration is now considerably longer.  Eyeballing the
median elapsed time, I'd say somewhere around 3000ms.

## Objectify fetching from datastore

http://voodoodyne.appspot.com/fetch

Objectify ofy = ObjectifyService.begin();
List things = ofy.query(Thing.class).list();
for (Thing thing: things)
{
thing.getId();
thing.getValue();
}

Note that the timing is pretty much the same as the LL API when it
includes actual fetches of the entity values.  It is, no doubt, just a
little higher.

## A pure measurement of Objectify's overhead

http://voodoodyne.appspot.com/fakeFetch

This causes Objectify to translate 10,000 statically-created Entity
objects to POJOs.  You can see the code here:

http://code.google.com/p/scratchmonkey/source/browse/appengine/performance-test/src/test/FakeFetchServlet.java

You'll notice (after you hit the URL a couple times to warm up the
JIT) that elapsed time converges to somewhere around 120ms.

---

Conclusion:

The numbers in the original benchmark are a result of improper
measurements.  The actual wall-clock overhead for Objectify in this
test is ~4% (120ms out of 3000ms).

Further speculation on my part, but probably correct: The overhead of
reflection is unlikely to be a significant part of that 4%.

Sloppy work.

Jeff

On Wed, Jun 8, 2011 at 7:55 AM, Yasuo Higa  wrote:
> It is not bogus.
> LazyList#size() fetches all data as follows:
> public int size() {
>        resolveAllData();
>        return results.size();
> }
>
> Yasuo Higa
>
> On Wed, Jun 8, 2011 at 11:32 PM, Dennis Peterson
>  wrote:
>> It's not my benchmark, it's Slim3's :) ...but you're right, it's bogus. I
>> asked on the main appengine group too, and it turns out the low-level
>> benchmark is doing lazy loading. With that fixed, their numbers come out
>> like yours.
>> I found this one too, which also gets results like yours:
>> http://gaejava.appspot.com/
>>
>> On Wed, Jun 8, 2011 at 4:44 AM, Erwin Streur  wrote:
>>>
>>> Indeed Dennis's measurements are very suspicious. First you should do
>>> a couple of warming ups on each of the implementations to prevent
>>> pollution like the JDO classpath scan for enhanced classes (which is
>>> one of the reasons for the high initial run). Then do a couple of run
>>> to determine a range of measurements to spot outlyers. your low-level
>>> API 2millis is definately one.
>>>
>>> When I did the measurements I got the following results
>>> low-level: 1150-1550
>>> Slim3: 1150-1600
>>> Objectify: 1950-2400
>>> JDO: 2100-2700
>>>
>>> These measurements confirm that GAE designed implementations are
>>> faster then the GAE implementation of a generic data access layer
>>> (JDO), but not so extrem as initially posted.
>>>
>>> The initial response using JDO is a known issue and especially low
>>> trafic website should not use it or use the always on feature (maybe
>>> this will change in the new pricing model)
>>>
>>> Regards,
>>>
>>> Erwin
>>>
>>> On Jun 7, 11:00 am, Ian Marshall  wrote:
>>> > The low-level API does indeed look very fast.
>>> >
>>> > Just a comment on JDO: repeat runs roughly halve the JDO run time. I
>>> > presume that this is because for repeat runs the JDO persistence
>>> > manager factory has already been constructed.
>>> >
>>> > On Jun 6, 8:44 pm, DennisP  wrote:
>>> >
>>> > > I'm looking at this online
>>> > > demo:http://slim3demo.appspot.com/performance/
>>> >
>>> > > Sample run:
>>> > > The number of entities: 1
>>> > > low-level API:get: 2 millis
>>> > > Slim3: 2490 millis
>>> > > JDO: 6030 millis
>>> >
>>> > > Is the low-level API really 

Re: [appengine-java] Does AppEngine support Servlet 3.0 ServletContainerInitializer

[Jeff Schnitzer]

Unfortunately GAE does not support Servlet 3.0.

Please star:  http://code.google.com/p/googleappengine/issues/detail?id=3091

Jeff

On Wed, Jun 8, 2011 at 11:45 AM, Marcel Overdijk
 wrote:
> Does AppEngine support Servlet 3.0 ServletContainerInitializer for
> code-based configuration of Servlet Container?
>
> --
> 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 google-appengine-java@googlegroups.com.
> To unsubscribe from this group, send email to 
> google-appengine-java+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/google-appengine-java?hl=en.
>
>

-- 
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 google-appengine-java@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine-java+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine-java?hl=en.

[appengine-java] Re: Does AppEngine support Servlet 3.0 ServletContainerInitializer

[Marcel Overdijk]

Silly me, already starred this some time ago...
Thanks anyway Jeff.

On Jun 8, 10:26 pm, Jeff Schnitzer  wrote:
> Unfortunately GAE does not support Servlet 3.0.
>
> Please star:  http://code.google.com/p/googleappengine/issues/detail?id=3091
>
> Jeff
>
> On Wed, Jun 8, 2011 at 11:45 AM, Marcel Overdijk
>
>
>
>
>
>
>
>  wrote:
> > Does AppEngine support Servlet 3.0 ServletContainerInitializer for
> > code-based configuration of Servlet Container?
>
> > --
> > 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 google-appengine-java@googlegroups.com.
> > To unsubscribe from this group, send email to 
> > google-appengine-java+unsubscr...@googlegroups.com.
> > For more options, visit this group 
> > athttp://groups.google.com/group/google-appengine-java?hl=en.

-- 
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 google-appengine-java@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine-java+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine-java?hl=en.

Re: [appengine-java] Re: Is the native API really so much faster than JDO and slim3?

[Gal Dolber]

Slim3 is not only fast, the api is completely awesome. It has been my choice
for a year now for all gae projects.
It includes "name safety" and and amazing querying utils.
Very recommendable!

On Wed, Jun 8, 2011 at 3:41 PM, Jeff Schnitzer  wrote:

> You are wrong.
>
> Try adding getProperty() calls to your LL performance test, and the
> speed advantage of the LL API goes away.  I don't know what to say
> about Slim3, but here's my test case:
>
>
> http://code.google.com/p/scratchmonkey/source/browse/#svn%2Fappengine%2Fperformance-test
>
> I created 10,000 entities in the datastore that have the same format
> as your test case - a single string property.  Here's what happens
> (try it - and remember to reload the urls several times to get a
> realistic median value):
>
> ## Low Level API with just .size()
>
> http://voodoodyne.appspot.com/fetchLLSize
>
> The code:
>
> List things =
>DatastoreServiceFactory.getDatastoreService()
>.prepare(new
> Query(Thing.class.getAnnotation(javax.persistence.Entity.class).name()))
>.asList(FetchOptions.Builder.withDefaults());
> things.size();
>
> Note that results are almost always under 2000ms.  Wild guess I'd say
> the median elapsed is ~1900, just like your example.
>
> ## Low Level API with actual fetch of the data
>
> http://voodoodyne.appspot.com/fetchLL
>
> The code:
>
> List things =
>DatastoreServiceFactory.getDatastoreService()
>.prepare(new
> Query(Thing.class.getAnnotation(javax.persistence.Entity.class).name()))
>.asList(FetchOptions.Builder.withDefaults());
> for (Entity ent: things)
> {
>ent.getKey();
>ent.getProperty("value");
> }
>
> Note that the duration is now considerably longer.  Eyeballing the
> median elapsed time, I'd say somewhere around 3000ms.
>
> ## Objectify fetching from datastore
>
> http://voodoodyne.appspot.com/fetch
>
> Objectify ofy = ObjectifyService.begin();
> List things = ofy.query(Thing.class).list();
> for (Thing thing: things)
> {
>thing.getId();
>thing.getValue();
> }
>
> Note that the timing is pretty much the same as the LL API when it
> includes actual fetches of the entity values.  It is, no doubt, just a
> little higher.
>
> ## A pure measurement of Objectify's overhead
>
> http://voodoodyne.appspot.com/fakeFetch
>
> This causes Objectify to translate 10,000 statically-created Entity
> objects to POJOs.  You can see the code here:
>
>
> http://code.google.com/p/scratchmonkey/source/browse/appengine/performance-test/src/test/FakeFetchServlet.java
>
> You'll notice (after you hit the URL a couple times to warm up the
> JIT) that elapsed time converges to somewhere around 120ms.
>
> ---
>
> Conclusion:
>
> The numbers in the original benchmark are a result of improper
> measurements.  The actual wall-clock overhead for Objectify in this
> test is ~4% (120ms out of 3000ms).
>
> Further speculation on my part, but probably correct: The overhead of
> reflection is unlikely to be a significant part of that 4%.
>
> Sloppy work.
>
> Jeff
>
> On Wed, Jun 8, 2011 at 7:55 AM, Yasuo Higa  wrote:
> > It is not bogus.
> > LazyList#size() fetches all data as follows:
> > public int size() {
> >resolveAllData();
> >return results.size();
> > }
> >
> > Yasuo Higa
> >
> > On Wed, Jun 8, 2011 at 11:32 PM, Dennis Peterson
> >  wrote:
> >> It's not my benchmark, it's Slim3's :) ...but you're right, it's bogus.
> I
> >> asked on the main appengine group too, and it turns out the low-level
> >> benchmark is doing lazy loading. With that fixed, their numbers come out
> >> like yours.
> >> I found this one too, which also gets results like yours:
> >> http://gaejava.appspot.com/
> >>
> >> On Wed, Jun 8, 2011 at 4:44 AM, Erwin Streur 
> wrote:
> >>>
> >>> Indeed Dennis's measurements are very suspicious. First you should do
> >>> a couple of warming ups on each of the implementations to prevent
> >>> pollution like the JDO classpath scan for enhanced classes (which is
> >>> one of the reasons for the high initial run). Then do a couple of run
> >>> to determine a range of measurements to spot outlyers. your low-level
> >>> API 2millis is definately one.
> >>>
> >>> When I did the measurements I got the following results
> >>> low-level: 1150-1550
> >>> Slim3: 1150-1600
> >>> Objectify: 1950-2400
> >>> JDO: 2100-2700
> >>>
> >>> These measurements confirm that GAE designed implementations are
> >>> faster then the GAE implementation of a generic data access layer
> >>> (JDO), but not so extrem as initially posted.
> >>>
> >>> The initial response using JDO is a known issue and especially low
> >>> trafic website should not use it or use the always on feature (maybe
> >>> this will change in the new pricing model)
> >>>
> >>> Regards,
> >>>
> >>> Erwin
> >>>
> >>> On Jun 7, 11:00 am, Ian Marshall  wrote:
> >>> > The low-level API does indeed look very fast.
> >>> >
> >>> > Just a comment on JDO: repeat

Re: [appengine-java] Re: Is the native API really so much faster than JDO and slim3?

[Jeff Schnitzer]

Slim3 may be a nice piece of software, but it has not been
demonstrated to be faster than anything (including JDO).  It might or
might not be faster - I don't know - but based on the sloppy
benchmarking, I'm pretty certain that the people making this claim
don't know either.

There's another ill-conceived performance claim on the Slim3 website:
"You may worry about the overhead of global transactions. Don't worry.
It is not very expensive."  There are three problems with their little
performance test:

 1) It only measures wall-clock time, not cost.
 2) It does not measure what happens under contention.
 3) The numbers are obviously wrong - they don't even pass a smoke test.

Look at these numbers (from the Slim3 home page):

Entity Groups   Local Transaction(millis)   Global Transaction(millis)
1   67  70
2   450 415
3   213 539
4   1498981
5   447 781

Just like the 1ms low-level API query performance in the benchmark
that spawned this thread, even a casual observer should be able to
recognize the obvious flaw - the numbers don't show any expected
relationship between # of entity groups or the use of global
transactions.  Interpreted literally, you would assume that local
transactions are much faster for 5 entity groups, but global
transactions are much faster for 4 entity groups.

It's pretty obvious that the benchmark author just ran one pass and
took the numbers as-is.  If you actually run multiple passes, you'll
find that there is enormous variance in the timing.  The only way you
can realistically measure results like this on appengine is to execute
the test 100 times and take a median.

FWIW, I deliberately haven't made any performance claims for Objectify
because I haven't put the necessary amount of due diligence into
creating a proper set of benchmarks.  It is not easy to measure
performance, especially in a dynamic environment like appengine.  I
only hope that the Slim3 authors have put more care and thought into
crafting their library than they have their benchmarks.

Jeff


On Wed, Jun 8, 2011 at 2:34 PM, Gal Dolber  wrote:
> Slim3 is not only fast, the api is completely awesome. It has been my choice
> for a year now for all gae projects.
> It includes "name safety" and and amazing querying utils.
> Very recommendable!
>
> On Wed, Jun 8, 2011 at 3:41 PM, Jeff Schnitzer  wrote:
>>
>> You are wrong.
>>
>> Try adding getProperty() calls to your LL performance test, and the
>> speed advantage of the LL API goes away.  I don't know what to say
>> about Slim3, but here's my test case:
>>
>>
>> http://code.google.com/p/scratchmonkey/source/browse/#svn%2Fappengine%2Fperformance-test
>>
>> I created 10,000 entities in the datastore that have the same format
>> as your test case - a single string property.  Here's what happens
>> (try it - and remember to reload the urls several times to get a
>> realistic median value):
>>
>> ## Low Level API with just .size()
>>
>> http://voodoodyne.appspot.com/fetchLLSize
>>
>> The code:
>>
>> List things =
>>        DatastoreServiceFactory.getDatastoreService()
>>                .prepare(new
>> Query(Thing.class.getAnnotation(javax.persistence.Entity.class).name()))
>>                .asList(FetchOptions.Builder.withDefaults());
>> things.size();
>>
>> Note that results are almost always under 2000ms.  Wild guess I'd say
>> the median elapsed is ~1900, just like your example.
>>
>> ## Low Level API with actual fetch of the data
>>
>> http://voodoodyne.appspot.com/fetchLL
>>
>> The code:
>>
>> List things =
>>        DatastoreServiceFactory.getDatastoreService()
>>                .prepare(new
>> Query(Thing.class.getAnnotation(javax.persistence.Entity.class).name()))
>>                .asList(FetchOptions.Builder.withDefaults());
>> for (Entity ent: things)
>> {
>>        ent.getKey();
>>        ent.getProperty("value");
>> }
>>
>> Note that the duration is now considerably longer.  Eyeballing the
>> median elapsed time, I'd say somewhere around 3000ms.
>>
>> ## Objectify fetching from datastore
>>
>> http://voodoodyne.appspot.com/fetch
>>
>> Objectify ofy = ObjectifyService.begin();
>> List things = ofy.query(Thing.class).list();
>> for (Thing thing: things)
>> {
>>        thing.getId();
>>        thing.getValue();
>> }
>>
>> Note that the timing is pretty much the same as the LL API when it
>> includes actual fetches of the entity values.  It is, no doubt, just a
>> little higher.
>>
>> ## A pure measurement of Objectify's overhead
>>
>> http://voodoodyne.appspot.com/fakeFetch
>>
>> This causes Objectify to translate 10,000 statically-created Entity
>> objects to POJOs.  You can see the code here:
>>
>>
>> http://code.google.com/p/scratchmonkey/source/browse/appengine/performance-test/src/test/FakeFetchServlet.java
>>
>> You'll notice (after you hit the URL a couple times to warm up the
>> JIT) that elapsed time converges to somewhere around 120ms.
>>
>> ---
>>
>> Conclusion:
>>
>> The numbers in

Re: [appengine-java] Re: Is the native API really so much faster than JDO and slim3?

[Gal Dolber]

Jeff, Objectify is a great project, I have used it a lot before slim3.
I didn't use slim3 global transactions yet, but I don't understand why you
attack that when that is the one feature that jdo/jpa/objectify/twig cannot
deliver.
Slim3 is indeed faster than any other because of the simple fact that it
uses apt(code generation) instead of reflexion, the generated code it's
almost the same that you'll write by-hand to wrap the low-level api.
I have made several small projects with the low level api and I needed to
write the util classes to do Entity->Pojo, Pojo->Entity anyway, so it is
understandable that slim3 will have the same performance than using the low
level api, cause in the end, the code is the same... you just don't need to
write it.

I like to have many libraries to choose from... you should not try to defeat
slim3, there are many ideas you can use for objectify to make it much
better, I am not sure if you tried it yet, but it really worth it, they did
a great job.
Regards

On Wed, Jun 8, 2011 at 6:45 PM, Jeff Schnitzer  wrote:

> Slim3 may be a nice piece of software, but it has not been
> demonstrated to be faster than anything (including JDO).  It might or
> might not be faster - I don't know - but based on the sloppy
> benchmarking, I'm pretty certain that the people making this claim
> don't know either.
>
> There's another ill-conceived performance claim on the Slim3 website:
> "You may worry about the overhead of global transactions. Don't worry.
> It is not very expensive."  There are three problems with their little
> performance test:
>
>  1) It only measures wall-clock time, not cost.
>  2) It does not measure what happens under contention.
>  3) The numbers are obviously wrong - they don't even pass a smoke test.
>
> Look at these numbers (from the Slim3 home page):
>
> Entity Groups   Local Transaction(millis)   Global Transaction(millis)
> 1   67  70
> 2   450 415
> 3   213 539
> 4   1498981
> 5   447 781
>
> Just like the 1ms low-level API query performance in the benchmark
> that spawned this thread, even a casual observer should be able to
> recognize the obvious flaw - the numbers don't show any expected
> relationship between # of entity groups or the use of global
> transactions.  Interpreted literally, you would assume that local
> transactions are much faster for 5 entity groups, but global
> transactions are much faster for 4 entity groups.
>
> It's pretty obvious that the benchmark author just ran one pass and
> took the numbers as-is.  If you actually run multiple passes, you'll
> find that there is enormous variance in the timing.  The only way you
> can realistically measure results like this on appengine is to execute
> the test 100 times and take a median.
>
> FWIW, I deliberately haven't made any performance claims for Objectify
> because I haven't put the necessary amount of due diligence into
> creating a proper set of benchmarks.  It is not easy to measure
> performance, especially in a dynamic environment like appengine.  I
> only hope that the Slim3 authors have put more care and thought into
> crafting their library than they have their benchmarks.
>
> Jeff
>
>
> On Wed, Jun 8, 2011 at 2:34 PM, Gal Dolber  wrote:
> > Slim3 is not only fast, the api is completely awesome. It has been my
> choice
> > for a year now for all gae projects.
> > It includes "name safety" and and amazing querying utils.
> > Very recommendable!
> >
> > On Wed, Jun 8, 2011 at 3:41 PM, Jeff Schnitzer 
> wrote:
> >>
> >> You are wrong.
> >>
> >> Try adding getProperty() calls to your LL performance test, and the
> >> speed advantage of the LL API goes away.  I don't know what to say
> >> about Slim3, but here's my test case:
> >>
> >>
> >>
> http://code.google.com/p/scratchmonkey/source/browse/#svn%2Fappengine%2Fperformance-test
> >>
> >> I created 10,000 entities in the datastore that have the same format
> >> as your test case - a single string property.  Here's what happens
> >> (try it - and remember to reload the urls several times to get a
> >> realistic median value):
> >>
> >> ## Low Level API with just .size()
> >>
> >> http://voodoodyne.appspot.com/fetchLLSize
> >>
> >> The code:
> >>
> >> List things =
> >>DatastoreServiceFactory.getDatastoreService()
> >>.prepare(new
> >> Query(Thing.class.getAnnotation(javax.persistence.Entity.class).name()))
> >>.asList(FetchOptions.Builder.withDefaults());
> >> things.size();
> >>
> >> Note that results are almost always under 2000ms.  Wild guess I'd say
> >> the median elapsed is ~1900, just like your example.
> >>
> >> ## Low Level API with actual fetch of the data
> >>
> >> http://voodoodyne.appspot.com/fetchLL
> >>
> >> The code:
> >>
> >> List things =
> >>DatastoreServiceFactory.getDatastoreService()
> >>.prepare(new
> >> Query(Thing.class.getAnnotation(javax.persistence.Entity.class).name()))
> >>.asList

Re: [appengine-java] Re: Is the native API really so much faster than JDO and slim3?

[Yasuo Higa]

What I want to provide is a fair and casual benchmark.

As jeff advised, I modified samples as follows:
for (Entity e : service.getBarListUsingLL()) {
e.getKey();
e.getProperty("sortValue");
}

for (Bar bar : service.getBarListUsingSlim3()) {
bar.getKey();
bar.getSortValue();
}

for (BarObjectify bar : service.getBarListUsingObjectify()) {
bar.getKey();
bar.getSortValue();
}

for (BarJDO bar : service.getBarListUsingJDO()) {
bar.getKey();
bar.getSortValue();
}

LL API is much slower than before.
http://slim3demo.appspot.com/performance/

Yasuo Higa


On Thu, Jun 9, 2011 at 7:45 AM, Jeff Schnitzer  wrote:
> Slim3 may be a nice piece of software, but it has not been
> demonstrated to be faster than anything (including JDO).  It might or
> might not be faster - I don't know - but based on the sloppy
> benchmarking, I'm pretty certain that the people making this claim
> don't know either.
>
> There's another ill-conceived performance claim on the Slim3 website:
> "You may worry about the overhead of global transactions. Don't worry.
> It is not very expensive."  There are three problems with their little
> performance test:
>
>  1) It only measures wall-clock time, not cost.
>  2) It does not measure what happens under contention.
>  3) The numbers are obviously wrong - they don't even pass a smoke test.
>
> Look at these numbers (from the Slim3 home page):
>
> Entity Groups   Local Transaction(millis)       Global Transaction(millis)
> 1       67      70
> 2       450     415
> 3       213     539
> 4       1498    981
> 5       447     781
>
> Just like the 1ms low-level API query performance in the benchmark
> that spawned this thread, even a casual observer should be able to
> recognize the obvious flaw - the numbers don't show any expected
> relationship between # of entity groups or the use of global
> transactions.  Interpreted literally, you would assume that local
> transactions are much faster for 5 entity groups, but global
> transactions are much faster for 4 entity groups.
>
> It's pretty obvious that the benchmark author just ran one pass and
> took the numbers as-is.  If you actually run multiple passes, you'll
> find that there is enormous variance in the timing.  The only way you
> can realistically measure results like this on appengine is to execute
> the test 100 times and take a median.
>
> FWIW, I deliberately haven't made any performance claims for Objectify
> because I haven't put the necessary amount of due diligence into
> creating a proper set of benchmarks.  It is not easy to measure
> performance, especially in a dynamic environment like appengine.  I
> only hope that the Slim3 authors have put more care and thought into
> crafting their library than they have their benchmarks.
>
> Jeff
>
>
> On Wed, Jun 8, 2011 at 2:34 PM, Gal Dolber  wrote:
>> Slim3 is not only fast, the api is completely awesome. It has been my choice
>> for a year now for all gae projects.
>> It includes "name safety" and and amazing querying utils.
>> Very recommendable!
>>
>> On Wed, Jun 8, 2011 at 3:41 PM, Jeff Schnitzer  wrote:
>>>
>>> You are wrong.
>>>
>>> Try adding getProperty() calls to your LL performance test, and the
>>> speed advantage of the LL API goes away.  I don't know what to say
>>> about Slim3, but here's my test case:
>>>
>>>
>>> http://code.google.com/p/scratchmonkey/source/browse/#svn%2Fappengine%2Fperformance-test
>>>
>>> I created 10,000 entities in the datastore that have the same format
>>> as your test case - a single string property.  Here's what happens
>>> (try it - and remember to reload the urls several times to get a
>>> realistic median value):
>>>
>>> ## Low Level API with just .size()
>>>
>>> http://voodoodyne.appspot.com/fetchLLSize
>>>
>>> The code:
>>>
>>> List things =
>>>        DatastoreServiceFactory.getDatastoreService()
>>>                .prepare(new
>>> Query(Thing.class.getAnnotation(javax.persistence.Entity.class).name()))
>>>                .asList(FetchOptions.Builder.withDefaults());
>>> things.size();
>>>
>>> Note that results are almost always under 2000ms.  Wild guess I'd say
>>> the median elapsed is ~1900, just like your example.
>>>
>>> ## Low Level API with actual fetch of the data
>>>
>>> http://voodoodyne.appspot.com/fetchLL
>>>
>>> The code:
>>>
>>> List things =
>>>        DatastoreServiceFactory.getDatastoreService()
>>>                .prepare(new
>>> Query(Thing.class.getAnnotation(javax.persistence.Entity.class).name()))
>>>                .asList(FetchOptions.Builder.withDefaults());
>>> for (Entity ent: things)
>>> {
>>>        ent.getKey();
>>>        ent.getProperty("value");
>>> }
>>>
>>> Note that the duration is now considerably longer.  Eyeballing the
>>> median elapsed time, I'd say somewhere around 3000ms.
>>>
>>> ## Objectify fetching from datastore
>>>
>>> http://voodoodyne.appspot.com/fetch
>>>
>>> Objectify ofy = ObjectifyService.begin();
>>> List things = ofy.query(Thing.class).list();

Re: [appengine-java] Re: Is the native API really so much faster than JDO and slim3?

[Dennis Peterson]

Thanks, I'd found that, I'm curious how it's implemented, since I made some
efforts in that direction myself a while back.

On Wed, Jun 8, 2011 at 11:49 AM, Yasuo Higa  wrote:

> Hi Dennis,
>
> The following document will help you about global transactions:
> http://sites.google.com/site/slim3appengine/#gtx
>
> Yasuo Higa
>
> On Thu, Jun 9, 2011 at 12:33 AM, Dennis Peterson
>  wrote:
> > Those multi-entity transactions are definitely interesting to me. There's
> > some overhead but no getting around that.
> > A while back I was playing around with some adhoc  methods to do it in a
> > specific case, but I suspect Slim3 is more solid and maybe faster than
> what
> > I was doing. Definitely easier. When I get a chance I want to dig in and
> > find out how it works.
> >
> > On Wed, Jun 8, 2011 at 10:26 AM, Mike Lawrence 
> > wrote:
> >>
> >> I get...
> >>
> >> The number of entities: 1
> >> low level 1717 millis
> >> slim3 1502 millis
> >> objectify 2970 millis
> >> jdo 3485 millis
> >>
> >> probably should modify this example
> >> to do an average of several runs
> >>
> >> one important thing to note, is slim3 allows you
> >> to update multiple entity types
> >> in a single transaction.
> >> not possible with the other 3 APIs
> >>
> >>
> >>
> >> On Jun 7, 4:00 am, Ian Marshall  wrote:
> >> > The low-level API does indeed look very fast.
> >> >
> >> > Just a comment on JDO: repeat runs roughly halve the JDO run time. I
> >> > presume that this is because for repeat runs the JDO persistence
> >> > manager factory has already been constructed.
> >> >
> >> > On Jun 6, 8:44 pm, DennisP  wrote:> I'm
> >> > looking at this online demo:http://slim3demo.appspot.com/performance/
> >> >
> >> > > Sample run:
> >> > > The number of entities: 1
> >> > > low-level API:get: 2 millis
> >> > > Slim3: 2490 millis
> >> > > JDO: 6030 millis
> >> >
> >> > > Is the low-level API really that much faster?
> >>
> >> --
> >> 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
> >> google-appengine-java@googlegroups.com.
> >> To unsubscribe from this group, send email to
> >> google-appengine-java+unsubscr...@googlegroups.com.
> >> For more options, visit this group at
> >> http://groups.google.com/group/google-appengine-java?hl=en.
> >>
> >
> > --
> > 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
> google-appengine-java@googlegroups.com.
> > To unsubscribe from this group, send email to
> > google-appengine-java+unsubscr...@googlegroups.com.
> > For more options, visit this group at
> > http://groups.google.com/group/google-appengine-java?hl=en.
> >
>
> --
> 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
> google-appengine-java@googlegroups.com.
> To unsubscribe from this group, send email to
> google-appengine-java+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/google-appengine-java?hl=en.
>
>

-- 
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 google-appengine-java@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine-java+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine-java?hl=en.

Re: [appengine-java] Re: Is the native API really so much faster than JDO and slim3?

[Jeff Schnitzer]

On Wed, Jun 8, 2011 at 4:26 PM, Gal Dolber  wrote:
> Slim3 is indeed faster than any other because of the simple fact that it
> uses apt(code generation) instead of reflexion, the generated code it's
> almost the same that you'll write by-hand to wrap the low-level api.

I'm really not trying to attack Slim3 the product - I'm sure it's
solid, it clearly has quite a community behind it.  And I'm sure the
global transactions feature is great news for those that need it.

I'm annoyed by two things:

 1) People who post benchmarks that purport to show something they do not.
 2) People who repeat memes uncritically.

For example, you repeat that Slim3 is faster because it uses code
generation instead of reflection.  Have you profiled these systems?
Have the Slim3 developers?  Even if Slim3 is faster, how do you/they
know it's because of reflection and not some other characteristic of
their code?  This has the same sound of people who blindly proclaimed
"garbage collection is slow!" and designed synchronization schemes
(ala early EJB) that actually reduced performance.

I am deeply skeptical that reflection is the issue, considering that
there are exactly three reflection calls (construction and two
setters) per entity, and a helluva lot of other processing involved.
Sure, it's possible, but I won't believe it without profiling.

Another problem with the reflection theory:  According to the
corrected Slim3 benchmark, Slim3 is now considerably faster then the
Low-Level API.  Which presumably doesn't use reflection.

Jeff

-- 
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 google-appengine-java@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine-java+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine-java?hl=en.

Re: [appengine-java] Re: Is the native API really so much faster than JDO and slim3?

[Jeff Schnitzer]

Thank you for fixing the benchmark.

I am very curious.  According to this new benchmark - it's hard to
tell without pushing the buttons a lot of times, but there seems to be
a trend - Slim3 is somewhat faster than the Low Level API.

Doesn't Slim3 use the Low Level API underneath?  How can it possibly be faster?

Jeff

On Wed, Jun 8, 2011 at 4:27 PM, Yasuo Higa  wrote:
> What I want to provide is a fair and casual benchmark.
>
> As jeff advised, I modified samples as follows:
> for (Entity e : service.getBarListUsingLL()) {
>    e.getKey();
>    e.getProperty("sortValue");
> }
>
> for (Bar bar : service.getBarListUsingSlim3()) {
>    bar.getKey();
>    bar.getSortValue();
> }
>
> for (BarObjectify bar : service.getBarListUsingObjectify()) {
>    bar.getKey();
>    bar.getSortValue();
> }
>
> for (BarJDO bar : service.getBarListUsingJDO()) {
>    bar.getKey();
>    bar.getSortValue();
> }
>
> LL API is much slower than before.
> http://slim3demo.appspot.com/performance/
>
> Yasuo Higa
>
>
> On Thu, Jun 9, 2011 at 7:45 AM, Jeff Schnitzer  wrote:
>> Slim3 may be a nice piece of software, but it has not been
>> demonstrated to be faster than anything (including JDO).  It might or
>> might not be faster - I don't know - but based on the sloppy
>> benchmarking, I'm pretty certain that the people making this claim
>> don't know either.
>>
>> There's another ill-conceived performance claim on the Slim3 website:
>> "You may worry about the overhead of global transactions. Don't worry.
>> It is not very expensive."  There are three problems with their little
>> performance test:
>>
>>  1) It only measures wall-clock time, not cost.
>>  2) It does not measure what happens under contention.
>>  3) The numbers are obviously wrong - they don't even pass a smoke test.
>>
>> Look at these numbers (from the Slim3 home page):
>>
>> Entity Groups   Local Transaction(millis)       Global Transaction(millis)
>> 1       67      70
>> 2       450     415
>> 3       213     539
>> 4       1498    981
>> 5       447     781
>>
>> Just like the 1ms low-level API query performance in the benchmark
>> that spawned this thread, even a casual observer should be able to
>> recognize the obvious flaw - the numbers don't show any expected
>> relationship between # of entity groups or the use of global
>> transactions.  Interpreted literally, you would assume that local
>> transactions are much faster for 5 entity groups, but global
>> transactions are much faster for 4 entity groups.
>>
>> It's pretty obvious that the benchmark author just ran one pass and
>> took the numbers as-is.  If you actually run multiple passes, you'll
>> find that there is enormous variance in the timing.  The only way you
>> can realistically measure results like this on appengine is to execute
>> the test 100 times and take a median.
>>
>> FWIW, I deliberately haven't made any performance claims for Objectify
>> because I haven't put the necessary amount of due diligence into
>> creating a proper set of benchmarks.  It is not easy to measure
>> performance, especially in a dynamic environment like appengine.  I
>> only hope that the Slim3 authors have put more care and thought into
>> crafting their library than they have their benchmarks.
>>
>> Jeff
>>
>>
>> On Wed, Jun 8, 2011 at 2:34 PM, Gal Dolber  wrote:
>>> Slim3 is not only fast, the api is completely awesome. It has been my choice
>>> for a year now for all gae projects.
>>> It includes "name safety" and and amazing querying utils.
>>> Very recommendable!
>>>
>>> On Wed, Jun 8, 2011 at 3:41 PM, Jeff Schnitzer  wrote:

 You are wrong.

 Try adding getProperty() calls to your LL performance test, and the
 speed advantage of the LL API goes away.  I don't know what to say
 about Slim3, but here's my test case:


 http://code.google.com/p/scratchmonkey/source/browse/#svn%2Fappengine%2Fperformance-test

 I created 10,000 entities in the datastore that have the same format
 as your test case - a single string property.  Here's what happens
 (try it - and remember to reload the urls several times to get a
 realistic median value):

 ## Low Level API with just .size()

 http://voodoodyne.appspot.com/fetchLLSize

 The code:

 List things =
        DatastoreServiceFactory.getDatastoreService()
                .prepare(new
 Query(Thing.class.getAnnotation(javax.persistence.Entity.class).name()))
                .asList(FetchOptions.Builder.withDefaults());
 things.size();

 Note that results are almost always under 2000ms.  Wild guess I'd say
 the median elapsed is ~1900, just like your example.

 ## Low Level API with actual fetch of the data

 http://voodoodyne.appspot.com/fetchLL

 The code:

 List things =
        DatastoreServiceFactory.getDatastoreService()
                .prepare(new
 Query(Thing.class.getAnnotation(javax.persistence.En

Re: [appengine-java] Re: Is the native API really so much faster than JDO and slim3?

[Yasuo Higa]

Slim3 uses LL API.

To resolve a strange issue that slim3 is faster than LL, I tried the
following samples:

One:
AsyncDatastoreService ds =
DatastoreServiceFactory.getAsyncDatastoreService();
Query q = new Query("Bar");
PreparedQuery pq = ds.prepare(q);
List list =
pq.asList(FetchOptions.Builder.withDefaults().limit(
Integer.MAX_VALUE));
for (Entity e : service.getBarListUsingLL()) {
e.getKey();
e.getProperty("sortValue");
}

Two:
AsyncDatastoreService ds =
DatastoreServiceFactory.getAsyncDatastoreService();
Query q = new Query("Bar");
PreparedQuery pq = ds.prepare(q);
List list =
pq.asList(FetchOptions.Builder.withDefaults().limit(
Integer.MAX_VALUE));

// VERY IMPORTANT
list.size();

for (Entity e : service.getBarListUsingLL()) {
e.getKey();
e.getProperty("sortValue");
}

The second one is much faster than the first one.
I fixed the samples to call list.size().
http://slim3demo.appspot.com/performance/

As a result, LL is as fast as slim3 (^^;

Yasuo Higa



On Thu, Jun 9, 2011 at 10:17 AM, Jeff Schnitzer  wrote:
> Thank you for fixing the benchmark.
>
> I am very curious.  According to this new benchmark - it's hard to
> tell without pushing the buttons a lot of times, but there seems to be
> a trend - Slim3 is somewhat faster than the Low Level API.
>
> Doesn't Slim3 use the Low Level API underneath?  How can it possibly be 
> faster?
>
> Jeff
>
> On Wed, Jun 8, 2011 at 4:27 PM, Yasuo Higa  wrote:
>> What I want to provide is a fair and casual benchmark.
>>
>> As jeff advised, I modified samples as follows:
>> for (Entity e : service.getBarListUsingLL()) {
>>    e.getKey();
>>    e.getProperty("sortValue");
>> }
>>
>> for (Bar bar : service.getBarListUsingSlim3()) {
>>    bar.getKey();
>>    bar.getSortValue();
>> }
>>
>> for (BarObjectify bar : service.getBarListUsingObjectify()) {
>>    bar.getKey();
>>    bar.getSortValue();
>> }
>>
>> for (BarJDO bar : service.getBarListUsingJDO()) {
>>    bar.getKey();
>>    bar.getSortValue();
>> }
>>
>> LL API is much slower than before.
>> http://slim3demo.appspot.com/performance/
>>
>> Yasuo Higa
>>
>>
>> On Thu, Jun 9, 2011 at 7:45 AM, Jeff Schnitzer  wrote:
>>> Slim3 may be a nice piece of software, but it has not been
>>> demonstrated to be faster than anything (including JDO).  It might or
>>> might not be faster - I don't know - but based on the sloppy
>>> benchmarking, I'm pretty certain that the people making this claim
>>> don't know either.
>>>
>>> There's another ill-conceived performance claim on the Slim3 website:
>>> "You may worry about the overhead of global transactions. Don't worry.
>>> It is not very expensive."  There are three problems with their little
>>> performance test:
>>>
>>>  1) It only measures wall-clock time, not cost.
>>>  2) It does not measure what happens under contention.
>>>  3) The numbers are obviously wrong - they don't even pass a smoke test.
>>>
>>> Look at these numbers (from the Slim3 home page):
>>>
>>> Entity Groups   Local Transaction(millis)       Global Transaction(millis)
>>> 1       67      70
>>> 2       450     415
>>> 3       213     539
>>> 4       1498    981
>>> 5       447     781
>>>
>>> Just like the 1ms low-level API query performance in the benchmark
>>> that spawned this thread, even a casual observer should be able to
>>> recognize the obvious flaw - the numbers don't show any expected
>>> relationship between # of entity groups or the use of global
>>> transactions.  Interpreted literally, you would assume that local
>>> transactions are much faster for 5 entity groups, but global
>>> transactions are much faster for 4 entity groups.
>>>
>>> It's pretty obvious that the benchmark author just ran one pass and
>>> took the numbers as-is.  If you actually run multiple passes, you'll
>>> find that there is enormous variance in the timing.  The only way you
>>> can realistically measure results like this on appengine is to execute
>>> the test 100 times and take a median.
>>>
>>> FWIW, I deliberately haven't made any performance claims for Objectify
>>> because I haven't put the necessary amount of due diligence into
>>> creating a proper set of benchmarks.  It is not easy to measure
>>> performance, especially in a dynamic environment like appengine.  I
>>> only hope that the Slim3 authors have put more care and thought into
>>> crafting their library than they have their benchmarks.
>>>
>>> Jeff
>>>
>>>
>>> On Wed, Jun 8, 2011 at 2:34 PM, Gal Dolber  wrote:
 Slim3 is not only fast, the api is completely awesome. It has been my 
 choice
 for a year now for all gae projects.
 It includes "name safety" and and amazing querying utils.
 Very recommendable!

 On Wed, Jun 8, 2011 at 3:41 PM, Jeff Schnitzer  wrote:
>
> You are wrong.
>
> Try adding getProperty() calls to your LL performance test, and the
> speed advantage of the LL API goes away.  I don't know what to say
> about Slim3, but here's my

Re: [appengine-java] Re: Is the native API really so much faster than JDO and slim3?

[Jeff Schnitzer]

I don't understand this code at all.  You're querying the data and
then iterating over a separate call?  And what does the extra call to
list.size() have anything to do with this?

The code linked from http://slim3demo.appspot.com/performance/ has
just gone back to calling list.size() without iterating the results,
which once again goes back to a bogus benchmark.

Jeff

On Wed, Jun 8, 2011 at 9:30 PM, Yasuo Higa  wrote:
> Slim3 uses LL API.
>
> To resolve a strange issue that slim3 is faster than LL, I tried the
> following samples:
>
> One:
> AsyncDatastoreService ds =
>    DatastoreServiceFactory.getAsyncDatastoreService();
> Query q = new Query("Bar");
>    PreparedQuery pq = ds.prepare(q);
> List list =
>    pq.asList(FetchOptions.Builder.withDefaults().limit(
>        Integer.MAX_VALUE));
> for (Entity e : service.getBarListUsingLL()) {
>    e.getKey();
>    e.getProperty("sortValue");
> }
>
> Two:
> AsyncDatastoreService ds =
>    DatastoreServiceFactory.getAsyncDatastoreService();
> Query q = new Query("Bar");
>    PreparedQuery pq = ds.prepare(q);
> List list =
>    pq.asList(FetchOptions.Builder.withDefaults().limit(
>        Integer.MAX_VALUE));
>
> // VERY IMPORTANT
> list.size();
>
> for (Entity e : service.getBarListUsingLL()) {
>    e.getKey();
>    e.getProperty("sortValue");
> }
>
> The second one is much faster than the first one.
> I fixed the samples to call list.size().
> http://slim3demo.appspot.com/performance/
>
> As a result, LL is as fast as slim3 (^^;
>
> Yasuo Higa
>
>
>
> On Thu, Jun 9, 2011 at 10:17 AM, Jeff Schnitzer  wrote:
>> Thank you for fixing the benchmark.
>>
>> I am very curious.  According to this new benchmark - it's hard to
>> tell without pushing the buttons a lot of times, but there seems to be
>> a trend - Slim3 is somewhat faster than the Low Level API.
>>
>> Doesn't Slim3 use the Low Level API underneath?  How can it possibly be 
>> faster?
>>
>> Jeff
>>
>> On Wed, Jun 8, 2011 at 4:27 PM, Yasuo Higa  wrote:
>>> What I want to provide is a fair and casual benchmark.
>>>
>>> As jeff advised, I modified samples as follows:
>>> for (Entity e : service.getBarListUsingLL()) {
>>>    e.getKey();
>>>    e.getProperty("sortValue");
>>> }
>>>
>>> for (Bar bar : service.getBarListUsingSlim3()) {
>>>    bar.getKey();
>>>    bar.getSortValue();
>>> }
>>>
>>> for (BarObjectify bar : service.getBarListUsingObjectify()) {
>>>    bar.getKey();
>>>    bar.getSortValue();
>>> }
>>>
>>> for (BarJDO bar : service.getBarListUsingJDO()) {
>>>    bar.getKey();
>>>    bar.getSortValue();
>>> }
>>>
>>> LL API is much slower than before.
>>> http://slim3demo.appspot.com/performance/
>>>
>>> Yasuo Higa
>>>
>>>
>>> On Thu, Jun 9, 2011 at 7:45 AM, Jeff Schnitzer  wrote:
 Slim3 may be a nice piece of software, but it has not been
 demonstrated to be faster than anything (including JDO).  It might or
 might not be faster - I don't know - but based on the sloppy
 benchmarking, I'm pretty certain that the people making this claim
 don't know either.

 There's another ill-conceived performance claim on the Slim3 website:
 "You may worry about the overhead of global transactions. Don't worry.
 It is not very expensive."  There are three problems with their little
 performance test:

  1) It only measures wall-clock time, not cost.
  2) It does not measure what happens under contention.
  3) The numbers are obviously wrong - they don't even pass a smoke test.

 Look at these numbers (from the Slim3 home page):

 Entity Groups   Local Transaction(millis)       Global Transaction(millis)
 1       67      70
 2       450     415
 3       213     539
 4       1498    981
 5       447     781

 Just like the 1ms low-level API query performance in the benchmark
 that spawned this thread, even a casual observer should be able to
 recognize the obvious flaw - the numbers don't show any expected
 relationship between # of entity groups or the use of global
 transactions.  Interpreted literally, you would assume that local
 transactions are much faster for 5 entity groups, but global
 transactions are much faster for 4 entity groups.

 It's pretty obvious that the benchmark author just ran one pass and
 took the numbers as-is.  If you actually run multiple passes, you'll
 find that there is enormous variance in the timing.  The only way you
 can realistically measure results like this on appengine is to execute
 the test 100 times and take a median.

 FWIW, I deliberately haven't made any performance claims for Objectify
 because I haven't put the necessary amount of due diligence into
 creating a proper set of benchmarks.  It is not easy to measure
 performance, especially in a dynamic environment like appengine.  I
 only hope that the Slim3 authors have put more care and thought into
 crafting their library than they have their benc