We’‘re planning to use Wildfire as the basis for a campus IM service at a public university. Total population (potential users) is around 35,000. Concurrent connections is anyone’‘s guess, I think we’'ll find out as things progress.
The deployment will run on Linux, with authentication via PAM (pam_krb5.so to be exact). We hope to use LDAP groups in a later phase.
Does Jive offer sizing guidelines?
I would recommend starting with a powerful dual processor box running Linux or Solaris with 2 to 4 GB of memory. You won’‘t be able reach 35K concurrent users with a single box and the current version of Wildfire (although it doesn’'t sound like you need to at first). However:
University of Chicago has tested with 20K concurrent users using a 64 bit server and JVM.
The Pampero project is scheduled to be released within the next six months and will let you scale to many tens of thousands of connections by using multiple servers.
Several universities I’'ve talked to are rolling out IM to one section of their user population at a time to gain experience – staff, faculty, then students for example.
We’'d definitely love to help make your implementation successful so let us know what we can do to help. Will you be using Spark?
Regards,
Matt
We plan on being client-agnostic, but Spark will probably be among our list of recommended clients. I imagine the recommendation might get stronger once we use LDAP for groups and identity information.
For the RAM sizing, is thre a particular amount consumed by each login and session?
For the RAM sizing, is thre a particular amount
consumed by each login and session?
One trick you can use to decrease memory usage is to set the thread stack size, by passing in -Xss128k to Java. The following thread discusses that:
http://www.jivesoftware.org/community/thread.jspa?threadID=15498
Otherwise, we don’'t currently have a good estimate for the amount of memory used by each user.
Regards,
Matt
Message was edited by: matt
Hi,
it’‘s very hard to tell, Wildfire has a local database cache, so allocated memory may usually be also for the cache. If you just do a connect and login without reading the vcard information you may calculate 30 MB for 100 users and 300 MB for 1000 users. I did not test with more users, but because of the cache it seems that it makes no difference of you have concurrent users or not, it’'s always a minimum of 300 MB for 1000 users.
LG
because of the cache it
seems that it makes no difference of you have
concurrent users or not, it’'s always a minimum of 300
MB for 1000 users.
I don’‘t believe that’'s the case. All caches are size limited so will never grow beyond a certain size.
Regards,
Matt
Atlauren,
Off topic, but Id be interested to know if your university uses Kerberos for many applications. Ive been working on GSSAPI/Kerberos auth in Wildfire and if its something you are interested in, I would love to have someone else test things. Obviously not all, or even many, of your users would use GSSAPI, but perhaps if in a lab where users already had Kerberos credentials the single-sign-on could be useful.
I’‘m in nearly the same situation, I’'m setting up an upgrade jabber server for Iowa State University with kerberos being big on the wish list. jabberd2 is going nowhere at the moment and wildfire is looking better and better. Our userbase for now is rather small, but if we could get it working we would want to make it a major university service. GSSAPI/krb would make up a large percentage of the total use because most users would be using our computers so we could patch Gaim and push it out.
I’‘m in nearly the same situation, I’'m setting up an
upgrade jabber server for Iowa State University
Nice! We started Jive Software in Iowa (Bill and I both went to the University of Iowa and are from Iowa City). Jabber the open source project also got it’'s start in Iowa, I believe. So, lots of Iowa connections…
kerberos being big on the wish list. jabberd2 is
going nowhere at the moment and wildfire is looking
better and better. Our userbase for now is rather
small, but if we could get it working we would want
to make it a major university service. GSSAPI/krb
would make up a large percentage of the total use
because most users would be using our computers so we
could patch Gaim and push it out.
If Spark had Kerberos support, would that be an option for you?
Regards,
Matt
Hi Matt,
was this an announcement that you’'re going back to the University of Iowa to give a lecture?
LG
I think Spark would be an option if it were kerberized out of the the box. AFAIK there aren’'t any good clients with krb support out yet. Right now I think most people use .gaim for our jabber server, but spark looks like a good suggestion for students for a class jabber room or something like,
One trick you can use to decrease memory usage is to
set the thread stack size, by passing in -Xss128k to
Java. The following thread discusses that:
adID=15498
Thanks, I’'ll try that. For a linux install, is the filename still “messengerd-service.exe.vmoptions”?
At the moment I’'m seeing 2.5 run out of memory after getting over three hundred errors like this in about ten minutes:
[org.jivesoftware.wildfire.net.SocketReader.run(SocketReader.java:159)]
Connection closed before session established
15517d3[SSL_NULL_WITH_NULL_NULL:
Socket[addr=/[ipremoved],port=14926,localport=5223]][/code]
I’‘m guessing it’‘s a borked PC out in the residential dorms. (Edit: Nope. Turns out it’'s our network vulnerability scanner! Cool.)
Message was edited by: atlauren
Turns out it’'s our network vulnerability scanner!
Hi Andrew,
you did hit the well-known OOM bug. If you just open and then close a TCP session to port 5222, 5223 or 5269 you cause this problem. I hope that this one is fixed very soon.
I think that you need to edit the wildfire start script (whichever is used), there is a variable which should be set to “-Xss128k” and also with Xmx and Xmx values.[/b]
LG
Hey LG,
I don’'t know if he is running into that same problem but anyway the problem was fixed and the latest nightly build includes the bug fix for JM-573.
Andrew, if you are not closing connections before they finish sending the initial stream header then you may have another issue. Let me know if this is not your case so we can follow this problem up.
Thanks,
– Gato