Hi Ray,
I share my PHPA experience with you
On: www.vanhorne.nl
RedHat 7.2 (kernel 2.4.7-10)
PHP 4.1.2
Apache 1.3.22
MySql 3.23.41
Machine PIII - 1000 Mhz (Coppermine) with 1156 Mb RAM (512+512+128)
In php.ini , memory_limit = 32 M (16M was even too less after a while)
php-accelerator uses 8M Cache (standard)
Main goal for the machine is to provide Moodle and a Content Managing System called Typo3. Moodle has about 250 participants, and still growing.
The combination php <--> phpa worked very well for a while, then troubles begin ... a complete "hang " of the machine, no service was reachable remote nor local. It had to reset the machine 3 times.
Then I decide to disabled phpa in php.ini and now it runs without phpa for a few days. From things I read on the net, php4.1.2 doesn't seems to be a "reliable" choise.
"phpa - people" blaim php4.1.2 and not phpa ...
Still don't know what went wrong, can't find anything suspecious in log-files. I even have a Intrusion Detection System (Snort) running to better understand what is going on. Maybe it was an attack that "killed" the machine but no ...
I really miss the performance now, with phpa it was a lot faster ...
If I can find time I will try MMCache, another php accelerator.
I'm also testing Moodle on FreeBSD 5.x which will replace my "old" RedHat 7.2 , the only problem is the time ...
Yes, I hear what you say about PHP 4.1.2, most things are moving along quite nicely in debian testing but PHP does seem to a lagging seriously behind at the moment.
My server appears to have got it's PHPA cache memory together over the weekend (apache and mysql close themselves down each night bless them, I found it easier to handle the logs that way) Anyway phpa_cache_admin is now reporting sensible (but high) figures now. I reset the cache to 16M and it says 15.3M is allocated with the max allocation of 15.9M. All a bit worrying high?
The performance is still disaapointing. I was I looking for an improvement in the speed of the code. The server is not gets all that many hits. I was hoping that some of the pages would just speed up when running through lots of code. I guess PHPA doesn't do that. It just helps a server which is gets loads of hits.
My server appears to have got it's PHPA cache memory together over the weekend (apache and mysql close themselves down each night bless them, I found it easier to handle the logs that way) Anyway phpa_cache_admin is now reporting sensible (but high) figures now. I reset the cache to 16M and it says 15.3M is allocated with the max allocation of 15.9M. All a bit worrying high?
The performance is still disaapointing. I was I looking for an improvement in the speed of the code. The server is not gets all that many hits. I was hoping that some of the pages would just speed up when running through lots of code. I guess PHPA doesn't do that. It just helps a server which is gets loads of hits.
Actually, for me PHP does speed up pages significantly ... after the first time a page is run I was getting 6 to 10 times the speed.
Those memory sizes seem too large ... but I don't have any immediately helpful suggestions beyond what's already been discussed.
Try upgrading PHP 4.1.2, though ... that's YEARS old now ... 
I think Moodle 2.0 should split up each module lib.php into two files ... one with "central" functions and one with "local" functions. to help reduce the amount getting parsed by things like Recent Activity.
Those memory sizes seem too large ... but I don't have any immediately helpful suggestions beyond what's already been discussed.
I think Moodle 2.0 should split up each module lib.php into two files ... one with "central" functions and one with "local" functions. to help reduce the amount getting parsed by things like Recent Activity.
Yes, PHPA may well be a help in the right circumstances. My particular problem, I've now discovered, wasn't one them. 
I'm running the Exercise module with a big class (nearly 500 students) and the database now has about 5000 assessments and 2000 submissions. Some the teacher's pages were begining to creak. On my development machine one page was taking about 30 seconds to build and another about 50 seconds. (On the production server the pages were taking about a fifth of those times but it was begining to feel distinctly slow.) As I said earlier in this tread PHPA was not improving matters.
Then I looked at the actual processes on the server. What was using up 90% of the CPU during the building of these particular pages was MySQL. Ah, I had that problem before, adding an index or two was the answer then. And it was again.
Adding an index to the assessment table and another to the submission table got the times down from 30 seconds to 5 seconds and from 50 seconds down to 10 seconds. (Which translates on the production server to very quick and quick.) Now looking at the cpu usage of Apache and MySQL it's roughly equal with, if anything, Apache (that is PHP) needing the greater share.
With the database not hogging all the cpu (as it did without the extra indices) PHPA could well improve matters a bit. Although I would not expect too much of an effect (as the database will not be speeded up, just hit a bit harder)
One other thing I have found. When running PHP 4.3.3 and the matching PHPA both seem happy with 24M of memory. PHP itelf seems to want more than 16M. The PHPA cache reports about 12M of the 24M is used once Moodle has run through a few pages.
Ray
I'm running the Exercise module with a big class (nearly 500 students) and the database now has about 5000 assessments and 2000 submissions. Some the teacher's pages were begining to creak. On my development machine one page was taking about 30 seconds to build and another about 50 seconds. (On the production server the pages were taking about a fifth of those times but it was begining to feel distinctly slow.) As I said earlier in this tread PHPA was not improving matters.
Then I looked at the actual processes on the server. What was using up 90% of the CPU during the building of these particular pages was MySQL. Ah, I had that problem before, adding an index or two was the answer then. And it was again.
Adding an index to the assessment table and another to the submission table got the times down from 30 seconds to 5 seconds and from 50 seconds down to 10 seconds. (Which translates on the production server to very quick and quick.) Now looking at the cpu usage of Apache and MySQL it's roughly equal with, if anything, Apache (that is PHP) needing the greater share.
With the database not hogging all the cpu (as it did without the extra indices) PHPA could well improve matters a bit. Although I would not expect too much of an effect (as the database will not be speeded up, just hit a bit harder)
One other thing I have found. When running PHP 4.3.3 and the matching PHPA both seem happy with 24M of memory. PHP itelf seems to want more than 16M. The PHPA cache reports about 12M of the 24M is used once Moodle has run through a few pages.
Ray
In reply to Ray Kingdon
Re: php-accelerator experience - using MySQL 4.0.x improves performance
by David Delgado -
Just that: Moodle seems to start having perfomance problems with large installations just in 2 main areas: CPU usage and database access. To solve the CPU issue, you can use PHP Accelerator or Turck MMCache (wich seems to give similar results and less problems).
Anyway, as you can see, you still will have problems with database access. Than can be solved using latest version of MySQL 4.0.x (currently 4.0.16), wich is now stable and does have a good query cache that makes Moodle much faster. Adding indexes would help too, but you are hacking normal Moodle behaviour, and those kind of thing could be bad for the manteinance of your server (Moodle upgrades and so on). Perhaps it is not the case, when talking about indexes, but it is better not to take any risks on that.
Anyway, as you can see, you still will have problems with database access. Than can be solved using latest version of MySQL 4.0.x (currently 4.0.16), wich is now stable and does have a good query cache that makes Moodle much faster. Adding indexes would help too, but you are hacking normal Moodle behaviour, and those kind of thing could be bad for the manteinance of your server (Moodle upgrades and so on). Perhaps it is not the case, when talking about indexes, but it is better not to take any risks on that.
In reply to David Delgado
Re: php-accelerator experience - using MySQL 4.0.x improves performance
by Martin Dougiamas -
Ray is talking about indexes in his own module, so he can add them to the main source.
In reply to Martin Dougiamas
Re: php-accelerator experience - using MySQL 4.0.x improves performance
by David Delgado -
Sorry, I did not notice about that. We will be happy to get his improvements on the module in the main distribution.
In reply to Martin Dougiamas
Re: php-accelerator experience - using MySQL 4.0.x improves performance
by Ray Kingdon -
Martin, Yes, indeed. From what I've read about MySQL it seems it's better not to throw indexes into tables willy-nilly, i.e. don't over-index. Only use them to get real performance benefits. These, however, only show up when the tables get to real-world proportions so it's seems a bit like after-the-event "tinkering", but I think that's the recommended approach. 
Yes, I agree, a lot of the current indexes were added afterwards that way.
By the way, back to the increasing memory usage... I don't mean to point the finger but one gets an indication of the reason for this is starting to happen recently from looking at the lib.php sizes in kilobytes:
How about we separate lib.php into two files?
core.php - contains all the main functions needed by core services as well as any functions they depend on.
lib.php - contains all the other functions for the module
I could modify the core services to check for lib.php if core.php wasn't found, which should preserve backward compatibility while modules are converted (note that that all the module files will need to include both manually).
How does that sound?
By the way, back to the increasing memory usage... I don't mean to point the finger but one gets an indication of the reason for this is starting to happen recently from looking at the lib.php sizes in kilobytes:
> cd mod
> du -sk */lib.php | sort -nr
160 exercise/lib.php
148 workshop/lib.php
100 quiz/lib.php
84 forum/lib.php
56 glossary/lib.php
48 dialogue/lib.php
28 chat/lib.php
24 attendance/lib.php
20 journal/lib.php
20 assignment/lib.php
16 survey/lib.php
8 scorm/lib.php
8 resource/lib.php
8 choice/lib.php
4 label/lib.php
How about we separate lib.php into two files?
core.php - contains all the main functions needed by core services as well as any functions they depend on.
lib.php - contains all the other functions for the module
I could modify the core services to check for lib.php if core.php wasn't found, which should preserve backward compatibility while modules are converted (note that that all the module files will need to include both manually).
How does that sound?
Great idea. In my modules the lib.php files contain more lines of cores than all the other files put together. Anything that reduces the number of lines of code per file will make them easier to maintain as well. 
My own thoughts on a naming convention were lib.php for the "global" services and modlib.php for the extra internal routines needed by the module. That way the recent activity, grades... polling routines wouldn't need changing. But I'm happy with either way.
My own thoughts on a naming convention were lib.php for the "global" services and modlib.php for the extra internal routines needed by the module. That way the recent activity, grades... polling routines wouldn't need changing. But I'm happy with either way.
I was thinking about keeping lib.php as the core library, too, but couldn't really think of a name for the other one that I liked. I suppose it really doesn't matter since it's only for internal use by the module itself, but some standardardisation is good.
modlib.php (or libmod.php for nicer listing!) may cause a little confusion with mod.html I suppose (which actually works in concert with the core lib.php!) ... but I can't think of much better .... lib2.php ?
modlib.php (or libmod.php for nicer listing!) may cause a little confusion with mod.html I suppose (which actually works in concert with the core lib.php!) ... but I can't think of much better .... lib2.php ?
Howsabout locallib.php? That says what it and doesn't conflict with other names.
Good one - it's a deal.
locallib.php it is then. [shakes hands]
locallib.php it is then. [shakes hands]