Introduction

[Patrick Laverty]

Patrick Laverty from Brown University. I've been the sort of project
manager and Confluence application administrator since initial
installation. We currently have almost 300 spaces, over 10,000 pages
and are connected to our central LDAP authentication which has over
26,000 users. We are currently only using a single node connected to
MySQL 5, both on a Red Hat Linux box and using our own Tomcat
instance. My attachments directory has just crossed over 10 GB.

We do want to move to a high availability option so we can aim for
zero service down time, and would like to switch to and Oracle
database, but this thing about the attachments in the database is a
little scary.

[David Foust]

David Foust from Infopro Corp, contracted to NASA. We are running
single node also, Solaris 10 x86 platform running under tomcat. We
have about 500 spaces, 300,000 pages, and about 17,000 users via
LDAP. Oracle database. We have around 70,000 / 150 GB of attachments
right now. Typically we average around 110 users concurrent (in a 5
minute window).

And we are growing growing!

We also desire to scale horizontally, but the limitations with the
attachments and stability issues reported have stopped us. Our HA
solution at the moment is we run on VMWare, so we can vmotion the
server if there is a hardware issue or something. I wish I didn't have
to run on a VM, but I don't see other HA options if we can't run a
cluster.

We also run 32-bit JVM rather than 64-bit. We experimented with
allocating more memory with the 64-bit , but we didn't get anything in
return but slower response times. Our current (relavent) startup
options are:

JAVA_OPTS="$JAVA_OPTS -Xms1G -Xmx3G -XX:MaxPermSize=256m -
Djava.awt.headless=true -verbose:gc -XX:+PrintGCDetails -XX:
+PrintGCTimeStamps -XX:+PrintClassHistogram"

[Igor Minar]

Hi,

Igor Minar from Sun Microsystems. I'm the lead engineer on
wikis.sun.com project - a public facing wiki for sun employees,
customers and communities.

Spaces: 880
Pages: 23k
Users: 71k

Confluence: 2.10.2 with many patches
Confluence mode: cluster, but we use only one node right now due to
poor reliability of the cluster
Confluence user management: default hibernate + custom Single SignOn
authenticator
Confluence attachment storage: db storage (we limit attachment size to
5MB)
DB: MySQL 5
Webserver: Sun Java Webserver 7
Java: Java 6 64bit

[Dan Hardiker]

Hi,

Dan Hardiker from Adaptavist. I'm a senior specialist consultant here
and work with clients to, amongst other things, scale to millions of
pages across thousands of spaces accessed by hundreds of thousands of
users. We mainly work on Linux/Windows with MySQL/Oracle/MSSQL ...
Java 6 all the way. I can't talk about any specific client systems,
although I will encourage them to join.

To be clear, I'm not here to pimp our services (you can decide for
yourself if you need them), instead we believe in open knowledge as
well as open source.

[Stefan Kleineikenscheidt]

Hi,

I'm Stefan Kleineikenscheidt from K15t, Stuttgart, Germany. I develop
a commercial plugin called 'Scroll' for exporting trees of Confluence
pages to DocBook and other formats. Previously, I worked at the
largest automotive supplier in the department running a confluence
instance with some 10 thousands users. Back then my job was to
heavily customize JIRA to turn it into a workflow management system
for internal use.

I am here to understand better the requirements of large scale
confluence installations and get a better understanding of what we
need to do to get our plugin ready for large confluence installations.

[Mark Nye (UIUC)]

This is Mark Nye from University of Illinois at Urbana-Champaign. We
have a campus Confluence installation running on a single Sun T2000
with Oracle. We use Confluence standalone (patched up v2.8.2) behind
Apache2. Authentication / authorization is over LDAP from the campus
AD. We have ~60,000 potential users with maybe 3,500 active
contributers. Currently we're hosting 650 spaces with about 20,000
pages and 16,000 attachments. Database size is 14GB.

System performance is slowly turning into an issue as the space and
page counts grows. We see three problems:

1) The dashboard (we use a standard Confluence layout) is becoming
very slow for some users. This appears to be a function of the total
system space count multiplied by the AD group membership count of the
individual user. We've done some cache turning, but it hasn't resulted
in significant improvement.

2) Per-thread execution speed on the T2000 is slow enough to have an
impact on some pages that use certain plugins, or include many comment
or links. Page load performance also appears to be impacted by per-
user AD group membership count.

3) Some plugins don't work well in an enterprise environment, and can
trigger full GCs that bring the whole service to a standstill. We've
experienced issues with the Calendar and Excel plugins.

We're looking at moving to a clustered installation with a set of
Intel-based application servers, while keeping the T2000 up front
running apache. I expect that this will greatly improve page render
speed, but I'm concerned that LDAP will continue to present a serious
bottleneck. There are other issues, but that's enough for an
introductory note.

I'm happy to see this group being created, and you can count on UIUC
being an active participant.

[DeltaKnowledge]

Hi All,

I work for Daniels Sharpsmart, an international manufacturer of
Healthcare safety technologies. We are based in Melbourne Australia
with offices in Chicago, USA and Spennymoor, UK and plants in USA,
Canada, Australia, New Zealand and South Africa.

I have a Masters in KM and completed my thesis on "Wiki use in Small
to Medium Enterprises", focusing on the cultural aspects of successful
and unsuccessful wiki implementations.

Daniels is running Confluence (v2.10.2 currently) with around 20
spaces, 50 users and around 10,000 pages. So we are a lot smaller than
you guys, but we seem to have a higher page/user ratio. We were
initially running LDAP, but turned it off when we need to give
external's access to the wiki,but not AD. After some corporate buy-
outs, etc, we are looking at going back to LDAP soon.

I look forward to hearing about the issues raised in this group and
how they are overcome. Hopefully I can also be of assistance from
time to time.

Kind Regards,

Stuart French
IT/KM Project Manager

[unixg...@gmail.com]

I'm Alice, in the Washington DC area. I work for a branch of the
federal government as a contractor. I've been asked not to discuss
details about problems we are having and then associate them with our
particular sites. Don't want to provide information for potential
hacker attacks.

I'm not full-time on Confluence, but Confluence admin is the biggest
part of my job. Started on 2.3 with HSQLDB and many crashes. Other
people have varying experience as confluence admins or developers.

We've got various confluence installations either in place, in
development, or in speculation. One site with 400 LDAP users and 400
spaces and 2GB of attachments, another with 10000 LDAP users, 10
spaces and 50MB attachments, others with anonymous users... No real
idea how much any of these sites will grow, other than if our
performance is slow, it won't be used as much.

Management wants us to look closely at clustering. We're not so sure.

We are getting more and more requests to create new "wiki's". Some of
them want to be very customized for their group, or look like a
standard website. Others want to be part of our big wiki even though
they have quite different access restrictions, groups, and purposes.

All newer sites are 2.8.2. Oldest site is still 2.5.7, but we are
working on migrating it to 2.8.2 for consistency's sake.

We've had performance problems on our biggest site. It's been up less
than a year. We've made a couple changes that have helped.

When we did profiling of certain pages, we found that the permission
checking was cycling through every group a user belonged to in order
to determine whether they had read access, write access, etc. Since we
have hundreds of LDAP groups, and one person might be in 20+ groups,
this took a long while. It didn't just check that all users were in
confluence-users and had all the needed accesses there. So we used the
<groupSearchFilter> tag in atlassian-user.xml to change Confluence to
only retrieve the 5-10 groups it needed.

The other issue was that we had the webserver and confluence app
server (Standalone) on the same SPARC Solaris box. So we moved the
Confluence install to an x86 Solaris server.

So old installs have Confluence on SPARC on the same box as the
webserver, and new installs have them separate. In both cases the
MySQL 5.x database is on a different Solaris/SPARC server. All Solaris
10 sites.

Thanks,
Alice

[Dan Petzen]

Hi.

I'm Dan Petzen, working on contract for a major financial institution
in London City. I was asked to re-engineer and develop Confluence (and
Fisheye/JIRA) roughly two years ago. We've gone through a long range
of performance issues as the number of users and data grew. I just did
a few quick queries and this is where we currently are at:

Pages: 1,354,896 (160,940 unique)
Attachments: 113,569 (45GiB on disk)
Spaces: 2,030
Users: 21,555 (in the Confluence DB - no LDAP)
Hits per day: ~200,000

We're still running the system on a 4 core/4GiB blade server, but new
hardware has been allocated, so we'll use an 8 core system together
with a 4 cores system as a cluster.

I won't go through the performance problems and the solutions we've
thrown at them as they would be too many to list, but I'm happy to
elaborate. Please just ask.

I'm currently almost done clustering Confluence 2.10.2.