[google-appengine] Re: Enabling edge cache - what am I missing
FYI, here's Brandon's post: https://groups.google.com/forum/#!topic/google-appengine/6xAV2Q5x8AU/discussion and two related issues you may be inclined to star (with more info in the comments as well): http://code.google.com/p/googleappengine/issues/detail?id=2258 http://code.google.com/p/googleappengine/issues/detail?id=4277 and there is this article: http://www.kyle-jensen.com/proxy-caching-on-google-appengine On Mar 11, 4:23 pm, Brandon Wirtz drak...@digerat.com wrote: Check the archive, I have a post about VERY specific formatting required to get Edge Cache to work. -Original Message- From: google-appengine@googlegroups.com [mailto:google- appeng...@googlegroups.com] On Behalf Of Kurt Sent: Sunday, March 11, 2012 12:16 AM To: Google App Engine Subject: [google-appengine] Enabling edge cache - what am I missing Hi. I am having a tough time getting edge caching to work. I have a simple handler that does: self.response.headers['Cache-Control'] = 'public, max-age:300' self.response.headers['Pragma'] = 'Public' My app is: * hosted on a custom domain * billing enabled But all I see are 200's in the logs. With edge cache, I should see 204s. Is there something I am missing? -- You received this message because you are subscribed to the Google Groups Google App Engine group. To post to this group, send email to google-appengine@googlegroups.com. To unsubscribe from this group, send email to google- appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en. -- You received this message because you are subscribed to the Google Groups Google App Engine group. To post to this group, send email to google-appengine@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
[google-appengine] Re: 500 errors + high latency + please communicate with us
My app (adb2) is getting over quota errors and is no longer serving requests. This has never happened before. According to the dashboard my app has used 34 instance hours to process under 100 requests which I can't imagine is possible under normal circumstances (especially since the app doesn't use much of the service APIs or datastore). Despite the app's low traffic there are a number of people that depend on using it so I hope Google can look into this. Just a little side note: There seems to be more and more recognition that Google's lack of support for paid services is getting to be kind of a drag. Even the el cheapo $4/mo hosting services have trouble ticket systems and respond pretty quickly to issues. It's nice that some of the developer support team (ie Ikai) follow up on some things but not having a real support system is pretty janky. And before someone says oh but you can sign up for premier support!, it's just not affordable for small projects. In general GAE has been a great platform to build apps for and I really appreciate it, but now that I'm paying for it I feel like I can complain a little... thanks, - Claude -- You received this message because you are subscribed to the Google Groups Google App Engine group. To post to this group, send email to google-appengine@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
[google-appengine] Re: Is App Engine suddenly becoming more expensive???
On May 11, 5:27 pm, Greg g.fawc...@gmail.com wrote: Actually the way I see it is that Google has given us a free ride for three years... Well, actually, Google got lots of developers to test their platform and various service API roll-outs for free for three years. It's been pretty much of a quid pro quo up until now. My python app gets sporadic traffic and the lengthy instance cold startup times are really damaging. I would be willing to pay $9/mo for an always on instance but if the billing increments are a minimum of one hour for new instances then it's kind of unfair for low traffic sites that get sporadic bursts of traffic that are just enough to trigger one or two new instances - especially if they were written in Python and there is no multi-threading support. Also, the datastore latency is sometimes very long which would also punish single threaded apps under this new scheme. I suggest that the $9/mo should cover three instances. thanks, - Claude -- You received this message because you are subscribed to the Google Groups Google App Engine group. To post to this group, send email to google-appengine@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
[google-appengine] Re: blobstore image.execute_transform returns empty data after resize if image is already at desired size
sorry, there's a typo... the line: image_data = googimg.execute_transforms(output_encoding=images.JPEG) should be image_data = img.execute_transforms(output_encoding=images.JPEG) the issue is the same though... -- You received this message because you are subscribed to the Google Groups Google App Engine group. To post to this group, send email to google-appengine@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
[google-appengine] blobstore image.execute_transform returns empty data after resize if image is already at desired size
I hope this is useful information for someone who has encountered this: If you upload an image via the blobstore that is, say, 1000x800 and then attempt to resize using the following: img = images.Image(blob_key=str(blob_key)) img.resize(1000,1000) image_data = googimg.execute_transforms(output_encoding=images.JPEG) You will find that image_data is empty. I couldn't find this behavior documented anywhere so I assume it is a bug. The following hack can be used if a non-empty image_data is expected: if len(image_data) == 0: image_data = blobstore.BlobReader(blob_key).read() -- You received this message because you are subscribed to the Google Groups Google App Engine group. To post to this group, send email to google-appengine@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
[google-appengine] what happened to the appengine svn repository?
It appears to be stuck at version 1.3.5 It has been useful in the past mainly for use in Eclipse as a reference with Pydev, but lately it's been out of date so much that it kind of seems pointless to even make the repository public. I'm assuming there must be some kind of Byzantine build process at Google that prevents timely commits. Should we just assume this repository is dead? -- You received this message because you are subscribed to the Google Groups Google App Engine group. To post to this group, send email to google-appeng...@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
[google-appengine] Re: Gae is down ?
Can't upload a new version either: 500 internal server error The dashboard is inaccessible as well. App is slow but works. On Jun 26, 9:55 pm, gg bradjyo...@gmail.com wrote: Seems to be just the admin... On Jun 26, 9:52 pm, Tom Wu service.g2...@gmail.com wrote: Server Error A server error has occurred. Return to Applications screen » http://appengine.google.com/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google App Engine group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~--~~~~--~~--~--~---
[google-appengine] Is it possible to delete or rename a named task queue?
I tried just removing the queue name from queue.yaml but the queue still seems to exist with a rate and bucket size set to 'paused'. If it isn't now, will it be possible to delete or rename queues in the future? The reason I ask is because I created a test queue with a crazy name and would rather not have to use it in the future. thanks, - Claude --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google App Engine group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~--~~~~--~~--~--~---
[google-appengine] Re: Just released: Python SDK 1.2.3
Thank you! These are really great new features. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google App Engine group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~--~~~~--~~--~--~---
[google-appengine] Re: Subversion not latest?
Hi Jeff, This seems to happen on pretty much every release. I sort of figured the repository would always have the latest and the zip/installer download would, if anything, trail it slightly. Otherwise what is the point of exposing the svn repository if it's out of date with respect to the actual release? I've never noticed any files checked into the trunk between releases so it seems kind of pointless. Is there a branch were we can get the latest working build? thanks, - Claude On Apr 23, 6:54 pm, Jeff S (Google) j...@google.com wrote: Hi Ross, I'm working on this now. The 1.2.1 code is in a branch and I'm merging into trunk as we speak. https://googleappengine.googlecode.com/svn/branches/1.2.1 Apologies for the delay, Jeff On Thu, Apr 23, 2009 at 6:43 PM, Ross M Karchner rosskarch...@gmail.comwrote: http://code.google.com/p/googleappengine/source/browse/trunk/python/V... Reports: release: 1.2.0 http://code.google.com/p/googleappengine/source/browse/trunk/python/V... --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google App Engine group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~--~~~~--~~--~--~---
[google-appengine] Re: Does TOS allow multiple versions of one app that do different things?
Awesome, thanks Jeff. I think doing it this way would make my app use less resources in general which is good for everybody. - Claude On Mar 26, 2:25 pm, Jeff S j...@google.com wrote: Hi Claude, On Mar 25, 8:27 pm, cz czer...@gmail.com wrote: The reason I ask this is for the following scenario: My main app uses Django 1.x and has fairly low, but quite useful ;), traffic thus often requiring a cold start. It incurs significant startup time and so the initial requests are quite slow. The pages also contain lots of images uploaded by users which in turn are initially very slow to serve up. What I'd like to do is use a lighter weight framework just to serve images and other pseudo-static content. It would be fairly straightforward to simply create a special version of the app that when installed has direct access to the same datastore and can be very fast. This wouldn't ever be set as the default version of course, but would still be 'a part of' the default app and it would be using the same quota bank and hopefully wouldn't be a violation of the TOS. Anways, after reading the TOS I couldn't find an answer to this. So, in case none of this makes much sense the gist of the question is can I have two versions of the app live at the same time (only one being the default)? Say my app id is 'foo'. I upload 'foo' version 5 and then I also upload a 'foo' version 6 with a different main.py and code that is optimized for a specific kind of content (eg. images, no templates). Version 5 is set as the default but generates pages with image urls that point to version 6. This would be fine since you are talking about using two versions under the same app ID. Quotas are applied based on the app ID (not further down on the version level), so sending traffic to multiple versions would be pulling from the same quota pool. Good question, Jeff Can I do this under the TOS and still be a good GAE citizen? thanks, - Claude --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google App Engine group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~--~~~~--~~--~--~---
[google-appengine] Re: Cold app startup stats in case you're curious
Django is pretty resource intensive what with all the middleware and
template processing so it makes sense that a more minimal app would be
much faster. As for using .96 my guess is that you'd save ~180ms by
skipping zipimport and a fair bit more by not having to compile all
the imports (assuming the default GAE libraries are *.pyc). I'm still
kind of a Python newbie (old Java/C++ prgmr) so this explanation might
be completely wrong. Please post your results if you try it out!
You're probably right about memcache, I was trying to figure out where
all that extra response time (not startup time) came from on a cold
start (500ms cold vs 10ms warm). Maybe it's just the Python
interpreter having to compile all the response processing code.
My app serves uploaded images and other longer term datastore
blobjects, and using a Django view to serve them up is super slow when
cold. I'm thinking of using the lighter weight webapp framework just
to serve this kind of content. I didn't want to use more than one
framework for the app, but it's probably worth it in this case. For
lower traffic apps anyway.
regards,
- Claude
On Mar 24, 11:58 pm, Robert rjaa...@gmail.com wrote:
Useful stuff, thanks!
Just yesterday I was looking into this same issue. I was wondering if
plain 0.96 Django use (without appengine helper or patch) would be
significantly faster, and your post really makes me want to try that.
I changed the handling of a single url in my app to be a plain GAE
(webapp.WSGIApplication) handler. This URL was for a cron-triggered
task that runs every minute. In the absence of other traffic this
resulted in a cold start every minute and this processing this trivial
request now only uses approx. 200 ms CPU quota. When it was part of
the main Django app, it would take over 2000 ms CPU quota.
BTW I'm fairly convinced that memcached data doesn't get flushed out.
On Mar 24, 6:27 am, cz czer...@gmail.com wrote:
I added some timing code to see how expensive a cold app startup is.
This is a Django1.x app so YMMV.
The typical numbers are:
Zipimport of Django: 180ms
Appengine-django-helper monkeypatching: 430ms
Misc imports, app-specific patching, etc: 20ms
Total app startup: 630ms
This is for startup only, not the time it takes to then process the
request, so this is a fixed expense. Also, this is real time not cpu
quota time which is much higher.
The biggest hog is the django-helper monkeypatcher. I'm eventually
going to try appengine-patch with the hope that it will be faster.
Additionally, on a cold startup my app processes a request in about
500ms, but on a warm app it only takes 10ms due to some aggressive
caching. I think that when all your app instances expire so does all
it's memcached data.
If anybody has done something similar and found different numbers
please post the results and let me know what I did wrong.
Here's the main.py I'm using in case you'd like to point out any
errors in my methodology:
from time import clock
t_main_start = clock()
# Standard Python imports.
import os
import sys
import logging
import settings
logging.getLogger().setLevel(settings.LOGGING_LEVEL)
# Fix (hack) for missing unlink
if os.name == 'nt':
os.unlink = lambda: None
# TODO (after gathering stats): remove this since appengine_django
does it for us
# Import Django 1.x from a zipfile and get rid of v.96.
t_zip_start = clock()
django_zip_path = os.path.abspath('django.zip')
if django_zip_path not in sys.path:
sys.path.insert(0, django_zip_path)
for k in [k for k in sys.modules if k.startswith('django')]:
del sys.modules[k]
# TODO (after gathering stats): remove this line
from django import template # provoke django zipimport
t_zip = (clock() - t_zip_start) * 1000
# Install appengine_django. Patches Django 1.x for use with GAE
t_patch_start = clock()
from appengine_django import InstallAppengineHelperForDjango
InstallAppengineHelperForDjango()
t_patch = (clock() - t_patch_start) * 1000
# Patch the appengine_django patch to fix User object creation
# Remove this when switching to appengine-patch
from monkeypatch import patch
patch()
# Google App Engine imports.
from google.appengine.ext.webapp import util
# Import the part of Django that we use here.
import django.core.handlers.wsgi
t_main = (clock() - t_main_start) * 1000
logging.info('[TIME] main.py startup: %.1fms (zipimport: %.1fms,
appengine-django: %.1fms)' % (t_main,t_zip,t_patch))
def real_main():
t_request_start = clock()
# Create a Django application for WSGI.
application = django.core.handlers.wsgi.WSGIHandler()
# Run the WSGI CGI handler with that application.
util.run_wsgi_app(application)
t_request = (clock() - t_request_start) * 1000
[google-appengine] Cold app startup stats in case you're curious
I added some timing code to see how expensive a cold app startup is.
This is a Django1.x app so YMMV.
The typical numbers are:
Zipimport of Django: 180ms
Appengine-django-helper monkeypatching: 430ms
Misc imports, app-specific patching, etc: 20ms
Total app startup: 630ms
This is for startup only, not the time it takes to then process the
request, so this is a fixed expense. Also, this is real time not cpu
quota time which is much higher.
The biggest hog is the django-helper monkeypatcher. I'm eventually
going to try appengine-patch with the hope that it will be faster.
Additionally, on a cold startup my app processes a request in about
500ms, but on a warm app it only takes 10ms due to some aggressive
caching. I think that when all your app instances expire so does all
it's memcached data.
If anybody has done something similar and found different numbers
please post the results and let me know what I did wrong.
Here's the main.py I'm using in case you'd like to point out any
errors in my methodology:
from time import clock
t_main_start = clock()
# Standard Python imports.
import os
import sys
import logging
import settings
logging.getLogger().setLevel(settings.LOGGING_LEVEL)
# Fix (hack) for missing unlink
if os.name == 'nt':
os.unlink = lambda: None
# TODO (after gathering stats): remove this since appengine_django
does it for us
# Import Django 1.x from a zipfile and get rid of v.96.
t_zip_start = clock()
django_zip_path = os.path.abspath('django.zip')
if django_zip_path not in sys.path:
sys.path.insert(0, django_zip_path)
for k in [k for k in sys.modules if k.startswith('django')]:
del sys.modules[k]
# TODO (after gathering stats): remove this line
from django import template # provoke django zipimport
t_zip = (clock() - t_zip_start) * 1000
# Install appengine_django. Patches Django 1.x for use with GAE
t_patch_start = clock()
from appengine_django import InstallAppengineHelperForDjango
InstallAppengineHelperForDjango()
t_patch = (clock() - t_patch_start) * 1000
# Patch the appengine_django patch to fix User object creation
# Remove this when switching to appengine-patch
from monkeypatch import patch
patch()
# Google App Engine imports.
from google.appengine.ext.webapp import util
# Import the part of Django that we use here.
import django.core.handlers.wsgi
t_main = (clock() - t_main_start) * 1000
logging.info('[TIME] main.py startup: %.1fms (zipimport: %.1fms,
appengine-django: %.1fms)' % (t_main,t_zip,t_patch))
def real_main():
t_request_start = clock()
# Create a Django application for WSGI.
application = django.core.handlers.wsgi.WSGIHandler()
# Run the WSGI CGI handler with that application.
util.run_wsgi_app(application)
t_request = (clock() - t_request_start) * 1000
logging.info('[TIME] request: %.1fms' % t_request)
def profile_main():
# Rename this to main() for profiling
import cProfile, pstats
prof = cProfile.Profile()
prof = prof.runctx(real_main(), globals(), locals())
print pre
stats = pstats.Stats(prof)
stats.sort_stats(time) # Or cumulative
stats.print_stats(80) # 80 = how many to print
# The rest is optional.
#stats.print_callees()
#stats.print_callers()
print /pre
main = real_main
if __name__ == '__main__':
main()
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Google App Engine group.
To post to this group, send email to google-appengine@googlegroups.com
To unsubscribe from this group, send email to
google-appengine+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/google-appengine?hl=en
-~--~~~~--~~--~--~---
[google-appengine] Re: help me about Django' url setting!!!!!!!
see: http://docs.djangoproject.com/en/dev/ref/middleware/#module-django.middleware.common http://www.djangosnippets.org/snippets/601/ in your settings.py: APPEND_SLASH = False On Mar 14, 5:01 am, gxtiou gxt...@gmail.com wrote: i don't want it to redirect to: http://www.abc.com/login/; added / in the end. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google App Engine group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~--~~~~--~~--~--~---
[google-appengine] Thanks GAE team
The datastore seems to be unusually zippy today, whatever you googly types did yesterday sure worked. Beautiful! thanks, - Claude --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google App Engine group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~--~~~~--~~--~--~---
[google-appengine] Re: Application instances seem to be too aggressively recycled
Actually, that is normal behavior. This has been discussed in previous threads. GAE seems to aggressively purge it's app cache, average app lifetime appears to be under 2 seconds. Appengine-patch may be marginally faster but both require Django1.x to be imported via zipimport, which is pretty expensive. Our app also exhibits this problem due to fairly low traffic, but there's not much that can be done as far as I can tell. Our app's dynamic pages contain lots of images also served via GAE, and since the browser can make many requests at once to load these, the app can be started up on several sever instances (probably due to load balancing) to deliver all the images. This can add up to a huge amount of CPU usage for just one page. Basically, the more traffic your app gets the faster it will be. Some people have suggested using a process somewhere to automatically make requests once per second or so to keep apps in the cache. But this is surely frowned upon by Google. On Mar 10, 11:44 am, peterk peter.ke...@gmail.com wrote: That sounds like very strange behaviour. I don't have much experience with django helper..I remember using it before switching to appengine patch, but I don't remember having these kinds of issues with it. I wasn't really looking out for them though, mind you. The only reassurance I can provide is that it definitely shouldn't be that way, that's not normal behaviour..so likely someone will be able to help you sort out what's causing this. I can recommend app-engine- patch as an alternative if you feel like comparing though. It's available here: http://code.google.com/p/app-engine-patch/ On Mar 10, 6:34 pm, Jason C jason.a.coll...@gmail.com wrote: As of right now, we are seeing instance start-ups around every 2-3 seconds - every 2-4 requests. We are usinghttp://code.google.com/p/google-app-engine-django/asthe shim. j On Mar 10, 12:23 pm, peterk peter.ke...@gmail.com wrote: How frequently are you hitting appengine 'cold', requiring a start-up? I'm running an app on django using app-engine-patch. Just testing and so forth, it averages around 1 request every 5 to 10 seconds. Just looking over my last 60 requests or so, I don't see any evidence of 'cold starts', all requests are within the range I'd be expecting (100-300ms in my case). Your start-up cost in any case sounds very high..are you using app- engine-patch, or how are you using django? On Mar 10, 5:22 pm, Jason C jason.a.coll...@gmail.com wrote: We have a new application that receives _very_ little load. So little, in fact, that each request spins up a new application instance. We are using Django trunk and the import overhead is high. All of this yields a long request (e.g., 8802ms) using a lot of CPU (e.g., 3247ms-cpu). With very little load, it makes sense that instances are recycled. On that assumption, we've started applying some primer load against a couple of uris in an attempt to keep some instances hot. We're applying around 1 request/second across 2 uris. When we hit a hot instance, we get blazing speed (e.g., url_1: 73ms 91ms-cpu, url_2: 368ms 615ms-cpu - these values are pulled from the App Engine console Logs tool and I'm not completely sure if this represents Runtime, or combined Runtime/API - I believe the latter). Under this 1 request/second load, we are still seeing lots of instance startup - even after 40-50 minutes of sustained load. Subjectively, the instance startups seem to come in bursts, though we've done no formal analysis around this. Does anyone else see this behavior? It _really_ kills our application performance - so much so, that we're considering moving away from Django in an effort to minimize the start-up pain. Any info or war stories would be appreciated. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google App Engine group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~--~~~~--~~--~--~---
[google-appengine] Latency problem still really a problem
Our app is still experiencing at least double the latency as compared to last week and the app is basically unusable. I'm really concerned about this since the GAE team has stated that the latency issue has been resolved. This is so disappointing if the current performance is considered to be fine. I'm really hoping that this isn't the case. I'm curious as to how you are testing latency internally? Perhaps the tests aren't reflecting very well some real world scenarios and that some combination of datastore operations are particularly onerous. In any case, latency is still much much worse than before the server maintenance. P.S. also getting random 502 errors which I assume is related to this issue: http://groups.google.com/group/google-appengine/browse_thread/thread/391a6ecc2febfc22/f43d82010fb1b598 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google App Engine group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~--~~~~--~~--~--~---
[google-appengine] Re: 502 Server Errors after upgrade?
Latency is still pretty much killing our site. Dynamic pages that took 1-3 seconds (which is bad enough) before the slowdown still take 10-20 seconds. The app dashboard is super sluggish as well (as Nick pointed out). I'm hoping this means that the GAE team is still working on it (if so, thanks guys). On Mar 3, 9:15 pm, Arun Shanker Prasad arunshankerpra...@gmail.com wrote: Hi, The system status site shows that all services are serving normal now, but my app is still experiencing DeadlineExceededError in pages that used be served well under 5s, and others are very slow and takes almost twice the normal time to serve. I know the Google App Engine team is working on resolving this and I thank them for that, but I made this post since the current status is shown as Normal and my app is still experiencing errors. Thanks, Arun Shanker Prasad. On Mar 4, 7:23 am, Pete Koomen pkoo...@google.com wrote: Hi all, we'll continue posting updates about this issue to our status site and downtime-notify group as we continue investigating: http://code.google.com/status/appenginehttp://groups.google.com/group... Thanks for your patience, we're still working hard on this one. Pete On Mar 3, 3:07 pm, Brandon Thomson gra...@gmail.com wrote: I think my errors are gone now. Thank you Google! On Mar 3, 1:44 pm, Artem p.ar...@gmail.com wrote: I am still getting 502s in our App (which is an instance of Rietveld without any changes except securing it with a password). app id is: wsl-codereview We have changed nothing. Problems started last night, but now every request is a 502. Artem On Mar 3, 1:25 pm, Brett Slatkin brett-appeng...@google.com wrote: Hi Nick, On Tue, Mar 3, 2009 at 8:55 AM, Nick Winter livel...@gmail.com wrote: http://code.google.com/status/appengine/detail/serving/2009/03/03#ae-... Just about every day for the past several weeks, there's been elevated latency like this, usually at similar times of day. It was unfortunate and frustrating before, but since last night our development is stalled because every part of App Engine is too slow to do any testing or data manipulation right now. 5 seconds per request? I'm confident that the App Engine team will get a handle on the performance and everything will be shiny once more, but it'd be nice to hear some word as to what's going on. Are the servers just overloaded? Did something go wrong with the maintenance last night? Is anomaly-yellow serving to be expected? We had some unexpected issues during the maintenance last night which caused elevated latencies and errors for all applications. We resolved the issue around 8:45pm last night and things have returned to normal since. Please let me know if you're still seeing any problems. As for the elevated latency for the dynamic request metric (that you linked to), this is primarily a product of alert tolerances. We're still tuning our status site metrics to match real-world expectations of App Engine performance. You'll notice today that we've raised some of these tolerances by a little bit, causing many of the lines to go back to a blue color (i.e., everything OK). -Brett --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google App Engine group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~--~~~~--~~--~--~---
[google-appengine] Re: 502 Server Errors after upgrade?
yep, our app still quite a bit slower than usual but slightly better than earlier today. zipimport still seems especially slow... I'm wondering if using non- trivial 3rd party frameworks such as Django 1.x is such a good idea on GAE. With this kind of latency I'm thinking maybe not. Perhaps for high traffic sites were multiple instances of the app remain in memory, but for medium to low traffic it's really terrible. Any chance this might get better? On Mar 2, 11:16 pm, Brenton toonscr...@nvbell.net wrote: Still bad for us at insightdining. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google App Engine group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~--~~~~--~~--~--~---
[google-appengine] Re: Profiling application, dev vs. prod
I think you could upload a different version (set it app.yaml) with profiling enabled and test using that version (on your live datastore). The default (non-profiled) version would still be what the public normally sees. On Feb 20, 5:51 am, Jarek Zgoda jarek.zg...@gmail.com wrote: Since enabling profiler output is not good for production site (and profiling takes additional response time), I'd like to profile my app on dev server, but as I discovered, the results are completely different. Is there any other possibility to see what makes my application to run slow without profiling it on live server? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google App Engine group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~--~~~~--~~--~--~---
[google-appengine] Re: New Limits for Several App Engine Operations
It would indeed be great to have some kind of way to store big binary blobs such as images etc. that are larger than 1mb without having to resort to using a third party storage solution like Amazon's S3. I'm under the impression though that Google is working on this (see roadmap). On Feb 16, 9:36 pm, Will vocalster@gmail.com wrote: To me, keeping 1MB datastore entity limit while allowing 10MB request/response doesn't make much sense. It is more useful to make the limits in sync/compatible. Regards, Will On Mon, Feb 16, 2009 at 10:21 PM, frank Shi frankshi...@gmail.com wrote: Because of these limits , leading to the implementation of my program sometimes unsuccessful. http://www.delicioustools.com On 2月14日, 上午6时13分, Marce (Google) ma...@google.com wrote: For those of you who haven't already heard, we're very excited yesterday to have announced that we've raised limits on several App Engine operations: * No more High CPU Requests! App Engine Apps were once allowed no more than 2 CPU-intensive requests per minute. We've made some adjustments to the way we handle requests, and have eliminated this limitation altogether. To learn more about how this works and the implications for your app, see our documentation. * Response deadline raised to 30 seconds. The amount of time an App Engine app can take to respond to an incoming request has been raised from 10 to 30 seconds! There are limits on the number of simultaneous active requests an application can process at any given moment--see our docs to learn more. * Size limits on code files, static files, and requests/responses raised to 10MB! App Engine apps can now receive requests and send responses of up to 10MB in size, and users can upload 10MB code and static files as well. Note that API requests (e.g. memcache.set(), db.put()) are still limited to 1MB in size. These changes were inspired and driven by a great deal of developer feedback, and we're not done! Please let us know what you'd like to see next on App Engine . --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google App Engine group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~--~~~~--~~--~--~---
[google-appengine] Re: New Limits for Several App Engine Operations
Awesome possum! Although having to deal with the more restrictive quotas before was probably a good thing in that it made us think more about efficiency and scalability. thanks, - Claude On Feb 14, 11:36 am, Nash-t timna...@gmail.com wrote: Nah, this is your reward for betting with Google and it is just going to get better. Not to be too much of a fanboy but Google is the best organization I've seen in the bay area since Genentech. (who also had their customer service growing pains if I remember correctly) Good job App Engine team! -Tim On Feb 14, 6:49 am, dalenewman dalenew...@gmail.com wrote: wait! all my suffering, struggling, and over-coming high cpu requests for nothing! put the limits back in :-) Dalewww.bookdope.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google App Engine group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~--~~~~--~~--~--~---
[google-appengine] Re: SDK version 1.1.9 Released
Um, this might be a dumb question, but the SVN source tree doesn't seem to reflect the latest version. It looks like it's stuck at r34 which according to the release notes is version 1.1.8. Is there a new repository or am I hallucinating? I usually just get the latest version via SVN but this seems to be behind the bundled release now. thanks! On Feb 9, 10:52 pm, Dan Sanderson dansander...@google.com wrote: Correct, all of the functionality and restrictions of the URL Fetch service apply to the httplib interfaces. -- Dan On Mon, Feb 9, 2009 at 6:33 PM, gesteves gfeste...@gmail.com wrote: Quick question: The docs state that You can use the Python standard libraries urllib, urllib2 or httplib to make HTTP requests. When running in App Engine, these libraries perform HTTP requests using App Engine's URL fetch service, which runs on Google's scalable HTTP request infrastructure. Does that mean that changing the user-agent header is still not allowed, even when using one of Python's standard libraries? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google App Engine group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~--~~~~--~~--~--~---
[google-appengine] gae 1.1.9 + appengine_django = ?
I'm sure this is something stupid on my end but I just can't see it...
everything worked fine until I checked out the latest versions of GAE
and appengine helper (r41, r74).
On startup (in main.py) I get this exception:
...\appengine_django\__init__.py in InstallModelForm()
515 Replace Django ModelForm with the AppEngine ModelForm.
516 # This MUST happen as early as possible, but after any auth
model patching.
517 from google.appengine.ext.db import djangoforms as aeforms
518 try:
519 # pre 1.0
google undefined, djangoforms undefined, aeforms undefined
type 'exceptions.ImportError': No module named ext.db
args = ('No module named ext.db',)
message = 'No module named ext.db'
The module google.appengine.ext.db is definitely there and as a test I
inserted a few import statements in main.py which seemed to indicate
every GAE module except ext.db is importable... anyways if anybody can
tell me what I've got wrong I'd really appreciate it.
thanks,
- c
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Google App Engine group.
To post to this group, send email to google-appengine@googlegroups.com
To unsubscribe from this group, send email to
google-appengine+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/google-appengine?hl=en
-~--~~~~--~~--~--~---
[google-appengine] Re: gae 1.1.9 + appengine_django = ?
Oh, and here's what the beginning of main.py looks like: # Standard Python imports. import os import sys import logging import settings # Fix (hack) for missing unlink if os.name == 'nt': os.unlink = lambda: None from appengine_django import InstallAppengineHelperForDjango InstallAppengineHelperForDjango() etc... --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google App Engine group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~--~~~~--~~--~--~---
[google-appengine] Re: gae 1.1.9 + appengine_django = ?
Thanks, I was looking at those threads, but I think my problem is unrelated since the module in question is accessible via PYTHONPATH and shouldn't have anything to do with skipped files. Also, as I stated previously, I have the latest version of GAE and the django helper checked out (r41 and r74 respectively). On Feb 10, 4:19 pm, Alexander Kojevnikov alexan...@kojevnikov.com wrote: On Feb 11, 11:16 am, jamesv jamesvreel...@gmail.com wrote: Mine is blowing up as well, except on: class 'google.appengine.tools.dev_appserver.InvalidAppConfigError': Application configuration could not be read from ./app.yaml http://groups.google.com/group/google-appengine/msg/9cb48e2e5d12aaae --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google App Engine group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~--~~~~--~~--~--~---
[google-appengine] Re: Google Analytics GAE
use appcfg without specifying severity to get just request logs: appcfg.py --email=youremail request_logs yourappdir On Feb 9, 12:45 pm, Greg g.fawc...@gmail.com wrote: On Feb 10, 2:16 am, Duncan kupu...@googlemail.com wrote: Logs generated on the server tell you how often particular pages have been requested: that includes requests from web crawlers, and from people who have gone out of their way to block Google Analytics, but it excludes requests for cacheable pages which have been cached on a user's browser or on an intervening proxy server. But how do you download those logs? appcfg.py seems to allow only debug/info/warning/error events, and I can't even get that working. If anyone can confirm they can download request logs, please post, and I'll spend more time time trying to crack it. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google App Engine group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~--~~~~--~~--~--~---
[google-appengine] Re: GAE Team, How does the import cache work? How do we reduce custom django overhead?
I have noticed that the app cache does not keep things around for much more than a few seconds, so if your site gets relatively little traffic it will have more problems than if it gets heavier traffic (paradoxically). Also, if your app returns pages with many images or other embedded content that it also served by GAE then when the browser does a multithreaded set of requests GAE then forks off more processes to handle these which in turn also reload your app. (At least this is what I've gathered looking at the logs and the number and timing of zipimport invocations). Basically, using a large framework with GAE like Django 1.0 (when it's imported at startup via zipimport) is sort of unusable right now if your site gets light traffic and does some non-trivial stuff on the server side. I understand the hesitancy to bundle a particular framework with GAE, but the GAE api, the webapp framework, and the bundled Django .96, all seems to indicate that Django was a major influence and I suspect many if not most of the applications use Django. It would make sense to bundle an up to date version of Django just as a default framework, non-Django users can always use whatever framework they want. And I don't buy the argument that upgrading the Django .96 release will cause a lot of grief, it really is not that hard to upgrade an application to use a more recent version. On Feb 9, 12:32 pm, johnP j...@thinkwave.com wrote: Another question: where does one start to troubleshoot if caching seems to fail. In my case (using appengine patch) - the app.yaml handler points to a script: common/appenginepatch/main.py This module *does* define a main() script. I placed logging.debug calls at the top of 5 common modules. When I click through 5 different views (each defined in the different modules) 5 times in quick succession, I see one instance of the logging.debug evaluating for each of these modules in the logs. So this tells me that something is caching, at least for this brief period of time. But the interesting thing is if I wait 30 seconds or a minute. Then I repeat the process (clicking through the 5 views in quick succession, 5 times - for a total of 25 clicks). I see that the logging.debug evaluates once again for each module - while the remaining 4 clicks don't reevaluate. So it's like the interpreter goes cold in 30 seconds. If it is caching for 20 seconds, shouldn't it cache for a minute? How long should the cache last for? Any suggestions where to look further? On Feb 9, 11:53 am, Andy Freeman ana...@earthlink.net wrote: Lazy importing (putting the import statements directly in the code paths, instead of on module start-up) can help reduce the cost of that first per-server request, though that's not always easy to do when using a framework. Hold it. I thought that the first instance was special in that it got extra CPU quota. (I don't remember if the first instance that gets extra CPU is the first invocation of a given handler in a process or the first handler used by a new process.) If the first instance does get extra CPU, lazy import is a bad idea. Instead, the first instance should use that extra CPU to do things, such as import, that subsequent instances will/might need. On Feb 9, 11:03 am, Dan Sanderson dansander...@google.com wrote: I can answer of couple of these: On Mon, Feb 9, 2009 at 9:29 AM, Mike Wesner m...@konsole.net wrote: 1. How does the import cache work exactly? I have read docs but still am left with questions on how exactly it works. If we have a main.py with our main() method in it... are all the imports in that file cached? Is there a way to keep our custom django in memory? All imports are cached on a per app server basis. The first time the app imports a module on an app server, the module is loaded from disk and evaluated. Subsequent imports of that module on that app server do not load or evaluate any code, in the same sense as if you imported a module more than once in a single run of a Python application. If a handler script (a Python code file associated with a URL mapping in app.yaml) has a main() method, the entire script is loaded and evaluated the first time the URL is requested. On subsequent requests for the URL, the main() method is called without re-loading or re-evaluating the script. This is similar to importing the handler script, with the minor difference that the main() method is not called directly on the first request, so you still have to call it in the script's code (see docs for examples) for the first request to succeed. If a handler script does not have a main() method, it is evaluated in full for every request, and its global variables are not retained on the app server between requests. 2. Since so many people use custom django, is there any plan to provide other versions of django besides the
[google-appengine] Re: SDK version 1.1.9 Released
This is really great! I just want you (google engineers) how much I appreciate your work on this. GAE is a really fun platform to use. Despite all the whining (a lot from me) it's turning into a great product, plus the fact that it's free (well, for smaller apps) is amazing. Well, ok, one more whine: Django 1.0? or maybe a faster zipimport? or lift the 1000 file limit? or increase app cache time-to-live? it's just that low traffic sites like mine get hosed by zipimport-ing and patching Django on startup... Sorry about that. I like using GAE so much I want it to be perfect. On Feb 9, 7:12 pm, Bill billk...@gmail.com wrote: Buried in the change log is an innocuous line about the remote API. From the module: This allows easy remote access to the App Engine datastore, and potentially any of the other App Engine APIs, using the same interface you use when accessing the service locally. On Feb 9, 6:12 pm, Jeff S j...@google.com wrote: Today we released version 1.1.9 of our SDK. Here's what's new in this release: * You can now use the Python standard libraries urllib, urllib2 or httplib to make HTTP requests. This has been a frequent request on our issue tracker. * We've been working on a set of tools that will make the process of uploading and downloading data from App Engine applications easier. Today we're excited to announce an early release of our new bulk uploading client. You can try it out here. Let us know what you think in our Google Group! * Several updates to our datastore, including the automatic generation of single property indexes and the addition of IN and != operators to db.Query. See the Datastore API docs for more details. * A bunch of additional bugfixes and enhancements, listed in our Release Notes. See the blog post:http://googleappengine.blogspot.com/2009/02/sdk-version-119-released and the downloads are available here:http://code.google.com/appengine/downloads.html Happy coding, Jeff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google App Engine group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~--~~~~--~~--~--~---
[google-appengine] Re: Reminder: App Engine chat time, tonight 7-8PM PST
Hi Marzia, I've been unable to make the chat times, is there a transcript archived somewhere? Thanks, - Claude On Jan 7, 11:56 am, Marzia Niccolai ma...@google.com wrote: Details about this and future chat times can be found here:http://groups.google.com/group/google-appengine/browse_thread/thread/... --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google App Engine group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~--~~~~--~~--~--~---
[google-appengine] Re: Google Team: Please Make Django 1.0 A Higher Priority
So far, for me App Engine has worked pretty well. The issue regarding Django 1.0 is a little more complicated than just use zipimport and django helper which is the standard response. While this works and is in fact what I use, there are some issues. One is that if your app doesn't have a lot of traffic Django is zipimported on almost every page request and the all monkey patching at init time doesn't seem super fast. This can blow out your CPU quota. The other thing is that the App Engine designers obviously had Django in mind when they designed App Engine and integrated (maybe included is a better word) it in the API. It's not just another feature request from the clamoring masses. I'm skeptical that upgrading to 1.0 would cause as much anguish as Google implies. Most serious users of Django use a zipped up 1.0 and the upgrade would be seamless. For the others, they've had a fair amount of time already to think about the changes and should be ready to make the changes if they haven't already. Also, App Engine is still beta which implies that every app running on it is in beta as well. Current users of those apps should expect some hiccups. I know there are a million other feature requests but this one is a little more of a basic API fix than a feature like adding Java or whatever (why don't the Java people just use one of the many hosted servlet environments anyway?). All in all, I'm pretty excited with App Engine. It was a great excuse to learn Python after programming in Java for many years, and I like the simplicity and basic level of constraints of the environment. Sure I would love a whole bunch more features but I figure they'll arrive eventually. It is a bit disconcerting that developer interest seems to have waned (based on forum traffic). And I wish Google would give us a little more open about what they are working on. I get the feeling that there are maybe three developers working on App Engine in their spare time and Google as a company isn't quite 100% sure they will fully support it. Please tell me I'm wrong. happy programming, - Claude On Dec 18, 1:12 pm, Greg g.fawc...@gmail.com wrote: I can understand the frustration when there seems to be little movement on something that is important to you... --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google App Engine group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~--~~~~--~~--~--~---
[google-appengine] Re: Google Team: Please Make Django 1.0 A Higher Priority
On Dec 18, 5:10 pm, Thomas Johansson prenc...@gmail.com wrote: I just want to address one thing here: There is nothing in AppEngine that is tied in any way to django or any framework. They just expose a ... Sure, of course. By API I loosely included the supplied default appengine frameworks. I suspect there aren't many AppEngine users that are building apps without using webapp or django right now. If I'm wrong then carry on, I retract everything. ... complexities of getting it working on your own with the current 1000 file and 1mb size limitations... That's the easiest part, and most appengine django users are doing just that (simply by omitting seldom used parts of django). The cost of repeated zipimports on requests is the problem. It eats into your quota. Unless I'm not understanding how appengine works, I would assume that if django 1.0 was included with the default frameworks there would be a high likelihood that it is always in memory. I'm using Django 1.0 now on appengine without any other issues besides that. CPU quotas are really tight right now, so it makes sense to minimize expensive events. That's all I'm sayin' On Dec 19, 1:54 am, cz czer...@gmail.com wrote: ... --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google App Engine group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~--~~~~--~~--~--~---
[google-appengine] Re: Reminder: Scheduled Maintenance This Evening
I'm getting 404/not found for http://appengine.google.com/ which was how I accessed the dashboard up until last night. Also, my app (adb2) is returning spurious 500 server errors and random 404/not found, but it worked fine up until the system maintenance period. This app was last deployed around 8pm last night so it should be still working I think. It's a Django app that uses zipimport for the django libs if that makes any difference... I can't get to the logs since the dashboard access seems borked. Is this just me or are the app servers still a little funky right now? Thanks, - Claude On Nov 11, 12:53 pm, Marce (Google) [EMAIL PROTECTED] wrote: Hi, This is just a reminder that this evening from 5-6pm PST, you will not be able to deploy new application versions. More details can be found here:http://groups.google.com/group/google-appengine-downtime-notify/brows... Also, a reminder that all notifications of App Engine downtime, planned or otherwise, can be found on the Downtime Notify group:http://groups.google.com/group/google-appengine-downtime-notify/ -Marzia --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google App Engine group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~--~~~~--~~--~--~---
[google-appengine] Re: Google App Engine Roadmap - Now Published
This is fantastic, thanks Marzia! There also seems to be a fair amount of clamor for beefing up the Image API, any chance that might be in the pipeline? Also, I would like to suggest that the documentation be fattened up, especially concerning the inner workings of datastore/BigTable and related best practices. The google-appengine forum and others have a lot of traffic concerning how to use the datastore efficiently, such as discussions about normalizing/denormalizing model schemas etc. and it would be great if there was some authoritative information about this subject. Anyways, it's altogether an awesome platform so thank you Googly types. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google App Engine group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~--~~~~--~~--~--~---
[google-appengine] Re: a way to determine image size would be greatly appreciated
Thanks Jeff, that is indeed pretty much the same issue. I swear I searched for it, but it was late... Anyways, I'm loving the GAE with Django 1.0. I'm excited to see how it evolves. thanks, - Claude On Oct 10, 1:47 pm, Jeff S [EMAIL PROTECTED] wrote: Hi Claude, This sounds a bit like the following feature request:http://code.google.com/p/googleappengine/issues/detail?id=435but your idea may be slightly different. Feel free to star this one, or file a new issue :) Thank you, Jeff On Oct 9, 10:25 pm, cz [EMAIL PROTECTED] wrote: If there was just one thing to add to the Image api, a way to determine the image size would be highest on my list. It just seems so easy to add... would it not be possible to stuff a couple of integers (height,width) along with the image data into the image service response ProtocolMessage? Maybe it's not so easy, I don't really know. But please, please, could someone at Google spend a couple of minutes to look into it? thanks, - Claude --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google App Engine group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~--~~~~--~~--~--~---
[google-appengine] a way to determine image size would be greatly appreciated
If there was just one thing to add to the Image api, a way to determine the image size would be highest on my list. It just seems so easy to add... would it not be possible to stuff a couple of integers (height,width) along with the image data into the image service response ProtocolMessage? Maybe it's not so easy, I don't really know. But please, please, could someone at Google spend a couple of minutes to look into it? thanks, - Claude --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google App Engine group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~--~~~~--~~--~--~---
[google-appengine] Re: appcfg.py and 500 Server Error
The offending index eventually was purged and I'm now able to upload... It appears that the offline processing of indexes is just kind of slow. - Claude --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google App Engine group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~--~~~~--~~--~--~---
