Last post Jan 11, 2014 11:47 AM by damienBod
Jan 10, 2014 04:39 AM|Alen44|LINK
Dear group, I would like to get an advice on how to implement the following, from architecture perspective.
I have a windows server that needs to host a single web service (no UI) that will be called from several external systems (the call can be either synced or asynced when most are synced). Hardware is not a problem in order to support up to 100 calls per second.
When each call is received, my backend process will run through some business logic and return a result. The business logic is all processed in memory by working with around 2 to 4 GB of preloaded data (all the processing is CPU and memory, no DB or file
system access when processing the request. cpu processing/usage can be intensive).
My options for implementation:
1. Host everything within a single IIS application that exposes the web service and all the data is loaded in the IIS process (IIS application). In that way when the IIS application starts everything is loaded into memory and then each web service call will
simply access this memory structures within the IIS process (no additional process).
2. IIS will host only the web service, and an additional windows process will do the business logic processing. This means that once IIS receives a call (let’s assume a sync request) it forwards the call to that process (to probably a dedicated thread that
will process it) and waits for a result from that process to return it back to the web service called. In that case, I also need an advice on how the communication between IIS and the additional process should be made (WCF?)
3. Maybe something completely different?
The most important aspects here are the response time (that is expected to be 1 second) and the stability of the solution (to avoid crashes etc).
Thanks a lot.
Jan 11, 2014 11:47 AM|damienBod|LINK
Both would work good, dependings on your requirements, what happens if your processing requirements increase or the process needs to scale etc. If you use separate process for business implementations, I would use self hosted Web Api 2 services hosted in
a windows service and not WCF. Only use WCF if you require Full-Duplex communication. If high proformance communication is required, you can use protobuf-net with web api 2. Nothing comes close to this, unless of course it is all in-process with no serialization.
Dangers with solution 1 is that the IIS recycles when your application memory usage is to big or grows.
hope this helps