A few days ago, Mr Pierre Lalonde posted this question to a post about Quickr Domino.....

Hi Darren,
Since you are (I think) the Reference for Lotus Quickr product, I was asking me this question: How good is Quickr?
We use it internaly to create Quick Room Spaces for limited (< 15) users. Have you deploy Quickr 8.2 in large enterprise (> 1000)?
I think it's a good product, but still not so easy to use for everyone.
What do you think?
- Pierre

I had indicated to Mr Lalonde that this deserved it's own post rather than a simple reply comment and here it is.....

First the $1M question. I believe the largest Quickr implementation I have personally neem involved in was for 850 users (give or take). I think for the purposes of this post 850 is close enough to 1000. That would mean the implicit answer to the question is "yes", however I'll clarify a few points.

1.        This is Domino. This is the Domino HTTP stack. Size your servers larger than you think you'll need or get a partner involved who can do this for you (IBM has a partner resource called TechLine that will do sizing based on a whole slew of answers you provide. We are still limited to 32bit Domino on Windows, but hopefully one day there will be 64 bit Quickr so we can keeps oddles and oddles of stuff in RAM.
2.        Quickr Domino can cluster just like "normal" Domino. As you add more concurrent users, start to look at a clustered environment. You will need some type of IP sprayer (Websphere Edge, etc) but this can even out your load very nicely.
3.        Make sure to tweak/tune the Quickr installation, specifically with caching and other options as outlined in the IBM DevWorks - Performance tuning IBM Lotus Quickr services for Lotus Domino article.
4.        If you are using SSL certificates for HTTPS access to Quickr make sure SSL_RESUMABLE_SESSIONS is sufficient (the default is 50, and a value of 0 is unlimited)
5.        Run DCT to ensure Domino is in an optimal state. Remember, you probably don't need to do all the DCT recommendations, so use with caution.
6.        On servers with a large number of places, upgrades and fix pack installs can take a fair while. Make sure you plan for that. And Quickr clusters are special, RTFM.
7.        Make sure you build your Domino server hardware for performance, that includes transaction logging. See this previous post for some pointers around this.

OK, so there's a few technical pointers. As you can see, Quickr Domino is absolutely capable of scaling to whatever level you need, provided you build your environment with that in mind. Now for some "production" tips....

1.        I like DAOS, and Domino Quickr is no exception. I know Rob Novak has tweeted he doesn't. YMMV. If you do it, leave the DAOS minimum size pretty large. You won't necessarily reduce the disk space used, but your NSF files will be far more svelte.
2.         End user adoption is difficult with any new technology, Quickr is no different. Find a user pain point that Quickr addresses, and roll it out in an over-the-shoulder fashion ("hey, Joe has Quickr.....I need it too"). "It will save disk space on the email server" is usually not sufficient for an end user to embrace Quickr ;)
3.        Know the product issues before you roll it out.....Folder ACLs, Manager access to create folders, etc. (some of these maybe addressed in Domino Quickr 8.5)
4.        If you are using the excellent Quickr Templates from SNAPPS, be sure you check for fixes and new releases before you do a fix pack install.
5.        If you are using connectors, you need to train the users. Errors when uploading will cause no end of issues for users. Also cancelling somebody's check out will lead to cage fights.
6.        Understand Quickr links will not work when disconnected. That sound obvious, but for users it is not. They are so used to replication that everything "just works". They may no longer be able to view a link in an email while on the plane. Hummm, maybe time for a feature request.....Offline Quickr attachment sync, like Activities does......

In conclusion, yes, Domino Quickr is Enterprise Ready. IMHO.
Darren Duke   |   February 16 2010 03:12:10 AM   |    quickr    |  
  |   Next Document   |   Previous Document

Discussion for this entry is now closed.

Comments (3)

Gravatar Image
1 - Pierre Lalonde    http://www.kiwi.ca    02/16/2010 8:16:35 AM

Thank you Darren for your very good explanation.

In the past, we've deployed Lotus QuickPlace for Extranet use by small group of people (< 20) and sometimes for larger ones (>300) but in this case it was use as an information distribution platform.

I think that Quickr will gets better and better over the next years and will benefits from the possibility to easily integrate with other products.

Thanks again for taking the time to answer my 1M$ question.

Best regards,


Gravatar Image
2 - Keith Brooks    http://www.vanessabrooks.com    02/16/2010 9:50:59 AM

Having not only put Quickplace but upgraded many to Quickr I can vouch for the 1,000's. In fact we have a few clients with nearly 1,000 sites and between 5,000 and 20,000 users hitting the one box.

Yes one. A big one and not always in cluster(although we argued for it). Quickr can handle quite a bit of data as well. Internal IBM Quickr sites are huge, 100's of GB per site.

So don't worry keep going.

Gravatar Image
3 - Michael Urspringer    http://www.urspringer.de    02/23/2010 6:25:46 AM

Thanks Darren. Very helpful!