nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

DAS ready for prime time ?

nipper

We implemented 1 1/2 year ago. The IW consultant suggested we not use DAS, since he felt it would not
scale. (DD 5.5)

I am curious how people feel about DAS now ? We have 165 authors changing templates & pushing them
forward via WF. We also have scripts to run DD when a DCR is saved (to dev table) & dd when submit
(to Stage) etc. It would be nice to bag the scripts if DAS will scale. One point that might help is that we work
in 1 WA, so I am not concerned about Get Latest and Update.

Comments ?

Andy

Find more posts tagged with

Comments

Migrateduser

Consider using the TeamSite event server for triggering DAS deployments, rather than the iwat triggers. It's more efficient.

I'll have to let others speak about their scalability experiences...

Todd Scallan
Director of Product Management
Interwoven
t: 408-530-7167
e: tscallan@interwoven.com

fish

We've had DAS here since day 1 (v 4.5), approx 3 yeas ago with a similar number of users although with multiple Workareas/branches. You're right about the Get Latest and Update concerns. This can be deactivated and say cronned over night (bit pants though). Although we have found no reason to do this. How ofen would these events be used?

One thing I do like about DAS is all our DCRs in TeamSite can be referenced to table(s) somewhere in DAS. It's along story but we've had a recent major change in Branch/Workarea/DCRs setup and our DAS setup remains unchanged and existing DAS tables already existed and made the database config changes minimal. So DAS has given us great flexibility so was worth the system overhead. Going forwards it is likely we'll migrate to turning DAS off and tailoring our database in a manner similar to your own. (On more recent implementations on different sites turning DAS off and using triggers and/or workflow to populate tables was the preferred solution. This was more efficient and took a bit more thought in setting up.)

I suppose the question is why would you want to change from your existing configuration and move to DAS? What are the benefits?

Steve North
Interwoven Consultant
Sony - Europe

nipper

>I suppose the question is why would you want to change from your existing configuration and move to DAS? What are the benefits?

Good point.

We run through a number of hoops to keep the WA DB in synch with WA DCRs, Stage with Stage, etc.

On the save of a DCR, we run iwdd to push the DCR to WA DB. That take 30 seconds to 1 minute. In that time
the user cannot do anything (we block the screen to prevent early termination). If this was a asynchronous
event then the users would be very happy.

Thanks

ANdy

frisbee

My 2 cts:

IF:
- you use event subsystem
- you use multithreaded (5.6)
- your templates are not very complicated (heavily nested replicants and such)
- you disable those silly deployments on PublishStagingArea events

it should scale reasonably well. That's assuming your 165 authors are not hammering out massive amounts of transactions all day, and you avoid generating massive amounts of transactions through batch processing during office hours. For instance at the place I work now they re-create the same 3000 DCRs each day at 11:00, and set the templating EAs on it. There's no way DAS will scale up to these kind of levels.