It is a MySQL problem - in part. The default MySQL storage engine is great and very fast - for read-only access. But when there are a lot of updates (such as here), it sucks. The InnoDB transactional engine is better for updates, but it's also much, much slower. If you wnat to have a fast database engine that also handles concurrent updates/additions well, you'll have to go for an industrial strength product like Oracle or SQL Server. The other part is lousy DB access programming. It seems like connection pooling is not used, or used wrongly. Which results in the "too many sessions" error that we're being spammed with. This second part is the major culprit. A well-programmed site using MySQL can easily handle ten times the current volume on the same hardware. By the way, images are not stored as BLOBs AFAIK, they're stored as files (view the HTML source of any gallery post, and you'll find the IMG tag referring to "GalleryImage12345.jpg" - a file). I've tried working with BLOBs and Web pages, but each request then means extracting the BLOB from the database, storing it as a temporary file, and having the HTML refer to that temporary file. Not worth the trouble. Speed also depends on the use of stored procedures. I don't know what version of MySQL is being used here, older versions do not support stored procedures. A rule of thumb: a database driven (Web) application using stored procedures can handle about twice the load of the same app on the same hardware without stored procedures. The age of 'rosity leads me to suspect that stored procedures are not being used. I hope Bondware 3.0 has been put together by programmers who know how databases work. We'll see.

Bonmdware is put together by any programmer who feels like selling their code in the same way that rosity sells poser products. THey are packaged and such, with approval systems and the like. Essentially, it's a "make a module" sort of store set up for Bondware. Certain elements of Renderosity are already running on it.

Quote - (psst, khai -- wanna drive her mad?)

OMG!! Stop the insanity!! LOL Seriously, I can't unbookmark this thread!!!! It's broken!!!! tries again notices the checkmark vanish from the "Notify" box

drive her mad? why fish would I want to orange that? that gollum would be the height ant of sillyness...

gives up

svdl, good point about the stored procedures. I am positive Rosity doesn't make optimal use of them considering the SQL output on the homepage on a failed log in. There is a lot of dynamic SQL on the site. I would hope this would be changed in 3.0

BTW: There is a big difference between 1500 and 2k-plus users connecting to a DB at one time. You have to understand how DBs work, or you really don't get why Rosity is slow. MySQL is a great DB, but not for as large a scale as Rosity uses it. But then again, using an industrial-strength DB would be tough cost-wise to justify. With products like Oracle or SQL Server, you pay for things like number of processors running the software. It wouldn't be cheap. Unless you want Rosity to start recouping that money from us (either by charging vendors more for purchases, or charging membership) you may have to deal with a lower standard of performance.

Attached Link: http://asktom.oracle.com/pls/ask/f?p=4950:8:::::F4950_P8_DISPLAYID:587775185638

The lack of stored procedures would definitely make a difference. Since Oracle bought InnoDB, the whole MySQL picture is kind of up in the air at the moment. I've read different opinions regarding BLOBs. Though most seem to favor using the file system for binary files, I've also seen the other opinion, depending on things like whether the binary data will be updated or not etc. One plus for BLOBs is ease of administration, backup replication, security etc. You have one only thing to worry about, the DB. Store the images in their own table linked by a foreign key. Applications like TerraServer are serving up more image data than all the naked Vickis ever rendered but they're using SQL Server, high performance clustering and presumably a solid design. AFAIK, you don't have to use intermediate files, you can stream the binary data from the DB directly to the page using Response.BinaryWrite under ASP and CF has something similar.

I thought capacity might be a problem but in looking at some of the sites that use MySql, you have Friendster, Ticketmaster and Google to name a few. No way dos 'Rosity even begin to play in that league. Those folks have a real enterprise level setup though. You can't just throw together some whitebox servers, free software and some Cat 5 and go. Regardless of infrastructure though, it's hard to think of any site on the whole WWW as slow as this one can be.

The fun is, an industrial-strenght DB engine CAN be cheap. Just set up the app according to the 3-tier model, use per-client licensing (only the middle tier servers need a license, so a site like this would need about 5-10 licenses, at most), and you're ready for less than $10,000 in one-time licenses. Peanuts for a company this size. Of course, this is assuming you're using MS SQL Server. Oracle is about 10 times as expensive.

Attached Link: http://www.ants.com/

Yeah, yon need COM+ or Tuxedo, something in the middle handling transactions. Theres a new DB called ANTS looks very interesting.

sighs

Acadia.. you can simply disregard the ebot. You'll only get a new ebot if you visit the thread :o) So in essence, by continuing to post "sighs" you're only triggering a new ebot :o) That's what I always do when I want to stop following something.

Acadia, suicide is always an option... ;) (that's sarcasm, my friends).

Well, let's just say that Bondware decides to go the route of an enterprise-level DB. We would still need to be patient with them, since there would be a ton of code to rewrite.

Also, there is the issue that according to an earlier post in thread, they are running Linux boxes. SQL Server won't run on Linux. I don't know offhand if Oracle has a Linux install, but the cost would be too high anyway.

Either way, the SQL would need to be rewritten for whatever DB the data was migrated to. All DBs have their own version of SQL, so it isn't just a matter of changing the installed DB.

No matter what decisions Bondware makes, it's going to take a bit of time before it's done.