Polling webservice performance - Will this work?

Question

Our app need instant notification, so obvious I should use some some WCF duplex, or socket communication. Problem is the the app is partial trust XBAP, and thus I'm not allowd to use anything but BasicHttpBinding. Therefore I need to poll for changes.

No comes the question: My PM says the update interval should be araound 2 sec, and run on a intranet with 500 users on a single web server.

Does any of you have experience how polling woould influence the web server.

The service is farly simple, it takes a guid as an arg, and returns a list of guids. All data access are cached, so I guess the load on the server is minimal for one single call, but for 500...

Except from the polling, the webserver has little work.

So, based on this little info (assume a standard server HW, whatever that is), is it possible to make a qualified guess?

• Is it possible or not to implement this, will it work?

Yes, I know estimating this is difficult, but I'd be really glad if some of you could share some thoughts on this

Regards

Larsi

Answer 1

Polling.. bad, but if you have no other choice, then it's ideal :)

Bear in mind the fact that you will no doubt have keep-alives on, so you will have 500 permanently-connected users. The memory usage of that will probably be more significant than the processor usage. I can't imagine network access (even in a relatively bloaty web service) would use much network capacity, but your network latency might become an issue - especially as we've all seen web applications 'pause' for a little while.

In the end though, you'll probably be ok, but you'll have to check it yourself. There are plenty of web service stress testers, you can use Microsoft's WAS tool for one, here's a few links to others.

Answer 2

Don't estimate, benchmark.

Answer 3

Try using soapui, a web service testing tool, to check the performance of your web service. There is a paid version and an open source version that is free.

cheers

Answer 4

I don't think it will be a particular problem. I'd imagine the response time for each request would be pretty low, unless you're pulling back a hell of a lot of data, so 500 connections spread over 2 seconds shouldn't hit it too hard.

You can use a stress testing tool to verify your webserver can handle the load though, before you commit to this design.

Answer 5

250 qps probably is doable with quite modest hardware and network bandwidth provided you do minimize the data sent back & forth. I assume you're caching these GUID lists on the client so you can just send a small "no updates" response in the normal case.

Should be pretty easy to measure with a simple prototype though to be more confident.