7.2 KiB
Maximum Call Stack Size Exceeded
https://github.com/wekan/wekan/issues?q=is%3Aissue+maximum+call+stack+is%3Aclosed
https://stackoverflow.com/questions/75869629/ios-websocket-close-and-error-events-not-firing
This can happen, when there is too much or incompatible code at browserside, for example at iOS Safari.
To fix it:
- Move ExcelJS from browserside to run at serverside https://github.com/wekan/wekan/pull/3871
- Use Bundle Visualizer to see what is the size of dependencies, and try what can be moved to serverside like at step 1, that bundle visualizer is used in this script https://github.com/wekan/wekan/blob/main/rebuild-wekan.sh
meteor run --exclude-archs web.browser.legacy,web.cordova --port 4000 --extra-packages bundle-visualizer --production 2>&1 | tee ../log.txt
- Make dependencies smaller. For example, use only required files, and do not include all dependencies:
23e5e1e3bd
. In that commit, package was forked to packages directory, then renamed, and added withmeteor add packagename
, where package name does not have character:
- Use Browserstack.com to see errors at browser / inspect / console, or use iOS or other device emulators, to see error messages. Testing at real device is more important, because they could work differently than emulators, emulators sometimes do not emulate all same features. Those error messages have file where error happened, and line number, like
something.js:301
. From there, scroll up a little, look at what function or what package dependency it is where it happened. If possible, try to move that package serverside, like at step 1. Or alternatively, look is it possible to remove or change to some other compatible dependency. - See what are the dependencies at your Meteor based software, compared to WeKan dependencies that are usually already upgraded to newest Meteor, is there any differences where changing to correct dependencies could help you to upgrade to newest Meteor:
- https://github.com/wekan/wekan/blob/main/package.json
- https://github.com/wekan/wekan/blob/main/.meteor/packages
- https://github.com/wekan/wekan/blob/main/.meteor/versions
- https://github.com/wekan/wekan/blob/main/.meteor/release
- If you get some errors, search are those same already fixed in WeKan/Meteor/RocketChat, could you fix them same way:
- https://github.com/wekan/wekan/blob/main/CHANGELOG.md
- https://github.com/wekan/wekan/issues
- https://github.com/wekan/wekan/issues?q=is%3Aissue+is%3Aclosed
- https://github.com/meteor/meteor/issues
- https://github.com/meteor/meteor/issues?q=is%3Aissue+is%3Aclosed
- https://github.com/RocketChat/Rocket.Chat/issues
- https://github.com/RocketChat/Rocket.Chat/issues?q=is%3Aissue+is%3Aclosed
- If you have some webserver providing SSL/TLS, check that you have websockets enabled:
- https://github.com/wekan/wekan/wiki/Caddy-Webserver-Config
- https://github.com/wekan/wekan/wiki/Nginx-Webserver-Config
- https://github.com/wekan/wekan/wiki/Apache
- OpenLiteSpeed https://github.com/wekan/wekan/issues/3334#issuecomment-723651328
- https://github.com/wekan/wekan/wiki/Local-self-signed-TLS
- https://github.com/wekan/wekan/wiki/Traefik-and-self-signed-SSL-certs
OLD: TODO
Identify the core service your app is providing and make sure it is running independently. Put everything non-critical, including reporting, on some other system.
Look at scaling tips here, quote:
smeijer commented 25 days ago Just wanted to let know that I haven't experienced this issue anymore since I've replaced a lot of
meteor publications
withapollo/graphql requests
.The reactivity is thereby lost, but in my case a 30sec poll is also fine. On the places that I do require reactivity, I only
publish
a singletimestamp
. This timestamp is passed through toapollo
, which triggers arefetch
when the timestamp is changed.The discussion here has also been helpfull to improve performance here and there.
Kadira
- https://github.com/edemaine/kadira-compose
- https://github.com/meteor/meteor-apm-agent
- https://github.com/kadira-open/kadira-server
- https://www.gethappyboards.com/2017/07/rolling-out-your-own-instance-of-kadira/
Finding memory leaks
Collect a heap profile and then analyze it
Older article: How to Self Detect a Memory Leak in Node
100% CPU usage
-
Increase ulimit system wide to 100 000 in systemd config.
-
Wekan Javascript code has increaded fiber poolsize.
-
There is on-going 100% CPU usage Meteor issue and hopefully fixes to Node.js will land in Node v8.12 sometime. Node 8.12 is now released and official version included at Wekan.
Scaling to thousands of users
Current versions of dependencies
Dockerfile, versions of Meteor.js, Node etc listed at beginning.
Included Meteor package versions
Added packages at package.json
Build from source
Wekan:
- On any x64 hardware that has Ubuntu 14.04 or Debian 9 or newer installed directly or in VM: Build from source scripts
Wekan for Sandstorm:
- Install above Wekan from source
- Install Sandstorm locally with
curl https://install.sandstorm.io | bash
, select dev install - Install meteor-spk
- Get 100% CPU issue fibers fixed node, and copy it to spk directory:
wget https://releases.wekan.team/node
chmod +x node
mv node ~/projects/meteor-spk/meteor-spk-0.4.0/meteor-spk.deps/bin/
- Add to your /home/username/.bashrc :
export PATH=$PATH:$HOME/projects/meteor-spk/meteor-spk-0.4.0
- Close and open your terminal, or read settings from .bashrc with
source ~/.bashrc
cd wekan && meteor-spk dev
- Then Wekan will be visible at local sandstorm at http://local.sandstorm.io:6080/
- Sandstorm commands:
sudo sandstorm
. Release scripts. Official releases require publishing key that only xet7 has.
Docker:
git clone https://github.com/wekan/wekan
cd wekan
- Edit docker-compose.yml script ROOT_URL etc like documented at https://github.com/wekan/wekan-mongodb docker-compose.yml script
docker-compose up -d --build