[drupal-devel] TCPHP goes for Drupal
Last Saturday, May 21, Allie Micka[0] and I gave a presentation to the Twin Cities PHP users group (TCPHP [1]) about Drupal. We had about 20 people attend. There is now a dramatic increase in the interest in using Drupal, and we have a number of professionals recommending and implementing sites using Drupal. One consultant has a client that is going to implement 100 web sites using Drupal. These PHP developers and consultants who are new to Drupal are coming up with some concerns and questions that seem worth giving some visibility to among the Drupal developers -- you all. I've attempted to summarize some of those concerns below. 1. Memory usage. Drupal quickly exceeds the default 8MB memory limit for PHP when a few modules are installed. This is a problem with several solutions, and some work is already done. [2] 2. Clearing out settings and other data from modules that were once enabled and installed, but are no longer in use. Many of us know how to use SQL to directly manipulate the table data to fix this, but it might be nice to have this in the admin code. [3] 3. Improved support for load-balanced server farms and other large site load distribution technologies. There is already a patch to support replicated databases. [4][5] 4. Advocacy: As we were generating our slides and talks, we found existing information somewhat disparate. It would be great to have a forum or taxonomy where anybody could post existing presentations, training information and other "unofficial" advocacy resources. [0] http://www.tcphp.org/user/3 [1] TCPHP: http://www.tcphp.org/ [2] Memory usage thread: http://tinyurl.com/9yt89 [3] Clearing module settings: http://tinyurl.com/9rpyq [4] Drupal server farm: http://tinyurl.com/89nxg [5] Replication support: http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/crackerjm/ replication/ -- Chris Johnson
1. Memory usage. Drupal quickly exceeds the default 8MB memory limit for PHP when a few modules are installed. This is a problem with several solutions, and some work is already done. [2]
This is being take care of -- I have written split mode which dramatically drops the memory usage of Drupal. I need testers though. Contact me please. Regards NK
On 28 May 2005, at 01:39, Chris Johnson wrote:
1. Memory usage. Drupal quickly exceeds the default 8MB memory limit for PHP when a few modules are installed. This is a problem with several solutions, and some work is already done. [2]
I have been thinking about profiling Drupal's memory consumption. I'd like know where most memory is consumed. Is there an easy way to profile this?
3. Improved support for load-balanced server farms and other large site load distribution technologies. There is already a patch to support replicated databases. [4][5]
You should talk to David (redLed). He has a Drupal server farm of about 10 machines. He is not subscribed to the mailing-list but usually hangs around in #drupal at FreeNode.
4. Advocacy: As we were generating our slides and talks, we found existing information somewhat disparate. It would be great to have a forum or taxonomy where anybody could post existing presentations, training information and other "unofficial" advocacy resources.
Please add your presentation to the contributions repository (contributions/docs/marketing/presentations) and extend http:// drupal.org/node/13188. Help us grow the 'Marketing book' at drupal.org! Thanks for advocating Drupal, Chris. Looks like you've been very convincing. :) -- Dries Buytaert :: http://www.buytaert.net/
On Saturday 28 May 2005 01:43 am, Dries Buytaert wrote:
I have been thinking about profiling Drupal's memory consumption. I'd like know where most memory is consumed. Is there an easy way to profile this?
I used Xdebug 2.0 (beta) [1] and KCachegrind to profile the path aliasing patch a couple weeks back. Xdebug outputs a ' Callgrind Profile Format' file which can be read into programs like KCachegrind [2] or WinCacheGrind [3]. It allowed me to see memory usage and the time spent in functions. The memory footprint in HEAD is already smaller than 4.6 since we got rid of storing all aliases in a static variable. I ran a quick profile on a 4.6 site (with no aliases) and it seems the next place to focus on would be drupal_load() in terms on memory usage. http://www.asitis.org/tmp/drupal_load-memory.png And here's how time is spent inside that function: http://www.asitis.org/tmp/drupal_load-time.png I don't know if this is the best way to profile memory usage, but it seems to give us the information we're after. Matt [1] Xdebug: This site is slower than molasses. - http://xdebug.org/ [2] KCachegrind - http://kcachegrind.sourceforge.net/cgi-bin/show.cgi/ [3] WinCacheGrind - http://dev.gauldong.net/mambo/content/view/25/52/
On 28 May 2005, at 17:46, Matt Westgate wrote:
I have been thinking about profiling Drupal's memory consumption. I'd like know where most memory is consumed. Is there an easy way to profile this?
I used Xdebug 2.0 (beta) [1] and KCachegrind to profile the path aliasing patch a couple weeks back. Xdebug outputs a ' Callgrind Profile Format' file which can be read into programs like KCachegrind [2] or WinCacheGrind [3]. It allowed me to see memory usage and the time spent in functions. The memory footprint in HEAD is already smaller than 4.6 since we got rid of storing all aliases in a static variable.
I ran a quick profile on a 4.6 site (with no aliases) and it seems the next place to focus on would be drupal_load() in terms on memory usage.
How do I interpret that? 16.22% of all memory is allocated in drupal_load()? -- Dries Buytaert :: http://www.buytaert.net/
On Wednesday 01 June 2005 02:13 am, Dries Buytaert wrote:
How do I interpret that? 16.22% of all memory is allocated in drupal_load()?
Since that screenshot is sorted by the 'Self' column, it means 'the amount of memory taken by a function', so drupal_load() uses 16.22%. Looking at that chart again it would have been more meaningful to sort by the 'Incl.' column which means 'the amount of memory of the overall lifecycle'. Then we can see that call_user_func_array(), node_page() and node_page_default() need to be analyzed instead and drupal_load() really doesn't seem to be a bottleneck. Of course I can't lay any claims to being an xdebug/kcachegrind expert and xdebug 2.0 beta may still be buggy. Matt
On 01 Jun 2005, at 15:56, Matt Westgate wrote:
On Wednesday 01 June 2005 02:13 am, Dries Buytaert wrote:
How do I interpret that? 16.22% of all memory is allocated in drupal_load()?
Looking at that chart again it would have been more meaningful to sort by the 'Incl.' column which means 'the amount of memory of the overall lifecycle'. Then we can see that call_user_func_array(), node_page() and node_page_default() need to be analyzed instead and drupal_load() really doesn't seem to be a bottleneck.
Of course I can't lay any claims to being an xdebug/kcachegrind expert and xdebug 2.0 beta may still be buggy.
Can you compile a prioritized list (or screenshot) of memory-hungry functions? When you say node_page_default() allocates a lot of memory; is that inclusive or exclusive the methods called from within node_page_default()? I'm asking because node_page_default() doesn't seem to do any caching. -- Dries Buytaert :: http://www.buytaert.net/
participants (4)
-
Chris Johnson -
Dries Buytaert -
Karoly Negyesi -
Matt Westgate