At Google IO I believe it was mentioned that TextProperty's are fine
for anything that you don't want indexed; They are no less efficient
than strings for short data. You might want to look into trying that
out with mime and type if you don't filter/order by them.
Other than that, I'd suggest try
Hey Thomas,
Thanks for the reply.
-So are textProperties more efficient than StringProperties because
they're not indexed?
-I noticed something weird: I do not have an index listed in appengine
dashboard for the thumb datastore. Maybe that's what's causing this
problem? To find all the images f
-So are textProperties more efficient than StringProperties because
they're not indexed?
You'd have to find the talk from Google IO to be sure. I believe it
was the one about scalability, in the QA section. But yes, that is my
understanding.
-I noticed something weird: I do not have an index lis
-So are textProperties more efficient than StringProperties
because
they're not indexed?
You'd have to find the talk from Google IO to be sure. I believe
it
was the one about scalability, in the QA section. But yes, that is
my
understanding.
As I understand it, every field
Thanks for the suggestions. I see the need for Cacheing to reduce the
load, but I don't understand why the current request is causing high-
cpu warnings (2 times the average cpu request). At this rate, if a few
first time users use my application & try to open images that haven't
been memcached (e
My app is also causing the same problems, I have used etags to set the
response to 302 if cached, I've tried everything short of memcache, I
have many images, I don't think that is a viable solution for me.
Any suggestions are welcome.
On Sep 29, 2:10 am, iceanfire <[EMAIL PROTECTED]> wrote:
> T
On Mon, Sep 29, 2008 at 11:18 AM, Arun Shanker Prasad
<[EMAIL PROTECTED]> wrote:
>
> My app is also causing the same problems, I have used etags to set the
> response to 302 if cached, I've tried everything short of memcache, I
> have many images, I don't think that is a viable solution for me.
W
Hi Barry,
I know that the memcache is free, but it will push out stuff if the
memory usage is high, I already have much bigger query result cached
in the memcache, I want to keep them there as long as possible. :)
Thanks,
Arun Shanker Prasad.
On Sep 29, 3:44 pm, "Barry Hunter" <[EMAIL PROTECTED
Hi,
memcache can decrease the average, that's all.
memcache is really good, but it can't be the answer for everything.
Else, I think with this CPU/Warning, there is no "good" solution. Now,
I'm just waiting for higher quota (free or not).
Did you remove all "DEBUG" flag (webapp, django render o
I will try removing the debug stuff, maybe that is what's causing this
problem. I'll let you know if this helps.
Thanks.
On Sep 29, 6:44 am, Sylvain <[EMAIL PROTECTED]> wrote:
> Hi,
>
> memcache can decrease the average, that's all.
> memcache is really good, but it can't be the answer for every
I just wanted to follow up on this discussion to (shamefacedly) point
out what was causing this problem: imports.
I had copied and pasted some code earlier, which I had later deleted
to slim down my code. What I had forgotten to do was: remove the
imports for that piece of code. Once I had remove
The default cache setting is no-cache, the browser will revalidate the
same image ever time the image being displayed.
You may try to set this explicitly to a week.
self.response.headers['Cache-Control'] = 'public, max-age=63'
On Sep 24, 10:59 pm, iceanfire <[EMAIL PROTECTED]> wrote:
> I'm st
12 matches
Mail list logo
