I can imagine that you have **** payload of load on your servers, since the search button doesn't let you decide what subgroup of texts you want to search in the first place. But do you think it's a better option to have everyone clicking for hours trough some topics before reaching his he head posted before weekend???

aye I know I know, we'd like to have it enabled beleive me :) but alas for the moment at least it's the way things must be. As soon as we can re-enable it we will, trust me.

crono im sure if you send them no less than 200 gigs of RAID5d 15k RPM storage with 128 megs on a mylex scsi controller w/ dual 1.4 athlonMPs powering it that they would love to transition the database over and reenable the search function.

until then learn to sort by poster.

What goes to the database, well, is it here realy needed? Mainly all they need to do is to search trough a whole ton of texts associated with keys( topics ).
A simple Hash would be enough.
If you use a full featured database, maybe even a relational one, you have ALWAYS the overhead of additional realation resolving, what makes it utterly slow compared to some good old style key/value hashs.
I mean, even oracle isn't faster then a hashed table ( we'r not even talking about access or db2 here ).
Probably you wont need a bunch of highend hardware, but some good assembly/unix cgi scripts getting the job done quickly and cheap( runtime ). Could even help to hold recent topics in cache of a deamon for quick searching trough ( out of ram ).
If you want it easier you could programm your deamon plus cgi in c or c++ even.
And belive me, not php or pearl, not the matter how good written, will ever be able to gain the speed compiled programms gain. Out of simple limits no script language can surpass the speed of compiled code. They are out of simple physical reasons at least 15fold slower then compiled code.
The gain would sure be worth the buck.

Cheers

Cronolyth...yes, not having Search is a bit problematic at the moment. ;)

However, if you had read my sticky post at the top of the Valley, titled Where's My Topic?, you would have noticed that I suggested a way topic-starters (or readers) could find their threads more easily. At the bottom of each thread page you will see a link...Subscribe To This Thread. Clicking on that will add a link to a thread to your User Control Panel...so you just have to click the User CP button at the top of the screen to get access to all threads to which you have subscribed. :)

I hope that helps. :)

Well, while 'Subscribe To This Thread' option is nice (although kinda pointless wince in your user settings you are always subscribed to the threads you post into, and after all, that's most likely the ones you'Re interested in) it still doesn't solve the problem if you actualkly search for some info. I mean, how many cheats threads are there? How many asking on how to turn on dismemberment? Walkthrough? Sabermoves?

The list is long. The storage sure is no problem I believe. Usually servers have one thing enough, space. The real problem is CPU power. Now you think, why that, I can search any text file in milliseconds, but did you ever try to search a board with thousands of text files? If they enable the search fucntion it should be limited to only one room. Maybe even think about limiting it to poster or topic only. The topic usually contains the info I want and it would save a lot of server power. Of course I don't know how customizable this Forum is.

Okay guys, let me tell you some technical stuff:
LucasForums uses the vBulletin program, that creates a search index table (MySQL). At the moment this table has the size of 200 MBytes. LucasForums is hosted on its own dedicated server (PIII 1Ghz 512 MByte RAM).

So if somebody starts a search it goes through this 200 MByte table every time. Doings this a few times is okay, but 50 people doing this at the same time all the day is too much for the current server configuration.

LFNetwork is aware of that problem.

So please understand that we disabled the search function to smaller the amount of server overloads.

Visac

Originally posted by Visac
At the moment this table has the size of 200 MBytes. LucasForums is hosted on its own dedicated server (PIII 1Ghz 512 MByte RAM).


Thanks Visac, I was going to post some similar info, but I had no idea on the server specs or the size of the table. :eek:

vBulletin uses a very inefficient method of searching, hopefully they'll re-examine that function in the next version.

And that was just the search table =)

More LucasForums facts:

Entire database size: 500 MBytes
Number of records: over 8,5 million

And that is without all the graphics you see on the page.


Visac

would it be possible ot get the the search feature enabled?
bb

God knows it would save us from having so many multiple threads on the same topics...

--R--

it was disabled to help reduce the workload that the sever had to take i belive, i dont know the mechanics of it, but im sure it wasnt for no reason at all...

But wasn't this supposed to be a NEW and INDEPENDENT server just for the forums?

^ Yes it is.

I really need to find a post with some scripting in it and I can't because its disabled. C'mon, just for a couple hours.

it doesnt work now? i just used it a week ago or so...

When will the search be enabled as I am pretty new at this and searching on these vbulletin is a very good resource and it being disabled means I am most probably asking questions other people have asked before.


Which means more posts on your server due to people asking the same questions over and over again.



:)



Thanks

Gary

Then again, the search table is actually 200 megs. I think all those repeat posts will be of less size.

Read the rest of the 'searching disabled', etc posts.