«Родовая травма» некоторых CMS
04.06.2014 297 Пишу Ваш комментарий компьютерная теорияПочему «компьютерная теория»? В самом деле, почему не практика? Дело в том, что не всем CMS (Content Management Service) эта «травма» присуща, а, с другой стороны, самих «движков» (уж позвольте так по-простому их называть), существуют десятки.
Рассмотреть их все и предложить решение проблемы для каждого из них, не входит в мои намерения, другое дело — обозначить проблему и показать теоретические пути её решения.
Я сталкивался с этой «травмой» и в бесплатных CMS, и в тех, которые распространяются за деньги. Не хочется показывать пальцем, но это был, например, движок «Netcat» старых версий (ещё до 3.xx). Возможно, сейчас, когда выпущена уже пятая стабильная версия, подобная проблема решена. Хочется в это верить, во всяком случае.
Теперь собственно к «травме». Большинство, если не сказать все «движки» имеют самописные или подключаемые wysiwyg-редакторы статей (What You See Is What You Get — как видишь, так и будет отображаться). Они позволяют людям, не знающим языка HTML, оформлять статьи: менять начертание шрифтов, их размер, цвет, выравнивать абзацы, добавлять в тексты таблицы и картинки. Как раз о картинках и пойдёт речь.
Дело в том, что когда вы в свои статьи активно добавляете иллюстрации, все они средствами «движка» сохраняются в определённую папку или папки. Очень логично при этом иметь инструмент просмотра картинок, которые уже загружены на сервер. В самом деле, иногда не требуется каких-то особых новых фото, достаточно выбрать уже имеющиеся, чтобы не дублировать одинаковые картинки при закачке на сервер. Тут-то и кроется «родовая травма» некоторых CMS. Если все фото, которыми вы иллюстрируете свои статьи, сохраняются в одной папке, со временем, этих снимков накапливается великое множество. Даже с учётом того, что фото для веб обычно оптимизируются — вес каждого отдельного файла очень не велик — общий объём файлов переваливает за сотни мегабайт.
Проблема при этом появляется не всегда, для этого должны вместе сойтись несколько моментов. Но уж если так и вышло — жди беды. Первое условие, как я уже сказал, все добавляемые снимки, хранятся в одной папке. Второе условие тоже вполне вероятно. Если вы не собственник (или арендатор) отдельного сервера под свой сайт, то чаще всего вам выделяется виртуальный сервер. Что это значит? Это означает, что довольно мощный сервер (его ресурсы) делят между заказчиками на хостинг — от нескольких и до десятков сайтов на одном компьютере. Каким бы мощным при этом не был сервер, ресурсы придется делить между многими сайтами. А коль скоро это так, то будут поставлены и различные ограничения для каждого владельца сайта (хостинга). Такое ограничение, чаще всего, касается объёма скачиваемой за один раз информации. Всё — мы добрались до «родовой травмы». Когда снимки для статей хранятся в одной папке, каким бы не было ограничение в объёме, рано или поздно вы его достигнете. В случае с CMS «Netcat 2.5 Corporate» и виртуальным хостингом «Мастерхост» это случилось при превышении объёма папки с картинками двухсот мегабайт. При нажатии кнопки «Обзор…» при выборе картинок на сервере, происходил запрос и «движок» старался загрузить все имеющиеся у него картинки в один приём. При этом объём файлов превышал заранее установленное на хостинге значение в 200 МБ, сервер «справедливо» считал это ddos-атакой на сайт и… для сохранения работы всего сервера в целом и всех остальных сайтов, расположенных на нём, проблемный сайт просто отключался на некоторое время.
Очень может быть, что подобные ограничения имеются и на выделенных серверах, где расположен только ваш сайт. И что же делать? Прежде всего, администраторам сайта (в случае с Неткетом в далёком уже 2006-ом году, это пришлось делать мне) приходится следить за переполнением папки с картинками. Со временем создавать новую папку и перенаправлять средствами «движка» или веб-сервера новые иллюстрации в неё. При этом при нажатии на кнопку «Обзор…» показывать не текущую или прошлую папку для загрузки картинок, а их родительскую. Разумеется, это полумера. Решением проблемы может стать доработка кода «движка» таким образом, чтобы, например, раз в месяц автоматически создавалась новая папка для иллюстраций (её название можно привязать к году и месяцу), а функция закачки картинок на сервер по календарю как раз и выбирала текущую последнюю папку. Этот механизм мы опробовали значительно позже с другой платной CMS. Разумеется, метод работает корректно в том случае, если общий объём иллюстраций за месяц не превышает установленного на сервере ограничения.
Как было бы здорово, если бы в платных или свободно-распространяемых «движках» их разработчики всегда заранее задумывались об удобстве использования их продуктов.