mirror of
https://github.com/zulip/zulip.git
synced 2025-11-07 07:23:22 +00:00
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>
126 lines
3.4 KiB
Plaintext
126 lines
3.4 KiB
Plaintext
upstream staging {
|
|
server staging0.zulipchat.net:443;
|
|
|
|
keepalive 10000;
|
|
}
|
|
|
|
upstream prod {
|
|
server prod0.zulipchat.net:443;
|
|
|
|
keepalive 10000;
|
|
}
|
|
|
|
server {
|
|
listen 80;
|
|
location / {
|
|
return 301 https://$host$request_uri;
|
|
}
|
|
|
|
include /etc/nginx/zulip-include/certbot;
|
|
}
|
|
|
|
server {
|
|
# The listen needs to be `www.zulipstaging.com` since bare zulipstaging.com
|
|
# is not a CNAME and thus has the public IP inside EC2
|
|
listen www.zulipstaging.com:443 http2;
|
|
server_name zulipstaging.com *.zulipstaging.com;
|
|
|
|
ssl on;
|
|
ssl_certificate /etc/letsencrypt/live/zulipchat.com/fullchain.pem;
|
|
ssl_certificate_key /etc/letsencrypt/live/zulipchat.com/privkey.pem;
|
|
|
|
location / {
|
|
proxy_pass https://staging/;
|
|
include /etc/nginx/zulip-include/proxy;
|
|
}
|
|
|
|
# We don't need /api/v1/events/internal, because that doesn't go through the loadbalancer.
|
|
location ~ /json/events|/api/v1/events {
|
|
proxy_pass https://staging;
|
|
include /etc/nginx/zulip-include/proxy_longpolling;
|
|
}
|
|
|
|
include /etc/nginx/zulip-include/certbot;
|
|
}
|
|
|
|
server {
|
|
# The listen needs to be `www.zulipchat.com` since bare zulipchat.com
|
|
# is not a CNAME and thus has the public IP inside EC2
|
|
listen www.zulipchat.com:443 default_server http2;
|
|
server_name zulipchat.com *.zulipchat.com;
|
|
|
|
ssl on;
|
|
ssl_certificate /etc/letsencrypt/live/zulipchat.com/fullchain.pem;
|
|
ssl_certificate_key /etc/letsencrypt/live/zulipchat.com/privkey.pem;
|
|
|
|
location / {
|
|
proxy_pass https://prod;
|
|
include /etc/nginx/zulip-include/proxy;
|
|
}
|
|
|
|
location ~ /json/events|/api/v1/events {
|
|
proxy_pass https://prod;
|
|
include /etc/nginx/zulip-include/proxy_longpolling;
|
|
}
|
|
|
|
include /etc/nginx/zulip-include/certbot;
|
|
}
|
|
|
|
server {
|
|
# The listen needs to be `www.zulip.com` since bare zulip.com
|
|
# is not a CNAME and thus has the public IP inside EC2
|
|
listen www.zulip.com:443 http2;
|
|
server_name zulip.com *.zulip.com;
|
|
|
|
ssl on;
|
|
ssl_certificate /etc/letsencrypt/live/zulipchat.com/fullchain.pem;
|
|
ssl_certificate_key /etc/letsencrypt/live/zulipchat.com/privkey.pem;
|
|
|
|
location / {
|
|
proxy_pass https://prod;
|
|
include /etc/nginx/zulip-include/proxy;
|
|
}
|
|
|
|
location ~ /json/events|/api/v1/events {
|
|
proxy_pass https://prod;
|
|
include /etc/nginx/zulip-include/proxy_longpolling;
|
|
}
|
|
|
|
include /etc/nginx/zulip-include/certbot;
|
|
}
|
|
|
|
server {
|
|
listen chat.hl7.org:443 http2;
|
|
server_name chat.hl7.org;
|
|
ssl_certificate /etc/letsencrypt/live/chat.hl7.org/fullchain.pem;
|
|
ssl_certificate_key /etc/letsencrypt/live/chat.hl7.org/privkey.pem;
|
|
|
|
location / {
|
|
proxy_pass https://prod;
|
|
include /etc/nginx/zulip-include/proxy;
|
|
}
|
|
|
|
location ~ /json/events|/api/v1/events {
|
|
proxy_pass https://prod;
|
|
include /etc/nginx/zulip-include/proxy_longpolling;
|
|
}
|
|
|
|
include /etc/nginx/zulip-include/certbot;
|
|
}
|
|
|
|
server {
|
|
listen uploads.zulipusercontent.net:443 http2;
|
|
server_name uploads.zulipusercontent.net;
|
|
|
|
ssl on;
|
|
ssl_certificate /etc/letsencrypt/live/uploads.zulipusercontent.net/fullchain.pem;
|
|
ssl_certificate_key /etc/letsencrypt/live/uploads.zulipusercontent.net/privkey.pem;
|
|
|
|
location / {
|
|
proxy_pass http://127.0.0.1:9292;
|
|
include /etc/nginx/zulip-include/proxy;
|
|
}
|
|
|
|
include /etc/nginx/zulip-include/certbot;
|
|
}
|