Hi Richard, Thanks for your comprehensive reply, that will certainly give us some stuff to start looking at. Yes we do mix pre-execute with render tags, but I don't think that they are heavily nested or majorly complex, but we can review them to see if we can reduce it. We have noticed the load on the db, if I remember correctly we counted 30 open connections to the db at one time during debugging, however I think it is unlikely that we will be able to get a separate db server, but the load generated by the other dbs on the server is not high and shouldn't be causing an issue. With the server - again we have noticed load, but nothing that should be crippling. With the publishing times - I know that would be an ideal solution, and our publishes to live are restricted in time for now (Likely to be freer in future), but the publish to staging is completely ad hoc and tied into the workflow process (pages get published to staging when they are submitted to workflow). Thanks for your help, we will see if we can tweak some of that stuff.
Rich. On Jun 26, 5:48 am, "Richard Hauer (5 Limes)" <[email protected]> wrote: > Adding a separate publication server will obviously take some of the > load off your CMS box, but keep in mind that unless your Database > server is up to it you will simply move th bottleneck and you won't > see the kind of improvements you might expect. > > I would suggest that your first point of call would be some > observations on your system, trying to identify the part of the system > that is actually causing your performance problem. There are > generally 3 suspects: > 1) Template complexity - mixed pre-execute, navigation manager, render > tags, element referencing, and heavily nested templates? You might > need to look at your CMS server's RAM and I/O or better yet reduce the > complexity a bit > 2) Database overloaded - RedDot puts an enourmous OLTP load on a > database, especially during publication as every element in every > template is merged through numerous single SQL calls embedded in the > old VB COM code. It's pretty shocking really. At any rate you should > have your database hardware set up for OLTP throughput > 3) Concurrency - RedDot makes heavy use of Session state and can > consume quite a lot of RAM per user. If you have several *concurrent* > users, say 20 or more, you can start to run into memory headroom > issues. This is because a 32bit process can only access about 1.5GB > of RAM (give or take), and that means about 60MB per user or less, > plus a bit for the shared system components. That isn't as much as it > sounds. A 64bit environment won't help you because all the COM > components are still 32bit. Your best bet at that point is to beef up > your DB and add a second front-end server to help balance the load. > If you publish against a box with 5 users on it they will almost > certainly suffer performance issues. > > Note that a "cluster" (misnomer) license will only really address > problem 3. > Hardware is cheap by comparison to every other type of solution. > > Of course you could simply schedule your publishing overnight when > nobody is using the system - but I assume that's obvious enough that > you already thought of that and there is a reason you can't do it. > > HTH. > > Regards, > Richard Hauer > ==================== > 5 Limes Pty Limitedwww.5Limes.com.au > > On Jun 25, 9:24 pm, reddotrich <[email protected]> wrote: > > > > > Hi All, > > > Has anyone had any issues or noticed any major improvments in > > performance when upgrading from v9 SP1 (we have got the .Net page > > builder) to version 10? Or heard if v10.1 (or v11 or whatever they are > > going to call it) has any major performance improvments? We are > > currently suffering performance issues with editors not being able to > > edit when someone else is publishing. I understand that we may be > > able to opt for a cluster license to avoid this, but of course the > > management would like a. a cheaper option (hence looking at free > > upgrades) and b. evidence to back up the idea. So if anyone has any > > stories to back up the idea, please share. > > > Rich- Hide quoted text - > > - Show quoted text - -- You received this message because you are subscribed to the Google Groups "RedDot CMS Users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/reddot-cms-users?hl=en.
