Not sure why you would necessarily want the reports server on the
database tier... Concurrent managers wake up periodically (like 60 or 90
seconds), query their tables to see if there are any jobs to run... run them if
there are and then go back to sleep. If they are all on the same tier, the
throughput is faster, and there is no network overhead. The more
concurrent jobs that you have, the more that this has the potential to become an
issue.
Also, the database maintains the status of the concurrent managers (are
they up, is it their work shift, are they sleeping...) and if the communication
gets off (for example if you shut down the database, then something happens on
the CM tier (Windows is good at things weirding out with the CM) to shut down
the managers, then bring up the database... the database thinks the managers are
up, they aren't, then sometimes when you try to start the managers, they won't
because the database thinks they already are... and you have to run CMCLEAN to
make the database forget the old status.
WE have our concurrent managers on the apps tier, and are working towards
migrating them to the database tier because performance is so
horrendous.
April Wells
|
- Concurrent Manager Sultan Syed
- Re: Concurrent Manager April Wells
- Re: Concurrent Manager Sultan Syed
- Re: Concurrent Manager Hemant K Chitale
- Re: Concurrent Manager Tim Gorman
- FW: Concurrent Manager Tim Gorman
- Re: FW: Concurrent Manager Hemant K Chitale
- Re: Concurrent Manager Tim Gorman
- RE: Concurrent Manager April Wells