> While one instance has only one thread, there could be many instances
serving the same number of clients simultaneously.

Yes, and those separate instances are not threads, they're processes.
More important,
they may be running on different machines, so neither thread ids nor
process ids are guaranteed to be unique.  That's why using thread or
process ids as identifiers is guaranteed to be wrong in any system
that uses multiple machines, such as app engine.

Depending on how you're aggregating, one of the uuid variants might be
appropriate.

>  > > I tried to store some data at the thread local objects pool (just as I
> > > do with Java)

You're assuming persistence in an environment where persistence is
unlikely.

However, to the extent that there is persistence, you can simply store
stuff in memory because a given process may be used to run a number of
instances, one after another.  (Not simultaneously - simultaneous
instances run in different processes, possibly on different
machines.)  While an instance is running, it can see what other
instances that ran in the same process left in memory after they
finished.

However, said stuff in memory for a given process is only accessible
to the currently running instance.

On Jun 11, 6:58 am, Liang Han <liang....@gmail.com> wrote:
> Nick,
>
> While one instance has only one thread, there could be many instances
> serving the same number of clients simultaneously.
> Thus, the metric from the multiple instances will be messed up,
> because the metric logs are recorded in the global area, such as
> memcache, or as the debug log.  (is there some area to store data per
> instance? or is there a way to get the instance id?)
>
> There shouldn't be any barrier for me to release the source code, but
> firstly, it has to work.
>
> > App Engine apps run in a single-threaded environment. That is, a given
> > interpreter instance will only ever be processing one request at any given
> > time. Thus, you don't need to worry about concurrent invocations.
>
> On Jun 11, 6:15 pm, "Nick Johnson (Google)" <nick.john...@google.com>
> wrote:
>
>
>
> > Hi Liang Han,
>
> > (Replies inline)
>
> > On Thu, Jun 11, 2009 at 2:15 AM, Liang Han <liang....@gmail.com> wrote:
>
> > > A simple application, which is running at the google app engine,
> > > visits the datastore, and uses the urlfetch service as well.    I want
> > > to add the 6 hooks into the code to get the timestamp when code is
> > > running at that checkpoint, thus the transactions performance
> > > profiling can be done by calculating with the timestamps.
>
> > > Here's the flow in pseudo code:
>
> > > class MainPage(webapp.RequestHandler):
> > >  def get(self):
> > >    --> 1. hook at program starting
> > >    do something ...
> > >    --> 2. hook before fetching url
> > >    result = urlfetch.fetch(url="http://...";)
> > >    --> 3. hook after fetching url
> > >    do something ...
> > >    --> 4. hook before visiting datastore
> > >    visit datastore
> > >    --> 5. hook after visiting datastore
> > >    do something
> > >    --> 6. finish hook
>
> > > Although it's straightforward to just add the hook code in the
> > > original code, however, in order to minimize the modification to
> > > existing code, I use the following approaches:
>
> > > 1. Use "apiproxy_stub_map.apiproxy.GetPreCallHooks().Append" to add
> > > hooks to get data at checkpoint 2, 3, 4, 5.   I referenced the article
> > >http://code.google.com/appengine/articles/hooks.html
>
> > > 2. Monkeypatch google.appengine.ext.webapp.WSGIApplication (assuming
> > > the original code is written with webapp framework) by overwritting
> > > def __call__(self, environ, start_response).  I just add my code
> > > before and after calling the real method.   Therefore, I can get data
> > > at checkpoint 1 and 6.     The orignial code just need to modified to
> > > use the subclass of  WSGIApplication.
>
> > Cool stuff you're working on! Are you planning on releasing it for others to
> > use?
>
> > > Here's the problem I run into.
> > > Since multiple users might be visiting the same application at the
> > > sametime, in order not to mess up data from different users, we must
> > > be able to get a same id, such as thread id for the 6 checkpoints of
> > > each user.  However, I cannot achieve this.
>
> > App Engine apps run in a single-threaded environment. That is, a given
> > interpreter instance will only ever be processing one request at any given
> > time. Thus, you don't need to worry about concurrent invocations.
>
> > -Nick Johnson
>
> > > I have tried to use thread.get_ident(), but it always returns -1.  (I
> > > know google app engine doesn't allow create new thread, but it doesn't
> > > make any sense to return -1 for threads created by google engine
> > > itself ...)
>
> > > I tried to store some data at the thread local objects pool (just as I
> > > do with Java), but seems the thread.local is not the same with the one
> > > in Java.    I'm not familiar with python anyway, maybe I miss
> > > something or misunderstand something.
>
> > > Do you guys have any idea about this?    Thanks very much in advance!- 
> > > Hide quoted text -
>
> - Show quoted text -
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to