There is no way a whole table would be locked when a record is edited or updated. You are mistake. sir.

 

I don't feel right complaining since it's a free site to browse, but the slowness in agrivating. I hope it gets fixed very soon.

 

I am neither an idiot or a troll . Im the proud owner of a very fast 02 Z28. I am just tired of reading all the stupid posts. A different viewpoint is all it is.
VB or any other language will not do anything its not instructed to do.

Ever hear of a buffer file? Guess what it does?

 

 

must be because it dosent have an LS1...

 

Antagonist, glad to see that you live up to your handle. This thread WAS a constructive conversation until you came in. If you do not want to offer useful information, feel free to stay out of it from here on out. Just b/c you're butthurt b/c of a little comment on the internet doesn't mean you have to retaliate by acting like a 3 year old. Its very apparent to everyone in here you are the one here that don't know what you're talking about.

Seeing as Brains here has been working on the database for the past few years, I'm more inclined to trust him on this one. Argue with us all you want, its just going to provide me with some humor

 

By arguing with Brains your just going to waste precious time he could put to the site

 

Kind of ironic....i got a database error message while trying to view the second page of this thread.

 

I have been getting several of these every day now for the last week-10 days.

 

SQL is the language that extracts/updates/maintains the information to and from the database.
You must have a language that executes the SQL commands because it cannot interface with the user by itself in a simplistic form. Think of it more as a script that needs a runtime interpreter. The point I was trying to make is that this site is not just driven by SQL, there is a whole lot more to it.
But what the hell do I know, I just write and maintain database code for a major corporation.



He is talking about Virtual Bulletin not Visual Basic
You remind me of this new guy at work "he has taken a SQL class in college so he knows everything"



You dont use files to buffer for fast execution because the limitations of I/O hardware. You use variables that are managed in memory, usually varchars , ints, etc...

 

Antagonist definitely sounds like a wet-behind-the-ears still-in-school kind of kid who thinks he's got a handle on everything computer related because he took a beginners programming class. BECAUSE if he had any experience, he'd fully understand what and why, and not make incorrect statements like " There is no way a whole table would be locked when a record is edited or updated. You are mistake. sir."

Since you posess SOO much knowledge and talent, I'm simply AMAZED you haven't written your own forum software and become a millionaire

Anyway, allow me to enlighten you, grasshopper:

 

I too have noticed it has been slow, mainly at night.

I'm glad to hear that you guys are working on the problem.

With all the sponsors that LS1tech.com has and what each and everyone pays to be a sponsor, money should not be a problem of making this board faster.

 

Brains - From a fellow Forum Coder to another quit waisting your time smacking the uneducated back into their holes and work on that code to speed things up, unless yer taking a stress break.

It's usually a thankless job, but I'll say thank you for your time. After all you did respond to my PM about a database issue a while back.

He has no clue what he's talking about, and everyone can see that.


Antagonist - for running my little site (tiny in comparison to LS1 Tech) you have to use SQL, VBA, HTML & JSP, not to mention anything about the Hardware/Operating System/Applications side.

If you feel froggy, try taking on something like my work environment here at the State of Texas. 6000 concurrent connections, 24/7 support, millions of records, over 1 million lines of code. Daily each programmer has to use SQL, PL/SQL, HTML, JAVA, JavaScript, C++.

We have to support Tablet PC's, wireless access, high speed access, dial up access, encryption, and a million other things, just so our users can access a database. There is so much more to it all than just SQL.

Your statement is like saying "Fixing a cracked block is easy, it's just metal." Which in theory is correct, but for practical usage, is total BS.

How about I give you a hot steaming cup of:

 

Ok so lets look at this from a performance stance Can we OVERCLOCK the database? Get some watercooling? Or is this just about code efficiency
J/K

What does corvetteforum.com use? They have some strange archiving that archives things very quickly and if you want to search the archives you have to click on a specific section of the forum.

Just throwing that out there. I'm sure you guys have exhausted all possible routes already.


PS. Ban him Travis!

 

CF does a lot of archiving, which moves things out of the main post and thread tables. Its kind of a pain in the butt to search because of it, and is the main reason we've been hesitant to follow suit. With me converting all the queries to be SQL92 compliant, it opens us up to run any database server that PHP offers support for (in one form or another, be it a library module or ODBC). There's no abstraction layer in the code however, so the conversion is MUCH more involved than simply changing MySQL-specific language/functions in the queries. I'm having to alter a *LOT* of the source because they coded directly against MySQL and its unique way of doing things. For instance, getting the last inserted auto_increment'ed column's value for a record -- MySQL has a function last_insert_id(), that will pull the last ID without having to specify which table you want the value from. Nobody else is that "lazy" about it, so the code should be changed to specify -- and there's a LOT of locations to do so.

Then there's performance tuning differences between database engines. One of the reasons why switching over to even InnoDB on MySQL doesn't pan out well, is the use of the ever-so-common SELECT COUNT(*). With the MyISAM storage engine, this isn't a costly call at all -- it executes instantaneously because with table locking the number of records is always the total number of rows in the table. With a storage engine that supports multi-level concurrency, you could have any number of records in flux -- inserts, deletes, etc. So, a COUNT(*) is very costly - especially on large tables. vBulletin makes heavy use of COUNT(*) as well, almost every page in fact. That will have to be rewritten as well.

The only "easy" solution I've come up with, and its one I may very well do first, is to segment the site. Basically turn the forums into a group of forums. vBulletin stores all the posts in one table, and all the threads in one table. That means we have over 3 million rows in the post table. It also means the whole thing is locked on updates, which is why the entire site freezes up when locks are held. By segmenting, I can reduce that to one pair of post/thread tables per group of forums, or possibly per forum. That would reduce the number of rows considerably, and severe lock times would only affect one or a small set of forums.

 

Yep, IIRC, what CorvetteForum does is move posts out of the active database (archive them) very quickly, as well as having much more limited search capabilities / indexing. LS1Tech doesn't want to do junk like that

 

You have apparently never used MySQL or SQL Sever (older versions) not to mention Access. Even with a page lock you can still lock the whole table if it's small enough.

Yes but can you execute SQL against every DB...

 

That is precisely the problem you *tend* to find with open source PHP applications. They run fast out of the box because of that but they don't scale well. Case in point... ls1tech.com

 

The problem with open sources is that most contributors dont have a platform where they can really stress test the code the way ls1tech stresses it.

 

Some, but not all. Best case example is Apache. Many Java technologies fall into that category as well e.g. Struts.