Работает на perl, путем генерации множества статических html файлов, за счет чего очень хорошо выдерживает даже большие нагрузки.
Ну в принципе так делает любая нормальная CMS и называется кешем. Интересно было бы услышать чем он лучше того что уже есть, скажем тот же монстр Wordpress который не один год затачивается под блоги и бесплатен к тому же. При грамотной настройке не думаю что и по скорости уступит. Да и сообщество у него куда больше.
Касательно статьи я бы с начало рассмотрел чем он хорош поподробней, а то пока нет мотивации пользоваться им (( выглядит как очередной велосипед. Но за старание и краткий курс создания плагина спасибо!
Здесь не кеш. Здесь в принципе динамической реакции на пользователя нет — только JS определяет пользователя по кукам (или аякс вызову) и подменяет внешний вид. Никакой динамики.
А что сейчас есть из широкоиспользуемых блог-платформ? wordpress и movabletype.
Остальное всё тяжеловесные CMS — жумлы, друпалы и тд.
В чем разница… MT «из коробки» тянет нагрузку такую, что WP разгонять и разгонять надо, именно за счет жесткой статики.
Если ставить вопрос «использовать или нет» я для себя решил что «нет». Но по работе сейчас связан с плагином для MT, так что познакомился крайне близко.
В принципе жёсткая статика быстрее кеша, это да. Могу согласиться что на ajax ничто не мешает допилить функционал. теже комментарии, последние записи, постраничная навигация в комментариях.
Я не знаком с это CMS близко, но просто не могу представить ситуацию в которой она будет лучше скажем вп.
А так думаю кто работает с WP не побежит на MT и наоборот, ибо не вижу для этого резона, оба движка затачиваются и легко выполняют свои функции.
Movable Type бесплатный. Есть расширенные версии с дополнительной функциональностью: Pro и Enterprise. Pro есть бесплатная, которую можно использовать во всех случаях, если не являешься юридическим лицом.
Я игрался с ней в 2008 и пару месяцев пытался вести блог на ней, быстро работали только статический страницы, любое другое действие поднимало перл, который на 10-15 секунд грузил под 99% 1ггц cpu и кушал 256мб памяти.
Ну и система глобального кэша мне тоже не понравилась, когда на сайте не 200, а 2000 страниц, то перегенировать его заново было довольно долгим занятием.
С какими ресурсами? На простом апаче на EC2 инстансе, без mod_perl, через CGI, комментарии бегают очень шустро (нагрузочное тестирование мы проводили).
SSI в него можно встраивать и на php.
10-15 секунд — это что-то удивительное. Какая версия была? 3.х или 4.х?
Генерация вообще затрагивает только изменившиеся файлы, а полный ребилд сайта нужен крайне редко — например, при смене дизайна или при установке спецплагинов. Во всех остальных случаях меняется максимум 3-5 файлов (категория, архив, возможно индексная, сама страница).
И опять же — что лучше, 1 раз сребилдить 2000 страниц, или на каждого из 100000 пользователей сгенерировать по 10 страниц?
>Во всех остальных случаях меняется максимум 3-5 файлов (категория, архив, возможно индексная, сама страница).
Простой пример — в сайдбаре каждой страницы статистика просмотров страниц сайтов. Без каких-то «хаков» типа SSI, image, iframe и т. п., включающих в статический html динамический контент генерация всего сайта должна происходить после каждого запроса.
Более того, для таких вещей существует JavaScript. Ломать кэш в браузерах пользователей, на локальных прокси-серверах, и вообще весь механизм кэширования где либо по дороге из-за пары незначительных циферок какой-то статистики на странице — это не то что, не разумно, а просто неприемлемо.
Желание клиента — чтобы сайт работал. В технические подробности ему нос сувать не нужно. Даже нельзя: «кухарки» должны оставаться «на кухне», а не давать советы как «ракеты строить».
Как угодно, можно и без xhr, если хочется, если асинхронность не нужна:
Покажите такого клиента, пожалуйста. Обычно ему объяснять надо как это должно работать, зачем это ему надо, и уровень допустимой деградации. Обычно «нет статистики с мобильной оперы» их устраивает.
А если желанием клиента будет чтобы сайт открывался на выключенном компьютере? Клиент кого нанимает, разработчика или лакея? Если клиент считает, что ему виднее, как надо делать с технической точки зрения, то пускай делает сам. Клиентов полно, вы один, можно ж найти адкватных, зачем со школьниками конкурировать? Пускай нанимают школьников и те делают, как их просят.
image — сложнее, криво, не скопировать циферки;
iframe — пожалуйста, можно и им, как было указано автором топика выше.
Здесь всё зависит от шаблонов, как они сделаны. Стандартные шаблоны после установки удобны для пользователя, но с точки зрения производительности они никуда не годятся, поскольку: множество включаемых шаблонов по разным условиям, виджеты, отсутствие кеширования в не меняющихся блоках. Я всем, в первую очередь, рекомендую посмотреть на эту статью: movable-type.ru/wiki/Оптимизация_публикации Там описаны основные моменты ускорения публикации.
Большинство модулей (плагинов) не нужно в Movable Type, всё делается с помощью шаблонов. А вот темы, да, их гораздо меньше. Но сделать свою тему из любого дизайна, в том числе из темы WP, очень легко.
Кстати, как в шаблон втыкать тег так, чтобы не вызывать ошибок если плагин обеспечивающий этот тег отсутствует (выключен)?
В wp это делается if(function_exists('zz'))zz();. через энное место, но работает.
А в MT?
Если тег не работает, то при сохранении шаблона MT сообщит об этом. Но можно добавить его между блочным <mt:Ignore>…</mt:Ignore>, тогда он будет игнорироваться (как и всё в этом теге).
То есть сделать так, чтобы после того, как плагин отключен или отсутствует, теги плагина не вызывали ошибок? Идея здравая, но вроде бы так сделать нельзя.
Вот это мне и не понравилось в первую очередь.
В итоге мы делаем auto-inject с кучей магии, чтобы иметь вохможность «прозрачной» установки включения/отключения.
MovableType — отрывки из разработки плагинов