Назад | Перейти на главную страницу

Мы переносим ваш wordpress на статический сайт. Это создает более 400 000 папок в 1 папке. Есть ли ограничение на количество подпапок?

Нашему веб-сайту WordPress несколько лет, и у него много сообщений, которые хорошо проиндексированы и хорошо ранжируются в Google. С любым серьезным трафиком мой сервер WordPress не работает - и это происходит даже после нескольких раундов оптимизации WordPress. У нас было достаточно проблем с wordpress, и мы решили перейти на него.

Мы переходим с wordpress на статический сайт для повышения производительности, чтобы страницы не отображались для каждого запроса, а статические html, css, js и файлы изображений могли обслуживаться непосредственно веб-сервером nginx вместо того, чтобы обращаться к другому серверу в конце.

Проблема в том, что у нас более 400 000 сообщений, и каждое сообщение будет иметь статическую страницу и, следовательно, статическую папку, в которой мы будем хранить соответствующие файлы, такие как html и файл изображения для этого сообщения. Таким образом, наша основная веб-папка будет иметь более 400 000 подпапок. Будет ли это проблемой в Linux? Или это будет проблемой для производительности моего веб-сервера? Есть ли что-то на стороне хостинга, о чем мне следует заботиться в этой ситуации?

Кто-нибудь здесь пробовал использовать ext4 с nginx с большим количеством подпапок в папке? Неужели это влияет на производительность? Имеются противоречивые отчеты о производительности ext4 при обработке большого количества папок ... Мы не хотим выполнять миграцию с дополнительной сложностью, если это действительно не необходимо. Миграция уже является для нас серьезным испытанием :), и мы хотели бы сделать ее как можно более простой, если нет реального риска снижения производительности. Кто-нибудь использовал веб-сервер nginx с большим количеством подпапок или файлов в одной папке?

Заранее спасибо.

Вот метод уменьшения количества каталогов, как указано в Ответ Артема Сергеевича Ташкинова и настройка nginx для подчинения исходной структуре URL.

Создайте структуру каталогов для каждого URL-адреса, при этом первые два символа каждого URL-адреса будут каталогом в корне документа. Поместите статический контент, начинающийся с этих двух символов, в этот каталог.

Nginx location что делает это возможным, довольно просто:

    location ~ /(..) {
            root /srv/www/example.com/$1;
    }

Это просто берет первые два символа URL-адреса после начального / и добавляет это в корень документа.

Обратите внимание, что для этого требуется все для перемещения в подкаталог с двумя символами. Это включает в себя верхний уровень /index.html, который необходимо разместить в $root/in/index.html. Другой пример - URL-путь верхнего уровня /images должен быть перемещен в $root/im/images. Исходный корень документа не будет содержать ничего, кроме этих двухсимвольных имен каталогов.

URL-адреса ваших документов останутся без изменений. Например, запись в блоге доступна по адресу /15-things-to-do-when-visiting-dubai будет в вашей файловой системе по адресу $root/15/15-things-to-do-when-visiting-dubai/index.html, но по-прежнему доступен по исходному URL. (Обратите внимание, что если в исходных URL-адресах не было косой черты в конце, будет добавлен один и будет сгенерировано 301 перенаправление для сохранения SEO.)

В конце концов, в корневом каталоге документа будет не более нескольких тысяч каталогов, и каждый из них, вероятно, будет иметь максимум несколько сотен каталогов или файлов. Это очень легко обрабатывается любой файловой системой Linux.

В лучшем случае вам следует избегать наличия более нескольких тысяч файлов на каталог в большинстве файловых систем, потому что в противном случае обход займет слишком много времени и ресурсов.

Вы можете создать такую ​​структуру каталогов, как:

  • 00
  • 01
  • 02

...

  • FE
  • FF

Это даст вам 256 каталогов, и вы можете вкладывать их бесконечно.

Или вы можете попробовать организовать сообщения с помощью /YYYY/MM/DD/$UID-post-title

Поскольку сайт статичен, как насчет размещения его на AWS S3 и превращения его в проблему AWS?

S3 может размещать сайты напрямую и каждая корзина может хранить практически неограниченное количество файлов (которые она называет объектами) в корзине. Раньше вы должны были быть очень осторожными с именами файлов, но это в значительной степени решено и сейчас это не большая проблема. Прочтите руководство по производительности и хорошо протестируйте.

S3 не всегда дешев для хранения или пропускной способности, вам следует использовать Калькулятор AWS чтобы рассчитать ваши затраты (новый калькулятор, похоже, не рассчитывает цены S3). Вы можете несколько снизить затраты на трафик, добавив заголовки кеширования к каждому объекту при его загрузке на S3, а затем оставив свою корзину S3 позади CloudFlare CDN (видеть этот вопрос). У CloudFlare есть бесплатные и платные планы, но с таким большим объемом трафика и контента я ожидаю, что вам понадобится платный план.