From the inside: Slow Ape start when external server connections are prohibited

When the server is configured so that all external requests are prohibited the following problem may occur.

Upon the first request IIS loads modules and if the module has a digital signature (according to certification requirements for Windows Server 2008 all dll and exe files must have one!), Windows addresses the trusted center (in our case it's Verisign). This happens only once, after that certificate is marked as valid.

If Windows fails to receive response from Verisign, it retries a couple of times (up to 10) and after that continues to load the application.

Side-effects:
Upon the first request (and after each App pool(s) recycling!) the delay up to 10 seconds may occur.

Workarounds:

• Change the registry key HKCU\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software Publishing\State from 0x00023c00 to 0x00023e00 for the user(s) whose account is used in the app pool(s) to say Windows not to check certificates
• create the file "c:\windows\system32\inetsrv\w3wp.exe.config" with the following content:

  <?xml version="1.0" encoding="utf-8"?>
  <configuration>
    <runtime>
      <generatePublisherEvidence enabled="false"/>
    </runtime>
  </configuration>

• allow access to Verisign for a little while.

Microsoft addresses this issue in its article http://support.microsoft.com/kb/936707.

You may never notice such behavior, but if you do, you are already aware of its cause and solutions:)

Disk-based caching for IIS7

We have already shed some light on the question of web caching and its benefits in our «Web Caching: what is it?» article. We've also explained how web caching is realized in Helicon Ape in «How mod_cache works?» article. Back then mod_cache could only store requests in the memory, but now, after Helicon Ape 1.2.0.21 release, there's mod_disk_cache module that enables cashing to the hard drive.

Enabling mod_disk_cache

To make mod_disk_cache working one should perform the following simple steps:

• Create disk cache folder. Say, c:\inetpub\cache.
• Grant Read & Write permisions for that folder to users running Application Pools on your IIS. By default it's IIS_IUSRS group.
• Point to that folder in httpd.conf using CacheRoot directive:
  

  CacheRoot c:\inetpub\cache

• Enable caching for requests to /app/ for example. To do that, specify in httpd.conf:
  

  CacheEnable disk /app/

  or in .htaccess inside /app/ folder:
  

  CacheEnable disk

That's the minimum configuration needed to have something cached. Now all requests containing expiration time (e.g. Cache-Control header) will be cashed on disk.

mod_disk_cache saves cached requests into hierarchical folder structure inside CacheRoot. Length of names and levels of these folders are defined by CacheDirLength and CacheDirLevels directives. Caching gives out even better effect when used together with mod_gzip module which compresses response before caching and sending it to the client.

Pros and cons of disk caching

The tests we've conducted showed that the speed of mem-based and disk-based cache is roughly equal.

The main advantage of disk cache is that cached data is stored on disk and does not depend on applications recycling, IIS and hardware reset, in contrast to memory cache that is stored until the first application recycling or IIS reset.

The shortage of disk cache lies in absense of intrenal recycling mechanism for the expired records that are not used any more. But that's not that critical:) The workaround may be: configure sheduled recycling of all cache once a day, i.e. remove all subfolders (or aged records only) and their content from CacheRoot.