MS Sharpoint Portal experiences

[wobbly1]

Hi there,

Are any of you using MS Sharepoint portal server[/b] within a VM and if so what have been your experiences/issues/performance views with this. Interested to hear any views, good or bad

Thanks in advance,

[jparnell]

Haven't used it myself, but look after an ESX environment where somone is trialling it on a couple of VMs. All I can tell you is they keep asking for more RAM :@

They've never complained about performance.

[RonH]

I have done this many times; It works just as it would work on phyisical servers.

Please remember as with all VM solutions, you still have to run your server sizing process to ensure that you have enough resources dedicated to your VM's, and be carefull not to overload your hosts. 99% of the time performance issues on VM's are caused by incorrect server sizing, overloaded ESX hosts, or network choking caused by too few phyisical network adapters installed in each ESX host.

Ron Henderson

President

GadTek Computer Services

"Enterprise VMware Solutions"

rhenderson@gadtek.com

[wunderon]

I've installed WSS 3.0 and MOSS 2007 using SQL 2005 VM backend. All worked fine except that the applications take several seconds to start up when first accessed. That is, first thing in the morning, when the first user hits the sharepont sites, it takes several seconds (5-15) for the web service to respond. After that inital lag, the response is normal.

I wonder if anyone else has seen this?

[asatoran]

I have similar lags with WSS2 as well. But this is not a production server and is slower hardware (1.4GHz P3 using VMWare Server on Win2k host.) Beyond that, I have not had any other problems with with WSS2 or 3 being virtualized.

[wobbly1]

thanks so far to those that have answered. Any further views/experienced welcome

[dawho9]

wunderon, have nearly the same setup as you and yeah, I have the same problem. I would say mine is a little worse, maybe closer to 25 to 35 second for the first response, but after that all is great.

Richard

[wally · Accepted solution]

Could this be your issue? http://blogs.msdn.com/joelo/archive/2006/08/13/697044.aspx

We also run 2 "large" and several "medium" farms without any major issues/incidents so far.

[Paul_B1]

thanks so far to those that have answered. Any

further views/experienced welcome

We've run our proof of concept in ESX 2.5.3 and it ran fine. I think the app guys are going to want it on physical, but not for any specific reason, i'm just not going to fight them (not worth the headache). They were a bit memory intensive, but nothing crazy.

[wobbly1]

dawho9/wunderon,

It would be good to know if the scripts mentioned in the link provided by wally help out with your initial slow response problem - will either of you be looking at this?

[dawho9]

Yeah, I'll load them up later today or tomorrow and report back as to what I find. But it does make sense. I'm pretty familiar with how ASP.NET does its compiling so I should have thought about this already.

Richard

Message was edited by:

dawho9

[wunderon]

The scripts implement HTTP GET on the various sites, which does in fact 'warm up' SharePoint and remove the first-thing-in-the-morning wait. I guess alternatives to this is to set the worker recycle to a longer interval than the daily default.

I don't see anything to suggest it has anything to do with virtualization at this point.

For implementations that have any amount of usage, this problem would only show up for a tiny percentage of users (i.e. the first on the site after a recycle or IISreset).

[conyards]

Interesting thread; Any chance that the number of users hitting the portal sites could be listed along with the virtual specifications.

A bit of an ask I know, but it'll help to put a term of reference around the discussion... The thread takes on a new meaning depending if we're talking about hundreds or thousands of end users.

Simon

[Paul_B1]

Interesting thread; Any chance that the number of

users hitting the portal sites could be listed along

with the virtual specifications.

A bit of an ask I know, but it'll help to put a term

of reference around the discussion... The thread

takes on a new meaning depending if we're talking

about hundreds or thousands of end users.

Simon

We had a small Proof of concept, I'm not sure of exact numbers, but it wasn't many. That being said, even the production environment only contains a few machines with 2-4GB of RAM and Quad Core procs.

[Anders_Gregerse]

Just launched a Sharepoint site for our 70.000 customers (everything is vm). Performance is reasonable. It's based on 64-bit Windows and 64-bit Sharepoint. It's a 3 node farm, each vm with one vcpu (sharepoint is rather pricy per cpu). We choose to virtualise it because that's our initial strategy for new implementations. If we need to do a V2P, it's fairly easy to do.

Learned lessons on vm's:

• 64-bit, 32-bit isn't enough memorywise for Sharepoint (/3Gb not supported)

• Sharepoint loves memory at least 3 GB (cache ease the burden on the cpu)

• Slow startups can be caused by not being able to access crl.microsoft.com (verification of signed .Net 2.0 components) (covers all .Net installations virtual or physical)

• Sharepoint is a heavy SQL user, we see about 60% cpu usage on the SQL (1vcpu, 3GB)

• Performance vs. price pr. cpu might make virtual sharepoint unattractive (same license price for 1vcpu as 1 pcpu quadcore)

[mike_caddy]

Lag is very common in both pysical and virtual sharepoint environments (in fact in all apps deployed on the ASP.NET platform)

One of the other respondants makes an iteresting point "Slow startups can be caused by not being able to access crl.microsoft.com (verification of signed .Net 2.0 components)" I had not heard this one before. Even if this is part of the problem you will always have a bit of lag as the ASP.NET compiler recompiles the aplication the first time it's run which for a sharepoint app can take quite some time.

[azn2kew]

I've architected and consulted severals MOSS 2007 projects without any issues using ESX 3.x and if you spec out your resources correctly with other crucial components than your performance would be decent. You should regularly tune your SQL 2005 databases and allocate enough memory for all the MOSS servers and enough network bandwidth also make sure your storage architecture is healthy as well such as RAID 5/10 depends how you want it but 50% wasted overhead if you're using RAID 10. If you experience latency, use Certeon as it specialize in SharePoint optimization for details especially large environment + latency issues.

If you found this information useful, please consider awarding points for "Correct" or "Helpful". Thanks!!!

Regards,

Stefan Nguyen

iGeek Systems Inc.

VMware, Citrix, Microsoft Consultant

[azn2kew]

Ron @ Gadtek,

FYI: I suggest you secure your website from browse permission, people can see all your goodies.

If you found this information useful, please consider awarding points for "Correct" or "Helpful". Thanks!!!

Regards,

Stefan Nguyen

iGeek Systems Inc.

VMware, Citrix, Microsoft Consultant