|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #62951 Log utime and stime
Submitted: 2012-08-27 14:13 UTC Modified: 2023-07-17 10:12 UTC
Avg. Score:3.5 ± 0.5
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:0 (0.0%)
From: rainer-phpbugs at 7val dot com Assigned: bukka (profile)
Status: Re-Opened Package: FPM related
PHP Version: 5.3.16 OS:
Private report: No CVE-ID: None
Have you experienced this issue?
Rate the importance of this bug to you:

 [2012-08-27 14:13 UTC] rainer-phpbugs at 7val dot com
To identify performance bottlenecks in our shared hosting environment, it is desirable to log the utime and stime consumed for each request. The current %{system}C and %{user}C just log the relative CPU-Usage percentage, not the absolute time used.

the patch below adds %(rsystem}C and %{ruser}C to the logformat options, measured in milliseconds via getrusage();


php_fpm_log_utime_stime.patch (last revision 2012-09-27 14:50 UTC by rainer-phpbugs at 7val dot com)

Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2012-09-27 14:33 UTC]
the patch does not seem to be complete. There's a missing part: how the log is 
handle ?
 [2012-09-27 14:33 UTC]
-Status: Open +Status: Feedback
 [2012-09-27 14:57 UTC] rainer-phpbugs at 7val dot com
I've missed the bit in fpm_log.c, since I didn't want to include my changes that cause tms_total to always be in 1/1000 seconds. The updated Patch includes this change.
 [2013-02-18 00:35 UTC] php-bugs at lists dot php dot net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.
 [2013-10-16 15:18 UTC]
-Status: No Feedback +Status: Re-Opened
 [2023-07-17 10:12 UTC]
-Assigned To: +Assigned To: bukka
 [2023-07-17 10:12 UTC]
Apology for very long time of no response. I have been looking into this and it might not be the best idea in the current architecture as it would leak info about usage in other pools and master process if multiple pools are used. Access log is pool specific so we need to respect the separation there.

I have finally created an issue for introduction of pool manager which is something that is planned for a long time: . I also added a note about this issue there.
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Jun 20 02:01:30 2024 UTC