Lightning wrote:
Very true. I've been looking at the code, trying
to find the db calls
where I could optimize something. and trying to find bottle necks, but
its pretty hard. The current code is *really* confusing. variables are
Isn't code always confusing? :-) However, if you are looking *for*
bottle necks, it means you are looking *at* the bottle. Try looking
at the fluid instead. Nobody really cares about the bottle anyway.
Another fun think would be to log every query made to
the test server
for say.. 500 page views or so along with a microtimestamp from the
begining to the end of the file. We could then properly analyze that
file and try to find the bottle necks and problematic query's. That
You're on the right track here. However, the first thing we do when
we try to analyze that log file is to filter out all entries that have
a short roundtrip or response time, since they are not a problem. So
it is rather unnecessary to log anything that has a short roundtrip.
We only need to log the slow responses.
start = time();
... /* do all the calls */
elapsed = time() - start;
if (elapsed > OUR_THRESHOLD)
Log("whooaaa, doing all the calls was very slow!!!");
Let's set the logging threshold so that only, say, 1% of all calls get
logged. The overhead for looking at the system clock at the beginning
and end of every call is neglectible. The overhead of writing a line
to the log for 1% of all calls is also neglectible. There is no
reason not to use this sort of logging in the live system.
If "start" is a global variable, you can write a subroutine to make
the whole program more readable:
void TimeLog(string text) {
time_t elapsed = time() - start;
if (elapsed > OUR_THRESHOLD)
Log(text + " took " + elapsed + " seconds");
}
Then the progam will look something like this:
start = time();
if (this_call == "GET") {
... /* do the get */
TimeLog("get");
}
else if (this_call == "SAVE") {
... /* do the save */
TimeLog("save");
}
else if (this_call == "STATISTICS") {
... /* do the statistics */
TimeLog("statistics");
}
The overhead for calling this subroutine for every transaction is
also neglectible. It is a matter of microseconds at most, and any
"performance problem" is a matter of several milliseconds.
--
Lars Aronsson (lars(a)aronsson.se)
Aronsson Datateknik -
http://aronsson.se/