Posted by "Nicolas Ross" on 10/25/05 18:16

Still, with fs_usage PID, I get more the 57k lines of stuff... I've found
another tool that is more appropriate to monitor system calls : sc_usage.
This tool gave me this :



=================
httpd 5 preemptions 7 context switches 1 thread
08:45:51
0 faults 90 system calls
0:00:11

TYPE NUMBER CPU_TIME WAIT_TIME
------------------------------------------------------------------------------
System Idle 0:03.867( 0:00.798)
System Busy 0:02.221( 0:00.300)
httpd Usermode 0:01.156

zero_fill 929 0:00.032 0:00.163
copy_on_write 1 0:00.000
cache_hit 22 0:00.000

read 829(2) 0:00.018 0:04.821( 0:01.096)
W
getdirentries 5214 0:02.260 0:00.416
getattrlist 6689 0:00.207 0:00.132
poll 1 0:00.000 0:00.016
close 5268(7) 0:00.106 0:00.016
fstat 10518 0:00.088 0:00.016
select 4(2) 0:00.000 0:00.010
fcntl 5293 0:00.014 0:00.010
lstat 6253 0:00.279 0:00.007
open 5312(49) 0:00.187 0:00.003
stat 6430(7) 0:00.181 0:00.001
mach_msg_trap 547 0:00.008 0:00.000
fstatfs 5212 0:00.075 0:00.000
readlink 280 0:00.006 0:00.000
write 50(9) 0:00.005 0:00.000
chdir 2 0:00.000
accept 1 0:00.000
getsockname 1 0:00.000
access 44 0:00.001
sigaction 21(14) 0:00.000
sigprocmask 23 0:00.000
umask 3 0:00.000
setitimer 3 0:00.000
socket 1 0:00.000
connect 1 0:00.000
setsockopt 4 0:00.000
gettimeofday 2 0:00.000
getsockopt 1 0:00.000
writev 1 0:00.000
shutdown 1 0:00.000
lseek 5308 0:00.026
vm_allocate 283 0:00.012
vm_deallocate 250 0:00.010
vm_copy 1 0:00.000


Which tells my that my last asumption is right, it's file-system related.
The process passes it's time at :

- System busy and idle tasks for 6 seconds
- read for 4.8 seconds
- getdirentries for 2.2 seconds
- httpd usermod (I assume that is php processing time, nothing wrong here)



Since I am a registered Apple developper I will log an incident with apple
for this. I'll let you all know



And Richard, I must rule out the mysql problem. As stated before, on two
hardware identical machine, one with 10.3, and one with 10.4. The mysql
database is on a third different machine. So connection time should be
identical. Besides, with the trace i've done with micro-seconds timestamps,
the majority of the time mysql_connect takes less than 0.01 seconds.

As for includes, again as stated before, all is the same, including config
files, thus include_path, wich only contains /usr/local/lib/php, and this
directory contains the base PEAR installed over time plus one or two other
file.

Nicolas

----- Original Message -----
From: "Brent Baisley" <brent@landover.com>
To: "Nicolas Ross" <rossnick-lists@cybercat.ca>
Cc: <php-general@lists.php.net>; "Shawn Moore" <shawn@heliumflash.com>;
"Atelier Fabien" <info@atelierfabien.be>
Sent: Monday, October 24, 2005 5:03 PM
Subject: Re: [PHP] php Slow with Mac OS X 10.4


> You certainly wouldn't want to do just fs_usage. Typing something like
> "fs_usage httpd" will show you just what the httpd process is accessing.
> Read the man pages for other options that may be helpful.
>
> I've got a few things running on OSX 10.4, although none that handle lots
> of traffic. Public sites:
> dutchessfootball.com - a football pool, the picks page is the slowest to
> load. That's on a single cpu 1.25 G4 512MB RAM
> heardthroughthegrapevine.com - wine tasting site, nothing fancy or that
> complicated. That's on a 400Mhz G4 384MB RAM.
>
> The big application is internal to my company and has about 285 "web"
> files total, and about 45 mysql tables (contacts, companies, resumes
> invoices, jobs, emails, journal,etc). They all have lots of includes
> since I use a custom templating system to separate php from html. I do
> not use PEAR or any content management system, I found them too slow. I
> know a few people who have looked at Mambo and rejected it because of
> it's CPU load, although they were all using Windows servers. I've never
> looked into why Mambo has high CPU requirements.
>
> Is it just the Mambo parts you are having problems with or is it php in
> general?
>
> With 100% CPU, we've narrowed it down to something there. Now we need to
> figure out why the CPU is the bottleneck.
>
> On Oct 24, 2005, at 4:21 PM, Nicolas Ross wrote:
>

[Back to original message]