LAMP站点上较长的目录路径/名称和URL的不利之处是什么？

Question

What are the downsides of longer directory paths/names and URL's on a LAMP site?

I am trying to organize images on my sites as efficiently as possible, and I'm keen on using many nested directories so that no sub-directory has more than 1,000 sub-directories.

In a worst-case scenario, images would be stored looking something like this:

./images/76/543/7654321/640/1.jpg

Are there any serious downsides to having so many sub-directories vs. something simpler like this:

./i/a7/c3/5e.jpg

I suppose the more sub-directories the Server has to dig in to, the longer it's going to take, and the longer the directory structure is, the longer the URL will be, so the more space the HREF will take up in the HTML doc. But how much of a difference will that make? Let's say we scale up to millions of users, is this something I need to take into consideration (short dir structure vs long dir structrue)?

For context, please view this .

Thanks!

Answer 1

Having a large number of files in one directory can make it slow. You are right to split it up. You can however try to reduce the length by using all alphanumeric characters in the path names.

If you were to have:

/images/[a-z0-9]{3}/[a-z0-9]{3}/[a-z0-9]{3}.jpg
/images/abc/def/ghi.jpg

With the above you can store 101559956668416 images. This seems ridiculous so perhaps something like:

/images/[a-z0-9]{2}/[a-z0-9]{2}.jpg
/images/ab/cd.jpg

With the above you can store 1679616 images. This is a reasonable number but might not be enough for your needs. So how about this:

/images/[a-z0-9]{2}/[a-z0-9]{2}/[a-z0-9]{2}.jpg
/images/ab/cd/ef.jpg

This allows for 2176782336 (2 billion) images and each directory will only ever have a maximum of 1296 child files/directories.

Mix in some capital letters and perhaps even some symbols and you can get away with even fewer. Personally I would go with the last option though. It seems to be a nice balance.