Грядущий апдейт битрикса

kostich, а есть где-то собранные ваши рекомендации по кукам и кэшу браузера для битрикса? Для не-админов :)

Бабушка на двое сказала!

У битрикса есть приемущество: вот сделали вы сайт заказчику, а к нему через месяц подвалил друг и спросил, за сколько тебе сайт сдеали, а он ответил: за 3 штуки!

А друг скажет: фууу... тебя надули, такой сайт за штуку можно было сделать!!!

А заказчик в ответ: он на битриксе!

И друг уберет язык в укромное место и ничего не ответит :)

Примерно 15-25% максимум, если техподдержка кончилась.

Есть. Обычно это прикладывается к ТЗ на оптимизацию различных проектов. Собственно там не только c куками заморочки, а еще и с strong validation support (Etag). Всем рекомендую читать -> http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.3.3 Оптимизацию надо же делать под два типа кэшей... shared (кэширующий акселератор) and non shared (кэш браузера), а это не так просто, если в решении под одним url есть заход для "гостей" и для "зарегистрированных". Возникает много всяких заморочек... но если подобную функциональность закладывать в архитектуру изначально, то сайты просто летают.

В Битриксе исходников кучу перелопачивать надо, а это никому не нужно, т.к. они через какое-то время выпустят новый мега-апдейт и надо будет заново накладывать патчи. При их отношении к клиенту что-то им дарить... давно бы уже программистов нормальных наняли бы, да вопрос глобально решили. И хостинг провайдеры рады были бы, т.к. кэши у всех крупных стоят. И юзерам бы приятнее было, т.к. сайты бы хостили не за 40 баксов, а всего за 20.

У cookie есть path, который заставляет слать браузер куку на этот url и всё что ниже. Следовательно если какой нибудь index.php ставит path в /, то браузер пуляет куками на все подряд.

Попробую какой-то простой напильник скреатировать:

Добавьте еще один virtualhost, как раз для "зарегистрированных". Пускай смотрит туда-же куда и для "гостей". Хост нужно добавлять потому, что веб-сервер в ответе будет светить ServerName, а не ServerAlias... так что просто синоним не прокатит. Если в процессе выставление кук domain не указывается, то его берет как раз из http response. Что бы обойтись синонимом надо еще добавить выставление domain в куках, с учетом ниже написанного. В скрипте для авторизации нужно проставить редирект на этот хост, обозвать его можно как registered. Статистикой для "гостей" мы жертвуем, ибо нефик.

В начале обработки вставьте определение hostname и выставление какого-то флажка, к примеру IS_STATIS, если пришло на домен для "гостей". Далее надо найти все выставлялки кук и обрамить их с учетом флажочка, что бы в случах с выставленным IS_STATIC куки просто не выставлялись.

Следовательно надо найти еще и ляпы по поводу выставления no-cache в хидере и остальных местах, грепать возможно по expires. Далее дописываем, что в случах с IS_STATIC нужно ставить какой-то expires, возможно минут 5-10, а можно и все 30, т.к. для "гостей" у нас сайт должен быть шустрым и быстрым.

Логично надо к процедуре подходить, т.к. в .htaccess надо еще выставить ExpiresByType на всякие там gif, jpeg и т.д... если это элементы дизайна, то можно смело ставить сутки, а лучше двое... хотя у меня в некоторых местах неделя стоит, т.к. дизайн не меняют годами.

Собственно на выходе получаем сайт registered.optimizedbitrix.ru для "зарегистрированных", а для "гостей" просто optimizedbitrix.ru. Если кэширующего акселератора на фронте нет, то воткните в апач mod_cache & mod_mem_cache. Это будет лучше, чем nginx на фронте и обычный apach с mpm prefork позади.

PS. Лепим какой-то каунтер типа spylog или мыл.вру и получаем нормальную статистику.

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

kostich, пытаюсь разобраться :)

Гостями называются UA, которые зашли первый раз? В смысле у которых куки нет?

Статистикой по заходам поисковых роботов пренебречь рискнет не каждый :)

Или незалогиненые?

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

Разные адреса для залогиненых и незалогиненых - это ж дубли. Которые поисковики склеивают так, как им в голову придет :) А люди на страницы ссылки ставят на те, на которые ходят. У меня, например, редактор в последней версии стала вдруг ссылки генерировать (из админки) с параметром "lang=ru". И без того страниц ужас сколько (интересные наблюдаются урлы в поисковиках - по три PAGEN), чтобы еще и самостоятельно дублировать.

Статистику битрикса люблю :)

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

они самые

ну а чем spylog не решение?

Ну если бы у них стата была по такой же технологии как у внешников, то вопросов бы и не возникало.

PS. Любой сайт под битрикс можно убить пионерским скриптом... они про это совершенно не думают.

большое списибо за полезную инфу

теже проблемы с кешированием и производительностью приходится решать для TYPO3

там есть для этого средства... но я подозреваю, что сделано не все возможное

(про разные вирт хостны для зарегеных и не зарегеных юзеров - я вообще нигде не видел)

Статьи на эту тему по TYPO3

http://typo3.org/development/articles/using-cache-control-headers-in-typo3/

http://typo3.org/development/articles/testing-and-tuning-typo3-performance/

ну и вот еще може будет интересно (typo3-метод защиты от пионеров, которые могут завалить сайт с кешированием)

http://typo3.org/development/articles/the-mysteries-of-chash/

+1

десять орденов.

Как минимум - тем, что веб-аналитика уже стоит, а за спайлог еще надо платить :) Причем больше, чем за продление техподдержки старших версий битрикса. А если учесть, что я в части случаев выступаю как дилер, то имеют значение и условия для дилеров :)

Кроме того, речь идет о привычке. На разных сайтах я статистикой смотрю разные вещи. На информационном сайте меня интересует скорее статистика переходов по рекламе, общую посещаемость я смотрю li, в большом магазине - разделяю при помощи статистики тех, кто пришел из результатов поиска и по контексту, рассматривая эти группы в разрезе того, какие они покупатели, а на небольшом сайте смотрю путь каждого, кто дошел до отправки формы обратной связи. Все это делается в один-два клика непосредственно из интерфейса просмотра заполненных форм, списка заказов, баннеров. А не пойти куда-то, настроить фильтры, посмотреть, подумать, внести изменения на сайте, опять пойти...

Есть еще мелочи. Типа того, что встроенная система статистики не работает вместе с сайтом, а не по другому графику. Не режется и на отключается при отключении JS.

Есть не мелочь. Статистику, которая ведется на сервере, никто не будет использовать для составления отчетов, которые будут проданы конкурентам :)

Потому и интересно будет посмотреть, как соптимизируют статистику.