Reference Book Uploads Posting Guidelines

[Jellby]

Originally Posted by Psymon

Yeah, I did catch that Jellby mentioned that (and did that), but isn't that expecting a bit much of others, to not only unzip (or un-rar) the files, and then have the knowledge -- never mind inclination -- to put them together?

Others don't have to do anything special: just download all pieces, and unpack the first one with to right tool (winrar, winzip, 7z...), it should automatically pick up the following parts and give you a single unpacked epub file as a result. You could also use other dedicated file splitter tool, but others are less likely to have it already installed.

[HarryT]

Originally Posted by Psymon

Why not just raise the limit for ebook uploads?

Because downloading large files puts a real strain on the server, and the site owner has indicated that he doesn't wish to increase it.

[Psymon]

Took some fiddling -- that is, self-tutoring (as I'd never done this before), but I managed to split my epub into separate zip files. Before I do load them up here, though, I am a bit curious about what Harry was saying...

Originally Posted by HarryT

Because downloading large files puts a real strain on the server, and the site owner has indicated that he doesn't wish to increase it.

I can certainly understand concerns about bandwidth, but as Jellby mentioned, when he ran into he same problem he just loaded it up in separate zip files -- so in the end, there hasn't been any "relief" on the server, it still adds up to the same amount of downloads, with the only difference being that it's an extra pain for the end user having to unzip/merge the zips files. So in the end, it would seem that this limit on file size has accomplished nothing at all but to create an inadvertent pain for people. :/

Not that I'm going to convince the site owner to change his mind and increase the limit (although it doesn't hurt to suggest it, at least!) but at the same time I suppose I have to wonder what's wrong with just providing a link where people can download the files -- assuming that the person posting intends to leave the files there "forever". That would give the MR server a bandwidth load of... zero! Well, apart from the 1kb text file that makes up the person's post, of course.

Also, not to complicate this even more, but with this current series of books I've done (one volume in particular) I can see that in time other things will be added to it (it's an anthology), or changes made, and if I have it on my own site that's easy enough to do -- but if I load it up here, then I have to remember to re-load up the newer version if/when one arises...

AND, I also noticed with past uploads that if/when I do upload a newer version, it re-sets the "counter" showing how many people have downloaded the file (even if I gave it the same name), i.e. uploading a new version re-sets that counter back to zero.

Any thoughts? Again, I certainly don't expect anyone to just up and change the way everything has been done here (for years and years, no doubt), but I guess I can't help but wonder about these various things.

[DaleDe]

Longer files have more download failures which require more resources I believe.

[Hampshire Nanny]

Originally Posted by Psymon

AND, I also noticed with past uploads that if/when I do upload a newer version, it re-sets the "counter" showing how many people have downloaded the file (even if I gave it the same name), i.e. uploading a new version re-sets that counter back to zero.

It seems that a lot of the uploaders simply include a line of text saying how many times the prior version was downloaded.

[dgatwood]

The core problem with downloads is that they behave differently than other resources.

1. They take a long time to download, during which time one client slot on the server is occupied. When all the slots fill up, you end up waiting a painful amount of time for any new requests, because they end up queued up behind the downloads. Fixing that on older servers requires serious server reconfiguration.
   
   If mobileread is actually using nginx as a web server, it shouldn't be impacted too badly by this issue. If that's just a proxy around Apache, yeah, that's gonna suck unless you spawn a second Apache server instance to handle just the downloads. But really, if you're serving lots of downloads, it is probably best to just shoot Apache in the head and move to something that actually handles large numbers of clients sensibly.
   
2. They need to be served as raw file resources, not served through PHP scripts or other CGI-like software, so that clients can properly negotiate a restart from where the last attempt left off in the case of a download failure. (I think there are ways to handle that using PHP, but it ain't pretty.) This makes record-keeping potentially problematic.
   
3. In memory-starved servers, they can blow out your disk cache pretty badly, resulting in considerable performance degradation.

For these reasons, it is often better to host downloadable content on a separate server that hosts large file downloads exclusively, but YMMV.