mirror of https://github.com/zulip/zulip.git
ea6934c26d
Zulip has had a small use of WebSockets (specifically, for the code path of sending messages, via the webapp only) since ~2013. We originally added this use of WebSockets in the hope that the latency benefits of doing so would allow us to avoid implementing a markdown local echo; they were not. Further, HTTP/2 may have eliminated the latency difference we hoped to exploit by using WebSockets in any case. While we’d originally imagined using WebSockets for other endpoints, there was never a good justification for moving more components to the WebSockets system. This WebSockets code path had a lot of downsides/complexity, including: * The messy hack involving constructing an emulated request object to hook into doing Django requests. * The `message_senders` queue processor system, which increases RAM needs and must be provisioned independently from the rest of the server). * A duplicate check_send_receive_time Nagios test specific to WebSockets. * The requirement for users to have their firewalls/NATs allow WebSocket connections, and a setting to disable them for networks where WebSockets don’t work. * Dependencies on the SockJS family of libraries, which has at times been poorly maintained, and periodically throws random JavaScript exceptions in our production environments without a deep enough traceback to effectively investigate. * A total of about 1600 lines of our code related to the feature. * Increased load on the Tornado system, especially around a Zulip server restart, and especially for large installations like zulipchat.com, resulting in extra delay before messages can be sent again. As detailed in https://github.com/zulip/zulip/pull/12862#issuecomment-536152397, it appears that removing WebSockets moderately increases the time it takes for the `send_message` API query to return from the server, but does not significantly change the time between when a message is sent and when it is received by clients. We don’t understand the reason for that change (suggesting the possibility of a measurement error), and even if it is a real change, we consider that potential small latency regression to be acceptable. If we later want WebSockets, we’ll likely want to just use Django Channels. Signed-off-by: Anders Kaseorg <anders@zulipchat.com> |
||
---|---|---|
.. | ||
ci | ||
circleci | ||
documentation_crawler | ||
droplets | ||
i18n | ||
lib | ||
linter_lib | ||
setup | ||
test-install | ||
tests | ||
zulip-export | ||
README.md | ||
__init__.py | ||
build-docs | ||
build-release-tarball | ||
cache-zulip-git-version | ||
check-capitalization | ||
check-frontend-i18n | ||
check-issue-labels | ||
check-openapi | ||
check-provision | ||
check-templates | ||
clean-branches | ||
clean-repo | ||
commit-message-lint | ||
commit-msg | ||
conf.ini-template | ||
coveragerc | ||
create-test-api-docs | ||
deploy-branch | ||
diagnose | ||
django-template-graph | ||
do-destroy-rebuild-database | ||
do-destroy-rebuild-test-database | ||
documentation.vnufilter | ||
fetch-pull-request | ||
fetch-rebase-pull-request | ||
find-unused-css | ||
get-handlebar-vars | ||
html-grep | ||
js-dep-visualizer.py | ||
lint | ||
pre-commit | ||
pretty-print-html | ||
provision | ||
push-to-pull-request | ||
release-tarball-exclude.txt | ||
renumber-migrations | ||
replacer | ||
reset-to-pull-request | ||
review | ||
run-dev.py | ||
run-mypy | ||
run-tsc | ||
run-yarn-deduplicate | ||
setup-git-repo | ||
show-profile-results | ||
stop-run-dev | ||
test-all | ||
test-api | ||
test-backend | ||
test-documentation | ||
test-emoji-name-scripts | ||
test-help-documentation | ||
test-js-with-casper | ||
test-js-with-node | ||
test-locked-requirements | ||
test-migrations | ||
test-queue-worker-reload | ||
test-run-dev | ||
test-tools | ||
update-authors-json | ||
update-locked-requirements | ||
update-prod-static | ||
update-zuliprc-api-field | ||
webpack | ||
webpack-helpers.ts | ||
webpack.assets.json | ||
webpack.config.ts | ||
zanitizer | ||
zanitizer_config.pm.sample |
README.md
This directory contains scripts that are used in building, managing,
testing, and other forms of work in a Zulip development environment.
Note that tools that are also useful in production belong in
scripts/
or should be Django management commands.
For more details, see https://zulip.readthedocs.io/en/latest/overview/directory-structure.html.