Any Site in Production Use ?

[Feris Thia]

Hi All,

I understand that GAE is still in preview used only, but I just wonder if anyone has used it in any semi or full production ? And with how many page hits / visitors per day ?

--
Thanks & Best Regards,

Feris Thia

[mitnickcbc]

I do, full production. And my suggestion is not to use it for
production. You can have very easy start with GAE since no server
config, easy deploy and tons of other good things. But you will get
more pain of growth due to these issues:
1. Manually quota increase process. This is not a problem if during
working hours. But you may met this issue at 7PM and you need to wait
for at least 14 hours to get a response, not mention during weekend or
holidays. For people who have no idea about quota denials, quota
denial means almost totally out of service. And currently we don't
have visibility to all quotas like datastore and URL fetch. This makes
it even harder to predict the needs of quota increase.
2. High amount CPU quota. This one has a very small quota number and
does't scale with your other quota. Recently I found it comes abnormal
and almost all my requests fallen into this category during certain
period of time (can be up to hours), while I didn't change any code.
Your traffic will drop to below 1.5 request/sec immediately no matter
how much quota you have.
3. It's out of your control. Since it's preview version, GAE team has
no responsibility to stay up late and work out your problem or provide
you 24*7 support. So when issue happens, you can do nothing except
waiting. Although GAE team responses quickly and provides useful
helps, but there are several times I felt helpless off working hours.
And my app has met 4 - 5 times serious issues like out of service for
6 hours during the last 10 days, due to the quota issues and there is
nobody helping me (no blame here, they are sleeping or in weekend).

If you are building something not going to have heavy load, you can
use GAE as production without much problem. But surely not business
application, otherwise your customer will shout at you and you really
can do nothing to help them.

[theo]

I'd like to second this, and perhaps offer a bit of clarification.

I've been involved in a project for some time now (I've been a user
from the very beginning), and I've been constantly frustrated with
some of the features of App Engine. In some ways, it's been amazing.
The fact that one is constrained from the start to create apps that
can scale horizontally is interesting and exciting to me. That being
said, there are a number of challenges that you should be aware of:

1. Poor documentation.

This is a dramatically changing project. It is definitely not like
other "beta" Google projects. It really is beta. You are not going
to be able to trust that all of the documentation is correct. This is
not a huge criticism of the project - it seems like things are
changing at a pretty rapid rate and I know from experience that it is
often difficult to keep documentation in sync with the current
production version. But it is something you'll have to deal with.

2. Poor uptime compared to commercial services

Everyone and their mother was atwitter over the S3 downtime some time
ago. App Engine regularly has such downtimes. App Engine is a much
more complex system to manage, so that is to be expected somewhat,
still - take that into account. To partially mitigate this, you can
follow a few websites:

cloudstatus.com
http://groups.google.com/group/google-appengine-downtime-notify

If you look at the history on the downtime google group, you can see
that they are at about 2 9's of reliability. This is not a criticism
- I love the service and well - you get what you pay for, but if you
are promising customers high reliability, they won't get it. Be aware
of this.

Besides that, the platform is great. The quotas are amazingly high
(if you don't hit the high CPU quota). The really great thing is that
App Engine (especially with the django helper) is essentially Django,
so there is little risk in developing for App Engine. If you find
that you can't continue to host your project on App Engine, you can
easily port it over to Django on something like slicehost or AWS.

[Bill]

I know buddypoke.com is using AppEngine. It's a fairly successful app
under heavy load. (I want to say hundreds of requests per second but
can't say my memory is correct there.)

[Feris Thia]

Hi Mitnickcbc,

Thank you for your thorough review. Actually I'm going it to use as a kind of social networking site. It is developed in Django and considering to port the model to Google DataStore.

But I myself has faced some cpu issue problems, and suspect for others which you prove me right.

Anyway, then meanwhile I'll have to wait until GAE is release in full edition.

Thanks again for the reviews and suggestions, really appreciate it.

Regards,

Feris

[Feris Thia]

Hi Theo,

On Tue, Sep 30, 2008 at 9:53 PM, theo <theodore....@gmail.com> wrote:

I'd like to second this, and perhaps offer a bit of clarification.

1. Poor documentation.

Wow, I just know this... I'll be more aware from now on.
 

2. Poor uptime compared to commercial services

Everyone and their mother was atwitter over the S3 downtime some time
ago.  App Engine regularly has such downtimes.  App Engine is a much
more complex system to manage, so that is to be expected somewhat,
still - take that into account.  To partially mitigate this, you can
follow a few websites:

cloudstatus.com
http://groups.google.com/group/google-appengine-downtime-notify

I have bookmarked the site and joined the group. Thanks for the references.

Besides that, the platform is great.  The quotas are amazingly high
(if you don't hit the high CPU quota).  The really great thing is that
App Engine (especially with the django helper) is essentially Django,
so there is little risk in developing for App Engine.  If you find
that you can't continue to host your project on App Engine, you can
easily port it over to Django on something like slicehost or AWS.

That's what I'm doing now. Developed it in Django and see if a more reliable environment to go.

Again, thanks for the great resources. Really appreciate it.

Regards,

Feris

[Sylvain]

Hi,

Currently my app get 15k requests a day (20 req/min in the high part).

Everything works very well :
- it's fast (particularly with memcache)
- very good framework : webapp, django,...
- nice dashboard
- easy to update

Except :
- the CPU/req warning : very hard to handle and now I don't want to
add new functions because I'm at the CPU limits.

Regards

[Jonathan Feinberg]

On Sep 30, 5:21 am, "Feris Thia" <fe...@phi-integration.com> wrote:

> I understand that GAE is still in preview used only, but I just wonder if
> anyone has used it in any semi or full production ? And with how many page
> hits / visitors per day ?

Yesterday was a good day; my app got 89,537 pageviews, according to
Google Analytics. I typically hum along at 10-13 requests per second
during the work day, according to the dashboard.

The great thing about GAE is that I don't have to worry about being
"slashdotted". If you do what you're supposed to do, App Engine just
shrugs off a few hours of 50 requests per second. It has been a joy.

[Bill]

You're talking about wordle.net, right? Those are pretty successful
metrics.

A lot of the issues people have been having are on datastore timeouts,
particularly on puts. It looks like the main processing for Wordle is
handled by a downloaded Java applet, and the datastore really gets
used when storing a wordle or returning a gallery page. Do you run
into any timeouts or elevated CPU for wordle puts? I'm using Google
Chrome and didn't have the Java plugin, so I noticed even your images
are created via the java applet so you're not storing image blobs (?).

[Feris Thia]

Hi Bill,

Thanks for the sharing, for the puts I have tested myself using single thread and it get cpu over quota easily. So I think it is not ready for production yet. 

Indeed, wordle is very popular (page rank 7). I'd take a look at how they handle datastore, or do you have any further info for that ?

Regards,

Feris

[Bill]

Feris, Wordle.net is Jonathan's site so I don't have any info other
than looking at the web pages. It looks the image thumbnails are
image blobs stored in datastore and the java applet displays graphics
on individual gallery pages. So he'd have at least one intensive
request when doing the thumbnail processing and image put. There's no
tagging or join models from what I can see, so his gallery page GET
should be reasonably fast.

I wonder what the most datastore-intensive and successful app out
there might be? "Compare the Candidates" (http://
comparecandidates.appspot.com) looks reasonably complex with the
ability to select issues, source, etc, but I think that page might be
broken up into many requests via AJAX and the pieces reassembled.
Using a rich client (AJAX, Flex, etc.) that can handle server errors/
timeouts and multiple requests per page might be a good way to use App
Engine.

On Oct 1, 9:26 pm, "Feris Thia" <fe...@phi-integration.com> wrote:
> Hi Bill,
> Thanks for the sharing, for the puts I have tested myself using single
> thread and it get cpu over quota easily. So I think it is not ready for
> production yet.
>
> Indeed, wordle is very popular (page rank 7). I'd take a look at how they
> handle datastore, or do you have any further info for that ?
>
> Regards,
>
> Feris
>

[Jonathan Feinberg]

On Oct 2, 2:59 am, Bill <billk...@gmail.com> wrote:
> Feris, Wordle.net is Jonathan's site so I don't have any info other
> than looking at the web pages.  It looks the image thumbnails are
> image blobs stored in datastore and the java applet displays graphics
> on individual gallery pages.

Correct. Thumbnails are little (~15K) blobs, and the saved Wordle
state is about 3K, which is then rendered by the applet.

> So he'd have at least one intensive
> request when doing the thumbnail processing and image put.

No, the applet generates the thumbnail and POSTs it as an opaque
binary blob. There's no processing to speak of on the server side.

> There's no tagging or join models from what I can see, so his gallery page GET
> should be reasonably fast.

Yes.

I get on the order of 100 bogus high CPU warnings per day in my error
log. They tend to come in clusters of 4 or 5 within a few seconds, so
it's clearly some issue on Google's end (these are simple datastore
GETs by key, and they timeout after 10,000 megacycles or so). They've
never been a threat to my quota, so I don't worry about them.

[Bill]

> I get on the order of 100 bogus high CPU warnings per day in my error
> log. They tend to come in clusters of 4 or 5 within a few seconds, so
> it's clearly some issue on Google's end (these are simple datastore
> GETs by key, and they timeout after 10,000 megacycles or so). They've
> never been a threat to my quota, so I don't worry about them.

How do you handle the datastore get failures? I'm concerned about
the .01% failure rate mentioned in another thread, because I'm
thinking this is behavior that's not just preview mode but something
that should be expected for datastore access. If so, can we issue
temporary redirects back to the same URL in the case of failure for
idempotent actions? Or are folks just assuming some very small
percentage of requests fail? (I'm thinking of handling it on the
client side with AJAX or Flash, where the client either informs the
user or reissues a request.)

[Alexandru Zbarcea]

nope ... it seems is using AWS now!

[Bill]

> nope ... it seems is using AWS now!

I met BuddyPoke's creator a week or so ago. He was very happy with
App Engine and said how great it was to handle his significant load.
If you are seeing AWS, it's probably static flash files being served
off Amazon S3. Let me know if that's incorrect.

[Alexandru Zbarcea]

i don't know, images are sure from aws:

"http://buddypoke.s3.amazonaws.com/images/install_orkut.jpg"


but app itself, i don't know ... and I don't think it matters
:-D

[davew]

I run BuddyPoke, so let me chime in. BuddyPoke is an OpenSocial
application that runs on Orkut, hi5, MySpace, netlog, friendster and
will soon be live on Ning. We have 17 million users, most of which has
come in the last two and half months.

I use App Engine to store user state in the App Engine datastore: a
user's avatar, pokes, moods, etc. I use Amazon S3 to store icons.
Before App Engine came along I was using a hosted box and Amazon S3
for all the icons. To this day I still use S3 for the icons, for the
simple reason that it's a significant amount of mostly static data.
Once App Engine is out of preview I will flip a switch and move all
the icons over to App Engine as well.

In terms of is App Engine ready for prime time. I can certainly stand
up and say yes it is for facebook, OpenSocial, iPhone apps, and really
any number of applications or websites where you may need to scale,
and scale rapidly, and it's not life or death for you to have 99.999%
up time. We all know it's still in *preview* release. So at the end
of the day you have to make your own decisions. But typically the
number one question is: does App Engine scale?? And the resounding
answer from my experience is YES it scales beautifully. There was one
week when Orkut went live to users in Brazil and my traffic went up 8x
overnight. I would have had serious problems handling the traffic for
BuddyPoke had it not been for App Engine. You could argue that I
could use EC2, or other platforms. I know a lot of people that use
EC2 for popular facebook apps, and they still spend a huge amount of
time working on scaling-related problems. With App Engine I'm working
on new features.. :)

As someone noted above App Engine still has short outages. But over
the past several months, I've seen more server problems with the
OpenSocial containers' servers I work with, than I have with App
Engine. From a user's perspective I guarantee that if BuddyPoke is
broken it's mostly not App Engine's fault. Normally BuddyPoke errors
are due to the OpenSocial container's proxy servers being overloaded
at peek hours, due to their own scaling problems. (Or I've simply
screwed something up the Flash client, which happens..) In that
regard I'm used to making calls that I expect might fail. Whether
it's a failure at the OpenSocial proxy layer, or with App Engine
timing out a datastore put, it doesn't really matter. The client will
handle retries or will display error messages to the user. You
shouldn't be writing code expecting all your server calls will
succeed. Write code expecting failures.

I also got effected when Amazon S3's servers went down for 8+ hours
one weekend. I don't quite understand the people that love AWS / S3
saying it never breaks, but are fast to criticize App Engine. I use
both, and I'm pretty sure if you add up all the short outages on App
Engine it still comes to less than the 8 hours that S3 experienced.

In terms of quota limits. The App Engine team has been incredibly
helpful in making sure that BuddyPoke can continue to grow. All I can
say is shoot them an email if you need more quota, but make sure to
provide information on what the quota is being used for, what kind of
growth you expect, etc. And make sure you profile and check your code
before you email them. I'll freely admit to making some big mistakes
early on by not having things like sharded counters that can spike cpu
usage no end.

I should also mention that BuddyPoke does three levels of caching
above App Engine with the OpenSocial container's App Data cache, the
browser cache, and the Flash SharedObject cached. So for the most
part, a cpu-intensive call is only made to App Engine when the user
does something - pokes a friend, changes their appearance etc. 99% of
profile page views, with BuddyPoke on it, will *not* make a call to
App Engine. I'm saying that just to make the point that I'm not doing
a billion daily calls to App Engine.. ;) But I am doing a significant
number of calls to know how well it scales, and to recommend it to
others.

-Dave

On Oct 3, 5:13 am, "Alexandru Zbarcea" <zbarce...@gmail.com> wrote:
> i don't know, images are sure from aws:
>
> "http://buddypoke.s3.amazonaws.com/images/install_orkut.jpg"
>
> but app itself, i don't know ... and I don't think it matters
> :-D
>

[mitnickcbc]

Just let you know that I'm migrating my app to AWS from GAE. The
reason is simple, manually quota increase process is not going to work
especially without full visibility into all quotas. GAE can scale but
doesn't scale now in preview version. I will only check back after it
starts charging.

[Nash]

My strong suggestion at this stage to anyone considering GAE for a
production, business use DO NOT USE GAE.

GAE has significant flaws; these are basic flaws and the time spent
writing a work-around to these problems is far too great for very
short internet times.

Let me add some basic very necessary items (I am going to do a blog
entry as well on these issues)

1. No Bulk Delete/Update: If you ever create a one-to-many or many-to-
many relation; you will inevitably come to a point when you have to
remove an object. In doing so, if that object was being referred by
400 objects; you have to read, change and write those objects back.
GAE does not allow you to change that this many objects. A user might
leave your service, you would want to remove all their data or mark it
as unavailable. A large tweet comes in, 20,000 followers need to be
updated. A group gets deleted, all the contacts referring to that
group need to be updated.

2. Random Datastore timeouts: The most annoying issue is that a single
object read/writeback can sometimes be <1000mc or can be more than
5000mc. This random behavior cripples the app and makes it impossible
to optimize

3. The Google Quota Bad: if your app exceeded it's short-term quota
the punishment is very excessive: a 24 hour ban. This is the worst
possible action you can take on a dot com: You take it offline.

4. No sorting: When using lists, inequalities etc you can't sort on
multiple properties. You just can't.

5. Limited Datastore functionality and very poor workarounds: Want to
use OR? Sorry, you can't. What to simulate OR in memory? Sorry, your
process will be killed either because of high quota or long response
time. Even if you get your app to do it in memory, it is a ticking
timebomb, it will explode when more users come in. Very unsalable in
that regard. Want to use two inequalities? Sorry.

6. Magic Exploding Indexes: Yes, Lists are a great concept but they
can cut you in half. You cannot mix multiple lists in a single WHERE
clause, or suffer explosion. You cannot create too many (20< if that
sounds like too many) indexes, you will have them explode. Lists are a
double-edged sword which cut you a lot more than help you.

7. In 2008, GAE keeps on making you reinvent the wheel: As a
webapplication/startup, the most important thing is feature velocity.
How fast can you deliver features? With GAE, some very common
functionality has to be reinvented over and over. To the point where
it consumes so much time that the cost-time benefits are completely
lost.

8. No HTTPS. Toy apps aside (apologies to wordle and buddypoke), if
google wants serious applications it NEEDS to add HTTPS support. In
this day and age of trust building, colored address-bar to peace of
mind; you cannot leave this feature out.

9. Dev Server is broken. The local test server doesn't work on half
our development systems. Its broken. Its results do not reflect the
behavior of GAE itself. It won't do simple things like load static
files.

10. No support: Ofcourse, this is a preview, if you get in a mess and
need a Googler's attention; it's up to their discretion and leisure
time do they respond to you. Nothing is binding at this time; you're
not paying them anything yet.

11. GAE Admin is NO replacement for the Django Admin. But that's how
it is portrayed in the GAE's documentation. You think that Google's
Admin is a replacement for django's admin. Boy, are you wrong. The GAE
admin is a very limited app; on dev server it will keep throwing
errors at you. The app looks more like a backend for programmers where
as the whole point of the django admin was to allow for "admin USERS"
to access it and make changes to the data. In its current form, it
can't be used by non-tech-savy users.

12. Very slow GAE upgrades: The GAE team is very slow on introducing
changes to appengine. For something that's targeted for release by the
end of the year, this is not at all going to the pace required.

13. No roadmap shared: We'd all shutup on the features if Google said
"we're working on it, it'll be out"; Google won't even say it's
working on it or that there is work being done

I'm a big fan of Django and when Google announced a scalable web
application framework with Django, I was thrilled! But I have been
very disappointed. This "preview" is not up to the level of Google's
"previews". Google has shown us that it has high quality standards so
much so that we trust it with our private email, docs etc whereas all
these services are in Beta.

My software shop had a team of 6 GAE developers, but until GAE can get
it's act together, we're pulling away from it. The time and money
wasted on getting simple things to work is atrocious and the light at
the end of the tunnel is just way too far away.

WS
-Nash

[Jonathan Feinberg]

On Oct 4, 6:20 pm, Nash <nasrul...@gmail.com> wrote:
> My strong suggestion at this stage to anyone considering GAE for a
> production, business use DO NOT USE GAE.

Unless, of course, you can't find anything else with the same scaling
properties, ease of use, and pleasure of development. Then do.

> 4. No sorting: When using lists, inequalities etc you can't sort on
> multiple properties. You just can't.

You can construct a synthetic property that represents the desired
ordering lexicographically. This costs you some storage, but so would
an index.

> 5. Limited Datastore functionality

In my opinion, you're making the logical error of judging the Google
data store vs. the properties of SQL. They are not comparable.

> 7. In 2008, GAE keeps on making you reinvent the wheel: As a
> webapplication/startup, the most important thing is feature velocity.
> How fast can you deliver features? With GAE, some very common
> functionality has to be reinvented over and over. To the point where
> it consumes so much time that the cost-time benefits are completely
> lost.

On the other hand, it's *so easy* to implement those features!

> 8. No HTTPS. Toy apps aside (apologies to wordle and buddypoke), if
> google wants serious applications it NEEDS to add HTTPS support. In
> this day and age of trust building, colored address-bar to peace of
> mind; you cannot leave this feature out.

There's a huge middle ground between "toy" and "e-commerce". What's
wrong with addressing that middle ground?

> 9. Dev Server is broken.

WFM

> 12. Very slow GAE upgrades: The GAE team is very slow on introducing
> changes to appengine.

Again, WFM.

> 13. No roadmap shared: We'd all shutup on the features if Google said
> "we're working on it, it'll be out"; Google won't even say it's
> working on it or that there is work being done

While there is room for improvement, I think it's safe to say that a
bug status of "accepted" means "working on it now" and that
"acknowledged" means "we intend to get to it."

> My software shop had a team of 6 GAE developers, but until GAE can get
> it's act together, we're pulling away from it. The time and money
> wasted on getting simple things to work is atrocious and the light at
> the end of the tunnel is just way too far away.

This story goes a long way in explaining your evident anger, and I'm
sorry for your lost time. I also share your frustration in not knowing
enough about what's going to happen and when. But I do think that
there are an enormous number of businesses that could do well to use
App Engine. There are a number of dimensions on which to measure the
suitability of App Engine for a particular task. For example, "storage-
intensive" really suggests the use of S3; "CPU-intensive" (like video
rendering or whatever) suggests the use of EC2. "Security above all"
suggests your own hardware in your own NOC. But there are many "real"
businesses that might be a good match for AE. I don't know Dave
Westwood, and can't speak for him, but I don't think there's anything
about GAE that's stopping him from monetizing BuddyPoke. (On the other
hand, I prefer to keep the Wordle web site non-commercial, while
licensing the core technology in other ways.)

[Feris Thia]

I'm a bit confuse for what this scale means. Is it scale in terms to server large static / cached  items ? I have tried to use model puts into datastore and it get over quota easily, I test it using a 1000 records - with only 3 fields and no blob - loop with around 27 records updates per second. Kinda slow.. is it supposed to be like that ? What if I developed a social networking site with very high updates to datastore ?

Any best practice suggestions ?

Please advice..

Regards,

Feris

[davew]

Hi Feris,

Are you testing it locally, or live? (The datastore can be slow for
puts locally.)

Are you trying to update the same records, or 1000 unique records?

If you are doing 27 updates per second, are you ramping up, and
ramping down your requests when you run tests? Try to simulate a
smooth usage graph, rather than a spikey one.

Have you tried profiling your code live with something like:
import logging
import cProfile, pstats, StringIO
prof = cProfile.Profile()
prof = prof.runctx("self.your_main_function()", globals(),
locals())
stream = StringIO.StringIO()
stats = pstats.Stats(prof, stream=stream)
stats.sort_stats("time") # Or cumulative
stats.print_stats(400) # how many to print
stats.print_callees()
stats.print_callers()

msg = "Profile: \n%s" % stream.getvalue()
logging.info(msg)

What are the 3 fields? Are they indexed?

-Dave

On Oct 5, 7:05 am, "Feris Thia" <fe...@phi-integration.com> wrote:
> I'm a bit confuse for what this scale means. Is it scale in terms to server
> large static / cached  items ? I have tried to use model puts into datastore
> and it get over quota easily, I test it using a 1000 records - with only 3
> fields and no blob - loop with around 27 records updates per second. Kinda
> slow.. is it supposed to be like that ? What if I developed a social
> networking site with very high updates to datastore ?
>
> Any best practice suggestions ?
>
> Please advice..
>
> Regards,
>
> Feris
>

[Nash]

Thanks Jonathan for your reply,

My intention is to bring these issues out, I'm a big Google, Django,
Python fan and I would love to see GAE work for a larger subset of
problems. Current functionality is just very limited.

> > 4. No sorting: When using lists, inequalities etc you can't sort on
> > multiple properties. You just can't.
>
> You can construct a synthetic property that represents the desired
> ordering lexicographically. This costs you some storage, but so would
> an index.

You can't do that with a two or more property sort. The combiniations
are infinite and despite the popular belief, the an object's instance
size is limited. If you attempt to save a large object, it will cause
a datastore timeout while populating the rows of it's index.

> > 5. Limited Datastore functionality
>
> In my opinion, you're making the logical error of judging the Google
> data store vs. the properties of SQL. They are not comparable.

I know the difference between the two and I'm not making a logical
error. I'm talking about basic functionality like deleting an object
which has 200 other objects refer to it. You need a way of updating
all those referring objects that the data is now deleted. If you don't
do that, you will need to always check whether that object exists
which itself incurs considerable costs while retrieving data.

> > 7. In 2008, GAE keeps on making you reinvent the wheel: As a
>

> On the other hand, it's *so easy* to implement those features!

I completely, respectfully disagree. Try implementing an OR. Or try
implementing simple word-based search (the SearchableModel doesn't
stack with GQL). Try getting data that is between two dates and with
in a range. As a programmer, I like small problems I can work with,
it's even fun. But these problems have no work around except doing it
"in-memory" or in a "purely-pythonic" implementation. Doing so will
create a solution which will ofcourse time-out and will not scale.

[Jorge Vargas]

On Sat, Oct 4, 2008 at 4:20 PM, Nash <nasr...@gmail.com> wrote:
>
> My strong suggestion at this stage to anyone considering GAE for a
> production, business use DO NOT USE GAE.
>

are you trolling with that reply? I saw it exactly the same in two
threads already.

[Feris Thia]

Hi Dave,

Thanks for responding. Below are my code details :

from google.appengine.ext import db

_DEBUG = True

class Feris(db.Model):
  pengarang = db.StringProperty()
  content = db.StringProperty(multiline=True)
  date = db.DateTimeProperty(auto_now_add=True)
 

def test():
  for i in range(1, 1000):
    ferisrecord = Feris(pengarang = "Feris Thia" + str(i), content="Great app" + str(i))
    ferisrecord.put()

if __name__ == "__main__":
  test()

On Mon, Oct 6, 2008 at 12:16 AM, davew <dave.w...@gmail.com> wrote:

Hi Feris,

Are you testing it locally, or live?  (The datastore can be slow for
puts locally.)

Both, in local it is much slower. I have screen captures from entity's console

For live - 12 records per second - this is the screenshot :

http://lh5.ggpht.com/feristhia.phi/SOoieKZ6LMI/AAAAAAAAAnQ/S_I-fWMglCc/s800/data_entity_live.png

For local - 427 records in about 3 minutes -
 http://lh6.ggpht.com/feristhia.phi/SOojGA3bmrI/AAAAAAAAAnY/OX_ahoI-jFk/s800/data_entity_local_page_1.png
http://lh5.ggpht.com/feristhia.phi/SOojGMwqXlI/AAAAAAAAAng/9Q78KxGn8IA/s800/data_entity_local_page_48.png

Are you trying to update the same records, or 1000 unique records?

Unique records.

 

If you are doing 27 updates per second, are you ramping up, and
ramping down your requests when you run tests?  Try to simulate a
smooth usage graph, rather than a spikey one.

I'm not get you quite well on this. I just use a pure for loop.
 

Have you tried profiling your code live with something like:
           import logging
           import cProfile, pstats, StringIO
           prof = cProfile.Profile()
           prof = prof.runctx("self.your_main_function()", globals(),
locals())
           stream = StringIO.StringIO()
           stats = pstats.Stats(prof, stream=stream)
           stats.sort_stats("time")  # Or cumulative
           stats.print_stats(400)  # how many to print
           stats.print_callees()
           stats.print_callers()

           msg = "Profile: \n%s" % stream.getvalue()
           logging.info(msg)

Will try on this. Thanks.
 

What are the 3 fields? Are they indexed?

No, they are not indexed. The model is Feris with 2 String and 1 Datetime field as showed above.

I notice that the fastest in live environment is 27 records/second. Is there any good suggestions on how to improve my code ?

Thanks,

Feris

[José Oliver Segura]

On Mon, Oct 6, 2008 at 4:48 PM, Feris Thia <fe...@phi-integration.com> wrote:
>...

>> What are the 3 fields? Are they indexed?
>
> No, they are not indexed. The model is Feris with 2 String and 1 Datetime
> field as showed above.

Sorry to ask, maybe my question is very stupid but... doesnt't
GAE index *by default* all StringProperties? That means that, despite
not telling it explicitely, these properties are, in fact, indexed ¿?
(simple indexes for individual properties)

> I notice that the fastest in live environment is 27 records/second. Is there
> any good suggestions on how to improve my code ?

I don't know how to improve that without having profile data,
but 0.03 secs/put seems reasonable to me. I think the way to improve
it is assume that you must focus on scale it for thousand/milions of
users and what matter is not the fact that one of them can do 27 puts
per second, but the fact that *most* of them can do about 27 puts per
second without degrading individual requests performance... That, is:
try to make performance tests emulating concurrent connections, don't
focus on improving individual, sequential puts, unless you know for
sure that they are not working ok (warnings in log files? datastore
timeouts?)

hope that helps,
Jose

[Bill]

> def test():
>   for i in range(1, 1000):
>     ferisrecord = Feris(pengarang = "Feris Thia" + str(i), content="Great
> app" + str(i))
>     ferisrecord.put()

Try batching your puts. Right now you are doing serial put() on 1000
instances. I'd try batching those puts and see how much faster group
puts can be:

def test:
batch = 100
num = 1000 / batch
for i in xrange(0, num):
ferisrecords = []
for j in xrange(0, batch):
ferisrecords.append(new_ferisrecord(i, j))
db.put(ferisrecords)

This discussion should probably be on a separate thread rather than
take-over the original intent.
-Bill