It seems like Tech is slowing down more and more. Every other site I go to is super fast compared to Tech. I've gotten to the point that if something doesn't load on this site within a couple of seconds I just go to another site. I understand the heavy volume here can create problems, but this site is ALWAYS sloooooooooooooow. I know the problem is not on my end because I access this site from multiple locations, all with very fast connections.

Is there any kind of upgrade being planned that will improve the speed of LS1tech???


Sorry about the bitching... it just drives me bonkers!

Thanks guys! Other than the speed, I LOVE the site!

 

i believe the board is about maxed out on speed.... and theonly way to go faster is new board software and they'd lose everything here.

 

I can tell some people need a refresher course in the search button.

Yes, its the board software that is limiting the speed. No, we won't lose everything if we were to switch software. However, there is no plan to switch software. There is nothing better to change to AFAIK. The problem lies in the database support that is currently found in the board software, or lack thereof.

 

Sorry guys, yes it IS getting slower and slower .. I'm currently working on basically recoding the entire back end of vBulletin to support a more enterprise-level database backend, which will solve the speed issues. Its not a quick or easy task though, especially with all the other things I have going on (a job, project cars, helping other folks, general LS1Tech admin duties, etc.). Please be patient!

 

I know of a better board.. i've never been a vB fan.. it costs money now, but this place makes enough of it.. you can check the board out at hondaswap.com

 

Invision Power Board -- I run that software as well on another forum. Its getting better as a package, but there's several reasons I still don't feel comfortable using it on a forum of this size (security, mainly). Its still on my radar though, and I'm very familiar with it though. I started using it when it was still a free product

 

so did i.. i love it.. it has its problems, but i dont know of anyone who had any with it.. yet.

 

FWIW, I'm archiving off some old posts temporarily to get the speed back up. Once we have a perm. solution in place, the posts will be added back into the database.

 

Thank you very much Brains. I wasn't trying to throw mud, it's just getting pretty bad IMO. I appreciate all the hard work that goes into making this board what it is.



cyphur_traq,
Sorry, maybe I should've done a seach for "slow" before I posted... I didn't mean to waste server space with something as silly as asking why the board is moving a warp turtle speed.

 

Indeed, its getting much worse, much to my chagrin. Its tough when you know what needs to be done, but its incredibly difficult to implement (ie. recoding to change database backends).

 

If you are a programmer that is also proficient in SQL and know what you are doing there should be no slowdown regardless of what database you are using. That is if it is a relational database which Im sure it is. All the querying on the database im sure is not complex and should execute very quickly if written efficiently. Whats the size of the db?

 

Would you like some help? Free of charge of course....

 

Not all databases are written in SQL. You also have to be skilled in other languages to rewrite that code such as PHP. Not sure on the exact size of the database but I will tell you its HUGE.

 

I'm not a database expert here, but when you have 1,000 members trying to post and edit posts and access threads and such simultaneously via MySQL, which (excuse me if I use somwhat incorrect terms, as again....not a database guy, I'm a network guy) locks the tables while it edits them, I understand that it runs into problems at this level of utilization.

vBulliten currently only supports MySQL AFAIK, which is why Brains started to code backend support for other database applications - which would allow a performance leap and would largely eliminate our bottleneck.

Now, if my understanding of this is flawed, please correct me. But this is how I've come to understand the situation.

 

MySQL is a strange bitch. There are different table types and varying locking strategies (table/record). But your analysis is correct. If you lock a table when someone is updating/inserting then no one else can update/insert on that table. Since my guess there is one table for the posts (exluding parent tables) then that would create a hell of a bottleneck.

For eg. (from the bottom of the home page) ...
Currently Active Users: 1025 (453 members and 572 guests)

That means only 453 users actually have write privileges. Then at most 453 could be trying to update the DB at once (unlikely). You could do analysis of the transactions to understand the number of DB writes per minute and then optimize accordingly. My guess is ~50 of those 453 are trying to update the DB at any given 10 second interval. The rest are just browsing.

 

Brains you seem like a busy guy Take your time the occasional slow downs don't bother me

 

technical - you've got it, for the most part
antagonist - you're an idiot (and a troll, but we'll get to that later)

VB does a *LOT* of database writes; updating status on the user table every page click, updating thread views, etc. As you're aware, the MyISAM storage engine doesn't support anything but a table level lock -- which means every one of those writes are blocking. Most complete quickly and don't cause a problem at all. The problem is when you have a costly query that blocks, and then you stack 500 requests right behind it in a matter of a second or two. Then the performance goes right in the can, and everyone waits. There's the option of switching to the InnoDB storage engine, but then we lose fulltext search, get slower overall performance, and a LOT more overhead. That didn't work either, performance was actually worse than MyISAM believe it or not.

PostgreSQL doesn't offer FULLTEXT indexing "in the box", but there's an add-on module that does. The biggest benefit is multi level concurrency control, which MySQL doesn't offer at all. Simply put, that means a client can read any record, even if its being updated, without blocking everyone else from doing their business. It means you can make multiple updates on the same table without issues -- ie. two or 100 people posting at once, no difference. If two people post at the same time under MySQL, everyone waits.

 

So MySQL doesn't have dirty read capabilities?

 

With InnoDB, kinda. But you lose fulltext indexing, which means falling back to either humungoid indexes, or separate huge search index tables. Not to mention the growth of the database size on disk, which means a significantly higher disk I/O cost.

MySQL is a GREAT database, for really fast application that rely on heavy amounts of selects. For applications with a mixed load, or many complex inserts/updates/deletes, you run into problems. vBulletin falls into the latter, especially when you start putting a few million posts into the database. We're being forced to temporarily archive off old posts to get the database size managable, so performance doesn't go completely in the drink.

 

Please. Databases are not written in SQL . SQL = structured query language. Queries, get it? It doesnt matter what language is used to create the program using the database . You can execute SQL from WITHIN almost any language.

If you know what you are doing.