Gossamer Forum
Home : Products : Gossamer Links : Pre Sales :

Links SQL performance

Quote Reply
Links SQL performance
What kind of perfomance gains do people see between links 2.0 and linksSQL? Will links 2.0 mods work with SQL? Using SQL, would a site with 10,000 - 15,000 links on a virtual host be possible? The host we use has very high quality servers that are very fast and have an OC3 connection. I can get a server with as little as 3 other people, so it's not we would be sharing the server with 200 other accounts like on other virtual hosts. I know that a dedicated server would be the best option but it might be some time before we can fund this project. Any advice that others have had would be greatly appreciated! Thanks in advance! Pirate
Quote Reply
Re: [dvd871] Links SQL performance In reply to
>>What kind of perfomance gains do people see between links 2.0 and linksSQL?<<

A great deal. Much faster, no database corruption, more features etc...

>>Will links 2.0 mods work with SQL? <<

Sorry, no. Although a lot of mods are built in to Links SQL by default and the others are easy to convert.

>>Using SQL, would a site with 10,000 - 15,000 links on a virtual host be possible?<<

Yes probably more would be possible based on your situation.

Last edited by:

PaulW: Dec 8, 2001, 3:32 AM
Quote Reply
Re: [dvd871] Links SQL performance In reply to
The 10,000 or 15,000 links is fairly trivial for Links SQL.

The big issue is how many "hits" to your site, or more importantly, your search.cgi will you be getting per day, or per unit time? Will you be running page.cgi (dynamic) or static pages. Those are the big ones. jump.cgi uses trivial amounts of resources compared to the flat file version.

This depends on your servers RAM and CPU, and how much the other virtual servers are using. Sheer size doesn't impact Links SQL much at all. Unlike Links 2.0, where the links file had to be read each time, a relational database just makes a records request to the engine, and it returns only the "hits" based on an index search, not a full text search. Even with a "full text" search, the search is substantially more efficient than gulping in a large text file :)

As long as you have enough diskspace to house your database, you can run giant databases. Some messages were posted with estimated sizes for databases.

With relational databases, MySQL being one, database size is nowhere near as important as it is with flat file databases. Most databases are benchmarked at 1,000,000 records, which is far beyond anything a flat file can handle :)

Your ISP will probably start to complain based on your searches and jumps (and if you are using page.cgi rather than static pages). But, with moderate usage, even that is much, much more efficient than Links 2.0 flat file :) If you were ok on that with the flat file version, then you'll be ok with the SQL version most likely.

Links SQL requires more baseline horse power than the flat file version, but it uses it more efficiently, so more can be done with that power. You should be able to handle 2-3x the traffic of a flat file site, with the same overall load. Your actual mileage may vary :)

I have 2 SUN X1's on order to replace my dying Sparc 10. One will have 1gig for the webserver and Links, and the other will have 512meg for the database server. :) At that time, I'll have some idea of how it really runs. My current machine was a good machine 2.5 years ago. These new machines together are half the price, and 4-5x the power (each). I can't wait :) (Actually, I'll have 10x the RAM too :)

Once I get them installed, I'll have some idea of the actual usage from Links, since I'll be able to compare the difference between the old and new machine, as well as being able to pull MySQL out of the picture by having it on a separate machine from the webserver.

I've been impressed with what I've been able to do with the old machine, and can't wait to see what a modern machine with Solaris 8 can do :) (Yes, I run solaris, rather than Linux... )




PUGDOG� Enterprises, Inc.

The best way to contact me is to NOT use Email.
Please leave a PM here.