Comments for SEO friendly redirects in Interchange

[phinjensen]

Comments for https://www.endpointdev.com/blog/2010/10/seo-friendly-redirects-in-interchange/ By Richard Templet

To enter a comment:

1. Log in to GitHub
2. Leave a comment on this issue.

[phinjensen]

original author: Jon Jensen
date: 2010-10-18T23:04:53-04:00

That makes sense. Just to be clear, your table is not actually storing full URLs with http://hostname/ etc., but just the URI starting with /path/to/wherver, right?

A couple of questions about the specific implementation:

What's the reason for interpolating the strings of the hash keys such as $hashref->{"$old"} instead of simply using the string as a hash key directly, as $hashref->{$old}?

And wouldn't it be more efficient to have your SELECT statement fetch only the relevant URI for $current_url instead of the whole table which you then search via a hash? You'd then be reading at most 1 record instead of the whole table each time.

I once did something similar in mod_perl and had 10,000 or more mappings so I definitely wouldn't have wanted to read the whole table on each request.

[phinjensen]

original author: Ron Phipps
date: 2010-10-19T01:12:13-04:00

Hey Jon,

I think that Richard is reading the entire table in on the first access and then on future reads he's looking up the values from a hash in scratch.

[phinjensen]

original author: Richard Templet
date: 2010-10-19T07:54:22-04:00

Jon,

Correct, the data in the table is only the URI. It's been a while since I wrote the original but I think the purpose behind using the quotes in the hash key was because URIs with hyphens were getting subtracted and not working properly. Ron is correct on the database query section, the first page load it creates $Scratch->{redirects} then each page load after that, it reads from the hashref instead of hitting the database each time.

[phinjensen]

original author: Jon Jensen
date: 2010-10-19T09:20:28-04:00

Ron, actually, now I notice that the table's being read into $Scratch, which gets stored in the session -- each individual session. That actually seems worse to me! Richard, what's your line of reasoning? If you've only got a handful of redirects it probably doesn't matter much, but with very many this doesn't seem like a good approach.

[phinjensen]

original author: Jon Jensen
date: 2010-10-19T09:23:20-04:00

On the quoting in Perl, there is no difference between $hashref->{"$someval"} and $hashref->{$someval} except that the quoted one is slower. It definitely would not do anything to hyphens. That's easy to confirm in a little test script.

[phinjensen]

original author: Richard Templet
date: 2010-10-19T09:35:46-04:00

The reasoning behind using the session was to limit the amount of database queries. I figured a trade off of some session bloat versus another database query per page view was worth it. The biggest user of this only has about 300 records in their table so I didn't feel the bloat was so bad that it would cripple Interchange. I know Interchange has the ability to create 'memory' tables and that might be a better way to do it but I've never used those on a production system so I don't if they are good or bad.

[phinjensen]

original author: Jon Jensen
date: 2010-10-19T09:47:21-04:00

This is a good case for using Interchange's memory tables. They get loaded up once, and all the reads are cheap after that. You wouldn't want to use them with a huge table, but only 300 records like this would be fine.

The only problem in either case is having it pick up updates to the table.

[phinjensen]

original author: Richard Templet
date: 2010-10-19T09:52:24-04:00

Right because any changes to the table would require a restart of Interchange to take affect, correct?

[phinjensen]

original author: Jon Jensen
date: 2010-10-19T10:10:43-04:00

Yeah, and the way you're doing it now the list is frozen in each session, so you'd have to purge that before they'd get any changes.

Probably better to use memcached or something lightweight for this than anything built into Interchange, actually.