In preparation for our transition from Proof of Concept to "pilot" we're looking at capacity planning with regard to our total projected user base over time, estimated groups/spaces and performance expectations as we grow.
Do you have any "best practices" shared by other enterprise customers (i.e. EMC), that could give us an idea of a recommended limitation for file size to be uploaded by users?
We're currently using 15MB limitation and we're concerned about performance impact over time as more and more users join and begin uploading documents. Our intent is to use Clearspace as the go-to place for our SEs to share information and content associated with the selling process (BoM, network design, product information, etc.).
Questions:
1. What does Jive use as a file size limitation?
2. Can you share "best practices" from other large enterprise customers?
3. Is there any correlation between file size, number of users and performance? If so, explain.
4. What other things do we need to think about as we architect our social network?
Hey Joe,
1. What does Jive use as a file size limitation?
On Jivespace (this site) we currently have file upload sizes limited to 100MB per file.
2. Can you share "best practices" from other large enterprise customers?
This really depends mostly on your needs. If you are looking to use Clearspace to allow the upload of most regular documents, spreadsheets, images, etc then the default is usually fairly good. I'd say on average a setting between 15MB and 50MB is usually more than enough for most uses. But again, this is really dependant on your situation. You can change this limit at any time if need be as well.
3. Is there any correlation between file size, number of users and performance? If so, explain.
Nope, there should be no performance impact simply based on the number of attachments or size of attachments. These files are simply stored in the database (and filesystem cache) upon upload and each request afterwards goes directly to the cache. The application should not be affected in any noticable way by this process.
4. What other things do we need to think about as we architect our social network?
In regards to file uploads there isn't much that I can think of off the top of my head. Most of the settings that you will set from the start can be modified at any time down the road to facilitate a change in expectations or requirements. Hopefully that helps. Let me know if you have any further questions. Thanks!
-Todd
Log in as admin.
Click on systems, setting, attachment.
3. Is there any correlation between file size, number of users and performance? If so, explain.
Nope, there should be no performance impact simply based on the number of attachments or size of attachments. These files are simply stored in the database (and filesystem cache) upon upload and each request afterwards goes directly to the cache. The application should not be affected in any noticable way by this process.
Todd,
We are running SBS 3.0.4 on RHEL 5.2 on Amazon EC2 on a high-CPU medium instance. We had uploaded a 50 or 60mb file to SBS and noticed some significant stability issues. We'd see SBS get killed by the Linux out of memory monitor (or whatever it's called). This happened a few times and finally I ended up installing Monit to keep track of things so it could restart SBS if Tomcat was killed. We ended up moving our file onto the filesystem and letting Apache serve it up directly, instead of going through SBS.
Andy
Jive combines the most powerful features of collaboration software, community software,
social networking software & social media monitoring into the leading SBS solution.
© Copyright 2000–2010 Jive Software. All rights reserved.
915 SW Stark St., Suite 400, Portland, OR 97205
Sales: 877-495-3700 | General: 503-295-3700
Privacy Policy | Sitemap | Jobs | Contact Us