Reputation: 141
Your help will give me a much better understanding on Windows azure. Thanks in advance.
I understand the worker role like a method(The Run() method in worker role), that is doing some time-consuming opperation. This allows me to have multiple instances of this worker role, to speed things up if traffic surges.
1) can I have a worker role that does more than on thing like: - a method that creates a PDF; - a method that creates a chart; -a method that parses som HTML; -a method that processes an image
I could easily do all this with 4 worker roles(one RUN() method for each functionality above), but this is very expensive. Can I place this 4 things as methods on the same worker role?
2) What is the disadvantage of hosting a WCF service on a worker role?
3) What is the disadvantage of talking between instances in the same Azure solution trough WCF insteed of queues? Is this slower?
Upvotes: 1
Views: 628
Reputation: 4842
Just adding to Smarx - be careful how you slice your functionality - you pay for every worker role you spin up, so unless you have a particularly hotspot in your workflow, and you're already running multiple workers at maximum capacity, you're better off creating a single worker role that can run as multiple instances.
Upvotes: 0
Reputation: 60143
The interface to a worker role is simple... you implement a Run() method that never returns, and we call it. What you do in there can be anything... you can spin up 100 threads doing different things, you can use Process.Start() to launch separate processes, you can start a web server, etc.
I don't know if there are disadvantages to hosting WCF in a worker role. In a web role, you could use IIS as the host, which may help with scalability of the service as compared to running your own host.
One common pattern is to have a worker role pulling work from a queue. The advantage of the queue is that it guarantees each message gets delivered at least once (so you don't lose work). It also distributes the load, because each worker can pull a message from a queue when it's ready for more work. If you use WCF or some other synchronous communication instead, you have to handle how to distribute the work and how to recover from errors (without losing work) yourself. It's certainly possible (and actually probably faster than a roundtrip to a queue), but it's harder to build a reliable, scalable service this way.
Upvotes: 4