[xwiki-users] file operations in file system storage is too slow
HI! Xwiki 3.1. Attachment versioning turned off. Storage is set to file system, Works fine with relatively small files. I uploaded 700M file - no problem, a bit to wait, but works fine. I tried then to delete this file. The result was also successful, but took nearly 1.5 minutes to finish. Is there any way to run file operations faster? Thanks a lot. Dmitry Bakbardin.
On 09/05/2011 12:10 AM, Haru Mamburu wrote:
HI!
Xwiki 3.1. Attachment versioning turned off. Storage is set to file system, Works fine with relatively small files. I uploaded 700M file - no problem, a bit to wait, but works fine. I tried then to delete this file. The result was also successful, but took nearly 1.5 minutes to finish. Is there any way to run file operations faster?
Deleting an attachment will save the file in the attachment trash, which means copying the file in another place. You could try to disable the attachment trash to get a faster result, if you don't care about rolling back deleted attachments. The time spent seems reasonable given that it involves disk I/O and a fairly large file. What could be done to improve responsiveness is to do all the work in the background, i.e. just start the file copy process and instantly resume the work. This means more work to ensure that future requests affecting that file won't interfere in a bad way. -- Sergiu Dumitriu http://purl.org/net/sergiu/
Thanks a lot for help, No way to disable recycle bin. If some vandals would ruin content and delete attachments - it would be lost without possibility to get it back. Move operations usually take milliseconds despite of file size. By accident I found a reason of such slow down: XE makes TWO copies of the file in recycle bin (in the file storage). Should I report it as a bug of file storage? Kind regards, Dmitry Bakbardin 05 сентября 2011, 22:35 от Sergiu Dumitriu <[email protected]>: On 09/05/2011 12:10 AM, Haru Mamburu wrote:
HI!
Xwiki 3.1. Attachment versioning turned off. Storage is set to file system, Works fine with relatively small files. I uploaded 700M file - no problem, a bit to wait, but works fine. I tried then to delete this file. The result was also successful, but took nearly 1.5 minutes to finish. Is there any way to run file operations faster?
Deleting an attachment will save the file in the attachment trash, which means copying the file in another place. You could try to disable the attachment trash to get a faster result, if you don't care about rolling back deleted attachments. The time spent seems reasonable given that it involves disk I/O and a fairly large file. What could be done to improve responsiveness is to do all the work in the background, i.e. just start the file copy process and instantly resume the work. This means more work to ensure that future requests affecting that file won't interfere in a bad way. -- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users
On 09/05/2011 03:28 PM, Haru Mamburu wrote:
Thanks a lot for help,
No way to disable recycle bin. If some vandals would ruin content and delete attachments - it would be lost without possibility to get it back. Move operations usually take milliseconds despite of file size. By accident I found a reason of such slow down: XE makes TWO copies of the file in recycle bin (in the file storage).
Should I report it as a bug of file storage?
Yes.
Kind regards,
Dmitry Bakbardin
05 сентября 2011, 22:35 от Sergiu Dumitriu<[email protected]>:
On 09/05/2011 12:10 AM, Haru Mamburu wrote:
HI!
Xwiki 3.1. Attachment versioning turned off. Storage is set to file system, Works fine with relatively small files. I uploaded 700M file - no problem, a bit to wait, but works fine. I tried then to delete this file. The result was also successful, but took nearly 1.5 minutes to finish. Is there any way to run file operations faster?
Deleting an attachment will save the file in the attachment trash, which means copying the file in another place. You could try to disable the attachment trash to get a faster result, if you don't care about rolling back deleted attachments.
The time spent seems reasonable given that it involves disk I/O and a fairly large file. What could be done to improve responsiveness is to do all the work in the background, i.e. just start the file copy process and instantly resume the work. This means more work to ensure that future requests affecting that file won't interfere in a bad way.
-- Sergiu Dumitriu http://purl.org/net/sergiu/
participants (2)
-
Haru Mamburu -
Sergiu Dumitriu