MOSS Forum

Ask Question   UnAnswered
Home » Forum » MOSS       RSS Feeds

MOSS 2007 on Intranet

  Asked By: Bobbi    Date: Jan 16    Category: MOSS    Views: 1606

We have successfully set up MOSS 2007 on one of our development servers
and we currently testing bandwidth and access times of pages and
documents in document libraries. Basically, a speed test from our remote
branches. We have enabled IIS Compression and Streaming for PDF. Most of
the documents that will go on some of our Policies Document Library will
be in PDF and the res which are edited daily or often will be in Word.
The speed on our MAN is acceptable. It is the remote branches on our WAN
that, even though Compressing and Streaming is enabled and we can see a
little difference in the speed and access time, still is lacking behind
compared to our MAN users. We're still in testing stage though.

My question is there any other enhancements, so to speak, on MOSS 2007
that can be enabled to speed up accessing of pages and documents?

Does anyone know of any testing methods out there that can give us a
true picture of our test?

Yep just 2 questions.



6 Answers Found

Answer #1    Answered By: Cathy Cameron     Answered On: Jan 16

Yes, we have also struggled with WAN performance issues. We ended up
spending three weeks building our environment in Microsoft's labs to
test the impact of various settings. It's a huge topic, so here are
some brief highlights:

* There are some blog posts around about using dynamic IIS
compression with SharePoint. (By default, static is enabled but
dynamic is not.) You need to run a script on the web servers to
configure it to compress some additional extensions like .aspx and
to set the compression level to 9. This produces worthwhile
improvements in page times and seem to have little impact on the web

* Blobcache is a feature of SharePoint that allows the servers to
cache published items in document libraries on their own disks (to
avoid requests back to SQL), and also allows you to configure the
headers on those items so that user browsers cache them and do not
re-request them. Without blobcache, every item within SharePoint is
marked to expire immediately, so the browser checks for an updated
version every time the page is re-displayed. Only items coming from
physical directories on the web front ends (like the _layouts
directory) have a non-zero expiry time without blobcache.

* Blobcache and IIS compression are completely unrelated features.
We found that independently they provided similar performance
benefits. However, we found that if you enable both (even just the
default static IIS compression), performance actually suffers
(despite a recommendation in a Technet paper that you should enable
both). We verified this against both 32-bit and 64-bit farms and in
our production environment.

* We ended up enabling IIS compression and disabling blobcache. To
allow full caching for very commonly used content, like images on
some home pages, I have set up a script to copy content from a
particular library onto the web front end server hard disks where
they can be accessed from the _wpresources virtual directory.

* The _themes virtual directory suffers from the same "expire
immediately" issue, so if you apply a theme, even a standard
Microsoft one, the browser checks for new versions of all the
elements like background images on every page load. Again, if you're
designing a theme, put everything possible under _layouts.

* IIS 6 by default re-authenticates every request. This means that
there is a request, followed by a 401 access denied, followed by
another request including credentials for every element on every
page. There is a registry setting to revert to IIS 5 behaviour and
keep the authenticated session open (for Kerberos, you also need WS
2003 SP2).

* We found a security hotfix last year had caused a bug where the
browser did not read policy settings correctly and reverted to http
1.0, effectively disabling compression. There is a patch available
to fix this, as well as a registry workaround.

* Fiddler is an invaluable tool to see what is actually going on the
wire between the client and server.

* Tweaking settings in output cache profiles does seem to have a big
effect on performance, particularly for pages with web parts doing
content queries.

* You need some objective way of measuring the effect of settings
changes. I ended up creating a spreadsheet with VBA code automating
the browser to make repeated requests against a range of pages, with
cache clearing every third run. Of course, you get performance
variations with time of day and background traffic, but averaging
over a number of cycles gives you a good indication of whether a
change has made things faster or slower in the real world. Of
course, you need to be running the test from a distant WAN location -
you can send the spreadsheet to someone and they can run it for you.

* Our testing with WAN compression appliances has so far given
disappointing results.

Answer #2    Answered By: Kerri Steele     Answered On: Jan 16

and as knoxcameron as said earlier, blob caching doesn't always work with
anonymous users. no idea why, it just quits working until you disable, iisreset,
and re-enable. Not optimal. no longer recommended by me.

how did you IIS Compress items in the DB? we haven't made that work yet...
(neither have the Microsoft guys I'm working with) We are only compressing items
on the file system.

Answer #3    Answered By: Alisha Itagi     Answered On: Jan 16

I read somewhere that blob caching does not work on Site Collection
Images list and some other list for anonymous users.

Answer #4    Answered By: Octavio Dotson     Answered On: Jan 16

As I recall from the old IIS days, with dynamic compression all is
compressed on the fly in a folder somewhere.
So I don't think you actually compress things in SQL...

Answer #5    Answered By: Judy Pittman     Answered On: Jan 16

That's right.

You need to run a script to add .aspx to the list of extensions for
dynamic compression, iisreset for luck, and then enable dynamic
compression in IIS Manager. I also added the axd extension, which
seems to be used for some Javascript files sent to the client.

Here's the script I used:


cd \inetpub\AdminScripts

W3Svc/Filters/Compression/GZIP/HcFileExtensions "css" "htc" "htm" "ht
ml" "js" "txt"

W3Svc/Filters/Compression/DEFLATE/HcFileExtensions "css" "htc" "htm"
"html" "js" "txt"

W3Svc/Filters/Compression/DEFLATE/HcScriptFileExtensions "asp" "asmx"
"aspx" "axd"

W3Svc/Filters/Compression/GZIP/HcScriptFileExtensions "asp" "asmx" "a
spx" "axd"

W3Svc/Filters/Compression/GZIP/HcDynamicCompressionLevel "9"

W3Svc/Filters/Compression/DEFLATE/HcDynamicCompressionLevel "9"

IIS compresses the html after it is generated by the .aspx code
before sending it to the client, so it is invisible to SharePoint.
With dynamic compression, it just compresses on the fly, without
saving a compressed version to disk like it does with static.

Answer #6    Answered By: Tricia Mullins     Answered On: Jan 16

I don't know if this is still an issue, but IIS on Win2000 had the
unpleasant habit of treating compressed aspx files as static, i.e. caching
them unless there was either (a) a form post or (b) a distinguishing
querystring parameter.

Hopefully they've made my warning unnecessary by now, but there it is.

Didn't find what you were looking for? Find more on MOSS 2007 on Intranet Or get search suggestion and latest updates.