Jean-Marc Orliaguet wrote:
Absolutely, this is called "debugging an application" (=> DEBUG, TRACE).
Well, I call BS on this ;-)
Things like ConflictErrors and slow-running requests are not something
you often find out about during application development. They emerge
once the load ramps up a
Jean-Marc Orliaguet wrote at 2005-12-6 21:45 +0100:
> ...
>>You err: I do want to see them in the logfile and
>>I stole Florents idea to use "threadframe" (in his "DeadlockDebugger")
>>to include a traceback for long running requests in the logfile.
>>This way, it is
>>easy not only to identify lon
Dieter Maurer wrote:
Jean-Marc Orliaguet wrote at 2005-12-6 10:59 +0100:
...
But aren't you looking for some sort of application profiler? or some
sort of benchmarker? One could argue that slowly rendered pages are sign
that the application is badly designed too, still you wouldn't want to
Jean-Marc Orliaguet wrote at 2005-12-6 10:59 +0100:
> ...
>But aren't you looking for some sort of application profiler? or some
>sort of benchmarker? One could argue that slowly rendered pages are sign
>that the application is badly designed too, still you wouldn't want to
>see in the log file:
Jean-Marc Orliaguet wrote:
But aren't you looking for some sort of application profiler?
The point is that you need information to build a profile...
sort of benchmarker? One could argue that slowly rendered pages are sign
that the application is badly designed too,
Indeed!
still you woul
Dieter Maurer wrote:
Jean-Marc Orliaguet wrote at 2005-12-4 22:28 +0100:
...
In the log flle I'd like to be informed about events that are
unexpected. Conflict errors of this kind occur "by design".
This argument is not convincing:
In a similar way, I could argue that "MemoryError"
