Do we need a 10 second delay for searches?

[Austin]

These types of things really irritate me, idk why. Just cus it seems like data is so cheap these days, what's the point of delaying it 10 seconds?

[Chip]

EC is a totally free resource that generates zero income for anyone. Our site is hosted on a server that has many other sites on it, and the hosting of EC's site is donated to the EC community by the company that originally set up EC. One of the very minimal limitations they have to deal with is managing CPU resources. (It's CPU resources, not data transfer, that is gobbled up by search functions.) So the very minimal 10 second time between searches helps to ensure that EC is a "good neighbor" to the other sites we share our server with.

Just FYI, the overwhelming majority of vBulletin sites with our volume of traffic have delays of 30 to 60, and sometimes 90 or 120 seconds, between searches, so 10 seconds is pretty much nothing in comparison.

[Hemera]

Yeah I've been on sites that do that, and really I don't mind it. I get the rule and the reasons behind it. It's not really all that bad

[Austin]

Oh okay, I didn't realized it used much CPU or w/e.

[Mad Man L]

I can testify to that. I have been a member on a different vBulletin forum, and you have to wait 60 seconds between searches. It's annoying. But with so much traffic, you need to do something to avoid the server crashing.

[Paul_UK]

I can confirm from another forum I run that searches with vBulletin do hit the CPU quite hard. It causes a lot of database activity on large forums, even when the database tables are indexed. It'll be interesting to see whether the new vBulletin is any better in that regard when the site is updated in due course.

[Chip]

If anything, vB4 is worse, based on my experience with one of the other forums I manage. They've cleaned it up a bit from the original 4.0 release (which was slow as molasses) to 4.1.x (whatever the current release is) but it is still a bigger resource hog than 3.x.

[Filip]

Well, I'm a member on a much larger site, and they just don't have any search AT ALL!

One handy trick is that google sometimes works well enough as a substitute.
Use the term: "site:emptyclosets.com" in addition to what you're looking for. Doesn't work on the really recent threads, but google is usually pretty good at indexing sites.

[Chip]

Originally Posted by Filip

One handy trick is that google sometimes works well enough as a substitute.
Use the term: "site:emptyclosets.com" in addition to what you're looking for. Doesn't work on the really recent threads, but google is usually pretty good at indexing sites.

Actually, that's a great idea. Our optimization software submits an updated sitemap to Google with all current threads once a day, and Google seems to be crawling several times a day, so its search results may be pretty close to current.

[Owen]

Originally Posted by Filip

Well, I'm a member on a much larger site, and they just don't have any search AT ALL!

One handy trick is that google sometimes works well enough as a substitute.
Use the term: "site:emptyclosets.com" in addition to what you're looking for. Doesn't work on the really recent threads, but google is usually pretty good at indexing sites.

That's what I use when I need to look for a thread that I remember for a specific line or something like that. Truth is that I only use the on-site search function when I need the utilities it provides, like searching by section or by poster. Any other time, I've always found using Google with a site specification to be superior.

[starfish]

It is just not the CPU, it is the disk storage also. Running a query against a large database can drive a lot of I/O. High performance storage is very expensive. Especially when you need lots of it. If you can limit the I/O you can use slower high capacity disks and save a lot of money.