I am proposing a 10 user SQL Express solution and need to be able to give them an idea as to what would prompt them to do an upgrade to Full SQL.
You should consider upgrading as you approach the limit of the database size. http://blogs.msdn.com/b/sqlexpress/archive/2010/04/21/database-size-limit-increased-to-10gb-in-sql-server-2008-r2-express.aspx. Performance of the db slows down as you come close to the limit. So to limit downtime and lag, you should upgrade to full SQL before you hit it.
Hi Guys,
I'm running into this same conundrum. We have a customer with a 4 user system and 1.7 million documents in the system now (and counting). We are starting to see a slow down when searching (text in particular). They are using LF 9.2.1 and I have just re-indexed the repository to see if re-indexing/optimizing the search catalog would speed things up but it made no difference. Tried adding more cores and more RAM to the server but again this made little difference. It seems there is a 'ceiling' almost that can be hit on a SQL express system.
From a Laserfiche stand point, at what point should you make the jump from SQL Express to a full SQL license model? Is it purely driven from the DB size or are there other considerations here also?
I remember with Laserfiche team I think there was a limit of 1M documents, surely it's the same or thereabouts for Avante for SQL express, or not? (even though it's not enforced)
I've had a look through various white papers but none really mention making the switch from one to another, just talk about a starting point. Any advice much appreciated.
Cheers!
The article Ray linked to above lays out the hard limit of 10 GB of storage. It also alludes to the RAM and CPU limitations present, which could lead you to upgrade long before you reach the storage limit. With only 1 GB or RAM allocated, it means that most of your database will not be held in memory. When the process has to pull data from the hard drive performance will suffer. Using a SSD will reduce the pain, but it's still not going to be as fast as it would be if more of the database was in RAM. It's not really possible to give an estimate as to when you might start feeling this, as different customers will have different-sized tables as well as different access patterns. The single CPU will also limit concurrency, which you may notice as you get more simultaneous active users.
For text searches, results are returned by the Laserfiche Full Text Search service, so the version of SQL you're using isn't a direct factor for performance. It will come into play as LFS applies security and retrieves the desired columns, but this happens for any kind of search. What I mean is that slow text searches (compared to non-text searches of comparable size) suggest that LFFTS might benefit from more resources, but that's going to be an decision independent of what you decide to do with SQL.
Thanks Brian, very helpful! 