php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Request #62951 Log utime and stime
Submitted: 2012-08-27 14:13 UTC Modified: 2023-07-17 10:12 UTC
Votes:2
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
View Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: rainer-phpbugs at 7val dot com
New email:
PHP Version: OS:

 

 [2012-08-27 14:13 UTC] rainer-phpbugs at 7val dot com 
Description:
------------
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();

Patches

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

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2012-09-27 14:33 UTC] fat@php.net 
the patch does not seem to be complete. There's a missing part: how the log is 
handle ?
 [2012-09-27 14:33 UTC] fat@php.net
-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] fat@php.net
-Status: No Feedback +Status: Re-Opened
 [2023-07-17 10:12 UTC] bukka@php.net
-Assigned To: +Assigned To: bukka
 [2023-07-17 10:12 UTC] bukka@php.net 
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: https://github.com/php/php-src/issues/11723 . I also added a note about this issue there.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Sun Nov 24 10:01:32 2024 UTC