search

RocketChat / Rocket.Chat

The communications platform that puts data protection first.
https://rocket.chat/
Other
39.9k stars 10.27k forks source link

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

Closed MR-ZiWeiter closed 1 week ago

MR-ZiWeiter commented 1 month ago

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:

Client Setup Information

Additional context

Relevant logs:

reetp commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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:

https://github.com/RocketChat/Rocket.Chat/issues/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[bot] commented 3 weeks ago

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[bot] commented 1 week ago

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