Register User need vevery Long Time. Wait at least 20 seconds

[MR-ZiWeiter]

Description: It takes a long time to register a user account using the provided interface or the REST API, but other interfaces respond quickly. My environment is deployed on the local machine

Steps to reproduce:

1. Open the registration page and fill in the registration related information
2. Click to register normally
3. The waiting time is very long

Expected behavior:Register an account quickly

Actual behavior:It takes a long time

Server Setup Information:

• Version of Rocket.Chat Server: rocketchat/rocket.chat:sha-d0bedf7
• License Type:Free
• Number of Users:
• Operating System: Centos7
• Deployment Method: docker
• Number of Running Instances: 1
• DB Replicaset Oplog:
• NodeJS Version: 14.21.3
• MongoDB Version:7.0.12

Client Setup Information

• Desktop App or Browser Version:Desktop App or Browser Version: Browser Chrome version 126.0.6478.127 (arm64)
• Operating System:MacOS、Windows10

Additional context

Relevant logs:

[reetp]

I'm slightly confused by your description here.

It takes a long time to register a user account using the provided interface or the REST API,

OK

but other interfaces respond quickly.

Which other interfaces?

My environment is deployed on the local machine

So exactly what is your local environment?

How much RAM etc does the 'server' have?

Is this a developer install, or a straight deployment? What is in your docker compose file?

Did you use oplogs?

What errors are in your logs?

Have you made sure websockets are working correctly?

[MR-ZiWeiter]

I'm slightly confused by your description here.

I opened the GUI interface to manually register a new account. The interface response time was very long, including the response time when using the administrator to register. It took more than 20 seconds each time.

It takes a long time to register a user account using the provided interface or the REST API,

OK

but other interfaces respond quickly.

Which other interfaces?

Currently there are only registration related interfaces, and the rest respond very quickly

My environment is deployed on the local machine

So exactly what is your local environment?

[root@VM1 ~]# uname -a
Linux VM1 3.10.0-1160.108.1.el7.x86_64 #1 SMP Thu Jan 25 16:17:31 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
[root@VM1 ~]# lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 64
On-line CPU(s) list: 0-63
Thread(s) per core: 2
Core(s) per socket: 16
Socket(s): 2
NUMA node(s): 2
Vendor ID: GenuineIntel
CPU family: 6
Model: 85
Model name: Intel(R) Xeon(R) Platinum 8163 CPU @ 2.50GHz
Stepping: 4
CPU MHz: 2742.309
CPU max MHz: 2500.0000
CPU min MHz: 1000.0000
BogoMIPS: 5000.00
Hypervisor vendor: Microsoft
Virtualization type: full
L1d cache: 32K
L1i cache: 32K
L2 cache: 1024K
L3 cache: 33792K
NUMA node0 CPU(s): 0-31
NUMA node1 CPU(s): 32-63
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology aperfmperf eagerfpu pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch invpcid_single ssbd rsb_ctxsw ibrs ibpb stibp fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm avx512f avx512dq rdseed adx smap clflushopt clwb avx512cd avx512bw avx512vl xsaveopt xsavec xgetbv1 md_clear spec_ctrl intel_stibp flush_l1d arch_capabilities
[root@VM1 ~]# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
fd0 2:0 1 4K 0 disk
sda 8:0 0 500G 0 disk
|-sda1 8:1 0 1G 0 part /boot
-sda2 8:2 0 499G 0 part |-centos_vm1-root 253:0 0 467.5G 0 lvm / -centos_vm1-swap 253:1 0 31.5G 0 lvm
sr0 11:0 1 1024M 0 rom
[root@VM1 ~]# free -h
total used free shared buff/cache available
Mem: 46G 37G 1.7G 496M 7.9G 8.7G
Swap: 0B 0B 0B
[root@VM1 ~]# hostnamectl
Static hostname: VM1
Icon name: computer-vm
Chassis: vm
Machine ID: ce3621fb29b9486cbcbc44274105cf40
Boot ID: 4735d56b2e864093a2e2dcbbd9b1d65c
Virtualization: microsoft
Operating System: CentOS Linux 7 (Core)
CPE OS Name: cpe:/o:centos:centos:7
Kernel: Linux 3.10.0-1160.108.1.el7.x86_64
Architecture: x86-64

How much RAM etc does the 'server' have?
The running memory is dynamic, and the physical machine has 256G RAM.
Is this a developer install, or a straight deployment? What is in your docker compose file?
developer install。Directly use docker deployment
Use these variables
ROOT_URL=
MONGO_URL=
PORT=
Accounts_UseDNSDomainCheck=
Did you use oplogs?

no

What errors are in your logs?

No log errors were found in the docker container logs
This is my complete log, including multiple registrations
Rocket.Chat-20240718104933.log

Have you made sure websockets are working correctly?
I just registered two accounts to chat with each other. There is a red dot prompt, but the message is not displayed in real time. It seems that websocket is not working. I checked the console and did not see the ws connection.

[reetp]

developer install。Directly use docker deployment

I think direct docker deployment has some issues. Either use compose or follow the developer docs for a full developer build.

https://developer.rocket.chat/v1/docs/server-environment-setup

Centos7

You know it is EOL? You should move to a supported OS.

SERVER RUNNING

That means the server is fundamentally up and working correctly.

"MongoServerError"

However, it looks like you have an issue with Mongo somewhere - how is it deployed?

The $changeStream stage is only supported on replica sets

Which means you probably haven't enabled replica sets in your Mongo DB as required in the docs.

"Failed to communicate with Rocket.Chat Cloud"

And your networking probably needs lookign at

http://dr.dsoft.site:3000

Probably related depending on your setup:

#32826

It seems that websocket is not working.

And you need to fix that one way or another.

License Type:Free

Note it is not 'Free'. It is open source and subject to MIT :-)

You should ask for support on CE in https://forums.rocket.chat or https://open.rocket.chat #support

As far as I can see at the minute this is a support issue and not a bug.

[github-actions]

This issue has been marked as stale because there has been no further activity in the last 10 days. If the issue remains stale for the next 4 days (a total of 14 days with no activity), then it will be assumed that the question has been resolved and the issue will be automatically closed.

[github-actions]

This issue was closed because it has been inactive for 14 days since being marked as stale.