Does Extended Path Aliases has some side effect on the performance?

@kurtzhong:
Thanks for your interest and it's a fair question.
I would be highly surprised if there was a noticeable difference, as it does so little (but does it well haha!).
But I'll promise to get back to you with some before & after figures when I next find some spare time.

How did you benchmark your timings and what are your figures?
Cheers,
Rik

CLosed due to inactivity.

The simple answer is yes. You will see quite a performance hit for uncached l() requests, as they will now need to look up in path_alias table.

This is mostly a more general Drupal related issue, but the additional requests to drupal_lookup_path will cause slowdowns on cache misses and this function is called by path_alias_xt.

Here's an example of a page load (See Attached Image).

Hi j0rd,

Thanks for the profiling.

Yes, naturally there we be a number of lookups for aliases of the base paths.

What is of greater interest than the numbers you've collected is the actual time in milliseconds that the module adds.
If it is, say, 100 milliseconds on, say, an average page-load of 2-3 seconds, then this to me is quite acceptable.
Also depends of course on what kind of page you're testing on. If it's a page with many links on it, but little else, then the relative contribution of the module is greater than when it's a page heavy with large images, Views etc.

Not sure how to improve the code. A lightweight "cache" is easy to implement, but will only have a serious impact if the same links are requested repeatedly.

What do you suggest?

Rik

I'd personally be completely happy to move every single alias look up into the cache backend, regardless of how often they're looked up. For my website, the cache backend is redis and thus these are in memory lookups. Most Drupal installs the cache backend is mysql, and thus the difference is minimal or potentially worse. But I'd be completely happy to store every single extended path alias in cache (it would not be more than a couple megs of memory, and would reduce database hits for me). And hopefully that would improve my page loads.

This is probably more of a problem with Drupal path router, than path_alias_xt. But I'll take my improvements anywhere.

---

First for the record let me state, that the website I'm working on does not use page or block caches.

While an un-optimized Drupal page requests (non-cached) can be 2-3 seconds, I've managed to get all my uncached page requests down to ~300-600 ms. Homepage and "Search" pages for me are ~300ms, and profile pages (full node page display) is currently ~500 ms. I can probably get the profile pages down to ~100ms, with some manual caches though, which I have no done yet.

So for me, 128 milliseconds performing path lookups is the obvious next win on reducing this. That's because, that's about 25-50% of over all page execution time. So I would say, that drupal_lookup_path() is one of my largest outstanding performance issues currently. Getting these into memory should fix this (for me).

If you want to see the example of the website in action it's:
http://www.yogatrail.com
Lots of links, lots of nodes, nodes all have lots of fields, page and block cache both disabled.

Reason I'm not using block or page caches, is because most pages are specific depending on the users location. And every node, has unique blocks attached to them depending on their location as well.

All the caching I'm using is via cache_get/cache_set and improvements for page times have been a mix of manually setting caches via cache_set/get, entitycache, redis as cache backend and I also avoid the database entirely for many of my blocks (pulling data directly from Apache Solr). Oh and not using views, because views is slow. I've also avoided using l() for certain links which happen a lot because they don't change and the alias look-ups take too long.

---

As for how I would improve this problem? I have no idea, never looked into yet. Anything with paths in Drupal I know is quite complex, and very easy to break things. This is why it's currently an outstanding issue for me.

---

If you need me to test patches or review code, I'm available for that. But until I really want to tackle this problem, I won't be actively developing a solution. But I figured I'd chime in on this issue.

UPDATE: I just re-turned on xhprof on my production server and reviewed my of my most common page types. Also between my first screenshot and now, I upgraded from path_alias_xt from 1.0 to 1.1 and thus path_alias_xt_get_extended_path_alias function is gone.

While durpal_lookup_path() is still quite a large performance burden (between 5-10% of max execution time), it's no where near as bad as my previous xhprof screenshot would suggest.

Additionally path_alias_xt_url_outbound_alter() and path_alias_xt_url_inbound_alter() account for very short periods of time, maybe 1-2 miliseconds, which is a performance hit I can deal with.

These function though, will increase the amount of function calls to expensive function calls like drupal_lookup_path(), so I really think, that's where the optimization at the end of the day needs to go.

I also did a short code review of 1.1, and it doesn't look like there's anything which could really be improved. _path_alias_xt_get_menu_item uses db_query, which is about as fast as Drupal queries get and otherwise it just looks like you're calling core functions.

Hi j0rd,
Thank you for your comprehensive analysis.

And very lovely site, that http://www.yogatrail.com. Very clean & modern looking.

[NB: Some images looking a bit so-so on my Retina display... (sorry, just teasing)]

So, after upgrading to path_alias_xt 7.x-1.1, there appear to be few quick wins, if I understand you correctly.

What I'm wondering though is: how many (which percentage) of your users really benefit from Extended Path Aliases? Doesn't the module really come into play for the administrative pages, i.e. pages that anonymous users would not have access to anyway?

If to you ultimate performance is everything, then maybe it's worthwhile sacrificing some handy features for yourself and other admins in favour of better performance for the general public visiting your site?

Cheers,
Rik

Closing due to inactivity.
Looks like latest code near optimal. Not much room for improvement.