Request time accuracy to low about wsgi-request-logger HOT 5 CLOSED

Thanks. I agree. But it seems that with Python v3.3 time.time()'s use is now deprecated. Instead, time.process_time() or time.perf_counter() should be used. I need to give it some thought. If you have a quick fix, fell free to provide my with a patch or pull request.

from wsgi-request-logger.

I'm in python2.7. Is time.time() deprecated in 3.3? I didn't see that in the docs.

If so, what I would do is abstract the time call in call and have the init test what runtime is being used and set the method that will be called for the timer.

from wsgi-request-logger.

Oops, yes, you're right. It's not time.time() that's deprecated but time.clock() and thus the one being currently used to calculcate the runtime in wsgi-request-logger.
Should the runtime of the script stand for actual time passed or for the CPU time spent on the process?

from wsgi-request-logger.

I would think time passed, if it's just the process you would miss anything that is offloaded to an other process. As well in my system time.time is giving me 6 decimal places where as time.clock is only 3. I have a lot of calls that are reported to be 0ms

from wsgi-request-logger.

In 963b2e7 I fixed this now. The updated version 0.4.3 is on PyPI. You can install it with

pip install --upgrade wsgi-request-logger

(I'm now using time.perf_counter() where it's available and time.time() as a backup. The actual time passed is what you want as this is the one related to user experience on your web site. If you want to benchmark CPU time spend on the script you would have to use Python 3.3+ and use [https://docs.python.org/3/library/time.html#time.process_time](time.process_time() as clock.)

from wsgi-request-logger.