Happstack: serveDirectory vs serveFile
Dear all, I've ran a simple benchmark where two serve functions were side-by-side in an msum and looked like dirs "hehe" $ serveDirectory DisableBrowsing [] "/hehe" dirs "favicon.ico" $ serveFile (asContentType "image/x-icon") "favicon.ico" "hehe" directory also contained file "favicon.ico". This is happstack server version 7.3.9. I've been hammering it with ab and confirmed this puzzling result: it seems that serveFile route is approximately two orders of magnitude slower than serveDirectory route... Will be grateful for any clues as to what I'm doing wrong! Thanks, S. -- Семен Тригубенко http://trygub.com
Hello! Underneath the hood, they are both using the same function to actually serve the file. There are a few reasons why serveDirectory might appear to be faster. The first thing to double check is that both serveDirectory and serveFile are returning 200 OK, and not 404. You want to confirm that the file really is being transferred in both cases. Given that favicon.ico is likely a small file, the time spent processing requests could be dominated by some other seemingly insignificant factor. Since serveDirectory is listed first, it is going to have a slight advantage, because the routes are tried in order. If you switch the order and list serveFile first do you see any change in performance? Additionally, in this code you could get away with using 'dir' instead of 'dirs' since you do not have any '/' in the path. Because 'dirs' has to look for the '/', it is going to take longer to search 'favicon.ico' than 'hehe' -- which would also give a slightly advantage to the serveDirectory branch. You are correct in expecting that serveFile should be faster than serveDirectory since it is supposed to do less. But microbenchmarks like this can easily be dominated by unrelated factors. - jeremy On Fri, Jan 23, 2015 at 10:09 AM, Semen Trygubenko / Семен Тригубенко < semen@trygub.com> wrote:
Dear all,
I've ran a simple benchmark where two serve functions were side-by-side in an msum and looked like
dirs "hehe" $ serveDirectory DisableBrowsing [] "/hehe" dirs "favicon.ico" $ serveFile (asContentType "image/x-icon") "favicon.ico"
"hehe" directory also contained file "favicon.ico".
This is happstack server version 7.3.9.
I've been hammering it with ab and confirmed this puzzling result: it seems that serveFile route is approximately two orders of magnitude slower than serveDirectory route...
Will be grateful for any clues as to what I'm doing wrong!
Thanks, S.
-- Семен Тригубенко http://trygub.com
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Hi Jeremy, Thanks for your reply. I have not found the cause of this issue, but I know now it is not related to happstack after all. On Fri, Jan 23, 2015 at 04:46:09PM -0600, Jeremy Shaw wrote:
The first thing to double check is that both serveDirectory and serveFile are returning 200 OK, and not 404. You want to confirm that the file really is being transferred in both cases.
Confirmed.
Since serveDirectory is listed first, it is going to have a slight advantage, because the routes are tried in order. If you switch the order and list serveFile first do you see any change in performance?
I tried that before with no luck.
Additionally, in this code you could get away with using 'dir' instead of 'dirs' since you do not have any '/' in the path. Because 'dirs' has to look for the '/', it is going to take longer to search 'favicon.ico' than 'hehe' -- which would also give a slightly advantage to the serveDirectory branch.
Previously it contained a '/', but it no longer does, so I've changed it now. Thanks for the tip!
But microbenchmarks like this can easily be dominated by unrelated factors.
Yes, sadly, I've done this benchmark from behind apache. I should have benchmarked happstack in isolation before posting, but previously the results correlated very well... After some experimentation I have found that this pathological behaviour is observed when file is small and going via apache on that route. When file size goes over 1-2kb it starts to fly but for some reason serving tiny files under 1kb is dog slow. When talking to happstack direct results are sane. Thanks for your help, and sorry for starting to dig in the wrong direction... S. -- Семен Тригубенко http://trygub.com
participants (2)
-
Jeremy Shaw -
Semen Trygubenko / Семен Тригубен ко