Возможно, я что-то не так помню, но как-то отложилось в памяти, что в GIF можно впихнуть какие-то левые данные. Если это так, то этими данными может быть и php-код. Только вот сам по себе он в этом случае исполняться не будет, его нужно как-то извлечь и запустить на исполнение. Т.е. нужны специальные средства для этого, некий специальный загрузчик, который этим будет заниматься. А загрузка такой картинки и ее отображение средствами HTML никакого побочного действия не окажет (кроме лишнего трафика).

Ок, это многое объясняет. Спасибо за инфу, буду изучать

А чем тестируется?

Как-то все очень непонятно пока — получается, что на часть запросов ответа нет, но зато на те, что ответ есть, скорость реакции в разы выше.

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

Я, например, очень серьезно относясь к вопросам производительности движка, практически ничего не понял из топика. В чем суть проблемы? И как она проявляется? Гляжу я на картинки и делаю предположение, что к скорости работы прямое отношение имеет параметр «Время ответа на запрос» (я прав, нет?). И вижу при этом следующую картину:
1) LS (xcache) — 6.64 сек
2) Alto (xcache) — 0.85 сек (т.е. скорость почти в 8 раз выше! или я неверно трактую это значение?)
3) Alto (memcached) — 7.58 сек (т.е. скорость на 12% ниже, чем у LS+xcache)

Я правильно все увидел? Если да, то не очень понимаю, в чем проблема, если сравнивать пункты 1 и 2. Если я не увидел чего-то важного, то разъясните, плиз.

ЗЫ. По оф.сайту претензии обоснованы, скоро будем обязательно переезжать на нормальный хост.

Если есть доступ к настройкам сервера Apache, то можно просто добавить в его конфигурацию директиву:

AllowEncodedSlashes On

Подчеркну, что это не в .htaccess добавляется, а именно в настройка апача или в настройки конкретного сайта (в секции VirtualHost)

Если это тоже темный лес или нет доступа к настройкам (или просто боитесь их трогать), то чуть попозже дам более подробные инструкции, как решить проблему на уровне движка

Навскидку два решения вижу:

1) Двойное URL-кодирование при отдаче ссылки, и обратное двойное декодирование при ее обработке

2) Генерировать для тегов дополнительное свойство URL (как это делается для статей) и работать с ним.

Как временное решение можно 1-й вариант заюзать, но второй мне кажется более правильным.

Изучение проблемы показало, что это не баг движка, а фича апача.

Подробнее здесь: www.it-rem.ru/mod_rewrite-i-slesh.html и здесь: httpd.apache.org/docs/2.2/mod/core.html#allowencodedslashes

А иерархия будет?

Чуть выше сказано:
И иерархия, в итоге, получается такая: категория — блог — топик.

И как в новом релизе с совместимостью существующих плагинов LS?

Ничего кардинально нового, поддержка совместимости с помощью специального плагина

Алена, я понял проблему. На самом деле все чуть-чуть сложнее, но суть ясна, работать есть над чем. А про get-запрос я уже писал — это не прописано жестко в движке и отключается элементарно в конфиге

Объясните, плиз, куда он смещен? Я же выше написал: если для Вас это принципиально, то убираете одну строку из конфига — и не будут никакие картинки создаваться налету, все будет жестко и элементарно — либо картинка есть уже готовая (тогда отдается), либо нет (тогда error 404 без вариантов). Куда уж безопаснее?

Извини, но я все равно не понял. У нас есть блог, а в нем есть топики. Если нужен еще один уровень группировки, то есть категории.

И иерархия, в итоге, получается такая: категория — блог — топик. Но иерархия не отображается в URL. У категории полный URL — /catrgory/name/. У блога — /blog/name/. У топика — свой (как настроите).

Так про что вопрос — про URL или про иерархию?

Предложение заслуживает внимания, спасибо

Нет, таких логов не ведем. И я думаю, что если их даже и вести, но не в базу писать, а просто в файл. Не вижу смысла базу этим грузить

Отключается элементарно — комментированием одной строки в конфиге

Если не ошибаюсь, то это старый-старый извечный вопрос, который в общем виде выглядит так: а можно, чтоб блог news показывался не по /blog/news/, а просто по /news/, а профиль юзера vania чтоб был не /profile/vania/, а просто /vania/, и чтоб категория music имела УРЛ не /category/music/, а просто /music/ и т.д.

Я правильно понял? Или речь о чем-то другом?

Есть сайт, где ширина зоны топика в старом дизайне была 540px, а сейчас она — 620px, но все ранее загруженные изображения так и остались на 540, а новые грузятся с шириной 620. Аватары в старом дизайне были 80px, а в новом их дизайнер нарисовал 120px. И размеры в фотосете изменились. Но если с кастрированными картинками в топике как можно было смириться (хотя и не очень хорошо это смотрится), то с аватарами и фотосетом ничего поделать было нельзя, кроме как писать специальный срипт, который бы перелопатил все аватары и фотки фотосетов. Пришлось творческий полет дизайнера прервать, и заставить его аватары и фтосет рисовать не в тех размерах, как ему кажется правильным с точки зрения дизайна и юзабилити, а в тех, в каких они есть сейчас.

Изложенный в статье подход решает эту проблему на счет «раз».

Постараемся все же делать хорошо, но не очень долго :) Пока мы опытным путем нащупываем правильное соотношение числа новых фич к релизу

Чтоб накрылся сервак, таких запросов должно быть очень много. А это уже сродни с ДДоС-атакой, и ее отсечение должно решаться не на уровне движка.

Впрочем, если есть идеи, как улучшить логику на уровне движка — готовы выслушать

Думаю, что это было б клево :)

На сегодня решение одно — выполнять обновление вручную, хорошо понимая, что вы делаете