Cached Searches

[Beorn]

Perhaps a feature could be added so that it checks for a cached search. I.e. I search for .htaccess. Then, I hit back a few times, check something, then hit forward a few times. My browser tries to reload (:mad:) the search page, but I'm confronted with the 20 second restricition notice. Could the DB be queried for the same query?

[Wayne Luke]

Actually it does something like that. However you can still only perform a search every 20 seconds on this forum. The delay is configurable by the admin though.

[dzeanah]

Newer versions of MySQL do that anyway -- queries that are identical to cached queries are answered from cached data.

Works well. No need to duplicate the effort.

[Kier]

Newer versions of MySQL do that anyway -- queries that are identical to cached queries are answered from cached data.

Works well. No need to duplicate the effort.
The vBulletin search caching system is rather more advanced than simply checking to see if the MySQL query is the same...

[dzeanah]

The vBulletin search caching system is rather more advanced than simply checking to see if the MySQL query is the same...That's fine. But it does represent additional complexity in the vB program, and I wonder how much additional performance it offers over the solution that's "free" in terms of vB's development cost.

In my experience, a "stock" MySQL 4 installation sees 45% of queries as duplicates and returns results from the query cache (that's on a machine that sees about 55 million queries per week). How much more are the vB developers going to be able to reduce the number of queries that actually hit a disk? How many man-hours will it take to implement <-> test <-> refine the caching algorithms?

It could very well be worth the effort; I'm inclined to say "leave it to the application you run on top of -- odds are the MySQL folks have already done a very good job."

[Kier]

Seeing as MySQL 4 is not even out of gamma yet, I don't really see how this helps anyone.

Rest assured, there are good reasons why we have our own caching mechanism, and seeing as it's already been written this is a moot point anyway.

[dzeanah]

Seeing as MySQL 4 is not even out of gamma yet, I don't really see how this helps anyone.
Well, I was kind of figuring on an as-yet undefined release date for vB. Leaves plenty of time for MySQL 4 to make it all the way to stable. :p

Rest assured, there are good reasons why we have our own caching mechanism, and seeing as it's already been written this is a moot point anyway.I'm curious. Can you share some of the thinking on that? Are you finding it difficult to optimize? (Really just a curiosity thing -- would love a PM if it's not appropriate here...)

[Kier]

Simply making a call to MySQL via PHP takes processing time, whether the result is pulled from MySQL's cache, or if it has to be queried fresh from the database. The search system executes several queries and we certainly wouldn't want to have to re-do all those queries just to switch from page 1 to page 2 of the search results. Using MySQL's cache wouldn't all us to do things like re-ordering the returned results without several trips to the database, or searching within search results.Those are just a few of the reasons that come to mind immediately.

[dzeanah]

Ah. That makes more sense -- instead of duplicating the functionality, you're doing the work with the highest return in vB itself -- sort of like a L1 cache vs L2 on a CPU.

[Beorn]

But none of this solves the problem of if you hit back a few times and foward a few times, you can't view the search results without waiting 20 seconds...

[Wayne Luke]

That really has nothing to do with cached searches. It is a check before vBulletin even looks for a cached search... Maybe this is something the developers can look at when their plate opens a little more.