Skip to content

Commit e6e27af

Browse files
Merge pull request #3224 from syncfusion-content/EJ2-897352-UgRedisMDocs
897352: Adding UG for Redis
2 parents ecc2e5d + e8b4281 commit e6e27af

File tree

5 files changed

+852
-386
lines changed

5 files changed

+852
-386
lines changed
Lines changed: 42 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,42 @@
1+
---
2+
layout: post
3+
title: Collaborative Editing in ##Platform_Name## Document Editor Control | Syncfusion
4+
component: DocumentEditor
5+
description: Learn about collaborative editing in Syncfusion ##Platform_Name## Document editor control of Syncfusion Essential JS 2 and more.
6+
publishingplatform: ##Platform_Name##
7+
documentation: ug
8+
domainurl: ##DomainURL##
9+
---
10+
11+
# Collaborative Editing
12+
13+
Allows multiple users to work on the same document simultaneously. This can be done in real-time, so that collaborators can see the changes as they are made. Collaborative editing can be a great way to improve efficiency, as it allows team members to work together on a document without having to wait for others to finish their changes.
14+
15+
## Prerequisites
16+
17+
- *Real-time Transport Protocol*: This protocol facilitates instant communication between clients and the server, ensuring immediate updates during collaborative editing.
18+
- *Distributed Cache or Database*: Used to temporarily store the queue of editing operations.
19+
20+
### Real time transport protocol
21+
22+
- *Managing Connections*: Keeps active connections open for real-time collaboration, allowing seamless communication between users and the server.
23+
- *Broadcasting Changes*: Ensures that any edits made by one user are instantly sent to all collaborators, keeping everyone on the same page with the latest document version.
24+
25+
### Distributed cache or database
26+
27+
To support collaborative editing, it's crucial to have a backing system that temporarily stores the editing operations of all active users. There are two primary options:
28+
29+
- *Distributed Cache*: Handles a higher number of `HTTP` requests per second compared to a database approach. For instance, a server with 2 vCPUs and 8GB RAM can handle up to 125 requests per second using a distributed cache.
30+
- *Database*: With the same server configuration, it can handle up to 50 requests per second.
31+
32+
Using the distributed cache or database all the editing operations are queued in order and conflict resolution is performed using `Operational Transformation` Algorithm.
33+
34+
> *Recommendation* - If you expect average `http` requests per second of your live application as 50 or below, then the database can provide reliable a backing system for operation queue. If you expect average requests per second of your live application as above 50, then the distributed cache is highly recommended backing system.
35+
> Tips to calculate the average requests per second of your application:
36+
Assume the editor in your live application is actively used by 1000 users and each user's edit can trigger 2 to 5 requests per second. The total requests per second of your applications will be around 2000 to 5000. In this case, you can finalize a configuration to support around 5000 average requests per second.
37+
38+
> Note: The above metrics are based solely on the collaborative editing module. Actual throughput may decrease depending on other server-side interactions, such as document importing, pasting formatted content, editing restrictions, and spell checking. Therefore, it is advisable to monitor your app's traffic and choose a configuration that best suits your needs.
39+
#### See Also
40+
41+
- [Collaborative editing using Redis cache in ASP.NET Core](../../document-editor/collaborative-editing/using-distributed-cache-asp-net-core)
42+
- [Collaborative editing using Microsoft SQL server in ASP.NET Core](../../document-editor/collaborative-editing/using-database-in-asp-net-core)

0 commit comments

Comments
 (0)