Alex Vandiver 58bf2a7935 tornado: Limit the width of the user queries, when they're needed.
Tornado requests try hard to not make SQL queries -- and if they're
necessary, to minimize the number of them.  Specifically, both session
objects and user objects are cached in memcached, and we expect that
both of them will have been filled there by Django before any requests
are made to Tornado.

In the event that memcached is flushed, or data is otherwise evicted,
we perform two database queries -- one for the session, and one for
the user.  However, the *width* of the latter query has grown
significantly over time, as the Realm object grew more fields, and
recently with the addition of role groups, which require multiple
joins each.  This leads to a query which is over 12k of text long, and
results in 319 columns.  In the event of a memcached flush, this can
result in a *significant* amount of SQL traffic, as nearly every
active Tornado request will make that query.

We do not wish to narrow the default query for Django; we instead tag
the request in the REST wrapper, and use that to use a much narrower
user cache entry.  That narrower cache entry is filled before the
queue is created in Django; we also use it to explicitly set the log
data, so the second "half" of the continued Tornado request does not
need to fetch any user data either when writing its log line.

Because they use different cache keys, this only affects the
session-based `/json/events` endpoint, which caches by user-id; the
`/api/v1/events` endpoint, which uses an API-key cache, keeps its wide
user object.  The former is 50% of the total request volume, whereas
the latter is only 2%, so adding an additional cache for it is
unnecessary complexity.
2025-02-13 12:40:53 -08:00
2024-12-10 10:00:45 -08:00
2024-12-10 10:00:45 -08:00
2024-11-13 09:18:56 -08:00
2025-01-14 09:42:16 -08:00

Zulip overview

Zulip is an open-source team collaboration tool with unique topic-based threading that combines the best of email and chat to make remote work productive and delightful. Fortune 500 companies, leading open source projects, and thousands of other organizations use Zulip every day. Zulip is the only modern team chat app that is designed for both live and asynchronous conversations.

Zulip is built by a distributed community of developers from all around the world, with 74+ people who have each contributed 100+ commits. With over 1000 contributors merging over 500 commits a month, Zulip is the largest and fastest growing open source team chat project.

Come find us on the development community chat!

GitHub Actions build status coverage status Mypy coverage Ruff code style: prettier GitHub release docs Zulip chat Twitter GitHub Sponsors

Getting started

You may also be interested in reading our blog, and following us on Twitter and LinkedIn.

Zulip is distributed under the Apache 2.0 license.

Description
Zulip server and web application. Open-source team chat that helps teams stay productive and focused.
Readme Apache-2.0 817 MiB
Languages
Python 58.5%
TypeScript 18.1%
JavaScript 9.1%
CSS 3.9%
HTML 3.6%
Other 6.6%