Zulip 1.8: Free software Slack alternative with email-style threading

Post by haffla » Wed, Apr 18, 2018, 11:12 PM UTC

eksmast wrote: post #62

haffla wrote: post #57

Zulip is using Python and Postgresql. Is this a great choice of stack for a chat app? I'd love to know how Zulip performs with hundreds of concurrent users. I am currently looking into Rocket.Chat which is based on Meteor (NodeJS) and MongoDB, a stack which, for me, seems better suited for this kind of app. But hey, I don't know, I haven't done performance tests or anything. Does anyone know about any hard limits wit…

If you care to login, there is a thread on zulip here https://chat.zulip.org/#narrow/stream/2-general/subject/Scal... regarding scaling. Relevant info- Zulip is designed for ~15k users with real-world tests of 3k users. Not sure about concurrent users.

Post by haffla » Wed, Apr 18, 2018, 11:21 PM UTC

rkangel wrote: post #79

haffla wrote: post #57

Zulip is using Python and Postgresql. Is this a great choice of stack for a chat app? I'd love to know how Zulip performs with hundreds of concurrent users. I am currently looking into Rocket.Chat which is based on Meteor (NodeJS) and MongoDB, a stack which, for me, seems better suited for this kind of app. But hey, I don't know, I haven't done performance tests or anything. Does anyone know about any hard limits wit…

PostgreSQL is really really good, for any normal amount of data, or any normal number of users. If you can make Postgre do most of the work, it doesn't hugely matter what you build on it. If you're Facebook or Google scale, you may need something with a different performance characteristics, but 99.9% of the world doesn't. Except that even Facebook doesn't: as I understand it they still use carefully sharded MySQL.

Post by pknopf » Thu, Apr 19, 2018, 1:57 AM UTC

egeozcan wrote: post #55

pknopf wrote: post #47

Earlier quoted context omitted.

Are companies required to delete employee records?

I can't answer your question but I'd like to note that users are not always employees.

Post by johnx123-up » Thu, Apr 19, 2018, 6:14 AM UTC

eksmast wrote: post #62

haffla wrote: post #57

Zulip is using Python and Postgresql. Is this a great choice of stack for a chat app? I'd love to know how Zulip performs with hundreds of concurrent users. I am currently looking into Rocket.Chat which is based on Meteor (NodeJS) and MongoDB, a stack which, for me, seems better suited for this kind of app. But hey, I don't know, I haven't done performance tests or anything. Does anyone know about any hard limits wit…

If you care to login, there is a thread on zulip here https://chat.zulip.org/#narrow/stream/2-general/subject/Scal... regarding scaling. Relevant info- Zulip is designed for ~15k users with real-world tests of 3k users. Not sure about concurrent users.

Post by voidmain » Thu, Apr 19, 2018, 4:53 PM UTC

halestock wrote: post #10

voidmain wrote: post #6

We used Zulip (then a commercial product) at FoundationDB, and really liked it. We had teams in two cities. The threading, which they sell as the core feature, is nice, and does make it more usable for "important" conversations than purely chronological chat. It also makes it easier to screen out conversations you don't care about. But IMO the killer feature is the "all messages" view that merges chosen streams in mo…

Off topic, but man I wish FoundationDB hadn't disappeared.