Here I am

What is up with this search engine??

Attention: TDR Forum Junkies
To the point: Click this link and check out the Front Page News story(ies) where we are tracking the introduction of the 2025 Ram HD trucks.

Thanks, TDR Staff

Membership #

Short sig now in place.

This POS search engine is about worthless...



Go try a search for ABS or DTT or BD or IAT, or ANY other acronym commonly used on this site, OR how about even common words like oil or nut--

it just spits out that "can't find it if 4 letters or less" junk. WHAT GOOD IS IT???



This thing ran MUCH better without the letter count feature--can it be restored back to the old method??
 
Right now the answer is no it can't. If you look through the threads on this forum you'll see a lot of discussions about the problem with that right now. Basically in a nutshell we are having performance issues because of the software currently being used. There is a bug in mySQL which causes the server to crash under high usage. They have done a number of hardware upgrades over the last year as well as a number of software tweaks to try to stay ahead of the problem. The traffic on the site continues to increase at an incredible rate and that is not helping. The other night the server was sending out approximately 400 pages per second and transfering over 900KB per second - that is an incredible amount of bandwidth. Just six months ago the load was a 1/4 of that level. With the current host they have the largest server that is available through them. They are currently looking at a number of solutions but have to be sure that whatever solutions is decided on that it will actually solve the problem. This is not an insignificant decision as all possible solutions involve a lot of expense. It's not that the TDR isn't willing to spend the money, just that they can't simply throw money at a solution that may not work and will have to be replaced in a short period of time. Having the search engine set to 4 characters significantly reduces the load on the server and is a temporary measure to help us keep the server up and running. If the search was set back to 3 characters server busy messages would be coming up all the time, right now there's only about 5 server busy messages going out a week. The biggest problem is that once it goes into "server busy" mode then a hard crash is not far behind. I assure you it's being worked on and we're looking at all possible solutions. Thanks for your patience.



-Steve St. Laurent

Lead Moderator
 
Steve

what was the boost pressure during this time ? and how about your pyro temp ? Does this unit have a fueling box installed? What size turbo does it have and is the waste gate disabled?What about bigger injectors? can we installe a BHAF? and of course dont forget a 4" from turbo to tailpipe.



We can help you but you have to want the change , we will be your warrentee station. We have the technology, trust us Steve and dont look back!



Bomb on Buddie



:D :cool: :D
 
Originally posted by roadranger

This POS search engine is about worthless...



Go try a search for ABS or DTT or BD or IAT, or ANY other acronym commonly used on this site, OR how about even common words like oil or nut--

it just spits out that "can't find it if 4 letters or less" junk. WHAT GOOD IS IT???



This thing ran MUCH better without the letter count feature--can it be restored back to the old method??



Try adding a * at the end of a 3-letter word. ie DTT*, or IAT*

it gives the search engine a 4-character word to search for.
 
That won't work Shovelhead. If you search on DTT* it wouldn't bring up DTT but it would bring up DTTD DTTA DTTB, etc. 3 character words are not in the index so there's no way to search for 3 character words right now.



-Steve
 
That used to work?????

I just tried it and I guess we're hosed now. :confused:



It USED to work. :confused:



Oh Well... ... ... . Progress marches on..... Backwards I guess. :rolleyes:



Thanks for the update Steve.
 
Sort of worked...

Shovelhead helped me yesterday with the wildcards, but come to think of it, I had to really play games to get a successful search for "5th gear nut" 5th never came up directly.
 
Last edited:
I know it can be frustrating to have to wait 35 seconds before performing a second search, but I found that I'm more careful in entering my search criteria right the first time that way. Would it be feasible to extend that interval so as to reduce traffic enough to support 3 letter words? I would gladly wait 5 minutes between search attempts if I could find those 3 letter acronyms. This might make a suitable temporary fix while the best solution is researched.
 
The basic problem is that this software uses a keyed search in an attempt to make it quick instead of a straight text search. This causes several problems. One big problem is that each post contents has to be entered in the key indexes which takes a lot of overhead and disk space. A text search will find anything if you are patient. This one will not. There is nothing that Ken and his partners can do about it really. I've never been able to get a search to work using logical operators either. A slow text search is a lot better because it will find things.
 
Steve,

I have read the messages here and the one sent to me by Robin about the 3 letter search. It sounds like, with the research going on, that someone may be trying to re-invent the wheel. Being a computer systems engineer and consultant, it seems to me that what you are looking for has been done by many other companies and web sites. How are you going about studying the issue? Have you talked to other companies who are doing the same thing and comparing traffic volume and search methods?



There should not be any need for trial and error.
 
Research

There are a whole lot of sites over at VBulletin.com that are in the same boat as us. Right now there ISN'T a solid solution that any of them have found because its a file locking bug in the Linux version of the database server software --- not with the VBulletin forum software. All the sites are trying different things and sharing the results. Many of the ideas have helped (and been applied here) but none have completely resolved the problem.



We are not shot-gunning this nor are we blindly throwing darts at it. Steve and I each have over 15 years in the industry and we can handle the job... . We are investigating several solutions, most of which involve moving the database over to a second server using Free BSD instead of Linux. All of them are expensive resolutions because it will double, at the very least, the number of servers being used plus involve a firewall. There aren't inexpensive dual server hosting solutions when you're pushing 300-400 gigabytes of data per month. As a consultant, you are probably aware that proposing a solution with other people's money is far different than spending your own. We want a wise, well thought decision that will solve the problem because simply throwing money at it is foolhardy



Steve asked for patience and noted it will take time. No matter how much the problem is brought up it will not help resolve the problems. We ARE working on it and if anything, repeatedly bringing it up takes time away from us that could otherwise be used to resolve the problem. Thanks for your patience.
 
Admin, I think I was agreeing with you, not arguing with you. My reference to trial and error was in reference to your comment that you can't throw money at it trying a lot of different solutions.



It sounds like you are using PC's for servers and I understand its limitations. It sounds to me like the programmer has a bug, or the operating system has a bug, and this type of bug is difficult to trap. Usually code has to be added to try and trap the condition then force it to occur.



I have programmed large switches and know how difficult it can be to find a bug that appears to be load dependent. My suggestion about looking at other systems meant to look at possibly using other computers, such as a main-frame running Unix. However, I have no clue as to what your budget is, nor what software you are using, nor what would be involved with switching to a larger computer since I have no knowledge of what you are currently doing. I was merely trying to suggest some general ideas.



I won't mention the subject again since you think it takes time away from solving the problem. I have always enjoyed having input when tackling problems such as this.
 
Re: Research

Originally posted by admin

... Right now there ISN'T a solid solution that any of them have found because its a file locking bug in the Linux version of the database server software...



Are you using MySQL? What is the bug? Do you have the source? Where in the source is the bug? And why is the bug specific to Linux?



Since I generally have lots of time and have been programming Unix for 15 years, I *might* be able to do something about that large, multi-legged creature crawling up the server's shoulder.



Please to note, I'm not being pushy or impatient. Just volunteering assistance. Since MySQL is open-source, the bug should be found and the fix sent back to the maintainer, or at least to the other V-Bulletin users who are anxiously awaiting a fix.



Neal
 
SEARCH

I thought it was just me , i feel a little better now. I remember a year ago the search worked better. Well i guess i will just ask a question instead of a search. :-{} :-{} JMO
 
I've had better luck with other search engines getting results since this one has been down. A Google search for killer dowel pin netted 240 hits, most were right on track and some were to this site...



Just tried a Google search for TDR coolant, had 273 hits, didn't look at all of them but some were to this site. Try it, you can't come out worse than this one here is doing.
 
Last edited:
Back
Top