Where are the audit logs stored in 2.1 running on RedHat (Fedora)?
How many users can the built in database support?
Where are the audit logs stored in 2.1 running on RedHat (Fedora)?
How many users can the built in database support?
If you use the RPM, Jive Messenger will be installed to /opt/jive_messenger. That would make the audit directory /opt/jive_messenger/logs. The file names will be in the form “jive-audit-1.log”
We haven’‘t tested the exact number of users that the embedded database can hold. I’‘m sure it wouldn’'t have problems with several tens of thousands, though.
Regards,
Matt
Hi Jeff,
When in doubt:
rpm -ql jive_messenger
or better still:
rpm -ql jive_messenger | grep log
(which only narrows the spectrum, but take a look at what else shows up).
And now a question for Matt.
Given that the embedded database can handle on the order of 10,000+ users, do you have any guidelines for determining a practical recommendation (or limitation) on the number of concurrent users? For example, the number of connections (with no traffic) would no doubt depend on basic kernel tuning params like fs.file-max, let alone the additional load generated by the typical user (sporadic bursts of sub-1k traffic), although that would no doubt be aggravated by each user joining multiple conference rooms.
I realize this is somewhat akin to asking how long a piece of string is, but if you could direct me to any Jive tuning docs in particular and JVM tuning links which you’‘ve found to be helpful, that’'d be great.
Now for a more specific question particular to my needs: Can you see any issues trying to support 200 internal (ie, private) (mostly technical) users on a single-CPU Linux host using Jive? My feeling is this should be relatively painless but defer to your experience.
Given that the embedded database can handle on the
order of 10,000+ users, do you have any guidelines
for determining a practical recommendation (or
limitation) on the number of concurrent users?
Jive Messenger currently uses Java’‘s standard I/O. This means one thread is allocated for each socket connection. This probably means that a reasonable limit for concurrent users is somewhere around 2500. If using Linux, it’'s definitely important to use the new threading lib.
Java now has the NIO library which doesn’‘t have the one thread per socket limitation. That would likely let the server scale to around 10K connections. However, I don’'t know of any XML parsers that integrate with NIO well yet.
For
example, the number of connections (with no traffic)
would no doubt depend on basic kernel tuning params
like fs.file-max, let alone the additional load
generated by the typical user (sporadic bursts of
sub-1k traffic), although that would no doubt be
aggravated by each user joining multiple conference
rooms.
Yep, the probable limits I discussed above would certainly be decreased by active users. Also, the embedded database will put more load on the server vs. an external database on another box – so it’'s likely an external db will scale better.
I realize this is somewhat akin to asking how long a
piece of string is, but if you could direct me to any
Jive tuning docs in particular and JVM tuning links
which you’‘ve found to be helpful, that’'d be great.
We haven’'t had the time or testing environment yet to really figure out what the max reasonable traffic loads are. We hope to start figuring this out soon.
Now for a more specific question particular to my
needs: Can you see any issues trying to support 200
internal (ie, private) (mostly technical) users on a
single-CPU Linux host using Jive? My feeling is this
should be relatively painless but defer to your
experience.
This shouldn’'t pose any problems at all.
Regards,
Matt
I need to know
How many users can the built in database support?
How many users can connect to the server ?
Thanks
Luis,
Please see my answers already in this thread. We don’'t have any more exact numbers than that at this point.
Regards,
Matt
Thanks