Со всей осторожностью, и только пока на собственном сервере, таким образом освободил более 60 гигабайт места. Правда там и сайтов 14 штук, с частым обновлением от поставщиков 6ть сайтов, одинаковых фото достаточно.
Идея сама по себе не нова. Даже плагин такой был, но там проверялись большие эскизы и удалялись оригиналы, если макс.эскиз можно было использовать как оригинал https://www.webasyst.ru/store/plugin/shop/hardlink/
В основу идеи, если я правильно уловил суть, заложена мысль об изначально неоптимальном оригинале. Скажем кто-то товар смартфоном щёлк и давай всю эту тяжесть на много мегапикселей грузить на сайт. Эскиз будет ОК, но за оригинал и его хранение в таком виде полагается строгий выговор тому, кто такое сделал. Это может быть неактуально, когда загрузка из каких-то прайсов на стороне ведётся, но даже там мы не можем ручаться за оптимальность исходника. Иной раз прилетает всякое оверсайзнутое в png 24bit прости Господи. Доверяй, но проверяй.
Практика хардлинков вообще имеет место, когда дубликаты имеют место. Однако есть магазины, где на несколько десятков тысяч фото нет ни одного дубликата от слова совсем т.к. все уникальное, а оригиналы оптимизированы так, что некоторые эскизы, а иной раз и webp версии нервно покурят в сторонке, хотя на потоке webp всё равно ушатает jpg на 10-15% при всей возможной оптимизации последнего, но место для хранения второго расширения эскиза иметь надо и это может перечеркнуть экономию, потому что на весы лягут на одну чашу оптимизированные эскизы для быстрой отдачи в webp, а на другую - экономия дискового пространства.
Вообще аудит и менеджмент темы дизайна по части генерации эскизов разных размеров позволяет изначально устранить проблему возникновения хлама. Примеры как это делать публиковал на форуме. И, если вы хотите контролировать этот момент, то надо провести взвешивание оригиналов в том числе, чтобы сделать какие-то выводы о том, чем стоит пожертвовать. Может быть избавиться от оригиналов. При загрузке из прайсов стоит ли их хранить вообще?
При фундаментальном подходе генерация всего набора разных эскизов идет сразу при загрузке, а общий их объем является величиной достаточно легко просчитываемой на условную среднюю тысячу товаров. Иногда такая схема может потребовать вмешательства в размерный ряд по-умолчанию (легкой правкой одного конфига и см. скриншот ниже), но эффект экономии на "своём" проекте того стоит и даже удалять ничего не придется т.к. всего у нас будет ровно столько, сколько необходимо. Создавать только то, что необходимо и достаточно - хороший кейс. Если во что бы то ни стало нужна генерация по требованию, то оставлять этот момент на авось пронесёт тоже не стоит.
Если генерация налету включена, но нет уверенности в том, что все это живёт корректно и кто-то не переполняет вам диск, то пишется сценарий проверки каталогов эскизов на инородную чуждую размерность эскиза (это должно быть что-то своё системное для той ОС и ПО, с которым работаете), а результат проверки заносится в файл. Если что-то будет найдено, то будет уничтожено, но при взятии процесса на контроль проблем не должно быть и несогласованных размеров через какое-то время уже не найдется. Это ставится в расписание и проверяется раз в какой-то период с занесением в отчет об удалении всего найденного (путь-имя-размер).
Снятие галочки хранение оригинала картинок, не спасает, тут все получилось сильно оптимизировать, что используется почти 6ть одинаковых магазинов. Но не способом мультидоменности, а именно как захотел заказчик, чтобы они были не зависимы друг от друга. А так как говориться, бог всем в помощь.
Хотел заострить внимание, что данная утилита, сравнивает файлы очень подробно, т.е. по размеру, по первым байтам, потом по хэш сумме, и только после этого проставляет жёсткие ссылки, минуя разницу в названиях файлов.
3 комментария
Со всей осторожностью, и только пока на собственном сервере, таким образом освободил более 60 гигабайт места. Правда там и сайтов 14 штук, с частым обновлением от поставщиков 6ть сайтов, одинаковых фото достаточно.
Позволю себе немного лирики на эту тему.
Идея сама по себе не нова. Даже плагин такой был, но там проверялись большие эскизы и удалялись оригиналы, если макс.эскиз можно было использовать как оригинал https://www.webasyst.ru/store/plugin/shop/hardlink/
В основу идеи, если я правильно уловил суть, заложена мысль об изначально неоптимальном оригинале. Скажем кто-то товар смартфоном щёлк и давай всю эту тяжесть на много мегапикселей грузить на сайт. Эскиз будет ОК, но за оригинал и его хранение в таком виде полагается строгий выговор тому, кто такое сделал. Это может быть неактуально, когда загрузка из каких-то прайсов на стороне ведётся, но даже там мы не можем ручаться за оптимальность исходника. Иной раз прилетает всякое оверсайзнутое в png 24bit прости Господи. Доверяй, но проверяй.
Практика хардлинков вообще имеет место, когда дубликаты имеют место. Однако есть магазины, где на несколько десятков тысяч фото нет ни одного дубликата от слова совсем т.к. все уникальное, а оригиналы оптимизированы так, что некоторые эскизы, а иной раз и webp версии нервно покурят в сторонке, хотя на потоке webp всё равно ушатает jpg на 10-15% при всей возможной оптимизации последнего, но место для хранения второго расширения эскиза иметь надо и это может перечеркнуть экономию, потому что на весы лягут на одну чашу оптимизированные эскизы для быстрой отдачи в webp, а на другую - экономия дискового пространства.
Вообще аудит и менеджмент темы дизайна по части генерации эскизов разных размеров позволяет изначально устранить проблему возникновения хлама. Примеры как это делать публиковал на форуме. И, если вы хотите контролировать этот момент, то надо провести взвешивание оригиналов в том числе, чтобы сделать какие-то выводы о том, чем стоит пожертвовать. Может быть избавиться от оригиналов. При загрузке из прайсов стоит ли их хранить вообще?
При фундаментальном подходе генерация всего набора разных эскизов идет сразу при загрузке, а общий их объем является величиной достаточно легко просчитываемой на условную среднюю тысячу товаров. Иногда такая схема может потребовать вмешательства в размерный ряд по-умолчанию (легкой правкой одного конфига и см. скриншот ниже), но эффект экономии на "своём" проекте того стоит и даже удалять ничего не придется т.к. всего у нас будет ровно столько, сколько необходимо. Создавать только то, что необходимо и достаточно - хороший кейс. Если во что бы то ни стало нужна генерация по требованию, то оставлять этот момент на авось пронесёт тоже не стоит.
Если генерация налету включена, но нет уверенности в том, что все это живёт корректно и кто-то не переполняет вам диск, то пишется сценарий проверки каталогов эскизов на инородную чуждую размерность эскиза (это должно быть что-то своё системное для той ОС и ПО, с которым работаете), а результат проверки заносится в файл. Если что-то будет найдено, то будет уничтожено, но при взятии процесса на контроль проблем не должно быть и несогласованных размеров через какое-то время уже не найдется. Это ставится в расписание и проверяется раз в какой-то период с занесением в отчет об удалении всего найденного (путь-имя-размер).
Снятие галочки хранение оригинала картинок, не спасает, тут все получилось сильно оптимизировать, что используется почти 6ть одинаковых магазинов. Но не способом мультидоменности, а именно как захотел заказчик, чтобы они были не зависимы друг от друга. А так как говориться, бог всем в помощь.
Хотел заострить внимание, что данная утилита, сравнивает файлы очень подробно, т.е. по размеру, по первым байтам, потом по хэш сумме, и только после этого проставляет жёсткие ссылки, минуя разницу в названиях файлов.