> 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 <[email protected]> wrote: > I can answer of couple of these: > > On Mon, Feb 9, 2009 at 9:29 AM, Mike Wesner <[email protected]> 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 .96 version? Would it > > be possibe to provide .97 and 1.0 under some other name (import > > django97 as django)? I have read that the provided django is always > > loaded in memory and thus would be faster. It would sure save us a > > lot of files to upload also. > > So far we're mostly considering upgrading the bundled Django only for the > next major API version. With the way the module load path works today, it'd > be difficult to introduce new modules into the default environment as a > backwards compatible change. As I've gone on about before here in the > group, having major third-party packages bundled with the API is not a good > way to go in the long run, and I'd rather see this need addressed by making > third-party packages easier to add to apps. > > App caching ought to be sufficient for mitigating the time spent importing > modules. Have you profiled your imports to see if they're a major > contributor to performance issues? 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. > > -- Dan --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to [email protected] 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 -~----------~----~----~----~------~----~------~--~---
