I am displaying architectural drawings in the browser except for larger files which are downloaded to the user’s hard drive with the following code…
Dim f As FolderItem = Volume(0)
f = New FolderItem(SelectedDrawingDocPath, folderitem.PathTypeNative)
myPDFFile = WebFile.Open(f)
myPDFFile.MIMEType = "application/pdf"
myPDFFile.ForceDownload = True
ShowURL(myPDFFile.URL)
There are some really big files and somewhere over 500mb WebFile.Open chokes with an out of memory error. When this happens, Xojo stops responding and needs to be closed and restarted on the server. Sometimes Xojo throws the error, sometimes the borwser throws an error and Xojo stops responding, sometimes xojo actually delivers the document but stops responding. My development machine has 32gb of RAM and I am getting out of memory errors somewhere around 750mb.
I am working around the problem by uploading the really large drawings to AWS S3 and sending an email to the end user with a link to download the file. That’s fine, but would prefer to use Xojo. Is there any way to avoid running out of memory with the above code. Is there another way to download documents to the users hard disk that would not encounter this problem?
Is the app compiled as 32-bit or 64-bit?
Good question. I have never compile if as 64-bit. I bet that will fix our problem. I am reading the guidelines now. Will get back to this thread after I deploy it 64-bit.
I am developing on a mac. Is debug mode 32-bit or 64-bit. Don’t see any options.
Ok. I compiled for 64-bit and things got better. I move my testing to the windows server to test the 64-bit built app. Compared to my development platform the production server is signifcantly slower.
The good news is that no matter what happens the Xojo web app on the server no longer stops functioning, but over about 60mb I think it’s the browser that gives up with…
[quote]502 - Web server received an invalid response while acting as a gateway or proxy server.
There is a problem with the page you are looking for, and it cannot be displayed. When the Web server (while acting as a gateway or proxy) contacted the upstream content server, it received an invalid response from the content server.[/quote]
At 70mb it takes about 2:30 mins, but at about 2:00 mins the browser throws the error. I don’t thiink xojo is running out of memory anymore. Outside of my client getting a new server and/or better internect connection, I think I am going to have to rely on AWS for anything over 30mb.
64-bit is something I should have been doing anyway. So Greg, thanks for pointing me in that direction.
Anyone have any other suggestions.
John
Keep in mind that uploads can be kept in memory more than once:
- The raw HTTP request
- If you ask for the raw data, it gets loaded into a buffer in the WebUploadedFile before it’s handed to you.
- if you then use a BinaryStream or a TextOutputStream, the data is transferred again
For the best performance, don’t request the raw data. Just copy the folderitem to another location on disk and then load it yourself if that’s what you want to do.
Also, I suggest that you try compiling your app using Moderate or Aggressive optimization. You may find that the framework can handle things a little faster that way.
Sending data over a network is slower.
Does every file time out at 2:00? Possible the Windows web server has a time out.
I have been using a similar scheme to serve files to my customers. However, pass 50 Mb or so, no matter what I tried, the Xojo WebFile chocked.
I ended up using a small php script to do the download.
[quote=398773:@Greg O’Lone]Keep in mind that uploads can be kept in memory more than once:
- The raw HTTP request
- If you ask for the raw data, it gets loaded into a buffer in the WebUploadedFile before it’s handed to you.
- if you then use a BinaryStream or a TextOutputStream, the data is transferred again
For the best performance, don’t request the raw data. Just copy the folderitem to another location on disk and then load it yourself if that’s what you want to do.
Also, I suggest that you try compiling your app using Moderate or Aggressive optimization. You may find that the framework can handle things a little faster that way.[/quote]
Sorry about that. It was late and I thought you were talking about uploads.
Some of the same rules apply though, just in different ways.
You can help the framework with large downloads by serving them in HandleUrl or HandleSpecialUrl though. If you make a WebFile that points to a file on disk, we incrementally load and transfer that data to the socket instead of loading it all at once. You may find that it will handle that better.
To be honest, transmitting any large files through a web app will be an issue though. What I usually suggest as these files are typically static is to put them on a CDN somewhere and use protected one-off URLs in the app itself to move the burden and bandwidth elsewhere.