Answered by:
Sharepoint 2013 - In Production Use?

Question
-
Hi
Dead simple - but genuine question - is Sharepoint 2013 fit for production use?
We are working on SP 2013 project for an SME with a small budget. We are coming against so many difficulties and issues with SP2013 that is becoming intensely frustrating and difficult to progress the project (even though the project requirements themselves are pretty straight forward).
We invested in SP2013 on the basis that it would make it easy to build a simple Document Storage and Records Management solution. Our view was, there is a market leading product here that people use for exactly this requirement, so why re-invent the wheel?
However, had we started from scratch and just build a pure ASP.NET application, I think we would have the project done and dusted by now (i.e. 6 months in at the moment) Yet with SP2013 we have encountered nothing but roadblocks:
1) Incredibly difficult and time-consuming to build very simple workflow constructs (Check-In a record, Declare a Record when an Item is created, Upload a Document larger than 20MB etc.)
2) Big administration and security headaches (We have a MS Support Engineer now trying to resolve an Office Web Apps Server integration issue for over 4 months and counting, with no resolution in sight; We are having constant problems with Claims Authentication; Crawling services continually fail etc. )
3) Simple performance issues. We are running on a 2-server farm with 32GB++ total RAM and very good hardware, including 8 cores on each box. Despite this, we are plagued by "pre-compilation" delays, ie. it can take up to 30 seconds to initially load a page, and sometimes they won't load at all; response times are very poor; we have worked hard on numerous "warm-up" scripts all to no avail, etc.
So...setting aside the rant, the question is a genuine one. Working with a small organisation with only a limited amount of development dollars, have we completely chosen the wrong product here? Is it the case that in order to build a reliable, fast, efficient but small-scale and basic Sharepoint solution, you need a minimum development fund of say, $250,000 or more? We have burned through maybe $70k so far on development, I would guess, and we are still faced with nothing but problems and nowhere near the end.
So what I am getting at here is.... Is $100,000 development budget simply not enough to build a small-scale solution based on Sharepoint 2013? Or have we simply chosen a product that is simply not yet fit for production use?
I would really like to know what others are experiencing out there, as I am just not sure whether the problem is entirely on our side, or whether, we have made the mistake of adopting SP2013 too early etc.
I appreciate it is difficult to ask for guidance without going into additional specifics, but I am just looking for a general guide as to what other people are doing and what kind of successes they are having, if any. If lots of other people have been able to build good SP2013-centric solutions at around the $100,000 mark, then clearly we are doing something wrong. On the other hand, I am honestly beginning to wonder if by investing in SP2013, we have simply bitten off a lot more than we can chew, and that we're not going to ever get a decent solution in place without spending, say, fives times as much, in which case, we really need to perhaps consider not throwing good money after bad.
The scale of the project we are trying to put together, is a simple records management Site, with around 10 document libraries and 3 or 4 search pages, for a group of 15 end users - that is literally the entire size of it.
I would really appreciate it if anyone is carrying out similar size projects, whether you have been successful with SP2013 and what sort of spend you had, etc.?
- Moved by Hemendra Agrawal Monday, June 24, 2013 6:15 AM SP 2013
Friday, June 21, 2013 4:59 PM
Answers
-
You're right, that's not acceptable performance and it is a sign something is going wrong. It is not going to be performance related (it's possible but so stupidly unlikely that it's not worth looking into at this point)
The first load of a site will always be slow. 20 to 30 seconds is not unreasonable, whilst you might be able to shave a little time off on hardware it's never going to get fast. To deal with the first load times your only options are warmup scripts or to tolerate it. For you i'd go with the warmup scripts.
However if you're timing out (typically an error message after 90 seconds) or getting significantly longer load times than 20-30 then it's a sign something isn't right.
The easiest way to see the slow load times is on the Central Admin site, how long does that take to start up after an IIS reset?
When you do that first load do you get any errors in the event viewer or in the SharePoint ULS logs on either the web front end or the application server? Also Enable the CAPI2 log on the servers (google will tell you how to find it, my other half is moaning about working on the weekend...) to confirm you're not getting any certificate issues.
The frustration is reasonable but there is hope.
- Edited by Alex Brassington Sunday, June 23, 2013 5:16 PM Added text regarding performance.
- Marked as answer by GuYuming Tuesday, June 25, 2013 2:15 AM
Sunday, June 23, 2013 5:15 PM
All replies
-
Hi Robert,
In my experience in most of the cases I have seen SharePoint being implemented primarily for corporate intranets , out of box document management and web development platform with several 10's of thousands of users and it definitely gets an expensive affair with the licensing and infrastructure costs and then operations.......SharePoint is so vast and has functionality and integration with several Microsoft products and one of the widely used product....but it doesn't mean that its for everyone .........some times the widely used might not fit for our requirements
Just taking into consideration the number of users you mentioned and the requirements you mentioned......I don't see much cost advantage in hosting in house...Generally large corporate gets the advantage of SharePoint by enabling collaboration between teams across geographies, faster development as you build on the features SharePoint already..have..and at the same time they have the money resources to manage these systems...
In your case you might consider SharePoint online and check the possibility of using no code solution which might save a lot of dollars on a longer run.......
I am not sure on the confidentiality of the data you are going to store...but there are many big companies which store data on the cloud...
Regards Murali
Friday, June 21, 2013 6:46 PM -
Thanks for your thoughts.
I think you may be right, and that we may have made a very costly mistake in investing in SharePoint for this size of organisation
Your views seems to cement my own suspicion that it is simply not a suitable product for us and that SharePoint is literally "too large" and complex for us to be able to deliver a solution - we simply do not have the Resources.
thanks again for your input
Friday, June 21, 2013 6:52 PM -
I do most of my work in SME environments, most of those are still using 2010 but a couple are on 2013 and do like it.
Is it fit for production use? Yes.
Your approach does sound problematic, by buying an off the shelf system you are by definition accepting a compromise. Generally they are cheaper systems which doesn't meet all your requirements perfectly but that has better support, more features and are less risky. It may well be that SharePoint is capable of meeting the business requirements but that the approach to getting there needs to change, probably including business process change.
This also feeds back into your use of the term 'develop'. Development is, in my mind at least, what developers do with C# code or painful amounts of Javascript. When you're on a limited budget you should keep your development to an absolute minimum, especially if you don't have experienced SharePoint developers. If you want to do ECM then you shouldn't need to do any development work at all. It's all configuration.
Also don't underestimate the difficulty in creating a custom application. It might be that the budget simply isn't big enough to meet the requirements, in which case you should be re-visiting the 80/20 rule.
2) Those aren't big security or administration headaches. The big security headaches is implementing a legal hold, arranging automatic deletion and mis-declared documents, recovering files that have been deleted in error and auditing processes as well as the ongoing 'who owns what' when someone leaves. This is one of the places where custom applications fall down, MS have pumped millions into developing ECM in SharePoint and it's pretty decent. Doing better isn't going to be easy on 100k.
3) It's a known issue, warm up script such as this: http://www.toddklindt.com/blog/Lists/Posts/Post.aspx?ID=404 or this: http://gallery.technet.microsoft.com/sharepoint/SharePoint-2007-2013-Warm-f5693356 can let you reduce the impact a lot.
So, short version. Don't develop, configure.
Also experience counts for a lot, find a SharePoint architect who's done a few similar projects and pay through the nose for them to sketch out the solution for you. It'll save you money overall and reduce the risk that you'll just keep burning cash.
- Edited by Alex Brassington Saturday, June 22, 2013 9:55 AM Added text.
- Proposed as answer by Jesper Arnecke Saturday, June 22, 2013 10:40 AM
Saturday, June 22, 2013 9:52 AM -
Just to support Alex comment. Most of the issues seen around SharePoint implementations are due to poor configuration of the system. Secondly poor knowledge of using the OOB functionality.
SP2013 introduces quite a few new ways of implementing and configuring, so you might find that getting an external expert opinion on your implementation might set you on right course.
Your budget sounds rather high to me. To build a stable SP platform takes 2-3 days. (Excluding AD, O/S, but including SP(service applications, web applications the lot) and SQL. If your concurrent users fits the architecture, then you shouldn't have any lags or poor performance.
Then add any OOB configuration of workflows etc. I mean with the consultancy price I'm selling at which is about 200$ per hour(Dk prices), there is still quite some budget for building workflows and "extra" functionality. I presume when you say development budget, you don't include licenses or other 3'rd party products? (Nintex etc.)
I'm starting to be impressed how it would actually be possible to spend that amount on the tasks you describe. Also what you should always consider is, that when you choose a standard product, your workflows needs to be standardized to match the product. Else you will end up in customization hell and burn there forever! - sorry got carried away. You will end up with a monster of a solution, which is expensive and annoying to maintain and develop, will never work as intended and not give you the benefits your were hoping for.
Saturday, June 22, 2013 10:54 AM -
Thanks for all your comments.
Just to take my perspective on this a step further and hopefully clarify why I am asking the "fitness for purpose" for question
As a weekend experiment, I set up a mini 3 server farm
The backend SQL Server database is 2008 R2 with 12GB RAM
The application SP2013 box is 2008 R2 with 12GB RAM
The front end web SP2013 box is 2008R2 with 12GB RAM
All three boxes are using 4 CPU's and RAID50 disks, with separate log drives on RAID 10 disks and separate OS swap files on RAID10 disks.
I followed the three-tier TechNet Installation guide to the letter, including the Set up of AD Accounts and the installation of KB fixes etc.
After the final front end web server was added to the Farm, and with no content, documents or anything else added to the system, I just did some basic performance testing, and I am already seeing errors ("Sorry, something went wrong") simply when trying to access the "Health and monitoring" section in Central Administration.
The issue is undoubtedly being caused by ASP.NET pre-compilation, because after say, trying it 3 or 4 times, trying to access exactly the same link will work like a charm and be very quick. But then, as soon as I try to access something that is not pre-compiled, it's back to square one again. This is exactly the same issue we were experiencing on our development box, and presumably is what the warm scripts are designed to help with etc.
Looking at the performance figures in Resource Manager on the servers, it is obvious that the disks and RAM are not bottle necks here for this fairly unscientific testing scenario. It just takes ages for SharePoint to precompile and anything; and bear in mind, this is on a brand new farm with NO content whatsoever. What is going to happen when we start to actually add content?
You can see why I'm pessimistic here. This is not a hardware issue - it's a SharePoint issue. How can I ask my users to tolerate an application that works this way? I'll be a laughing stock. Even if I do zero development and try to make use of what comes "out of the box" I am still going to have a system which simply does not respond to my users' interaction. It'll drive them nuts in a week.
Hence my earlier conclusion that we might have been better off just building a simple ASP.NET bespoke application for our needs - at least we'd be able to precompile it.
My 2 cents: there are some flaws with this product. Unless I am missing something...
Apologies for the "rant-ness". Just pure frustration really
- Edited by RobertEllis3 Sunday, June 23, 2013 4:04 PM minor amend
Sunday, June 23, 2013 3:54 PM -
You're right, that's not acceptable performance and it is a sign something is going wrong. It is not going to be performance related (it's possible but so stupidly unlikely that it's not worth looking into at this point)
The first load of a site will always be slow. 20 to 30 seconds is not unreasonable, whilst you might be able to shave a little time off on hardware it's never going to get fast. To deal with the first load times your only options are warmup scripts or to tolerate it. For you i'd go with the warmup scripts.
However if you're timing out (typically an error message after 90 seconds) or getting significantly longer load times than 20-30 then it's a sign something isn't right.
The easiest way to see the slow load times is on the Central Admin site, how long does that take to start up after an IIS reset?
When you do that first load do you get any errors in the event viewer or in the SharePoint ULS logs on either the web front end or the application server? Also Enable the CAPI2 log on the servers (google will tell you how to find it, my other half is moaning about working on the weekend...) to confirm you're not getting any certificate issues.
The frustration is reasonable but there is hope.
- Edited by Alex Brassington Sunday, June 23, 2013 5:16 PM Added text regarding performance.
- Marked as answer by GuYuming Tuesday, June 25, 2013 2:15 AM
Sunday, June 23, 2013 5:15 PM