FRED SAUER: All right.
Here's a developer who is a little bit conscious about the
bill at the end of the day.
He says, each day, I fight to really save every
penny on App Engine.
MANDY WAITE: Don't we all.
FRED SAUER: We all do.
How could you help us better profile our applications?
App Stats, something you actually mentioned, he thinks
is a little bit hard to use.
And what's the best way to tune your application?
MANDY WAITE: An interesting question.
OK, so we mentioned App Stats earlier.
I think we've discussed it before.
We think that App Stats is still probably the way to go.
It's built into the platform already, no
external tooling needed.
It's there, ready to go.
It will only profile your RPCs.
It won't tell you where all of the hotpots in your code are.
But it will definitely give you a really good indication
about what your application is spending its time doing,
particularly in terms of RPC calls, calls to the data
store, that's includes, as well.
It's very easy to get up and running, as well.
So I'm not sure if it's difficult for you to actually
get up and running and using it, or if it's difficult for
you to actually get anything meaningful from it.
But, generally, it's fairly easy for both Java and for
Python to get up and running with App Stats.
To get access to the console--
they provide a custom console you can have access to, which
you can actually include in your basic admin console.
Once you have that available to you, you can
look at your RPCs.
You can look at each one of your requests, open up the
request, and then drill down into the request to see where
you're spending your time.
And even then, with Python--
I'm not sure this is available with Java-- but with Python,
you can actually look at the code that
generated the RPC call.
FRED SAUER: Yeah, in Python, you have stack choices.
That's right.
MANDY WAITE: So with Python, you can actually dive straight
in to where the code is that's actually calling the wrong RPC
calls, and actually modify it and redeploy the application
to see what result you get.
So that's really cool.
So I think we recommend using App Stats,
definitely for RPCs.
I'm not really familiar with any other
profiles for App Engine.
Although I did briefly at [INAUDIBLE]
Academy actually produce a profiler, Ben [? Cayman's ?]
made one.
Probably worth looking into.
FRED SAUER: Yeah, check out Ben [? Cayman's ?] blog.
He does have a Python profiler with some nice UI widgets that
tell you about the loading performance of your site.
To kind of finish up on the App Stats, I think what some
of our users sometimes run into is they feel like all the
information that App Stats provides is really
overwhelming.
And it's good maybe to take a step back.
And one of things that App Stats provides that I really
enjoy looking at is there's these timeline graphs that
give you a breakdown of the RPCs visually.
And 99% of the time when I'm using App Stats, I only look
at the graphs.
There's a whole page [? throw ?] of stack traces
and debugging information and data that's being
sent back and forth.
Almost everything related to performance of your
application, you can find just by looking at the graph.
You can see whether you have data store reads that are
staircased all sequentially behind one another, or whether
they're happening in parallel.
You can see that you're making a memcache call and then a
data store call, which tells you there's a
memcache miss, right?
So really just getting comfortable with those graphs,
I think, will provide most of value with very little effort.
MANDY WAITE: Would you recommend it for running on
production as well?
FRED SAUER: I do, but depending on the
traffic of your site.
If you only have a few requests per second, then
sure, run it.
If you're doing a lot of traffic, what we recommend is
that you either deploy another version in production that you
hit so you can say version dot your app ID dot [? appsweb ?]
dot com and access that directly.
And that way you don't have all the data from all the
requests from all your users piling on top of each other.
But you can very carefully just poke at your application
and say, I'm going to do this one request here.
And then I want to see the App Stats profile.
We've even had people with mobile clients.
They'll have a couple users that
report performance problems.
And they'll change their application to send down a
ping to those users and say, OK, this mobile client should
connect to a different back-end name.
And then those users are isolated on their own version
where you can do diagnostics.
Maybe you can enable some traces.
You can enable App Stats.
And then when everything's all tuned, you tell the clients to
go back to the original version.
So yeah, a lot of ways to utilize it.