On 5/26/07, Edi Weitz edi@agharta.de wrote:
I suppose gzip itself will also take some time, won't it? Why do you think flexi-streams is the culprit in this case?
Because it was convenient to blame flexi-steams ;-) (re: the upload performance thread)
I think static files aren't something we should be particularly concerned with. If you have lots of static files and Hunchentoot can't serve them fast enough for your purposes, let Apache serve them, or put them behind mod_lisp and use mod_gzip. Besides, clients will cache Javascript files, so they'll have to read your big Ajax library only once.
I wasn't too concerned about scalability. Like you said, if it is a public facing high-traffic website, putting hunchentoot behind mod-lisp would be a safer bet.
However, even in intranet application, downloading 790k verse 220k is a huge difference in user experience.
And not to mention that you don't have to deal with apache setup and configuration.
Imagine hacking httpd.conf and installing mods verse writing your own mod-alias mod-rewrite in lisp, changing the rules in runtime without restarting the web server. Which one is more fun? ;)
(accept-gzip-p (search "gzip" (header-in :accept-encoding)))I think that's a bit too simplistic. The header could be one of
Accept-Encoding: x-frogzipper Accept-Encoding: gzip; q=0 Accept-Encoding: *
Yeah, you're right. I was just trying to do some experiments and fish for ideas from the mailing list.
Something like this maybe (untested):
See? I threw in a brick and got some quality code back. Not bad at all :-)
I'm not against it per se, but I wouldn't want to add it just for static files.
Agreed. I don't think we should put half baked solution into hunchentoot. For now I'll adopt it into lsp:create-lsp-folder-dispatcher-and-handler.
Thanks, -- Mac