None of the mentioned calls does allow us to directly get back the images, so we need to do a new API call for each image. Our documents on average are 40 pages, so when every “get image” call takes 1.5 second it results in 60 seconds of overhead.
What we would like to see options like:
return the raw images (base64 encoded?) in the first splitDocument / saveAs call
return a .zip with all images in it
Heard from Billy Lundy you were already busy with implementing, but please keep me up-to-date because this would drastically reduce your server load (amount of Other API operations calls).
You already have reported this issue and our developers were working on it. The good news is that the issue has been resolved and it is live already. This will be announced in the coming public release next week and respective topics will be added to documentation for your reference.
Hi Muhammad, I’ve tried to test the “zipOutput” feature, but it does not seem to work yet. The SDK still only puts images in the online folder, not the expected .zip file.
Otherwise I’ve got to determine those things based on the amount of images in the .zip which seems weird to me. Please always return the Pages, because we should be able to do things based on that. The .zip content should represent what is in the Pages array.
Can you please elaborate what exactly do you want in Pages? Do you want to return it an integer value to indicate total number of pages in the ZIP file or do you want it to return the names of output pages?
Regarding saveAs, it is working fine at my end. Can you please share your code to reproduce the issue?
Concerning the Pages. I’d expect that if zipOutput is returned, the SplitPages array shoud also be set in the same way as it usually was without the zipOutput parameter.
As far as performance of split resource is concerned, following were my observations.
Tested a 30 MB file with images and less number of pages. It took less than 5 seconds.
Tested a 10 MB file with 75 pages. It took around 2 minutes.
Based on the above tests, if the document has more text and number of pages, then it takes more time to split. Can you please also share your document? This will help us testing it at our end once the issue is resolved.
1) We can confirm the second scenario, splitting a file with many pages takes > 2 minutes.
2) We would love to help you testing the 30MB files, but currently we’ve got to pay for all calls we make. A demo account only allows 100 calls and 1MB for a file.
Can you please make a test account for us with a 30MB (or higher) upload limit and many document calls? Last week we finally did discover the poor performance when we were already live.
Pages property returns null instead of pages array and performance issues have been logged into our issue tracking system as SAASWORDS-206 and SAASWORDS-207 respectively. We will keep you updated on these issues in this thread.
As far as testing larger files is concerned, you can also test the files with Aspose.Words for .NET because this is not Aspose for Cloud specific issue; it will be resolved in Aspose.Words for .NET first.
You are asking me to test with a totally different product? We do not have a .NET development environment, so that will not be possible. Please keep us up to date about releases for the Cloud products. Thanks for now!
In fact 30 MB limit is not available for all customers. It has been allocated to a limited number of customers with custom plans to maintain the performance.
We will check the possibility of a test account for you after the issue is resolved. Sorry for the inconvenience.
Performance issue has a high priority but it can take some time as this issue will be fixed in the codebase first. We cannot share a concrete ETA but it is expected to be fixed in near future.