Hi again, Miroslav.
Thank you for the explanation. All the behaviour I observed makes sense now.
I tested the RadUpload server-sidee handler performance with 40 parallel file uploads (size ranging between 30 and 600 MB, from 4 different client hosts), with three chunk size scenarios:
~97 KB (default): very stable regarding memory consumption and a bit processor hungry (avg 13%).
512 KB: same stability regarding memory consumption (though eating a bit more in avg) but hungrier regarding processor (avg. 19%)
4096 KB: the IIS application pool went crazy, with high memory consumption and huge processor time (28%); I don't recommend anyone to set such an upload chunk size. Furthermore, as the Silverlight client is encoding 4 MB before uploading data, the client host performance is also affected...
I suppose the base64 encoding/decoding has much to do with increasing processor time and my suspected lack of scalability. Can we switch off base64? Is it really needed in all scenarios? For example, if I only upload binary data (images, videos, etc.) is it really critical to base64 encode?
Thank you for your patience.