IIS Logs reverse deploy

All-

My Boss wants me to grab the IIS logs from our web servers that have OD Rcvr on them. Sounds straightforward right?

I havenâ€™t done it before but I have herd a lot of talk about how great OD is for doing such a thing. Anything I should look out for?

Any who, my boss wants them zipped up for archiving and I said sure.

Can anyone give me the difference (speed, band with used) between...
1. Zipping them up on the web server and reverse deploying the zip file (say, 1000 files 100 megs after compression (WinZip)).
2. As apposed to running OD directly on the log files with compression turned on (I am assuming compression level 6, (equivalent to wWinZip)?

Thanks in advance!
win2k3 TS 6.5 sp1; OD 6.0.1; DD enabled
The Professor-

Find more posts tagged with

Comments

Adam Stoller

Your boss wants them zipped for archiving - okay - but that has no bearing on whether or not you use compression for the deployment (the files will be uncompressed at the end of the deployment and you'll have to compress them yourself anyway) - and if you're going to compress them yourself on the reverseSource side then I'm pretty sure you don't want compression turned on during deployment because it is likely to waste time trying to compress an already compressed file (I'd be surprised if it gains you anything in that scenario).

As for compressing the files for archival purposes - I'm not sure if doing a reverse deployment allows for a dnrDeploymentJob - which can only run on the 'source' side - to run on the 'reverseSource' side ... it might, but it might not.

If it does not - then there's no real option - perform the reverse deployment of the log files un-compressed, then use a DNR on-success, on-reverseTarget side, to compress them (if you're using Perl for the DNR, consider Archive::Tar module).

If you can run the dnrDeploymentJob on the reverseSource - then you have the option of compressing them before or afterwards and the big question will probably be error-recovery. If you compress them first and then the deployment fails - what happens when you try to run the deployment again? It's probably safest to do the compression *after* the files have been received.

The above is just my opinion - no real evidence to support it.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

ProfessorX

Do you have an opnion on speed and band width will be?

Better to zip and deploy? or
Better to Deploy with compression? or
Really not much difference?

Thanks in advance!
win2k3 TS 6.5 sp1; OD 6.0.1; DD enabled
The Professor-

Migrateduser

A reverse deploy scenario does, in fact, allow for a DNR job to be executed. The DNR specs are normal with regard to specifying where the job is to be run, etc. That is, you want to compress the files before transfer. That's fine, so all you would need to do in this case is specify the command in the DNR as normal and declare the location as "source". Other than that, it's very straight-forward.

Dave

Environments:
(1,2) TS6.5, TS6.5SP1 on W2K3
(3) Vignette V7 Portal on Solaris 9

Adam Stoller

Thanks for the clarification - so dnrDeploymentJob - which can only run on 'source' - can run on 'reverseSource' too.
I still think, however, that it would be better to do the archival compression afterwards, on the 'reverseTarget' side (which means a dnrDeployment on-success on-target)

As for whether or not the speed / bandwidth values favor enabling compressed deployments ... I think empiracle evidence (a.k.a.: trial-and-error) will be the best guide - as only you (professorX in this case) can verify the results with the actual CPU of your servers and topography of your network.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

table.txt