Running SSIS packages from the Command Line
For more efficient memory usage, run your saved SSIS package from the command line instead of running directly from visual studio. Example: dtexec.exe /F "c:\fullpath\Package.dtsx" /Rep EWPD > "OptionalCreateLog.log" tests have shown memory usage to be up to 66% less. Running from visual studio will start devenv and DtsDebugHost processes in your Task Manager, whereas command line processing will start DTEXEC.
Update to the latest version.
We always recommend users use the most current build (version), which may contain new or improved features, code fixes, or updated functionality. Melissa data provides many ways to ensure you keep your components to the latest version.
MatchUp: Optimize Your Matchcode
Applying certain optimizations, or configuring the matchcode settings, can greatly reduce processing time without sacrificing accuracy. For a complete discussion see the Matchcodes > Optimization section of the MatchUp SSIS WebHelp or
MatchUp: Keep Work File Location Local
Although the component's interface lets you change the location of the MatchUp work files, you should only override this setting after thorough testing for operating systems and speed.
MatchUp: Back up your Matchcode database
One of the nice things about SSIS is that you can use a canned component (like Conditional split) to separate source records by zipcode into different streams and run the jobs separately. If you have the hardware, this may allow you to take advantage of multi-threading of the processor and multi-instance of the components.
Limit Pass Through Fields
The greater the number of Pass-through fields required will slow down the process. You should pass a unique record identifier as a passthru, then using the source record identifier, join the results with the source fields not used outside the component.
Run on a local instance
VERY IMPORTANT - We are not convinced that VM memory management can be replicated as well as a physical machine - at least not without advanced configuration on your part and high performance hardware hosting the VM - which is beyond the scope of our supporting the performance of the component. Below are some links to related concerns with VM performance...
These are not meant as a deterrent, only to point out the potential issue.
Minimum Hardware Requirements
Although our components are tested and function on older hardware configurations, we "officially" support a recommended hardware configuration and will "unofficially" support configurations in which the components will run. Hardware configurations below the minimum requirements are not supported, in which we will advise hardware upgrades.