Hi guys, Came across few materials about win azure and wcf services for cloud computing. If anyone working on this platform and technology, can u please share your experience on:
i) Performance (comparison to clustering)
ii) Manageability (deployment)
iii) Scalability (when the server farm expands)
Thank you in advance, would really appreciate any comments pertaining these subjects.

Dani AI

Generated

Context: describes an order-management system with heavy DB transactions, real-time orders, daemons feeding the database, a desire to keep hot state in memory inside services, and WCF over netTcpBinding with no queueing. The core trade-offs are state placement, WCF instance model, and how the database is scaled and protected under bursts.

State and affinity: platform-level session affinity is brittle at cloud scale. Two practical patterns work better: (1) Stateless front ends — keep service instances short-lived (PerCall) and push shared state into a distributed cache or durable store; (2) Partitioned affinity — assign logical key ranges to instances (a partition map / consistent-hashing approach) so an instance can hold hot state in-memory and requests are routed to that instance. Local in-memory caches give best latency but require warm-up and failover; a distributed cache increases network hops but simplifies horizontal scale and resilience.

WCF and hosting notes: netTcpBinding is a good low-latency transport, but WCF session semantics do not guarantee cluster-wide affinity or survive instance restarts. For scale, prefer stateless handlers; if in-process state is unavoidable, use a singleton with careful concurrency control and thread-safety, and keep handlers short. Avoid long-running DB transactions inside request handlers — acknowledge quickly and offload heavy work to background processors or lightweight buffers so the database isn’t overwhelmed during spikes.

Database and operational guidance: shard or partition order data by a natural key to reduce contention, minimize transaction scope, tune indexes, and use batching where possible. Add robust telemetry (latency, DB lock/queue metrics, cache hit rates) and drive autoscale from those signals. As suggested, platform-specific choices (which cache, internal endpoints, instance sizing) are best validated with controlled load tests and platform forum guidance.

Recommended Answers

All 4 Replies

i) Performance is fine, but am not quite sure what kind of performance you want to compare. Can you elaborate, or give an example? It would depend heavily on the kind of application you are building, and the components needed.

ii) Deployment is relatively easy once you have a package (you can make these from VS). Uploading/installing a package will take about 20 minutes minimum, but there are provisions for a staging environment.

iii) Adding processors/servers is just updating the configuration from the portal. It can even be controlled from your code.

It is a order management system with heavy database transactions. The orders have to be in real time. Yet daemons will be feeding real time data into the database as well. I am looking forward to load in-memory database in the services too.
Hense my concern is, could wcf and azure's help me to achieve this by maximizing processing affinity for asynchronous programming (if server farm expands).
Request/response - through tcpBinding (no queues but smart asynchronous request handler implementation).

If you have a clear picture of what you want, I'd feed it to the guys on the Azure forums at MS. They're really helpful in finding flaws and recommendations.

Sure if that helps.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.