Search

A new extension, "Improved Page Resolve" is now available for download. Comments and feedback can be left here but if you discover any issues, please post it on the issue tracker.

Improved Page Resolve allows you to create index page with parameters and show it without a need to include its handle in URL.

Does this have any additional features compared to Root Page Params?

Hmm... looks like it does not. I wrote it long time ago, before Root Page Params (i compared dates of first commits :), and noticed it's not listed here.

I can remove it to keep list of extensions clean.

I think that they work a bit different way (just looking at the code).

This extension has less features, but also keeps overall number of database calls the same (because data it gets from database is used by Frontpage later).

Root Page Params calls Frontend->resolvePage again, so that function is run twice. I understand that's needed for additional features, but if someone does not need them, that will just make things slower (probably just a tiny bit, but still).

I don't think we need two extensions that do the same thing.

It is not exactly the same, but feel free to remove it - it will stay on github if anyone else finds it useful (like i do, obviously :).

Improved Page Resolve updated to version 1.2 on 29th of June 2012

I happened to install 1.1 in 2.3 yesterday, which was working!, Updated anyway... Cheers!

Thanks :). Maybe it's something with my setup here, but it did not handle situation when index has parameters, and there is a page, e.g., "one" - when i tried to access said page, i was getting index page instead. 1.2 fixes that.

This was all dealt with when URL Router and Root Page Params were merged in version 1, and now version 2.

Also, params from the root will be a core feature very soon.

This was all dealt with when URL Router and Root Page Params were merged in version 1, and now version 2.

Unless something has changed there, they use more resources than this extension. I needed a simple "params to index" thing, without any other features, with as little work for a server as possible. That is why this extension uses only a single SQL query, which is used in place of Symphony's query, which means that total number of queries does not change at all.

Also, params from the root will be a core feature very soon.

That will be great, especially if it will not slow down execution when compared to current implementation :).

I would like to put one thing straight: while you are very convinced your solution is faster than the Root Page Params and URL Router solutions, I have to disagree.

The RPP adds one query, sure, but this is a very light, cached query, which is completely optimized by the indexes in your table, and the database itself. In effect, the query itself is nearly for free, so there is only the overhead of the connection between PHP and MySQL. Because most small systems will have these installed on the same server the latency here is minimal. Of course, if you are making thousands of queries this is a different story, because you will not be able to execute them at the same time. Yet, this is not the case here, as we are talking about a single query extra.

Now, looking at your query, you are using lots of MYSQL functions like COALESCE, that make it harder for MySQL to cache the results, and you are sorting on three different fields, which is quite expensive. So, even though you are cutting away one query you might put a heavier load on the MySQL server.

All in all I would have to benchmark them, but I do not think you an easily say: my solution is cheaper because it uses one query less.

Also, if there are differences they are most likely very, very small. Every single datasource without filters and a limit with one entry will be heavier. So please, if you are optimizing, look at these places first, it will be more rewarding and a lot less difficult.

For everybody interested, here are the two queries compared:

  • RPP:

SELECT * FROM sym_pages WHEREpath%s ANDhandle= '%s' LIMIT 1

  • IPR:

"SELECT p.*, t.type FROM sym_pages p LEFT JOIN sym_pages_types t ON p.id = t.page_id AND t.type = 'index' WHERE POSITION(CONCAT_WS('/', p.path, p.handle) IN '%s') = 1 OR (t.type = 'index' AND p.params IS NOT NULL AND (LENGTH(p.params)-LENGTH(REPLACE(COALESCE(p.params,''), '/', ''))+1) >= %d) ORDER BY t.type != 'index' ASC, (LENGTH(p.path)-LENGTH(REPLACE(COALESCE(p.path,''), '/', ''))+1) DESC, p.sortorder DESC LIMIT 1"

creativedutchmen, of course my query is heavier, but in my case it was better to make database work more than to add PHP-database calls, and additional loops in PHP. Like with everything else, one has to select best solution for a case, and there is no universally best solution :).

My query could be optimized a lot if some of the stuff was pre-calculated (it could create separate table with needed data, which would be faster than working on raw text).

My query could be optimized a lot

But why would you put yourself through all that pain? What do you think you are gaining? Of course you could replace your complex query by something even more complex and optimized, but what about maintainability? What if the table containing the pages changes?

but in my case it was better to make database work more than to add PHP-database calls, and additional loops in PHP

How do you know? Have you benchmarked the different solutions? Please, before making claims about speed and performance, at least come up with some numbers!

Of course you could replace your complex query by something even more complex and optimized, but what about maintainability?

Not more complex, but a lot simpler - if the stuff that now has to be calculated from text, could be just read from pre-calculated values.

How do you know? Have you benchmarked the different solutions? Please, before making claims about speed and performance, at least come up with some numbers!

Database was on separate server and we did not have many pages. Which means that there was not many calculations on text, but communication between PHP and database could take time (even if database is on the same server, there is still some work required to pass data between PHP and database). If You have many pages (hundreds?) and database is on the same server as PHP, then heavier query (with calculations on text) will surely be less optimal solution. If You have like ten pages and database on separate server, then it will be more optimal solution. If i, or someone else, implement pre-calculations for paths and param count, then it probably will be better solution in more cases.

Sorry for keeping this (very unimportant) discussion alive for far too long. But I couldn't resist.

So, I did a few tests locally, and the results surprise me a bit. My measurements are done by adding: $time = microtime(true); to the top, and echo (microtime(true) - $time)*1000; at the bottom of both the resolving functions of the IPR and the RPP.

My server is a 2.4GHz macbook pro with 4GB of RAM, on nearly idle load. My installation has 4 pages, and the database is installed locally. I have not added indexes or changed anything to the default tables created by Symphony.

The results below are taken from 10 different measurements, at random intervals. I've also calculated the standard deviation, to show how consistent the results were:

Improved page resolve:
mean: 1.043343544 ms
stddev: 0.107984782 ms

root page params:
mean: 0.003933907 ms
stddev: 0.000835411 ms

So, in my tests, the root page params extension is over 250 times faster than the improved page resolve.

Now, your biggest concern is that the query has to be executed twice (once for the rpp, and then once for Symphony itself). This is very true, so in the worst case the rpp results have to be doubled.

Next up, I installed both extensions on a live server, which happens to have its database installed on a separate machine. Both extensions perform slightly worse (because of the slower server, probably). This time I only took 3 measurements for every extension, because I didn't want to mess up actual visitors.

The results here are a bit different, but still very interesting:

improved page resolve:
mean: 2.180258433 ms
stddev: 2.08577142 ms (!)

root page params:
mean: 0.010967255 ms
stddev: 0.000953674 ms

The big fluctiation on the improved page resolve can be explained by the fact that the database is on a seperate server, which apparently suffers from load a bit more than the webserver. Again, the results for the rpp might have to be doubled to take everything into account.

Conclusion: there is a huge relative performance difference between the rpp and the ipr, both with local and separate databases. In absolute terms, however, the results are completely irrelevant, as your network latency will most likely vary with over ten times the worst result measured in this test.

note: yes, I am having exams this week, and I am using this as a way out. Sorry!

note: yes, I am having exams this week, and I am using this as a way out. Sorry!

If you put the same effort into your exams, you'll do just fine ;-)

creativedutchmen, thanks for the results! IPR got its a** kicked :(. Can i ask how many pages there are on the live server?

your network latency will most likely vary with over ten times the worst result measured in this test

Unfortunately :(.

Could You create table like this:

CREATE TABLE `sym_pages_resolve` (`page_id` int unsigned not null, `path` varchar(255), `params_count` int unsigned not null default 0, UNIQUE KEY `page_id` (`page_id`), INDEX `path` (`path`));
INSERT INTO `sym_pages_resolve` (`page_id`,`path`,`params_count`) SELECT id, CONCAT_WS('/', p.path, p.handle, '%'), (LENGTH(p.params)-LENGTH(REPLACE(COALESCE(p.params,''), '/', ''))+1) FROM `sym_pages` p;

and then test with this SQL for IPR:

SELECT p.*, t.type FROM sym_pages p LEFT JOIN sym_pages_types t ON p.id = t.page_id AND t.type = 'index' LEFT JOIN `sym_pages_resolve` pr ON pr.page_id = p.id WHERE '%s' LIKE pr.path OR (t.type = 'index' AND pr.params_count >= %d) ORDER BY t.type != 'index' ASC, pr.params_count DESC, p.sortorder DESC LIMIT 1

?

Create an account or sign in to comment.

Symphony • Open Source XSLT CMS

Server Requirements

  • PHP 5.3-5.6 or 7.0-7.3
  • PHP's LibXML module, with the XSLT extension enabled (--with-xsl)
  • MySQL 5.5 or above
  • An Apache or Litespeed webserver
  • Apache's mod_rewrite module or equivalent

Compatible Hosts

Sign in

Login details