4

If I mount a static directory in CherryPy, like so:

wwwroot_config = { '/': 
                      { 'tools.staticdir.on': True, 
                        'tools.staticdir.dir': '/path/to/dir' } }

cherrypy.tree.mount(root, '/', config = wwwroot_config)

File downloads from that directory go pretty slowly.

However, if I create my own WSGI app...

self.wsgi_server = wsgiserver.CherryPyWSGIServer((self.bindaddress, self.port), self.download_file, numthreads = 1)

With self.download_file containing, basically:

return serve_file(theFile, "application/x-download", "attachment", os.path.basename(theFile), debug = True)

I get speeds that are 4-5x faster.

However, this way is not as flexible because the headers that serve_file adds to the request (such as the range headers and content length) don't get returned in the response - I have to do it myself.

Is there anything I can do to make the first way faster?

Dave
  • 2,029
  • 2
  • 21
  • 30
  • 1
    Doesn't CherryPy come with just a development server like Flask does? For Flask, the recommendation is to have a *real* webserver like Nginx serve the static files and just interface with CherryPy using `uwsgi` or something similar. – Blender Aug 22 '12 at 20:50
  • 1
    I think Blenders advice is valid for any Python app in production environment. It is good design even for small websites, because it makes easier to serve static files from CDN later. – Paulo Scardine Aug 22 '12 at 22:12
  • @Blender it doesn't. At least it is [what the author thinks](http://stackoverflow.com/a/3441801/2072035). Also WSGI is not required, because CherryPy serves a HTTP server role pretty well. Though I have to admit that having Nginx in front always gives more flexibility in routing, serving static content, SSL, etc. – saaj Sep 11 '14 at 12:27

1 Answers1

2

I've had this same problem before, though only on Windows machines as I can recall. Are you running CherryPy on Windows? There seems to be a bug in CherryPy 3.5.0 which returns the wrong Content-Length header for static files, which causes the browser to sit idly waiting for more bytes which don't exist.

I haven't researched the issue in detail, but you might want to inspect the Content-Length header sent by the server, and see if it matches the actual size of the static files. A temporary workaround may be to manually set (or remove) the Content-Length header in a 'before_handler' hook.

Isa Hassen
  • 300
  • 1
  • 9