Memory usage in RadUpload

Thread is closed for posting
6 posts, 0 answers
  1. Nikolaj
    Nikolaj avatar
    5 posts
    Member since:
    Apr 2008

    Posted 04 Jul 2008 Link to this post


    During stress testing of RadUpload I have experienced that the memory consumption on the webserver increases dramatically when uploading.

    This is no surprise as we are testing with a lot of data, but I am getting quite concerned about the general memory usage of the component.

    Lets say for instance that we have:
    10 user each uploading 25 files of 35 mb's at the same time amounting to roughly 9gb of data.

    So can you give a rough overview of the maximum memory usage in this scenario? (data only ofcourse, not objects etc.) - and what and when the data is in the memory. Are all files for each user in memory simultaneously? Or only 1 at a time?

    Hope you can enlighten me

    BR.
    Nikolaj
  2. Veselin Vasilev
    Admin
    Veselin Vasilev avatar
    2992 posts

    Posted 07 Jul 2008 Link to this post

    Hi Nikolaj,

    Have you enabled RadMemoryOptimization?

    I suggest that you check this help article: Uploading Files > RadMemoryOptimization

    I hope this helps.

    Kind regards,
    Veskoni
    the Telerik team

    Instantly find answers to your questions at the new Telerik Support Center
  3. Nikolaj
    Nikolaj avatar
    5 posts
    Member since:
    Apr 2008

    Posted 08 Jul 2008 Link to this post


    Thanks for the quick reply.

    Yes as far as I can see based on the link you wrote Memory optimization is enabled, ie. all the criterias mentioned in that article is covered.

    Is there some other way of determining if the memory optimization is actually running? We don't get any exceptions regarding it. Maybe there is some logging we can do?

    When we stress test the component with multiple users and multiple files we have experienced increases in memory user of more than 500mb on the webserver.

    br

    Nikolaj
  4. Paul
    Admin
    Paul avatar
    4281 posts

    Posted 08 Jul 2008 Link to this post

    Hi Nikolaj,

    Are you using IIS7? If so, please refer to our Known Limitations help article for details on the matter.

    Sincerely yours,
    Paul
    the Telerik team

    Instantly find answers to your questions at the new Telerik Support Center
  5. Nikolaj
    Nikolaj avatar
    5 posts
    Member since:
    Apr 2008

    Posted 08 Jul 2008 Link to this post


    no we are using IIS6

    br

    Nikolaj
  6. Erjan Gavalji
    Admin
    Erjan Gavalji avatar
    1455 posts

    Posted 08 Jul 2008 Link to this post

    Hi Nikolaj,

    I'm afraid we don't have much clues that could directly give the answer. I have only one guess, although I believe this is not the case:

    When stress testing, are the browser and the web server located on different computers? This is the case, when you would actually monitor the server memory usage.

    Let me add some more detail:

    During the form submission, an instance of the RadUploadHttpModule starts parsing the upload request.
    The request is being parsed chunk by chunk (binary data), where the chunk size is between 32kB and 1 MB.
    The chunk is actually the binary data, which is being currently processed. It is the only part of a file, which is kept in the memory.

    A small note - I mention chunks, which are part of a file; the data, which is part of the page text fields is kept in the memory, as it is needed for the page to run expectedly, but its size is relatively small.

    There is one chunk, which is typically bigger than the others - the initial chunk of a file upload request, but again it is not that big and it is not kept in the memory after it is parsed.

    Having said that, if you have ten users, simultaneously uploading files (i.e. you have ten simultaneous requests), the memory consumption should be less than 100 MB.

    Let me know if that helps.

    Kind regards,
    Erjan Gavalji
    the Telerik team

    Instantly find answers to your questions at the new Telerik Support Center
Back to Top