Keith
|
| Posted: 09/01/2003, 12:47 PM |
|
I noticed that the code generated (PHP) for the crid component is slow and CPU intensive. I see that the apache httpd daemon (php compiled in) cpu utilization go way up when processing a grid. Why is this?
|
|
|
 |
RonB
|
| Posted: 09/02/2003, 12:59 AM |
|
I must say I havent had that trouble at any time. The code seems to run very fast on my company's intranet.
Slow running code can have many causes. Most of them have to do with server configuration, database configuration, network load, php configuration(if that's what you are using) Apache configuration etc etc.
What are the webserver specs? We use a pentium 4 2gig with 1 meg ram. That's running both the webserver and the MySQL database. We have about 400 people using the intranet everyday and no complaints about speed.
Ron
|
|
|
|
Keith
|
| Posted: 09/02/2003, 9:52 AM |
|
I am running Apache 1.27 PHP/4.3.2 on an UltraSparc II 200E w. 512MB of ram.
I am also running postgresql 7.3.4 on the same machine. The table only has 24 records and the grid is only displaying 10 columns. I don't know if its all the template processing but 1.5 seconds feels very slow and 21% cpu utilization is a bit high. Could it be template processing thats addding the overhead?
Are there any php tweaks I need to look at?
last pid: 15624; load averages: 0.42, 0.22, 0.13 13:12:01
35 processes: 34 sleeping, 1 on cpu
CPU states: 57.5% idle, 41.3% user, 1.2% kernel, 0.0% iowait, 0.0% swap
Memory: 512M real, 264M free, 8000K swap in use, 393M swap free
PID USERNAME THR PRI NICE SIZE RES STATE TIME CPU COMMAND
11089 nobody 3 20 0 24M 15M sleep 16:33 20.99% httpd
11091 nobody 3 58 0 25M 15M sleep 17:23 2.82% httpd
15611 postgres 1 48 0 1808K 1480K cpu 0:00 0.98% top-3.5b8-sun4u
21134 postgres 4 58 0 9104K 6384K sleep 0:10 0.16% postgres
19630 root 1 58 0 1664K 976K sleep 5:17 0.13% prngd
19704 postgres 4 58 0 7808K 4344K sleep 0:23 0.07% postgres
19706 postgres 4 59 0 7856K 2056K sleep 0:06 0.04% postgres
|
|
|
|
Headhunter
|
| Posted: 09/02/2003, 1:47 PM |
|
Did you create an index on the columns where you created joins (if they exist)?
I had the same problem. It was a matter of creating the right indexes on my table(s)
|
|
|
|
RonB
|
| Posted: 09/02/2003, 1:54 PM |
|
check the php.ini file (comments at beginning of the file explain some stuff about performance). I'm just wondering... do you get these times on average with all pages showing grids or just some of the pages?
Sometimes tweaking the queries helps more then tweaking php or apache. With the queries to the oracle database I've made it a habbit to extensively test and tweak the queries to maximum efficiency. I've had large queries reduce their time from 6 seconds to 1 just by rewriting the query. Also checking indexes etc on the database will improve performance (with 24 records that will not make a lot of difference though). I get pages with mysql that take arround 2 to 3 seconds but that's mostly when I'm having to do a lot of event code and when I'm combining data from mysql and oracle in 1 grid(especialy when using a view from oracle that uses a lot of union and subquery statements).
I'm constantly complaining about the lack of subquery and view support in the production version of mysql but I think mysql will get slower as well when these features are introduced.
Ron
|
|
|
|
Keith
|
| Posted: 09/02/2003, 2:02 PM |
|
|
|
|
|
Keith
|
| Posted: 09/02/2003, 2:03 PM |
|
There are no joins. The select statement simply selects all of the _24_ records without even a 'where' clause. Again even without indexing, this should be a breeze. Most of the CPU utilization is comming from the apache server. I have handwritten code in PHP for database use in the past but were pretty fast. Althoug h, I never used templates back then.
|
|
|
|
Keith
|
| Posted: 09/02/2003, 2:14 PM |
|
I am using Code Charge Studio 2.x BTW.
|
|
|
|
Ashiff
|
| Posted: 09/02/2003, 3:00 PM |
|
Now that you are blaming codecharge for no fault of theirs. Eventhough your server has 512 MB RAM, php.ini has initial setting of 30 seconds for timeout of script and 4MB of ram usage. change that to a higher value.
ULTRASPARC to display 24 records, I hope you know what you are doing.
|
|
|
|
Keith
|
| Posted: 09/04/2003, 12:22 AM |
|
Now that you are blaming codecharge for no fault of theirs. Eventhough your server has 512 MB RAM, php.ini has initial setting of 30 seconds for timeout of script and 4MB of ram usage. change that to a higher value.
ULTRASPARC to display 24 records, I hope you know what you are doing.
---
24 record table was used for testing. The real table has much more.
|
|
|
|
DaveRexel
|
| Posted: 09/04/2003, 1:51 PM |
|
Hello Keith,
Your process list does indicate high load at the initial loading of the the grid (httpd) and drops off when the other calls are made...
Would you care to run your tests using progressively larger pages 10 - 20 - 50 - 100 records using progressively larger amounts of returned data and post the results?
I suspect that the initial high load (20.99%) may stay relatively constant for different amounts of data due to all the CCS templates & classes being loaded.
Greetings
Dave
|
|
|
|
Keith
|
| Posted: 09/04/2003, 3:08 PM |
|
Dave,
I think the templates are probably adding the all the overheard. Is there a way to get php to cache all this. Does php parse and compile this code everytime the page is accessed? What can be doen to tweak PHP other than increase memory usage?
|
|
|
|
Keith
|
| Posted: 09/07/2003, 11:36 PM |
|
I noticed that the asp grid code for this site is fast. Could it be that IIS and asp is faster than PHP?
|
|
|
|
RonB
|
| Posted: 09/08/2003, 5:48 AM |
|
"Could it be that IIS and asp is faster than PHP?"
LOL ......No.
Ron
|
|
|
|
