Uploading Files in .Net

[Rob Meade]

Dear all,

We have purchased a product called SA-FileUp which we have used in our
organisation for a number of years, I'm quite an an avid supporter of it,
recently I've been trying to ensure some of our older applications which
used native .Net uploading moved across to our .Net implementation of
SA-FileUp.

Because there is development time involved in this I have now been asked by
my manager to "test" both native and SA techniques to see how bad the issue
is if we didn't use the SA-FileUp component.

I appreciate that there is a percentage of "sales" talk behind the reasons
for using their product on their website, however, there is a lot of mention
of the native approach not being great because it uses the servers memory to
store the files in temporarily prior to the final save to disc, as opposed
to their products saving to a temporary file prior to the final save. I
personally believe the product to be a significant tool for us to use and as
such need to prove it!

My understanding of the two processes is limited, but I think it goes
something like this...

If we use SA-FileUp, the component streams the file and saves it as a
temporary file on the server before finishing the transaction and saving it
as a normal file.

Where-as the native .net approach loads the file into memory on the server
instead prior to saving as a file.

I've been quized on the native approach along the lines of "surely after the
file is saved the memory is released?", which would make sense, but I would
argue that if the application is putting a heavy demand on the server,
either in the number of uploads at anyone point, or the size of the files in
question, or both, this could have a significant effect on the memory
consumption on the server.

Would anyone here, perhaps someone else who has used it or just has some
theories be able to provide be with any technical information regarding the
two approaches?
Any links would also be advantageous, and in addition, any suggestions for
conducting a test of both methods - I suggested to my manager that this
might be hard to simulate as we'd want to test it in anger with many files,
many uploads, no other network traffic to the server etc etc.

Any information for any testing you may have performed yourselves would be
really appreciated.

As I said initially, I am a fan of the product and would hope that they
remain in use in this organisation, I am sadly now faced with having to
prove its worth due to financial reasons

Regards

Rob

 

[Jon Paal [MSMD]]

contact SA and have them justify their product. They should be able to give you ample reasons to keep using their services

 

[Rob Meade]

...

contact SA and have them justify their product. They should be able to
give you ample reasons to keep using their services

Hi Jon,

Oh I have, in fact its almost the same text I posted here, and they've come
back with some informative information, however, as its "their" product I
assumed that I should perhaps take the information with a pinch of salt, ie,
if they say ".Net is Satan spawn when it comes to uploads", maybe that isn't
necessarily true.

I was kinda hoping to get some replies here from people maybe using native
uploading in .Net and telling me that it was fine, and to explain their
usuage of it, or, people that had to invest in the same or similar products
because of limitation in .Net etc.

Their information suggested that in .Net 1.0 / 1.1 there were bigger
problems than in .Net 2.0 - they mentioned that native uploading in .Net 2.0
comes closer to one of their versions, albeit it doesn't have built in
progession support etc etc.

Regards

Rob

 

[Jon Paal [MSMD]]

Only SA can offer the information about technical issues since they know what's "under the hood' in their product. I doubt if
anyone has tried to create a performace benchline comparison.

I have been using .net upload with no problems but I can't give you any performance stats.

Since you have an SA license and .net is built in , sounds like you can use either one as desired. I would go with the idea that
using a non third-party approach is better, unless there is later to be found a specific problem that can only be resolved by that
third-party product.

 

[Rob Meade]

...

Only SA can offer the information about technical issues since they know
what's "under the hood' in their product. I doubt if anyone has tried to
create a performace benchline comparison.

Hi Jon, thank you for your reply.

Regarding the info, I guess just info from peoples own experiences would
have been sufficient, ie, did they find that using native uploading was ok
with a low traffic website, or that they have 10million uploads a day and
there's no problem.

I have been using .net upload with no problems but I can't give you any
performance stats.

How frequently is the upload functionality used though? ie, is it just a
small piece of a larger application, therefore not used particularly
frequently?

We have two systems that use uploading in anger here, a document management
service and also a similar application for clinical documents, both of these
are having large quantities of documents uploaded each day, more for the
clinical ones as they are patient letters being written by hospital staff,
each secretary might produce 40-50 documents a day, there's probably around
50 secretaries doing this, and here lies my concern using native uploading
if theres the chance of the servers memory getting laced..

Since you have an SA license and .net is built in , sounds like you can
use either one as desired. I would go with the idea that using a non
third-party approach is better, unless there is later to be found a
specific problem that can only be resolved by that third-party product.

I think there problems were primarily in .net 1.0 and 1.1 with regards to
the memory, but obviously there are some other "features" from the third
party component which could be useful (progression indicator and the like)..

Thanks for your reply and thoughts..

Regards

Rob