Uploading Large Files with ILINX Capture and IIS

From time to time I receive questions about large file uploads with ILINX Capture. ILINX Capture can upload files of any size. The limitation is within Internet Information Services(IIS) and or the amount of memory installed in the web server. This is not only true for ILINX Capture, but and ASP or ASP.Net application.

Depending on the architecture of the ASP or ASP.Net application files being uploaded to the web server are typically streamed into the web server’s memory during the upload process before being written to disk. Depending on the number of user concurrently uploading files and the size of the files being uploaded will determine how much physical memory should be installed in the server. By default IIS has a 200KB size limit for uploading a single file. This can be increased, but not any higher than necessary or you may risk overconsumption of the web server’s memory.

Configuring File Upload Size in IIS 6

1. Open Internet Information Services Manager by clicking the Windows Start Menu and Run. Type inetmgr and click OK.

2. Once IIS Manger opens navigate the tree and right click the server name and click properties.

3. From the server properties window check the Enable Direct Metabase Edit checkbox and click OK.

4. Browse to the C:\windows\system32\inetsrv directory and edit the Metabase.xml file with a text editor such as Notepad.

5. Search for the attribute AspMaxRequestEntityAllowed and edit the value to the size in bytes that you want to allow for a maximum upload size. Save and close the Metabase.xml file.

AspMaxRequestEntityAllowed=”204800″

6. Open the Registry editor and navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSOAP\30\SOAPISAP.

7. Modify the MaxPostSize key. Set the decimal value to the maximum upload size in bytes and click OK.

8. Reboot the web server to ensure the changes have taken effect.

Configuring File Upload Size in IIS 7

1. Open Internet Information Services Manager by clicking the Windows Start Menu and Run. Type inetmgr and click OK.

2. Navigate the tree to the Virtual Directory that you would like to enable large file uploads.

3. In the Features View pane double click ASP.

4. In the ASP setting pane edit the Maximum Requesting Entity and Response Buffering Limit columns. Set this to the maximum file upload size in bytes and click Apply.

 

5. Open the Windows Command Prompt and enter the following command. Change the maxAllowedContentLength to your maximum file upload size in bytes and hit enter to execute the command.

C:\Windows\System32\inetsrv\appcmd set config “Default Web Site” -section:requestFiltering -requestLimits.maxAllowedContentLength:104857600

9. Open the Registry editor and navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSOAP\30\SOAPISAP.

10. Modify the MaxPostSize key. Set the decimal value to the maximum upload size in bytes and click OK.

11. Reboot the web server to ensure the changes have taken effect.

Bryan Wilhelm
Senior Systems Engineer
ImageSource, Inc.

Installation Hand Off to the Client

As an integrator there are many things we can do as far as making the install a success, but only a very limited amount we can do to guarantee its continuing success. One of the most often seen issues is the handoff of an installation to the client, in particular the maintenance of the database.

I will talk in particular about installations using Microsoft SQL Server. When the database is created it is more often as not left to us as the integrators to create the database (sometimes even the installation of the MSQL Server instance as well). We will choose the path for the database file groups, and allow the defaults for everything else. For operational purposes of our software this will work, but there should be changes made and additional procedures put in place by the clients DBA to guarantee continued optimal performance of the newly implemented system.

When visiting these systems at a later date we find that log files have not been truncated, leaving to question whether any backups have been done at all. Log files are the record of changes which have taken place since the last log truncation; this allows that the database can be restored to a point in time since the last full backup to reverse an adverse action or system failure. These log files are often much larger than the data files. In a maintained system a DBA would have established a normal backup strategy which would have backed up the log file at different intervals through the day and truncated the log file after a full database backup.

The other is often finding the file growth setting for the database to be at a preset auto growth amount. These by default are either 10 mb or 10%. When the database was first established an estimate was made to come up with a number which would be used for the initial file size for the database and log files. For databases which have a need for growth these presets can be very inefficient, as among other things they are likely to do their growth during business hours. Take a 200gb database which started at 150 gb, if it grows by only 10 mb every time it needs to grow there will be a large number of inefficient file space allocations to have made up the 50gb of space. If told to grow by 10 percent, then we will have seen 15 gb file allocations taking place but during business hours which can have an impact upon users. One which the maintenance has been taken up by the DBA will have been monitored and auto growth will have been turned off. The DBA would have scheduled the data file growth based upon measurements taken of the databases past growth rate, and most likely the new space allocation will have taken place in off business hours.

There may be a myriad of reasons why this handoff has failed including the lack of a DBA in the organization. I do not purport to know what the answer is, only that when a follow on visit to a client is made, that inspection of the database for these settings would be worthwhile so that they can be brought the clients attention and hopefully then engagement by the IT department for the maintenance needing to take place.

 

Jeff Doyle
Senior System Architect
ImageSource, Inc.