Development
Threads by month
- ----- 2026 -----
- June
- May
- April
- March
- February
- January
- ----- 2025 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2024 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2023 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2022 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2021 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2020 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2019 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2018 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2017 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2016 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2015 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2014 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2013 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2012 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2011 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2010 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2009 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2008 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2007 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2006 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2005 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
May 2005
- 81 participants
- 503 discussions
Issue status update for http://drupal.org/node/22035
Project: Drupal
Version: cvs
Component: base system
Category: tasks
Priority: normal
Assigned to: Anonymous
Reported by: mikeryan
Updated by: Dries
Status: patch
Before this patch can be committed, we need to do more testing. I'd
like to know how this behaves on sites with few or no path aliases, and
on sites like drupal.org, with a modest amount of path aliases.
The reason I'm asking is because MySQL is often the bottleneck and not
PHP/Apache. This is the case on drupal.org, for example. The proposed
patch moves some of the processing costs from PHP to MySQL. On
drupal.org, the amount of SQL queries/page would double. Needless to
say, this is somewhat scary. ;)
More numbers would be appreciated.
Dries
Previous comments:
------------------------------------------------------------------------
May 5, 2005 - 03:10 : mikeryan
See Investigate use of conf_url_rewrite [1] for context...
The current core support for translating incoming path aliases to the
internal Drupal path (drupal_get_path_alias) and substituting aliases
when generating links to internal paths (drupal_get_normal_path) does
not scale well with many aliases. The ease with which pathauto enables
site administrators to generate large numbers of aliases exposes this
issue, but it is inherent in the core implementation, because
drupal_get_path_map reads in the entire url_alias table at bootstrap
time. I'd like to discuss ideas on how to improve the performance...
Most obviously, why not simply query the url_alias table as needed
instead of loading the whole table? In the incoming case, only a single
simple SELECT is necessary, which will always be more efficient than
reading the table. In the outgoing case, there might be some slight
performance advantage to caching the table with a small number of
aliases, but the disadvantage can become huge as the alias table grows.
One note - I've noticed that the src column in url_alias is not
indexed, I think adding an index should significantly help the
performance in the outgoing case if we were to do individual SELECTs.
Any other thoughts?
[1] http://drupal.org/node/21938
------------------------------------------------------------------------
May 5, 2005 - 04:02 : mikeryan
Attachment: http://drupal.org/files/issues/bootstrap.inc_2.patch (1.06 KB)
What the hell, I went ahead and gave it a shot... On my home system,
where I'm testing out 4.6.0, page loads have been taking several
seconds, which I attributed to the fact that it's an old computer and
I'm multi-tasking like crazy. I implemented my own suggestion, and now
pages load in about one second, it makes an incredible difference
(FWIW, my url_alias table has over 4000 rows).
Patches attached, go give it a try...
------------------------------------------------------------------------
May 5, 2005 - 04:02 : mikeryan
Attachment: http://drupal.org/files/issues/common.inc_11.patch (723 bytes)
One attachment per note, that's tedious...
------------------------------------------------------------------------
May 5, 2005 - 04:03 : mikeryan
Attachment: http://drupal.org/files/issues/path.module_0.patch (1.34 KB)
------------------------------------------------------------------------
May 5, 2005 - 04:03 : mikeryan
Attachment: http://drupal.org/files/issues/database.mysql_4.patch (553 bytes)
------------------------------------------------------------------------
May 5, 2005 - 04:04 : mikeryan
Attachment: http://drupal.org/files/issues/database.pgsql_2.patch (502 bytes)
------------------------------------------------------------------------
May 5, 2005 - 04:07 : mikeryan
Note: I just noticed that the database.*sql patches showed an extra diff
(not mine) to the location field in locales_source. I did my diffs
against a freshly-updated DRUPAL-4-6, and had made the edits against a
release from a few days ago... Those locales_source changes should
probably be removed from my patches before applying.
------------------------------------------------------------------------
May 8, 2005 - 01:13 : mikeryan
I upgraded Fenway Views [2] to Drupal 4.6.0 today, incorporating these
patches. Performance is very noticeably improved.
[2] http://fenway-views.com/
------------------------------------------------------------------------
May 8, 2005 - 15:31 : killes(a)www.drop.org
Attachment: http://drupal.org/files/issues/pathalias.patch (4.98 KB)
I've merged the patch into one. Much more convenient. I also changed it
to cvs as only there new features will be added.
Upgrade path needs to be added.
Mike, can you run some more tests? We are especially interested in
"hard" data ie numbers with possibly error bars. it would be
interesting to know how this patch affects sites that have only a few
path aliases vs those with a lot of them. Also, how pages with a lot of
node links (tracker) are affected.
It might be worthwhile to add static caching in drupal_get_normal_path
if it gets calle dmore than once for a link on one page view.
------------------------------------------------------------------------
May 8, 2005 - 19:21 : mikeryan
Thanks for merging the patches, I wasn't aware you could patch multiple
files at once. If this is accepted, of course, adding the index on src
should be incorporated into updates.inc.
In terms of hard data, I've never profiled PHP code - what tool(s) do
you use? I couldn't find anything referenced in the PHP manual...
re: pages with lots of links - on Fenway Views the big test is the
calendar [3], and the performance improvement seems even more dramatic
here. I don't know why - the url_alias table is read once per page, so
I would expect as you do that preloading the table would tend to look
better when you have a hundred internal links on the page. Maybe we're
both underestimating exactly how fast a simple MySQL query on an
indexed key can be (I'm using MySQL 4.0.20, BTW)...
[3] http://fenway-views.com/calendar
------------------------------------------------------------------------
May 8, 2005 - 19:26 : killes(a)www.drop.org
As we speak, Mathias is doing some tests. The tool of choice is usually
apache bench. If you have a lot of url aliases, the generated array
will be huge. Part of the improvement could be due to the fact that you
need less memory now.
------------------------------------------------------------------------
May 8, 2005 - 19:28 : mikeryan
Great, thanks!
------------------------------------------------------------------------
May 8, 2005 - 19:34 : Dries
On drupal.org it takes 800 ms or more to generate a page. Of these 800
ms, only 4 ms is spent building the path alias map (incl. the SQL query
time which takes about 1 ms). That is, building the map takes 0.5% of
the total time which is neglible. In our url_alias table are only 321
aliases though. How many aliases do you have?
What is more, when we build drupal.org's main page, we query this map
215 times. I believe your patch would introduce 215 SQL queries ...
I'm afraid that if we'd apply your patch, we'd pay a serious
performance penalty (unless we have many more aliases).
Can you provide some numbers/measurements?
------------------------------------------------------------------------
May 8, 2005 - 19:37 : Dries
Note: my measurements did not take into account the time spent searching
the map. On the main page, we search this array 215 times.
------------------------------------------------------------------------
May 8, 2005 - 20:08 : puregin
I believe that it's felt that adding path aliases would improve the
Drupal documentation. This may well add 400+ paths to the URL aliases
table on Drupal.org
------------------------------------------------------------------------
May 8, 2005 - 20:27 : Dries
I spent some more time investigating this.
The relevant code in bootstrap.inc is this:
function drupal_get_path_alias($path) {
if (($map = drupal_get_path_map()) && ($newpath = array_search($path,
$map))) {
return $newpath;
}
...
Turns out that the time to build the map is neglible (< 5ms, see
previous comments), however the total time spent on 'path aliasing' it
about 70ms per page! 50ms of these 70ms are spent on $map =
drupal_get_path_map(). The remaining 20ms is spent on $newpath =
array_search($path, $map).
The first call to drupal_get_path_map() takes 3 to 5 ms, each
subsequent call takes about 0.3 ms. Searching the array costs 0.1 ms.
However, if you have to do this 130+ times, this adds up to a whopping
70 ms. Remind that we have 321 aliases in our map.
As drupal_get_path_alias() is typically called from code>url(), which
in turn is typically called from l() I set out to investigate the time
spent in l(). Looks like l() easily gets called 120 times/page, and
that each call to l() costs about 0.9 ms. That is about 2 or 3 times
the cost of the /average SQL query/. The total time spent in l() is
115 ms!
------------------------------------------------------------------------
May 9, 2005 - 00:25 : adrian
This is a complete aside, and probably off-topic, but I would like to
mention that I was actually
looking at rewriting url() to be able to handle 'external urls' ,
because I want to do aliases using the site subdomain, like for
instance :
http://category.sitename.com/article/title_goes_here -> node/23
Rewriting url to allow this would also allow us to use l() for external
links of any kind, getting rid of a bunch of inline html.
------------------------------------------------------------------------
May 9, 2005 - 00:46 : chx
adrian, I have written a patch for l to support external links but Ber
said that a module like weblink shall handle those.
------------------------------------------------------------------------
May 9, 2005 - 01:03 : mikeryan
I've got over 4000 aliases on Fenway Views - another pathauto user
reported over 6000.
I don't have a profiling tool to give timing data, but adding a quick
counter shows that for the Fenway Views calendar [4],
drupal_get_path_alias() is called 404 times and drupal_get_normal_path
is called 227 times. And trust me, this page loads MUCH faster with my
patch than it does with the path map.
I think those SQL queries are a lot cheaper than one might expect...
[4] http://fenway-views.com/calendar
------------------------------------------------------------------------
May 9, 2005 - 06:24 : mathias
Attachment: http://drupal.org/files/issues/pathalias-with-caching.patch (5.62 KB)
Some benchmarks, with MySQL and Drupal caching disabled.
2 SETS OF TESTS
=======================================
1) 500 nodes and aliases
2) 20,000 nodes and aliases
3 TYPES OF TESTS PER SET
=======================================
1) Baseline unmodified Drupal
2) The following change inside drupal_get_path_map():
- if (is_null($map)) {
+ if ($map === NULL) {
$map = array(); // Make $map non-null in case no aliases
are defined.
3) Pull aliases only when needed rather than loading the entire alias
table.
SET 1 - 500 Nodes and 500 Aliases
using: ab -c 10 -n 100 [homepage]
=======================================
Baseline
Time taken for tests: 13.00 seconds
Requests per second: 3.85 [#/sec] (mean)
Transfer rate: 56.35 [Kbytes/sec] received
is_null() VS NULL
Time taken for tests: 12.463 seconds
Requests per second: 4.01 [#/sec] (mean)
Transfer rate: 57.63 [Kbytes/sec] received
Per Instance Alias Lookup (32 additional queries)
Time taken for tests: 11.502 seconds
Requests per second: 4.35 [#/sec] (mean)
Transfer rate: 63.30 [Kbytes/sec] received
SET 2 - 20,000 Nodes and 20,000 Aliases
using: ab -c 5 -n 50 [homepage]
=======================================
Baseline
Time taken for tests: 204.583 seconds
Requests per second: 0.24 [#/sec] (mean)
Transfer rate: 3.34 [Kbytes/sec] received
is_null() VS NULL
Time taken for tests: 127.629 seconds
Requests per second: 0.39 [#/sec] (mean)
Transfer rate: 5.35 [Kbytes/sec] received
Per Instance Alias Lookup (32 additional queries)
Time taken for tests: 28.788 seconds
Requests per second: 1.74 [#/sec] (mean)
Transfer rate: 23.59 [Kbytes/sec] received
ANALYSIS
=======================================
Converting 'is_null()' to '=== NULL' is a no brainer and results in a
nice performance gain. And while per instance alias lookups also give a
huge boost for site with thousands of aliases, they're benefits are
entirely dependent on the number of system URLs and menu items visible
per request. As noted above I tested the standard homepage which added
32 additional queries. A request for something like the admin interface
would presumably show less benefits. I would've tested this, but I
didn't know how to invoke an authenticated page request with 'ab'. A
positive of this approach is we no longer would be storing all the
aliases in memory.
What other concerns do we have with this last approach? Am I properly
testing the strain on the database?
------------------------------------------------------------------------
May 9, 2005 - 07:08 : Dries
Can you try making the following changes?
1. To common.inc:
function drupal_rebuild_path_map() {
- drupal_get_path_map('rebuild');
+ drupal_get_path_map(TRUE);
}
2. To bootstrap.inc:
-function drupal_get_path_map($action = '') {
+function drupal_get_path_map($rebuild = FALSE) {
static $map = NULL;
- if ($action == 'rebuild') {
+ if ($rebuild) {
$map = NULL;
}
That is, replace the string comparison with a boolean comparison. Not
sure it is going to make a significant difference but it might be
another micro-improvement.
I'll test your patch shortly.
------------------------------------------------------------------------
May 9, 2005 - 14:21 : mathias
Dries. Those changes had no real performance gain.
20,000 Nodes and 20,000 Aliases
using: ab -c 5 -n 50 [homepage]
=======================================
Baseline
Time taken for tests: 204.583 seconds
Requests per second: 0.24 [#/sec] (mean)
Transfer rate: 3.34 [Kbytes/sec] received
String VS Boolean
Time taken for tests: 204.190 seconds
Requests per second: 0.24 [#/sec] (mean)
Transfer rate: 3.34 [Kbytes/sec] received
1
0
Issue status update for http://drupal.org/node/22035
Project: Drupal
Version: cvs
Component: base system
Category: tasks
Priority: normal
Assigned to: Anonymous
Reported by: mikeryan
Updated by: mathias
Status: patch
Dries. Those changes had no real performance gain.
20,000 Nodes and 20,000 Aliases
using: ab -c 5 -n 50 [homepage]
=======================================
Baseline
Time taken for tests: 204.583 seconds
Requests per second: 0.24 [#/sec] (mean)
Transfer rate: 3.34 [Kbytes/sec] received
String VS Boolean
Time taken for tests: 204.190 seconds
Requests per second: 0.24 [#/sec] (mean)
Transfer rate: 3.34 [Kbytes/sec] received
mathias
Previous comments:
------------------------------------------------------------------------
May 4, 2005 - 19:10 : mikeryan
See Investigate use of conf_url_rewrite [1] for context...
The current core support for translating incoming path aliases to the
internal Drupal path (drupal_get_path_alias) and substituting aliases
when generating links to internal paths (drupal_get_normal_path) does
not scale well with many aliases. The ease with which pathauto enables
site administrators to generate large numbers of aliases exposes this
issue, but it is inherent in the core implementation, because
drupal_get_path_map reads in the entire url_alias table at bootstrap
time. I'd like to discuss ideas on how to improve the performance...
Most obviously, why not simply query the url_alias table as needed
instead of loading the whole table? In the incoming case, only a single
simple SELECT is necessary, which will always be more efficient than
reading the table. In the outgoing case, there might be some slight
performance advantage to caching the table with a small number of
aliases, but the disadvantage can become huge as the alias table grows.
One note - I've noticed that the src column in url_alias is not
indexed, I think adding an index should significantly help the
performance in the outgoing case if we were to do individual SELECTs.
Any other thoughts?
[1] http://drupal.org/node/21938
------------------------------------------------------------------------
May 4, 2005 - 20:02 : mikeryan
Attachment: http://drupal.org/files/issues/bootstrap.inc_2.patch (1.06 KB)
What the hell, I went ahead and gave it a shot... On my home system,
where I'm testing out 4.6.0, page loads have been taking several
seconds, which I attributed to the fact that it's an old computer and
I'm multi-tasking like crazy. I implemented my own suggestion, and now
pages load in about one second, it makes an incredible difference
(FWIW, my url_alias table has over 4000 rows).
Patches attached, go give it a try...
------------------------------------------------------------------------
May 4, 2005 - 20:02 : mikeryan
Attachment: http://drupal.org/files/issues/common.inc_11.patch (723 bytes)
One attachment per note, that's tedious...
------------------------------------------------------------------------
May 4, 2005 - 20:03 : mikeryan
Attachment: http://drupal.org/files/issues/path.module_0.patch (1.34 KB)
------------------------------------------------------------------------
May 4, 2005 - 20:03 : mikeryan
Attachment: http://drupal.org/files/issues/database.mysql_4.patch (553 bytes)
------------------------------------------------------------------------
May 4, 2005 - 20:04 : mikeryan
Attachment: http://drupal.org/files/issues/database.pgsql_2.patch (502 bytes)
------------------------------------------------------------------------
May 4, 2005 - 20:07 : mikeryan
Note: I just noticed that the database.*sql patches showed an extra diff
(not mine) to the location field in locales_source. I did my diffs
against a freshly-updated DRUPAL-4-6, and had made the edits against a
release from a few days ago... Those locales_source changes should
probably be removed from my patches before applying.
------------------------------------------------------------------------
May 7, 2005 - 17:13 : mikeryan
I upgraded Fenway Views [2] to Drupal 4.6.0 today, incorporating these
patches. Performance is very noticeably improved.
[2] http://fenway-views.com/
------------------------------------------------------------------------
May 8, 2005 - 07:31 : killes(a)www.drop.org
Attachment: http://drupal.org/files/issues/pathalias.patch (4.98 KB)
I've merged the patch into one. Much more convenient. I also changed it
to cvs as only there new features will be added.
Upgrade path needs to be added.
Mike, can you run some more tests? We are especially interested in
"hard" data ie numbers with possibly error bars. it would be
interesting to know how this patch affects sites that have only a few
path aliases vs those with a lot of them. Also, how pages with a lot of
node links (tracker) are affected.
It might be worthwhile to add static caching in drupal_get_normal_path
if it gets calle dmore than once for a link on one page view.
------------------------------------------------------------------------
May 8, 2005 - 11:21 : mikeryan
Thanks for merging the patches, I wasn't aware you could patch multiple
files at once. If this is accepted, of course, adding the index on src
should be incorporated into updates.inc.
In terms of hard data, I've never profiled PHP code - what tool(s) do
you use? I couldn't find anything referenced in the PHP manual...
re: pages with lots of links - on Fenway Views the big test is the
calendar [3], and the performance improvement seems even more dramatic
here. I don't know why - the url_alias table is read once per page, so
I would expect as you do that preloading the table would tend to look
better when you have a hundred internal links on the page. Maybe we're
both underestimating exactly how fast a simple MySQL query on an
indexed key can be (I'm using MySQL 4.0.20, BTW)...
[3] http://fenway-views.com/calendar
------------------------------------------------------------------------
May 8, 2005 - 11:26 : killes(a)www.drop.org
As we speak, Mathias is doing some tests. The tool of choice is usually
apache bench. If you have a lot of url aliases, the generated array
will be huge. Part of the improvement could be due to the fact that you
need less memory now.
------------------------------------------------------------------------
May 8, 2005 - 11:28 : mikeryan
Great, thanks!
------------------------------------------------------------------------
May 8, 2005 - 11:34 : Dries
On drupal.org it takes 800 ms or more to generate a page. Of these 800
ms, only 4 ms is spent building the path alias map (incl. the SQL query
time which takes about 1 ms). That is, building the map takes 0.5% of
the total time which is neglible. In our url_alias table are only 321
aliases though. How many aliases do you have?
What is more, when we build drupal.org's main page, we query this map
215 times. I believe your patch would introduce 215 SQL queries ...
I'm afraid that if we'd apply your patch, we'd pay a serious
performance penalty (unless we have many more aliases).
Can you provide some numbers/measurements?
------------------------------------------------------------------------
May 8, 2005 - 11:37 : Dries
Note: my measurements did not take into account the time spent searching
the map. On the main page, we search this array 215 times.
------------------------------------------------------------------------
May 8, 2005 - 12:08 : puregin
I believe that it's felt that adding path aliases would improve the
Drupal documentation. This may well add 400+ paths to the URL aliases
table on Drupal.org
------------------------------------------------------------------------
May 8, 2005 - 12:27 : Dries
I spent some more time investigating this.
The relevant code in bootstrap.inc is this:
function drupal_get_path_alias($path) {
if (($map = drupal_get_path_map()) && ($newpath = array_search($path,
$map))) {
return $newpath;
}
...
Turns out that the time to build the map is neglible (< 5ms, see
previous comments), however the total time spent on 'path aliasing' it
about 70ms per page! 50ms of these 70ms are spent on $map =
drupal_get_path_map(). The remaining 20ms is spent on $newpath =
array_search($path, $map).
The first call to drupal_get_path_map() takes 3 to 5 ms, each
subsequent call takes about 0.3 ms. Searching the array costs 0.1 ms.
However, if you have to do this 130+ times, this adds up to a whopping
70 ms. Remind that we have 321 aliases in our map.
As drupal_get_path_alias() is typically called from code>url(), which
in turn is typically called from l() I set out to investigate the time
spent in l(). Looks like l() easily gets called 120 times/page, and
that each call to l() costs about 0.9 ms. That is about 2 or 3 times
the cost of the /average SQL query/. The total time spent in l() is
115 ms!
------------------------------------------------------------------------
May 8, 2005 - 16:25 : adrian
This is a complete aside, and probably off-topic, but I would like to
mention that I was actually
looking at rewriting url() to be able to handle 'external urls' ,
because I want to do aliases using the site subdomain, like for
instance :
http://category.sitename.com/article/title_goes_here -> node/23
Rewriting url to allow this would also allow us to use l() for external
links of any kind, getting rid of a bunch of inline html.
------------------------------------------------------------------------
May 8, 2005 - 16:46 : chx
adrian, I have written a patch for l to support external links but Ber
said that a module like weblink shall handle those.
------------------------------------------------------------------------
May 8, 2005 - 17:03 : mikeryan
I've got over 4000 aliases on Fenway Views - another pathauto user
reported over 6000.
I don't have a profiling tool to give timing data, but adding a quick
counter shows that for the Fenway Views calendar [4],
drupal_get_path_alias() is called 404 times and drupal_get_normal_path
is called 227 times. And trust me, this page loads MUCH faster with my
patch than it does with the path map.
I think those SQL queries are a lot cheaper than one might expect...
[4] http://fenway-views.com/calendar
------------------------------------------------------------------------
May 8, 2005 - 22:24 : mathias
Attachment: http://drupal.org/files/issues/pathalias-with-caching.patch (5.62 KB)
Some benchmarks, with MySQL and Drupal caching disabled.
2 SETS OF TESTS
=======================================
1) 500 nodes and aliases
2) 20,000 nodes and aliases
3 TYPES OF TESTS PER SET
=======================================
1) Baseline unmodified Drupal
2) The following change inside drupal_get_path_map():
- if (is_null($map)) {
+ if ($map === NULL) {
$map = array(); // Make $map non-null in case no aliases
are defined.
3) Pull aliases only when needed rather than loading the entire alias
table.
SET 1 - 500 Nodes and 500 Aliases
using: ab -c 10 -n 100 [homepage]
=======================================
Baseline
Time taken for tests: 13.00 seconds
Requests per second: 3.85 [#/sec] (mean)
Transfer rate: 56.35 [Kbytes/sec] received
is_null() VS NULL
Time taken for tests: 12.463 seconds
Requests per second: 4.01 [#/sec] (mean)
Transfer rate: 57.63 [Kbytes/sec] received
Per Instance Alias Lookup (32 additional queries)
Time taken for tests: 11.502 seconds
Requests per second: 4.35 [#/sec] (mean)
Transfer rate: 63.30 [Kbytes/sec] received
SET 2 - 20,000 Nodes and 20,000 Aliases
using: ab -c 5 -n 50 [homepage]
=======================================
Baseline
Time taken for tests: 204.583 seconds
Requests per second: 0.24 [#/sec] (mean)
Transfer rate: 3.34 [Kbytes/sec] received
is_null() VS NULL
Time taken for tests: 127.629 seconds
Requests per second: 0.39 [#/sec] (mean)
Transfer rate: 5.35 [Kbytes/sec] received
Per Instance Alias Lookup (32 additional queries)
Time taken for tests: 28.788 seconds
Requests per second: 1.74 [#/sec] (mean)
Transfer rate: 23.59 [Kbytes/sec] received
ANALYSIS
=======================================
Converting 'is_null()' to '=== NULL' is a no brainer and results in a
nice performance gain. And while per instance alias lookups also give a
huge boost for site with thousands of aliases, they're benefits are
entirely dependent on the number of system URLs and menu items visible
per request. As noted above I tested the standard homepage which added
32 additional queries. A request for something like the admin interface
would presumably show less benefits. I would've tested this, but I
didn't know how to invoke an authenticated page request with 'ab'. A
positive of this approach is we no longer would be storing all the
aliases in memory.
What other concerns do we have with this last approach? Am I properly
testing the strain on the database?
------------------------------------------------------------------------
May 8, 2005 - 23:08 : Dries
Can you try making the following changes?
1. To common.inc:
function drupal_rebuild_path_map() {
- drupal_get_path_map('rebuild');
+ drupal_get_path_map(TRUE);
}
2. To bootstrap.inc:
-function drupal_get_path_map($action = '') {
+function drupal_get_path_map($rebuild = FALSE) {
static $map = NULL;
- if ($action == 'rebuild') {
+ if ($rebuild) {
$map = NULL;
}
That is, replace the string comparison with a boolean comparison. Not
sure it is going to make a significant difference but it might be
another micro-improvement.
I'll test your patch shortly.
1
0
Re: [drupal-devel] [drupal:dries] /database database.mysql database.pgsql
by Stefan Nagtegaal 09 May '05
by Stefan Nagtegaal 09 May '05
09 May '05
Op 8-mei-2005, om 21:11 heeft drupal-devel(a)drupal.org het volgende
geschreven:
> User: dries Branch: HEAD Date: Sun, 08 May 2005 19:11:31 +0000
>
> Modified files:
> /database database.mysql database.pgsql
>
> Log message:
> - Patch #22319 by Ber: updated default database schems not to use
> Xtemplate any more.
>
> Links:
> http://cvs.drupal.org/diff.php?path=drupal/database/
> database.mysql&old=1.184&new=1.185
> http://cvs.drupal.org/diff.php?path=drupal/database/
> database.pgsql&old=1.121&new=1.122
>
> --
> [ Drupal cvs list | http://list.drupal.org/ ]
Shouldn't the code in the database files be consistent either? So,
instead of:
<code>
-INSERT INTO system VALUES ('themes/bluemarine/
xtemplate.xtmpl','bluemarine','theme','themes/engines/xtemplate/
xtemplate.engine',1,0,0);
-INSERT INTO system VALUES ('themes/engines/xtemplate/
xtemplate.engine','xtemplate','theme_engine','',1,0,0);
+INSERT INTO `system` VALUES ('themes/engines/phptemplate/
phptemplate.engine', 'phptemplate', 'theme_engine', '', 1, 0, 0);
+INSERT INTO `system` VALUES ('themes/bluemarine/page.tpl.php',
'bluemarine', 'theme', 'themes/engines/phptemplate/
phptemplate.engine', 1, 0, 0);
</code>
we should do:
<code>
-INSERT INTO system VALUES ('themes/bluemarine/
xtemplate.xtmpl','bluemarine','theme','themes/engines/xtemplate/
xtemplate.engine',1,0,0);
-INSERT INTO system VALUES ('themes/engines/xtemplate/
xtemplate.engine','xtemplate','theme_engine','',1,0,0);
+INSERT INTO system VALUES ('themes/engines/phptemplate/
phptemplate.engine', 'phptemplate', 'theme_engine', '', 1, 0, 0);
+INSERT INTO system VALUES ('themes/bluemarine/page.tpl.php',
'bluemarine', 'theme', 'themes/engines/phptemplate/
phptemplate.engine', 1, 0, 0);
</code>
Thoughts??? (Notice the backquotes, used in the applied patch)
---
Stefan Nagtegaal
http://www.istyledthis.nl/
1
0
09 May '05
On May 9, 2005, at 6:48 AM, jasonwhat wrote:
>
> http://drupal.org/node/21940#comment-38421 In this post I talk
> about some of the various modules out there that let users create
> data about themselves, data on other users, and relationships.
> What seems clear to me is there is development going on in CS and
> Drupal and Civicgroups of several similar user managemnt and
> organanization tools.
> I brought this issue up here http://civicspacelabs.org/home/node/
> 12285 and realize that maybe the CivicCRM is the to omnipotent api
> that will unify all several modules. If I'm correct, the CivicCRM
> won't just have it's own data fields, like the current contact
> module in CS, but will share with modules like profile once they
> are updated to work with it.
>
Actually you don't want to normalize on CivCRM. Thanks for opening
that giant can of worms ;-)
We need to normalize on a common set of labels for our community
member data. But first let's talk about the types of data. The
three types of data we want to capture are reference data,
relationship data, and activity data. The reference data must be
qualified because as you noted it could be coming from any kind of
social software application. You can think of reference data as
name, number, address, etc. Unfortunately, it could also come from
buddylists, petitions, or volunteer lists. That reference data must
be qualified for the source which the reference data came from.
I have been meaning to identify a common set of labels for community
member data but haven't got around to it. I believe that CivCRM has
done a good job with their data model. But they are focused on the
non-profit sector and as a result it's possible that their model
doesn't include reference data that you might consider critical such
as blog, or xfn. There model is flexible and can handle these
changes. The point is that CivCRM has a public data model and how
they map internally is up to them, but as long as other member data
applications can normalize to an agreed set of labels in the
community we should not have a problem. This is very important
exercise and should happen soon.
Once we have a Drupal blessing, a non-profit blessing, a political
blessing, and a social software blessing of our reference labels we
can do something very important. We can create a set of master
textual descriptions of data types known as conformed dimensions.
With conformed dimensions we can query multiple data sources, or data
marts. Querying across multiple sources is known as drilling across
or a multi-pass query. Overall this is refered to as a data bus-
architecture.
Most folks in Drupal land assume that they will always have a single
database. But anyone in the political or non-profit field will tell
you that decentralized data sources is a fact of life that you just
have to get used to. A data bus architecture is how you design your
data infrastructure to be able to be accessible.
This might seem like overkill but sometime in the next several weeks
CRM will be merged with Drupal. When that happens leaders of
communities are going to start asking questions about the
relationship between content in the CMS and people represented in the
CRM. Those questions will be unpredictable and we need the
flexibility designed in to be able to answer those questions. Over
time, new applications will be developed that involve social
information, as you have noted is already happening. How we
integrate those applications with Drupal is going to be of incredible
importance to leaders who would benefit greatly by being able to ask
complex questions about their communities. If we do less than a
great job those questions will not be able to be answered.
A good place to start would be to research SugarCRM, CivCRM, and
SalesForce.com's non-profit data models. The goals would be to set
a reference and relationship labeling standard that all application
developer could adhere to. If they did meet that standard then it
would greatly facilitate the integration of data sources into a data
bus architecture.
There are literally hundreds of world class engineers who have
tackled these problems internally inside corporations. Just as all
the Unix expertise poured out of companies into Linux there is an
opportunity for all this data integration expertise to pour out into
getting CRM and CMS integration done right. They are just waiting
in the wings watching to see what happens.
I hope you take up this challenge.
Cheers,
Kieran
> If CivicCRM seems like the place to unify all this then I think
> there needs to be a more visible way to get these module
> maintainers and developers involved now. I do believe there is a
> mailing list for this, but I mean a more visible acceptance from
> developers that the CivicCRM is what they should be looking
> towards, and coding towards as much as that is possible.
> I might be stating the obvious here, but my fear is that modules
> like "contact directory" http://drupal.org/node/15863 will continue
> to be developed duplicating the fothcoming CivicCRM. Or maybe the
> module is great and will ultimately be an important aspect of the
> CRM, but if so it would nice to have that conversation started now,
> rather than later. With all the posts about extending profile, or
> searching profiles, referrals and invites, and organic grouping, it
> would be nice for these developers to join in the CivicCRM
> discussion and development, rather than starting their own.
>
> I see that CivicCRM was discussed at FOSDEM, but I don't know if a
> more general "user management" discussion has taken place or not.
> I'm not sure if it needs to, but just throwing these thoughts out
> to the wolves.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: civicspace-dev-unsubscribe(a)civicspacelabs.org
> For additional commands, e-mail: civicspace-dev-
> help(a)civicspacelabs.org
>
>
>
1
0
Issue status update for http://drupal.org/node/22035
Project: Drupal
Version: cvs
Component: base system
Category: tasks
Priority: normal
Assigned to: Anonymous
Reported by: mikeryan
Updated by: Dries
Status: patch
Can you try making the following changes?
1. To common.inc:
function drupal_rebuild_path_map() {
- drupal_get_path_map('rebuild');
+ drupal_get_path_map(TRUE);
}
2. To bootstrap.inc:
-function drupal_get_path_map($action = '') {
+function drupal_get_path_map($rebuild = FALSE) {
static $map = NULL;
- if ($action == 'rebuild') {
+ if ($rebuild) {
$map = NULL;
}
That is, replace the string comparison with a boolean comparison. Not
sure it is going to make a significant difference but it might be
another micro-improvement.
I'll test your patch shortly.
Dries
Previous comments:
------------------------------------------------------------------------
May 5, 2005 - 03:10 : mikeryan
See Investigate use of conf_url_rewrite [1] for context...
The current core support for translating incoming path aliases to the
internal Drupal path (drupal_get_path_alias) and substituting aliases
when generating links to internal paths (drupal_get_normal_path) does
not scale well with many aliases. The ease with which pathauto enables
site administrators to generate large numbers of aliases exposes this
issue, but it is inherent in the core implementation, because
drupal_get_path_map reads in the entire url_alias table at bootstrap
time. I'd like to discuss ideas on how to improve the performance...
Most obviously, why not simply query the url_alias table as needed
instead of loading the whole table? In the incoming case, only a single
simple SELECT is necessary, which will always be more efficient than
reading the table. In the outgoing case, there might be some slight
performance advantage to caching the table with a small number of
aliases, but the disadvantage can become huge as the alias table grows.
One note - I've noticed that the src column in url_alias is not
indexed, I think adding an index should significantly help the
performance in the outgoing case if we were to do individual SELECTs.
Any other thoughts?
[1] http://drupal.org/node/21938
------------------------------------------------------------------------
May 5, 2005 - 04:02 : mikeryan
Attachment: http://drupal.org/files/issues/bootstrap.inc_2.patch (1.06 KB)
What the hell, I went ahead and gave it a shot... On my home system,
where I'm testing out 4.6.0, page loads have been taking several
seconds, which I attributed to the fact that it's an old computer and
I'm multi-tasking like crazy. I implemented my own suggestion, and now
pages load in about one second, it makes an incredible difference
(FWIW, my url_alias table has over 4000 rows).
Patches attached, go give it a try...
------------------------------------------------------------------------
May 5, 2005 - 04:02 : mikeryan
Attachment: http://drupal.org/files/issues/common.inc_11.patch (723 bytes)
One attachment per note, that's tedious...
------------------------------------------------------------------------
May 5, 2005 - 04:03 : mikeryan
Attachment: http://drupal.org/files/issues/path.module_0.patch (1.34 KB)
------------------------------------------------------------------------
May 5, 2005 - 04:03 : mikeryan
Attachment: http://drupal.org/files/issues/database.mysql_4.patch (553 bytes)
------------------------------------------------------------------------
May 5, 2005 - 04:04 : mikeryan
Attachment: http://drupal.org/files/issues/database.pgsql_2.patch (502 bytes)
------------------------------------------------------------------------
May 5, 2005 - 04:07 : mikeryan
Note: I just noticed that the database.*sql patches showed an extra diff
(not mine) to the location field in locales_source. I did my diffs
against a freshly-updated DRUPAL-4-6, and had made the edits against a
release from a few days ago... Those locales_source changes should
probably be removed from my patches before applying.
------------------------------------------------------------------------
May 8, 2005 - 01:13 : mikeryan
I upgraded Fenway Views [2] to Drupal 4.6.0 today, incorporating these
patches. Performance is very noticeably improved.
[2] http://fenway-views.com/
------------------------------------------------------------------------
May 8, 2005 - 15:31 : killes(a)www.drop.org
Attachment: http://drupal.org/files/issues/pathalias.patch (4.98 KB)
I've merged the patch into one. Much more convenient. I also changed it
to cvs as only there new features will be added.
Upgrade path needs to be added.
Mike, can you run some more tests? We are especially interested in
"hard" data ie numbers with possibly error bars. it would be
interesting to know how this patch affects sites that have only a few
path aliases vs those with a lot of them. Also, how pages with a lot of
node links (tracker) are affected.
It might be worthwhile to add static caching in drupal_get_normal_path
if it gets calle dmore than once for a link on one page view.
------------------------------------------------------------------------
May 8, 2005 - 19:21 : mikeryan
Thanks for merging the patches, I wasn't aware you could patch multiple
files at once. If this is accepted, of course, adding the index on src
should be incorporated into updates.inc.
In terms of hard data, I've never profiled PHP code - what tool(s) do
you use? I couldn't find anything referenced in the PHP manual...
re: pages with lots of links - on Fenway Views the big test is the
calendar [3], and the performance improvement seems even more dramatic
here. I don't know why - the url_alias table is read once per page, so
I would expect as you do that preloading the table would tend to look
better when you have a hundred internal links on the page. Maybe we're
both underestimating exactly how fast a simple MySQL query on an
indexed key can be (I'm using MySQL 4.0.20, BTW)...
[3] http://fenway-views.com/calendar
------------------------------------------------------------------------
May 8, 2005 - 19:26 : killes(a)www.drop.org
As we speak, Mathias is doing some tests. The tool of choice is usually
apache bench. If you have a lot of url aliases, the generated array
will be huge. Part of the improvement could be due to the fact that you
need less memory now.
------------------------------------------------------------------------
May 8, 2005 - 19:28 : mikeryan
Great, thanks!
------------------------------------------------------------------------
May 8, 2005 - 19:34 : Dries
On drupal.org it takes 800 ms or more to generate a page. Of these 800
ms, only 4 ms is spent building the path alias map (incl. the SQL query
time which takes about 1 ms). That is, building the map takes 0.5% of
the total time which is neglible. In our url_alias table are only 321
aliases though. How many aliases do you have?
What is more, when we build drupal.org's main page, we query this map
215 times. I believe your patch would introduce 215 SQL queries ...
I'm afraid that if we'd apply your patch, we'd pay a serious
performance penalty (unless we have many more aliases).
Can you provide some numbers/measurements?
------------------------------------------------------------------------
May 8, 2005 - 19:37 : Dries
Note: my measurements did not take into account the time spent searching
the map. On the main page, we search this array 215 times.
------------------------------------------------------------------------
May 8, 2005 - 20:08 : puregin
I believe that it's felt that adding path aliases would improve the
Drupal documentation. This may well add 400+ paths to the URL aliases
table on Drupal.org
------------------------------------------------------------------------
May 8, 2005 - 20:27 : Dries
I spent some more time investigating this.
The relevant code in bootstrap.inc is this:
function drupal_get_path_alias($path) {
if (($map = drupal_get_path_map()) && ($newpath = array_search($path,
$map))) {
return $newpath;
}
...
Turns out that the time to build the map is neglible (< 5ms, see
previous comments), however the total time spent on 'path aliasing' it
about 70ms per page! 50ms of these 70ms are spent on $map =
drupal_get_path_map(). The remaining 20ms is spent on $newpath =
array_search($path, $map).
The first call to drupal_get_path_map() takes 3 to 5 ms, each
subsequent call takes about 0.3 ms. Searching the array costs 0.1 ms.
However, if you have to do this 130+ times, this adds up to a whopping
70 ms. Remind that we have 321 aliases in our map.
As drupal_get_path_alias() is typically called from code>url(), which
in turn is typically called from l() I set out to investigate the time
spent in l(). Looks like l() easily gets called 120 times/page, and
that each call to l() costs about 0.9 ms. That is about 2 or 3 times
the cost of the /average SQL query/. The total time spent in l() is
115 ms!
------------------------------------------------------------------------
May 9, 2005 - 00:25 : adrian
This is a complete aside, and probably off-topic, but I would like to
mention that I was actually
looking at rewriting url() to be able to handle 'external urls' ,
because I want to do aliases using the site subdomain, like for
instance :
http://category.sitename.com/article/title_goes_here -> node/23
Rewriting url to allow this would also allow us to use l() for external
links of any kind, getting rid of a bunch of inline html.
------------------------------------------------------------------------
May 9, 2005 - 00:46 : chx
adrian, I have written a patch for l to support external links but Ber
said that a module like weblink shall handle those.
------------------------------------------------------------------------
May 9, 2005 - 01:03 : mikeryan
I've got over 4000 aliases on Fenway Views - another pathauto user
reported over 6000.
I don't have a profiling tool to give timing data, but adding a quick
counter shows that for the Fenway Views calendar [4],
drupal_get_path_alias() is called 404 times and drupal_get_normal_path
is called 227 times. And trust me, this page loads MUCH faster with my
patch than it does with the path map.
I think those SQL queries are a lot cheaper than one might expect...
[4] http://fenway-views.com/calendar
------------------------------------------------------------------------
May 9, 2005 - 06:24 : mathias
Attachment: http://drupal.org/files/issues/pathalias-with-caching.patch (5.62 KB)
Some benchmarks, with MySQL and Drupal caching disabled.
2 SETS OF TESTS
=======================================
1) 500 nodes and aliases
2) 20,000 nodes and aliases
3 TYPES OF TESTS PER SET
=======================================
1) Baseline unmodified Drupal
2) The following change inside drupal_get_path_map():
- if (is_null($map)) {
+ if ($map === NULL) {
$map = array(); // Make $map non-null in case no aliases
are defined.
3) Pull aliases only when needed rather than loading the entire alias
table.
SET 1 - 500 Nodes and 500 Aliases
using: ab -c 10 -n 100 [homepage]
=======================================
Baseline
Time taken for tests: 13.00 seconds
Requests per second: 3.85 [#/sec] (mean)
Transfer rate: 56.35 [Kbytes/sec] received
is_null() VS NULL
Time taken for tests: 12.463 seconds
Requests per second: 4.01 [#/sec] (mean)
Transfer rate: 57.63 [Kbytes/sec] received
Per Instance Alias Lookup (32 additional queries)
Time taken for tests: 11.502 seconds
Requests per second: 4.35 [#/sec] (mean)
Transfer rate: 63.30 [Kbytes/sec] received
SET 2 - 20,000 Nodes and 20,000 Aliases
using: ab -c 5 -n 50 [homepage]
=======================================
Baseline
Time taken for tests: 204.583 seconds
Requests per second: 0.24 [#/sec] (mean)
Transfer rate: 3.34 [Kbytes/sec] received
is_null() VS NULL
Time taken for tests: 127.629 seconds
Requests per second: 0.39 [#/sec] (mean)
Transfer rate: 5.35 [Kbytes/sec] received
Per Instance Alias Lookup (32 additional queries)
Time taken for tests: 28.788 seconds
Requests per second: 1.74 [#/sec] (mean)
Transfer rate: 23.59 [Kbytes/sec] received
ANALYSIS
=======================================
Converting 'is_null()' to '=== NULL' is a no brainer and results in a
nice performance gain. And while per instance alias lookups also give a
huge boost for site with thousands of aliases, they're benefits are
entirely dependent on the number of system URLs and menu items visible
per request. As noted above I tested the standard homepage which added
32 additional queries. A request for something like the admin interface
would presumably show less benefits. I would've tested this, but I
didn't know how to invoke an authenticated page request with 'ab'. A
positive of this approach is we no longer would be storing all the
aliases in memory.
What other concerns do we have with this last approach? Am I properly
testing the strain on the database?
1
0
Issue status update for http://drupal.org/node/22035
Project: Drupal
Version: cvs
Component: base system
Category: tasks
Priority: normal
Assigned to: Anonymous
Reported by: mikeryan
Updated by: mathias
Status: patch
Attachment: http://drupal.org/files/issues/pathalias-with-caching.patch (5.62 KB)
Some benchmarks, with MySQL and Drupal caching disabled.
2 SETS OF TESTS
=======================================
1) 500 nodes and aliases
2) 20,000 nodes and aliases
3 TYPES OF TESTS PER SET
=======================================
1) Baseline unmodified Drupal
2) The following change inside drupal_get_path_map():
- if (is_null($map)) {
+ if ($map === NULL) {
$map = array(); // Make $map non-null in case no aliases
are defined.
3) Pull aliases only when needed rather than loading the entire alias
table.
SET 1 - 500 Nodes and 500 Aliases
using: ab -c 10 -n 100 [homepage]
=======================================
Baseline
Time taken for tests: 13.00 seconds
Requests per second: 3.85 [#/sec] (mean)
Transfer rate: 56.35 [Kbytes/sec] received
is_null() VS NULL
Time taken for tests: 12.463 seconds
Requests per second: 4.01 [#/sec] (mean)
Transfer rate: 57.63 [Kbytes/sec] received
Per Instance Alias Lookup (32 additional queries)
Time taken for tests: 11.502 seconds
Requests per second: 4.35 [#/sec] (mean)
Transfer rate: 63.30 [Kbytes/sec] received
SET 2 - 20,000 Nodes and 20,000 Aliases
using: ab -c 5 -n 50 [homepage]
=======================================
Baseline
Time taken for tests: 204.583 seconds
Requests per second: 0.24 [#/sec] (mean)
Transfer rate: 3.34 [Kbytes/sec] received
is_null() VS NULL
Time taken for tests: 127.629 seconds
Requests per second: 0.39 [#/sec] (mean)
Transfer rate: 5.35 [Kbytes/sec] received
Per Instance Alias Lookup (32 additional queries)
Time taken for tests: 28.788 seconds
Requests per second: 1.74 [#/sec] (mean)
Transfer rate: 23.59 [Kbytes/sec] received
ANALYSIS
=======================================
Converting 'is_null()' to '=== NULL' is a no brainer and results in a
nice performance gain. And while per instance alias lookups also give a
huge boost for site with thousands of aliases, they're benefits are
entirely dependent on the number of system URLs and menu items visible
per request. As noted above I tested the standard homepage which added
32 additional queries. A request for something like the admin interface
would presumably show less benefits. I would've tested this, but I
didn't know how to invoke an authenticated page request with 'ab'. A
positive of this approach is we no longer would be storing all the
aliases in memory.
What other concerns do we have with this last approach? Am I properly
testing the strain on the database?
mathias
Previous comments:
------------------------------------------------------------------------
May 4, 2005 - 19:10 : mikeryan
See Investigate use of conf_url_rewrite [1] for context...
The current core support for translating incoming path aliases to the
internal Drupal path (drupal_get_path_alias) and substituting aliases
when generating links to internal paths (drupal_get_normal_path) does
not scale well with many aliases. The ease with which pathauto enables
site administrators to generate large numbers of aliases exposes this
issue, but it is inherent in the core implementation, because
drupal_get_path_map reads in the entire url_alias table at bootstrap
time. I'd like to discuss ideas on how to improve the performance...
Most obviously, why not simply query the url_alias table as needed
instead of loading the whole table? In the incoming case, only a single
simple SELECT is necessary, which will always be more efficient than
reading the table. In the outgoing case, there might be some slight
performance advantage to caching the table with a small number of
aliases, but the disadvantage can become huge as the alias table grows.
One note - I've noticed that the src column in url_alias is not
indexed, I think adding an index should significantly help the
performance in the outgoing case if we were to do individual SELECTs.
Any other thoughts?
[1] http://drupal.org/node/21938
------------------------------------------------------------------------
May 4, 2005 - 20:02 : mikeryan
Attachment: http://drupal.org/files/issues/bootstrap.inc_2.patch (1.06 KB)
What the hell, I went ahead and gave it a shot... On my home system,
where I'm testing out 4.6.0, page loads have been taking several
seconds, which I attributed to the fact that it's an old computer and
I'm multi-tasking like crazy. I implemented my own suggestion, and now
pages load in about one second, it makes an incredible difference
(FWIW, my url_alias table has over 4000 rows).
Patches attached, go give it a try...
------------------------------------------------------------------------
May 4, 2005 - 20:02 : mikeryan
Attachment: http://drupal.org/files/issues/common.inc_11.patch (723 bytes)
One attachment per note, that's tedious...
------------------------------------------------------------------------
May 4, 2005 - 20:03 : mikeryan
Attachment: http://drupal.org/files/issues/path.module_0.patch (1.34 KB)
------------------------------------------------------------------------
May 4, 2005 - 20:03 : mikeryan
Attachment: http://drupal.org/files/issues/database.mysql_4.patch (553 bytes)
------------------------------------------------------------------------
May 4, 2005 - 20:04 : mikeryan
Attachment: http://drupal.org/files/issues/database.pgsql_2.patch (502 bytes)
------------------------------------------------------------------------
May 4, 2005 - 20:07 : mikeryan
Note: I just noticed that the database.*sql patches showed an extra diff
(not mine) to the location field in locales_source. I did my diffs
against a freshly-updated DRUPAL-4-6, and had made the edits against a
release from a few days ago... Those locales_source changes should
probably be removed from my patches before applying.
------------------------------------------------------------------------
May 7, 2005 - 17:13 : mikeryan
I upgraded Fenway Views [2] to Drupal 4.6.0 today, incorporating these
patches. Performance is very noticeably improved.
[2] http://fenway-views.com/
------------------------------------------------------------------------
May 8, 2005 - 07:31 : killes(a)www.drop.org
Attachment: http://drupal.org/files/issues/pathalias.patch (4.98 KB)
I've merged the patch into one. Much more convenient. I also changed it
to cvs as only there new features will be added.
Upgrade path needs to be added.
Mike, can you run some more tests? We are especially interested in
"hard" data ie numbers with possibly error bars. it would be
interesting to know how this patch affects sites that have only a few
path aliases vs those with a lot of them. Also, how pages with a lot of
node links (tracker) are affected.
It might be worthwhile to add static caching in drupal_get_normal_path
if it gets calle dmore than once for a link on one page view.
------------------------------------------------------------------------
May 8, 2005 - 11:21 : mikeryan
Thanks for merging the patches, I wasn't aware you could patch multiple
files at once. If this is accepted, of course, adding the index on src
should be incorporated into updates.inc.
In terms of hard data, I've never profiled PHP code - what tool(s) do
you use? I couldn't find anything referenced in the PHP manual...
re: pages with lots of links - on Fenway Views the big test is the
calendar [3], and the performance improvement seems even more dramatic
here. I don't know why - the url_alias table is read once per page, so
I would expect as you do that preloading the table would tend to look
better when you have a hundred internal links on the page. Maybe we're
both underestimating exactly how fast a simple MySQL query on an
indexed key can be (I'm using MySQL 4.0.20, BTW)...
[3] http://fenway-views.com/calendar
------------------------------------------------------------------------
May 8, 2005 - 11:26 : killes(a)www.drop.org
As we speak, Mathias is doing some tests. The tool of choice is usually
apache bench. If you have a lot of url aliases, the generated array
will be huge. Part of the improvement could be due to the fact that you
need less memory now.
------------------------------------------------------------------------
May 8, 2005 - 11:28 : mikeryan
Great, thanks!
------------------------------------------------------------------------
May 8, 2005 - 11:34 : Dries
On drupal.org it takes 800 ms or more to generate a page. Of these 800
ms, only 4 ms is spent building the path alias map (incl. the SQL query
time which takes about 1 ms). That is, building the map takes 0.5% of
the total time which is neglible. In our url_alias table are only 321
aliases though. How many aliases do you have?
What is more, when we build drupal.org's main page, we query this map
215 times. I believe your patch would introduce 215 SQL queries ...
I'm afraid that if we'd apply your patch, we'd pay a serious
performance penalty (unless we have many more aliases).
Can you provide some numbers/measurements?
------------------------------------------------------------------------
May 8, 2005 - 11:37 : Dries
Note: my measurements did not take into account the time spent searching
the map. On the main page, we search this array 215 times.
------------------------------------------------------------------------
May 8, 2005 - 12:08 : puregin
I believe that it's felt that adding path aliases would improve the
Drupal documentation. This may well add 400+ paths to the URL aliases
table on Drupal.org
------------------------------------------------------------------------
May 8, 2005 - 12:27 : Dries
I spent some more time investigating this.
The relevant code in bootstrap.inc is this:
function drupal_get_path_alias($path) {
if (($map = drupal_get_path_map()) && ($newpath = array_search($path,
$map))) {
return $newpath;
}
...
Turns out that the time to build the map is neglible (< 5ms, see
previous comments), however the total time spent on 'path aliasing' it
about 70ms per page! 50ms of these 70ms are spent on $map =
drupal_get_path_map(). The remaining 20ms is spent on $newpath =
array_search($path, $map).
The first call to drupal_get_path_map() takes 3 to 5 ms, each
subsequent call takes about 0.3 ms. Searching the array costs 0.1 ms.
However, if you have to do this 130+ times, this adds up to a whopping
70 ms. Remind that we have 321 aliases in our map.
As drupal_get_path_alias() is typically called from code>url(), which
in turn is typically called from l() I set out to investigate the time
spent in l(). Looks like l() easily gets called 120 times/page, and
that each call to l() costs about 0.9 ms. That is about 2 or 3 times
the cost of the /average SQL query/. The total time spent in l() is
115 ms!
------------------------------------------------------------------------
May 8, 2005 - 16:25 : adrian
This is a complete aside, and probably off-topic, but I would like to
mention that I was actually
looking at rewriting url() to be able to handle 'external urls' ,
because I want to do aliases using the site subdomain, like for
instance :
http://category.sitename.com/article/title_goes_here -> node/23
Rewriting url to allow this would also allow us to use l() for external
links of any kind, getting rid of a bunch of inline html.
------------------------------------------------------------------------
May 8, 2005 - 16:46 : chx
adrian, I have written a patch for l to support external links but Ber
said that a module like weblink shall handle those.
------------------------------------------------------------------------
May 8, 2005 - 17:03 : mikeryan
I've got over 4000 aliases on Fenway Views - another pathauto user
reported over 6000.
I don't have a profiling tool to give timing data, but adding a quick
counter shows that for the Fenway Views calendar [4],
drupal_get_path_alias() is called 404 times and drupal_get_normal_path
is called 227 times. And trust me, this page loads MUCH faster with my
patch than it does with the path map.
I think those SQL queries are a lot cheaper than one might expect...
[4] http://fenway-views.com/calendar
1
0
Can Drupal support "automatic relative URL" generation?
By automatic relative URL" I mean something similar to MediaWiki's "[[]]"
construct:
http://meta.wikimedia.org/wiki/Help:Editing#Links.2C_URLs
For example, rather then hard-coding this entire URL into the content of
this message:
http://drupal.org/node/21832
...I would prefer the Drupal new-post mechanism take this URL string and
auto-convert it to something that just says "/node/21832" and will
automatically change if the server is "assigned" a new primary "base"
URL/domain address. This can also help (and is my biggest purpose) with
local "caches" of Drupal content for "snapshot" reference, say as an
included documentation set for a product that was developed using Drupal
for said product's collaboration and/or documentation.
Alternatively, maybe Drupal could allow the author to make a reference like
[[node/21832]] to do the same as above (and still support pathauto aliases
in the process).
Does my explanation make any sense?
Does this capability exist? Possibly via some module or patch?
-Matt
3
2
[drupal-devel] Before I patch: is there an existing /[cat]/[user] solution?
by Matt England 09 May '05
by Matt England 09 May '05
09 May '05
Hello,
I am trying to auth-generate URL alias paths in the form of
/blogname/category or /category/blogname (or in pathauto speak:
/[user]/[cat] or /[cat]/[user]).
I have posted numerous questions about this in several places. Jeremy of
GreenAsh recommended I try using taxonomy_browser in combo with pathauto
for this (see http://drupal.org/node/21320#comment-36674 ), but I as of yet
have really no clue as to how to use taxonomy_browser to do anything...and
have yet to find what I found to be a useful taxonomy_browser doc reference.
Before I try my own patch for this, I ask: can anyone think of way I can
get things to work with existing 4.6.0 tools/resources so that I don't have
to go code something myself? I am willing to pay $30 US dollars via
paypal.com (or some other convenience mechanism) to anyone who can help me
accomplish this task.
More details can be found here:
>http://drupal.org/node/21832
>http://drupal.org/node/21320
>http://drupal.org/node/21320#comment-37449
As well as in the included email found below.
I have already created one patch ( http://drupal.org/node/21885 ) for
another problem ( http://drupal.org/node/21712 ), and I'm hoping I can do
something similar for this problem (described in more detail below).
Thanks very very much in advance for any help,
-Matt
Chicago, IL USA
mobile: 312-543-9916
>Date: Wed, 04 May 2005 19:36:46 -0500
>To: drupal-support(a)drupal.org
>From: Matt England <mengland(a)mengland.net>
>Cc: mengland(a)mengland.net
>Subject: [drupal-support] URL alias: howto get /[cat]/[user] display?
> pathauto/taxonomy_browser?
>
>I am trying to auth-generate URL alias paths in the form of
>/blogname/category or /category/blogname (or in pathauto speak:
>/[user]/[cat] or /[cat]/[user]).
>
>Can anyone offer suggestions? I'm been checking this out for a while and
>am getting concerned that I'm not going to find a solution.
>
>These forum discussions provide more detail:
>
>http://drupal.org/node/21832
>http://drupal.org/node/21320
>http://drupal.org/node/21320#comment-37449
>
>The file references in the immediately-previous reference are supposed to
>be available via briefcase.yahoo.com, and the links are broken, so I
>include the files as attachments to this email.
>
>Thanks for any help,
>-Matt
>
>
>
>-- [ Drupal support list | http://lists.drupal.org/
3
5
Issue status update for http://drupal.org/node/22035
Project: Drupal
Version: cvs
Component: base system
Category: tasks
Priority: normal
Assigned to: Anonymous
Reported by: mikeryan
Updated by: mikeryan
Status: patch
I've got over 4000 aliases on Fenway Views - another pathauto user
reported over 6000.
I don't have a profiling tool to give timing data, but adding a quick
counter shows that for the Fenway Views calendar [1],
drupal_get_path_alias() is called 404 times and drupal_get_normal_path
is called 227 times. And trust me, this page loads MUCH faster with my
patch than it does with the path map.
I think those SQL queries are a lot cheaper than one might expect...
[1] http://fenway-views.com/calendar
mikeryan
Previous comments:
------------------------------------------------------------------------
May 4, 2005 - 21:10 : mikeryan
See Investigate use of conf_url_rewrite [2] for context...
The current core support for translating incoming path aliases to the
internal Drupal path (drupal_get_path_alias) and substituting aliases
when generating links to internal paths (drupal_get_normal_path) does
not scale well with many aliases. The ease with which pathauto enables
site administrators to generate large numbers of aliases exposes this
issue, but it is inherent in the core implementation, because
drupal_get_path_map reads in the entire url_alias table at bootstrap
time. I'd like to discuss ideas on how to improve the performance...
Most obviously, why not simply query the url_alias table as needed
instead of loading the whole table? In the incoming case, only a single
simple SELECT is necessary, which will always be more efficient than
reading the table. In the outgoing case, there might be some slight
performance advantage to caching the table with a small number of
aliases, but the disadvantage can become huge as the alias table grows.
One note - I've noticed that the src column in url_alias is not
indexed, I think adding an index should significantly help the
performance in the outgoing case if we were to do individual SELECTs.
Any other thoughts?
[2] http://drupal.org/node/21938
------------------------------------------------------------------------
May 4, 2005 - 22:02 : mikeryan
Attachment: http://drupal.org/files/issues/bootstrap.inc_2.patch (1.06 KB)
What the hell, I went ahead and gave it a shot... On my home system,
where I'm testing out 4.6.0, page loads have been taking several
seconds, which I attributed to the fact that it's an old computer and
I'm multi-tasking like crazy. I implemented my own suggestion, and now
pages load in about one second, it makes an incredible difference
(FWIW, my url_alias table has over 4000 rows).
Patches attached, go give it a try...
------------------------------------------------------------------------
May 4, 2005 - 22:02 : mikeryan
Attachment: http://drupal.org/files/issues/common.inc_11.patch (723 bytes)
One attachment per note, that's tedious...
------------------------------------------------------------------------
May 4, 2005 - 22:03 : mikeryan
Attachment: http://drupal.org/files/issues/path.module_0.patch (1.34 KB)
------------------------------------------------------------------------
May 4, 2005 - 22:03 : mikeryan
Attachment: http://drupal.org/files/issues/database.mysql_4.patch (553 bytes)
------------------------------------------------------------------------
May 4, 2005 - 22:04 : mikeryan
Attachment: http://drupal.org/files/issues/database.pgsql_2.patch (502 bytes)
------------------------------------------------------------------------
May 4, 2005 - 22:07 : mikeryan
Note: I just noticed that the database.*sql patches showed an extra diff
(not mine) to the location field in locales_source. I did my diffs
against a freshly-updated DRUPAL-4-6, and had made the edits against a
release from a few days ago... Those locales_source changes should
probably be removed from my patches before applying.
------------------------------------------------------------------------
May 7, 2005 - 19:13 : mikeryan
I upgraded Fenway Views [3] to Drupal 4.6.0 today, incorporating these
patches. Performance is very noticeably improved.
[3] http://fenway-views.com/
------------------------------------------------------------------------
May 8, 2005 - 09:31 : killes(a)www.drop.org
Attachment: http://drupal.org/files/issues/pathalias.patch (4.98 KB)
I've merged the patch into one. Much more convenient. I also changed it
to cvs as only there new features will be added.
Upgrade path needs to be added.
Mike, can you run some more tests? We are especially interested in
"hard" data ie numbers with possibly error bars. it would be
interesting to know how this patch affects sites that have only a few
path aliases vs those with a lot of them. Also, how pages with a lot of
node links (tracker) are affected.
It might be worthwhile to add static caching in drupal_get_normal_path
if it gets calle dmore than once for a link on one page view.
------------------------------------------------------------------------
May 8, 2005 - 13:21 : mikeryan
Thanks for merging the patches, I wasn't aware you could patch multiple
files at once. If this is accepted, of course, adding the index on src
should be incorporated into updates.inc.
In terms of hard data, I've never profiled PHP code - what tool(s) do
you use? I couldn't find anything referenced in the PHP manual...
re: pages with lots of links - on Fenway Views the big test is the
calendar [4], and the performance improvement seems even more dramatic
here. I don't know why - the url_alias table is read once per page, so
I would expect as you do that preloading the table would tend to look
better when you have a hundred internal links on the page. Maybe we're
both underestimating exactly how fast a simple MySQL query on an
indexed key can be (I'm using MySQL 4.0.20, BTW)...
[4] http://fenway-views.com/calendar
------------------------------------------------------------------------
May 8, 2005 - 13:26 : killes(a)www.drop.org
As we speak, Mathias is doing some tests. The tool of choice is usually
apache bench. If you have a lot of url aliases, the generated array
will be huge. Part of the improvement could be due to the fact that you
need less memory now.
------------------------------------------------------------------------
May 8, 2005 - 13:28 : mikeryan
Great, thanks!
------------------------------------------------------------------------
May 8, 2005 - 13:34 : Dries
On drupal.org it takes 800 ms or more to generate a page. Of these 800
ms, only 4 ms is spent building the path alias map (incl. the SQL query
time which takes about 1 ms). That is, building the map takes 0.5% of
the total time which is neglible. In our url_alias table are only 321
aliases though. How many aliases do you have?
What is more, when we build drupal.org's main page, we query this map
215 times. I believe your patch would introduce 215 SQL queries ...
I'm afraid that if we'd apply your patch, we'd pay a serious
performance penalty (unless we have many more aliases).
Can you provide some numbers/measurements?
------------------------------------------------------------------------
May 8, 2005 - 13:37 : Dries
Note: my measurements did not take into account the time spent searching
the map. On the main page, we search this array 215 times.
------------------------------------------------------------------------
May 8, 2005 - 14:08 : puregin
I believe that it's felt that adding path aliases would improve the
Drupal documentation. This may well add 400+ paths to the URL aliases
table on Drupal.org
------------------------------------------------------------------------
May 8, 2005 - 14:27 : Dries
I spent some more time investigating this.
The relevant code in bootstrap.inc is this:
function drupal_get_path_alias($path) {
if (($map = drupal_get_path_map()) && ($newpath = array_search($path,
$map))) {
return $newpath;
}
...
Turns out that the time to build the map is neglible (< 5ms, see
previous comments), however the total time spent on 'path aliasing' it
about 70ms per page! 50ms of these 70ms are spent on $map =
drupal_get_path_map(). The remaining 20ms is spent on $newpath =
array_search($path, $map).
The first call to drupal_get_path_map() takes 3 to 5 ms, each
subsequent call takes about 0.3 ms. Searching the array costs 0.1 ms.
However, if you have to do this 130+ times, this adds up to a whopping
70 ms. Remind that we have 321 aliases in our map.
As drupal_get_path_alias() is typically called from code>url(), which
in turn is typically called from l() I set out to investigate the time
spent in l(). Looks like l() easily gets called 120 times/page, and
that each call to l() costs about 0.9 ms. That is about 2 or 3 times
the cost of the /average SQL query/. The total time spent in l() is
115 ms!
------------------------------------------------------------------------
May 8, 2005 - 18:25 : adrian
This is a complete aside, and probably off-topic, but I would like to
mention that I was actually
looking at rewriting url() to be able to handle 'external urls' ,
because I want to do aliases using the site subdomain, like for
instance :
http://category.sitename.com/article/title_goes_here -> node/23
Rewriting url to allow this would also allow us to use l() for external
links of any kind, getting rid of a bunch of inline html.
------------------------------------------------------------------------
May 8, 2005 - 18:46 : chx
adrian, I have written a patch for l to support external links but Ber
said that a module like weblink shall handle those.
1
0
Issue status update for http://drupal.org/node/22035
Project: Drupal
Version: cvs
Component: base system
Category: tasks
Priority: normal
Assigned to: Anonymous
Reported by: mikeryan
Updated by: chx
Status: patch
adrian, I have written a patch for l to support external links but Ber
said that a module like weblink shall handle those.
chx
Previous comments:
------------------------------------------------------------------------
May 5, 2005 - 03:10 : mikeryan
See Investigate use of conf_url_rewrite [1] for context...
The current core support for translating incoming path aliases to the
internal Drupal path (drupal_get_path_alias) and substituting aliases
when generating links to internal paths (drupal_get_normal_path) does
not scale well with many aliases. The ease with which pathauto enables
site administrators to generate large numbers of aliases exposes this
issue, but it is inherent in the core implementation, because
drupal_get_path_map reads in the entire url_alias table at bootstrap
time. I'd like to discuss ideas on how to improve the performance...
Most obviously, why not simply query the url_alias table as needed
instead of loading the whole table? In the incoming case, only a single
simple SELECT is necessary, which will always be more efficient than
reading the table. In the outgoing case, there might be some slight
performance advantage to caching the table with a small number of
aliases, but the disadvantage can become huge as the alias table grows.
One note - I've noticed that the src column in url_alias is not
indexed, I think adding an index should significantly help the
performance in the outgoing case if we were to do individual SELECTs.
Any other thoughts?
[1] http://drupal.org/node/21938
------------------------------------------------------------------------
May 5, 2005 - 04:02 : mikeryan
Attachment: http://drupal.org/files/issues/bootstrap.inc_2.patch (1.06 KB)
What the hell, I went ahead and gave it a shot... On my home system,
where I'm testing out 4.6.0, page loads have been taking several
seconds, which I attributed to the fact that it's an old computer and
I'm multi-tasking like crazy. I implemented my own suggestion, and now
pages load in about one second, it makes an incredible difference
(FWIW, my url_alias table has over 4000 rows).
Patches attached, go give it a try...
------------------------------------------------------------------------
May 5, 2005 - 04:02 : mikeryan
Attachment: http://drupal.org/files/issues/common.inc_11.patch (723 bytes)
One attachment per note, that's tedious...
------------------------------------------------------------------------
May 5, 2005 - 04:03 : mikeryan
Attachment: http://drupal.org/files/issues/path.module_0.patch (1.34 KB)
------------------------------------------------------------------------
May 5, 2005 - 04:03 : mikeryan
Attachment: http://drupal.org/files/issues/database.mysql_4.patch (553 bytes)
------------------------------------------------------------------------
May 5, 2005 - 04:04 : mikeryan
Attachment: http://drupal.org/files/issues/database.pgsql_2.patch (502 bytes)
------------------------------------------------------------------------
May 5, 2005 - 04:07 : mikeryan
Note: I just noticed that the database.*sql patches showed an extra diff
(not mine) to the location field in locales_source. I did my diffs
against a freshly-updated DRUPAL-4-6, and had made the edits against a
release from a few days ago... Those locales_source changes should
probably be removed from my patches before applying.
------------------------------------------------------------------------
May 8, 2005 - 01:13 : mikeryan
I upgraded Fenway Views [2] to Drupal 4.6.0 today, incorporating these
patches. Performance is very noticeably improved.
[2] http://fenway-views.com/
------------------------------------------------------------------------
May 8, 2005 - 15:31 : killes(a)www.drop.org
Attachment: http://drupal.org/files/issues/pathalias.patch (4.98 KB)
I've merged the patch into one. Much more convenient. I also changed it
to cvs as only there new features will be added.
Upgrade path needs to be added.
Mike, can you run some more tests? We are especially interested in
"hard" data ie numbers with possibly error bars. it would be
interesting to know how this patch affects sites that have only a few
path aliases vs those with a lot of them. Also, how pages with a lot of
node links (tracker) are affected.
It might be worthwhile to add static caching in drupal_get_normal_path
if it gets calle dmore than once for a link on one page view.
------------------------------------------------------------------------
May 8, 2005 - 19:21 : mikeryan
Thanks for merging the patches, I wasn't aware you could patch multiple
files at once. If this is accepted, of course, adding the index on src
should be incorporated into updates.inc.
In terms of hard data, I've never profiled PHP code - what tool(s) do
you use? I couldn't find anything referenced in the PHP manual...
re: pages with lots of links - on Fenway Views the big test is the
calendar [3], and the performance improvement seems even more dramatic
here. I don't know why - the url_alias table is read once per page, so
I would expect as you do that preloading the table would tend to look
better when you have a hundred internal links on the page. Maybe we're
both underestimating exactly how fast a simple MySQL query on an
indexed key can be (I'm using MySQL 4.0.20, BTW)...
[3] http://fenway-views.com/calendar
------------------------------------------------------------------------
May 8, 2005 - 19:26 : killes(a)www.drop.org
As we speak, Mathias is doing some tests. The tool of choice is usually
apache bench. If you have a lot of url aliases, the generated array
will be huge. Part of the improvement could be due to the fact that you
need less memory now.
------------------------------------------------------------------------
May 8, 2005 - 19:28 : mikeryan
Great, thanks!
------------------------------------------------------------------------
May 8, 2005 - 19:34 : Dries
On drupal.org it takes 800 ms or more to generate a page. Of these 800
ms, only 4 ms is spent building the path alias map (incl. the SQL query
time which takes about 1 ms). That is, building the map takes 0.5% of
the total time which is neglible. In our url_alias table are only 321
aliases though. How many aliases do you have?
What is more, when we build drupal.org's main page, we query this map
215 times. I believe your patch would introduce 215 SQL queries ...
I'm afraid that if we'd apply your patch, we'd pay a serious
performance penalty (unless we have many more aliases).
Can you provide some numbers/measurements?
------------------------------------------------------------------------
May 8, 2005 - 19:37 : Dries
Note: my measurements did not take into account the time spent searching
the map. On the main page, we search this array 215 times.
------------------------------------------------------------------------
May 8, 2005 - 20:08 : puregin
I believe that it's felt that adding path aliases would improve the
Drupal documentation. This may well add 400+ paths to the URL aliases
table on Drupal.org
------------------------------------------------------------------------
May 8, 2005 - 20:27 : Dries
I spent some more time investigating this.
The relevant code in bootstrap.inc is this:
function drupal_get_path_alias($path) {
if (($map = drupal_get_path_map()) && ($newpath = array_search($path,
$map))) {
return $newpath;
}
...
Turns out that the time to build the map is neglible (< 5ms, see
previous comments), however the total time spent on 'path aliasing' it
about 70ms per page! 50ms of these 70ms are spent on $map =
drupal_get_path_map(). The remaining 20ms is spent on $newpath =
array_search($path, $map).
The first call to drupal_get_path_map() takes 3 to 5 ms, each
subsequent call takes about 0.3 ms. Searching the array costs 0.1 ms.
However, if you have to do this 130+ times, this adds up to a whopping
70 ms. Remind that we have 321 aliases in our map.
As drupal_get_path_alias() is typically called from code>url(), which
in turn is typically called from l() I set out to investigate the time
spent in l(). Looks like l() easily gets called 120 times/page, and
that each call to l() costs about 0.9 ms. That is about 2 or 3 times
the cost of the /average SQL query/. The total time spent in l() is
115 ms!
------------------------------------------------------------------------
May 9, 2005 - 00:25 : adrian
This is a complete aside, and probably off-topic, but I would like to
mention that I was actually
looking at rewriting url() to be able to handle 'external urls' ,
because I want to do aliases using the site subdomain, like for
instance :
http://category.sitename.com/article/title_goes_here -> node/23
Rewriting url to allow this would also allow us to use l() for external
links of any kind, getting rid of a bunch of inline html.
1
0