Mayan EDMS slows down as the document library grows because background tasks and foreground actions share the same server resources. Every document uploaded starts four processes automatically: OCR, indexing, workflow triggers, and scheduled tasks. All four run against the same CPU, memory, and disk that users depend on for search and page loads.
None of those processes pauses for the others. At low volume, the competition is invisible. At high volume, it shows up as slow search, delayed page loads, and a system that feels like it's struggling.
The slowdown builds through three compounding factors:
- Queue growth — more documents mean more background jobs running at once
- Resource competition — background jobs consume what foreground actions need
- No alerts — nothing signals the problem until users already feel it
Bulk uploads make it worse for a fourth reason. When 200 documents enter the system at once, 200 OCR jobs, 200 indexing jobs, and all matching workflow triggers fire simultaneously against the same fixed resource pool. Every user logged in at that moment slows down together.
This compounds silently over months. A library that ran cleanly at 500 documents starts showing strain at 5,000. Nothing in Mayan EDMS flags the threshold. Users notice the slowdown before anyone checks the server.
Changing the server fixes the ceiling. First, you need to know what is causing it. If document control at scale is a broader challenge your team is facing, this breakdown of why businesses struggle with document control covers the wider picture.
How Does Library Size Affect Speed?
Speed in Mayan EDMS is directly tied to library size because every background process runs against the entire document set. A library with 500 documents gives each process a short queue, a light index, and little competition for resources. A library with 50,000 documents gives every process a longer queue, a heavier index, and constant competition from other processes running at the same time. That difference is not a bug. It follows from how the system processes and indexes content.
The gap between those two states opens across two stages:
At low volume: The document library is small. OCR finishes quickly because there are few documents to process. Search returns results fast because the index is light. Every action completes against a small dataset and a short queue.
As volume grows: Every background process runs against a larger dataset. OCR queues grow longer. Full-text search indexes more content. Workflow triggers fire more often. Each process takes slightly longer than before. Across thousands of documents and multiple concurrent users, those small increases compound into a noticeable and persistent slowdown.
The infrastructure that handled the system at low volume is the same infrastructure now handling it at high volume. That is where the ceiling appears.
Every Upload Extends the Processing Queue
Every document uploaded to Mayan EDMS starts four background tasks immediately. None of them waits for the user to finish or for the system to be idle. They start, they run, and they consume resources whether anyone is watching or not.
The four tasks are:
- OCR runs automatically on every upload
- Document indexing starts as soon as OCR completes
- Workflow triggers fire if the document matches a configured rule
- Scheduled tasks run on their own timer, regardless of user activity
All four share the same system resources: CPU, memory, and disk. None of them pauses for the others. At low document volumes, this background activity is invisible. At high volumes, it competes directly with the actions users take in the foreground.
A user running a full-text search is asking the system to read the same index that the background indexing process is writing to at that moment. One of them waits, and it is almost always the user.
| Background process | What triggers it | Resource it uses most |
|---|---|---|
| OCR | Every new upload | CPU |
| Document indexing | After OCR completes | CPU and disk |
| Workflow triggers | Document matches a rule | CPU and memory |
| Scheduled tasks | Time-based, runs continuously | CPU, memory, and disk |
The queue above runs whether one document enters the system or two hundred. The difference is how much it affects everyone else.
What Happens When There Are No Performance Alerts?
Mayan EDMS has no built-in alert for queue length, resource consumption, or performance thresholds. The system processes everything it receives and shows no indication of strain until the strain becomes visible through degraded response times. That is why the slowdown always feels sudden even when it was not.
There is no notification for any of the following:
- OCR queue length reaching a level that affects search speed
- Background tasks consuming resources that slow foreground activity
- Server memory or CPU crossing a performance threshold
By the time a user notices that search is slow, the queue has already been building for some time. By the time someone checks the server, resource usage may already have been affecting every user for hours.
Teams running Mayan EDMS on shared hosting or underpowered servers experience this as a slowdown that appears without warning. The degradation was gradual. The point at which it became noticeable felt abrupt because nothing signalled it was coming.
The system never tells you it is struggling. The first signal is always a user complaint.
What Keeps Mayan EDMS Running After You Log Out?
Closing the browser does not stop Mayan EDMS.
The system continues processing after every user session ends because the background queue runs independently of who is logged in. OCR keeps running. Indexing continues. Scheduled tasks fire on their own timer regardless of whether anyone is using the system.
This creates a specific pattern that teams notice but rarely connect to its cause:
- A large upload happens late in the working day
- The queue builds through the evening while nobody is logged in
- Users arrive the next morning to a system that feels slow from the first action they take
A large upload at 5 pm can still be affecting system performance at 9 am the next morning if the queue has not cleared overnight. The system is not broken. It is finishing work that started when nobody was watching.
The slowdown users feel in the morning did not start in the morning. It started the night before.
Why Does One Bulk Upload Slow Down Everyone Else?
A bulk upload does not slow down only the user who started it. It slows down every user currently logged in because all background tasks from that upload run immediately against the same shared resource pool.
When 200 documents enter Mayan EDMS simultaneously, three things happen at once:
- 200 OCR jobs enter the queue at the same moment
- Indexing for all 200 begins as each OCR job completes
- Workflow triggers fire across all matching documents in parallel
The system handles all of this against the same fixed pool of resources available to every user currently logged in. A single user doing a bulk upload at 10 am slows down every other user working in the system at that moment, even if those other users are doing something entirely unrelated to the upload.
| Action | Documents affected | Users affected |
|---|---|---|
| Single document upload | 1 | Upload user only |
| Bulk upload of 50 files | 50 | All current users |
| Bulk upload of 200 files | 200 | All current users, noticeably |
| Scheduled task firing mid-session | All indexed documents | All current users |
This is a resource competition problem. It appears when the infrastructure is not sized to handle the peak load the team is generating. The fix is not behavioural. It is infrastructure.
Three Places to Check Before Escalating
When Mayan EDMS starts responding slowly, the cause is almost always visible in one of three places before it requires escalation. Each place points to a different layer of the system, and checking them in order narrows the problem quickly.
1. Search Response Time
Open Mayan EDMS, run a full-text search for a common word that appears in many documents, and note how long the results take to appear. Under two seconds means the index is healthy. Five seconds or more means the index is under load, or system resources are constrained.
2. The OCR Queue
Found in the Mayan EDMS administration panel. A queue with hundreds of pending tasks means the system is consuming the CPU that search and page loads also depend on. Documents uploaded in a recent batch are still being processed until the queue clears.
3. Server Resource Usage
CPU consistently above 80 percent and available memory below 20 percent mean the infrastructure is undersized for the current document volume and user load. These numbers are not visible inside Mayan EDMS. They require server access or a monitoring tool watching the instance.
| What to check | Where to find it | What a healthy reading looks like |
|---|---|---|
| Search response time | Mayan EDMS search bar | Under 2 seconds for common terms |
| OCR queue length | Administration panel | Queue under 10 pending tasks |
| CPU usage | Server monitoring tool | Consistently below 80 percent |
| Available memory | Server monitoring tool | Above 20 percent free at all times |
These three checks usually point to the same answer. The system is processing correctly. The server underneath it is not keeping up.
When the Server Is the Problem
A Mayan EDMS instance slows down when the server running it does not have the CPU, memory, or disk space to handle the volume the team is generating. The software is processing correctly. The infrastructure beneath it has reached its ceiling.
That ceiling appears at a predictable point:
- The document library grows past what the current hardware handles comfortably
- Background tasks start competing with foreground actions for the same resources
- Users notice the slowdown before the server shows any obvious sign of failure
A Mayan EDMS instance running on a shared server or a local office machine hits this ceiling earlier than a dedicated instance. The infrastructure that handled 500 documents and three users starts showing strain at 5,000 documents and ten users. Adding more documents does not change the software. It changes the load on the hardware underneath it.
One option for teams hitting this ceiling is running Mayan EDMS on a dedicated cloud instance. Yobitel maintains a prebuilt AMI on the AWS Marketplace that runs on Amazon EC2 with EBS storage, giving Mayan EDMS dedicated compute and disk instead of shared resources. Resizing the instance does not require data migration, and storage expands from the AWS console without downtime.
For teams whose slowdown traces back to infrastructure rather than configuration, moving to dedicated compute is the direct path forward.
Frequently Asked Questions:
Why does Mayan EDMS slow down after a large upload?
Large uploads create a spike in the OCR queue and trigger simultaneous indexing jobs across all uploaded documents. Those background processes consume CPU and memory that page loads and search queries also depend on. The slowdown affects every user currently in the system until the queue clears.
Does Mayan EDMS show a warning before performance drops?
No. Mayan EDMS does not have a built-in performance alert or queue threshold notification. The first visible sign of a performance problem is usually slow search results or delayed page loads. By that point, the queue has typically been building for some time.
What is the fastest way to check if the OCR queue is causing the slowdown?
Open the Mayan EDMS administration panel and check the current OCR task queue. A queue with more than a few dozen pending tasks is actively consuming CPU resources and will slow search and page load performance until it clears.
Can Mayan EDMS performance be improved without changing the server?
Partially. Scheduling large uploads during off-peak hours reduces the impact of queue spikes on active users. Limiting the number of simultaneous workflow triggers reduces background CPU load. Neither change increases the total processing capacity of the server. When document volume and user count grow beyond what the current infrastructure supports, resizing the server is the lasting fix.
Why does Mayan EDMS feel slow in the morning, even when nobody uploaded anything overnight?
Mayan EDMS runs scheduled tasks on a continuous timer regardless of user activity. Background indexing and workflow processing that started from a large upload the previous evening may still be running when users arrive the next morning. The system continues working after user sessions end.
How much server capacity does Mayan EDMS need for a team of 10 users?
A team of 10 active users with a growing document library needs dedicated compute rather than shared hosting. On AWS, a t3.large instance handles light to moderate workloads for a team of this size. As document volume grows beyond 10,000 files or concurrent user activity increases, moving to a larger instance type removes the performance ceiling without migrating data.
Top comments (0)