Yeah the SSIS service in SSMS is a bit misleading. I have been caught out by this too. All the SSIS service does (as shown in SSMS) does is lets you see what packages are stored on the server, and what packages are running. It isn't specifically a server host for running the process. You have to specifically call it on the host to make it run there. More info here:
http://blogs.msdn.com/michen/archive/2006/08/11/package-exec-location.aspx
Running it as a SQL agent job sounds interesting. Is there some documentation you can guide me to?
Connect to the SQL Server in SSMS, find SQL Agent, create a new job of type SSIS Package. You can schedule it or start it manually. Just make sure the agent service account has access to your source file. Theres more detailed info setting up the job about halfway down this page:
http://www.microsoft.com/technet/prodtechnol/sql/2005/mgngssis.mspx
Just before this statement:
To run SSIS packages on remote SQL Server systems, you can use the SQL Server Management Studio to create a SQL Agent job on remote server. That SQL Agent job can then perform an execute Agent Task that calls the dtexec utility to run the SISS package on the remote system.
I don't have much practical advice on tuning an SSIS server. There is a lot of info here:
http://www.microsoft.com/technet/prodtechnol/sql/2005/ssisperf.mspx
which boils down to: the more memory you have, (and configure your package to use), the better. You can tweak buffer sizes to suit the amount of data you expect, the amount of RAM you have. You can turn on logging to tell you if buffer sizes are causing bottlenecks.
Regarding the other components on your server, if you want to store your packages in MSDB then you'll need to have the SQL Server running. If you want to store them as a file then you don't need it running. SQL Server can be memory hungry so I think its a better idea to store them as a file.
Storing them as a file has some security/encryption hurdles though.. but that is another story.
