Browse All Articles
> Signal R - A Real-Time Application
Real-time is more about the business, not the technology. In day-to-day life, to make real-time decisions like buying or investing, business needs the latest information(e.g. Gold Rate/Stock Rate). Unlike traditional days, you need not wait for a few months or a few weeks to get market trend inform.
Real Time (RT) Application
A Real-time application gives information instantly and constantly. The efficiency of the application depends mostly on how it is fault tolerant to missed timing requirements. In real-time application, required response times are achieved with a combination of custom hardware and software, possibly with no-
or a very thin-operating-system layer. As they function constantly, they need to be closely analyzed for performance metrics.Some of the real-time applications are listed below
- Video conference applications
- VoIP(voice over Internet Protocol)
- Online gaming
- Community storage solutions
- Some e-commerce transactions
- IM (instant messaging)
- Current active visitors,Currently logged-in users
- When friend comes online or goes offline
- When someone likes or comments on status
- Send notification on event to subscribed users
- How many people are actively playing a particular game, watching online webinar/event, etc
- Total transactions, purchases, impressions, messages, clicks till day and so on
Soft vs Hard
Real-time web application development with Signal R
What is Signal R
Signals are used for communication (e.g.
analog and digital). R stands for real-time.
Real-time web refers the ability to have server code push content to the connected clients instantly. Signal R in short refers to Real-time application communication
What it does?
- Over HTTP connection, push content from Server to client RPC.
- It is a connection abstraction. Gives impression of working on a permanently open persistent connection. It is NOT reliable messaging.
- It sends each message through the message-bus.
How it is measured and monitored
SignalR OverviewPattern Used:
- Performance counters gives the number of events since the last application pool or server restart.
- Connection metrics, Message metrics, Message bus metrics, Error metrics, Scaleout metrics
It is designed in Hub and Spoke pattern. SignalR in Central, with all other browsers being changeable and flexible and contextual to it
It is categorized into major four areas as presented below.
SingulaR files are listed hereSignalR
- Persistent Connection
- Transport types
- A meta package that brings in SignalR.Server and SignalR.Js
- Server side components needed to build SignalR endpoints
- .NET client for SignalR
- Ninject dependency resolver for SignalR
Transport Flow of SignalR
Problem Statement: Design Parameters to meet real-time requirements
Performance can creep into real-time application as it scales up and also ASP.NET, Signal-R thread and memory limitations have the mutual short-term nature of Web requests
Few set of tunable parameters :
Three main factors of scaling are specialization, optimization, and distribution
- Specialization – Compartmentalization of application into smaller pieces in order to isolate the problem. MVC takes care of the same by splitting controller, Model, View and also image servers, streaming server can be split
- Optimization - Provides components for distribution by reducing the amount of work needed for a given operation. This translates directly into fewer servers needed to scale to the same number of users.
- Clustering - Each server in the cluster sends out a information to let the other servers know it is alive. challenge of effective clustering lies in eliminating affinity/ stickiness
It can be scaled with Backplane scaling approach using Redis, SQL Server
State property of the hub’s proxy and caller property in hub is used for maintaining the state. State can be maintained through multiple connections and method calls to a database. Sticky Session isn’t supported as it is limitation to distribute.
Persistent memory objects, like in-process session and cache objects, memory usage becomes much more problematic while scaling. Each webserver gets the message from redis and stores it in a local cache. This local cache is where SignalR clients (browsers), are served.
- Scaling Cache Storage :
- Specialization—Partitioning of the database into logical pieces. Those partitions could be datacentric.
- Cluster :Have multiple databases, each containing a portion of the whole database.
Response Time = Payload/Bandwidth + Round Trip Time(RTT) + Appturns/Concurrent Requests+Server Compute Time(Cs)+ Client Compute Time(Cc)
Scaling Approaches for better performance (Load balancer Vs Backplane)Backplane Server -Overview
- A Backplane Server is an independent orchestrator of the message interchange between Backplane Clients and may serve multiple independent Buses.
- Each server instance connects to the backplane through the bus. When a message is sent, it goes to the backplane, and the backplane sends it to every server. When a server gets a message from the backplane, it puts the message in its local cache. The server then delivers messages to clients from its local cache.
- Introduce delays in message delivery, which will not work well for low-latency work. With multiple servers to handle clients and mostly latency is minimal this might not work.
- Trade-off here is between latency and complexity
- Signal R Supports 3 backplanes Azure ServiceBus, SQL Server, Redis
- Amazon Web Services (AWS)
- Do not support Azure ServiceBus
- SQL Server in EC2 needs manual handling ,a counter-intuitive to running on cloud infrastructure
- Supports Redis
- Default MessageBus of signalR gets replaced with a bus designed for that backplane.
This article would help in understanding the overview of SignalR.