Just wondering if anyone else is experiencing this: On localhost, the front page of Moodle 2.0 loads at around 3 seconds, but when I enable the debugging session via Netbeans, it takes 30-40 seconds. I'm sure it was never this slow before, but can't pin down a cause.
I develop 2.0 on NB 6.9 in a LAMP environment. I've used both FF 3.6 and Opera. In any case, I don't have that problem.
If I were you, I'd try a different browser first, since that's the easiest to rule out. Then try either rolling back NB or setting breakpoints and stepping through.
Ok. Finally fixed.
I'm ashamed to say that after having probably spent 8-10 hours in total messing about with every setting after the sun, it turned out to be PHP's memory limit being too low. Upping it to 512M from 100M made page loads with xdebug enabled go from 49 seconds to 6.
- Don't assume that PHP out of memory problems will show up in OSX activity monitor as swap usage, or in the php error log. Xdebug seems to manage its own memory and doesn't complain when it has too little.
- Try the simple stuff first
Can you add how you upped the memory limit of php?
I don't have problems debugging (yet), using Eclipse and xdebug, but when running the maven php-plugin reports I run out of memory somewhere (it's not really clear where yet).
So maybe your settings change may help.
Find the php.ini file (in /etc on linux, or a variety of places on windows depending on how you installed PHP) and then find the line with memory_limit = 100M and alter it to whatever you need.
Remember to restart apache for the changes to take effect.
Thanks for the hint. Do you have any experience whether this will speed up NetBeans in general?
And have you tried the integrated Git support of NetBeans 7?
I'm not sure about NetBeans in general, as it doesn't deal directly with PHP except through Xdebug, so I don't think that setting will speed up anything apart from the page loads.
RAM, on the other hand, is a different matter. I've noticed that with a full Moodle 2.0 open as a project, my NetBeans (7.0) on OSX can happily eat around 1GB of memory and often grows to 1.5, so I've had to up the memory of my laptop from 2GB (very slow, lots of swap used) to 8GB and it's now a lot faster.
With no real effort to do anything special apart from development with NetBeans and Firefox, the system seems to settle at 4.5-5GB after a few hours, so I think even 4GB may be too little to get best performance.
As for the Git integration, I've not tried it as it didn't seem ready for primetime, but I've been following it here. Looks like it's testable now, at least for some features, so I'll give it a go. Have you used it yourself?
Many thanks for your thorough reply, especially regarding RAM!
And no, I haven't tried the Git feature yet. I'm still struggling to wrap my mind around the very concepts of Git so I'm content with pulling my Moodle from CVS
As a follow up - I though this problem had come back, but fixed it again by:
- Turning off theme designer mode
- Changing the docroot specified in httpd.conf so that it had no trailing slash.
Both had a significant effect and together got the front page load from 40s down to 12s when xdebug is enabled.
Also, change to .dev instead of .localhost for local urls. .local and .localhost seem to be treated oddly by Lion. Adding ipv6 hosts entries has helped too.
I couldn't understand why xdebug was suddenly slow. It was working fine.
But your theme designer mode jogged my memory. I had been doing some code checking and had set this in config.php
$CFG->themedesignermode = true
So now have
$CFG->themedesignermode = false; // When on, xdebug is really slow
Fixed the problem - cheers!
Thanks for the info Matt. Also I know what you mean about the time wasting on this issue, I've experienced a great deal myself. I guess I'll have to leave Xdebug switched off till I can buy more RAM. I tried switching some over from another machine but it ended up being the wrong type.
Thanks heaps for the info regarding the problem though.
I spend about 2 hours configuring opcache, php memory and a lot of other things just to find out that the virus scanner was slowing down the data transfer on port 9000 that is used by Netbeans. Maybe RAM is not the problem after all.