Poor performance with very large stanzas

We have an application that sends multi-megabyte stanzas. Our standard socket-based implementation of the protocol can transfer these messages over our local network quite quickly. When I send these same messages over ejabbered, they can take several minutes, and ejabbered uses 100% cpu during the whole operation. I turned off offline message storage, have removed all traffic shapers, but cannot determine why ejabbered would use so much CPU to process a few MB like this.

Does anyone have experience getting this to work?

You're going to have to

You're going to have to provide more detail when you ask questions like this.

  • Which ejabberd version?
  • Which Erlang version?
  • Which operating system and version?
  • What hardware? CPU, RAM, etc
  • Ethernet speed?
  • How many multi-megabyte messages were you sending at the same time, and how frequently?
  • How many online users?
  • When you say 100% CPU, do you mean that all CPUs were at 100%, or just the ejabberd Erlang VM?
  • What was the ejabberd VM's memory consumption?
  • Any other info like this could be helpful.

Sure. Ejabbered version: I'm

Sure.

Ejabbered version: I'm using the ejabberd installed by apt-cache on Ubuntu11.04 (apt-cache reports Version: 2.1.5-3+squeeze1build0.11.04.1).

Erlang: Also from apt, which reports version: 1:13.b.3-dfsg-2ubuntu3

OS and computer specs: I'm running on ubuntu 11.04 on a 4 CPU linux box w/ 16 GB ram and hyperthreading (so it looks like 8 cores to the user).

Ethernet is a 1GB ethernet card, but all messages are sent to/from localhost, so none of the messages in question are hitting the network.

I can repro this with exactly 1 large message bringing ejabberd up from a clean state. I have two users logged in - one sending and one receiving. We are not saving messages for offline consumption, nor is logging set to verbose. I have max stanza size set to 100MB and I have disabled all shapers.

The 'beam' process was using exactly 100% of 1 cpu after the message was sent and finished processing the message approximately 5 minutes later.

If I send the same data in 100K chunks it completes in under 3 seconds. This is a workaround we are using now, but it's not idea long-term. We're running our application over BOSH, so we only get two connections at once from the browser. Limiting ourselves to 100K per round-trip with the server over the internet is not ideal.

Anything else I can add?

Thanks.

Syndicate content