Вспоминаю «Логомиры» в своей школе. Вот они привили мне вкус к программированию класса эдак с третьего.
Там, кстати, программируются тоже всяческие животные, а код выглядит примерно как «вперёд 100, налево 90, натянуть скин бегущей лошади 1, натянуть скин бегущей лошади 2».
Согласен, можно забивать на таких пользователей, но только если потеря пары процентов пользователей не будет связана напрямую с потерей пары процентов прибыли.
Я до сих пор теряюсь — для себя делаю на js, на серьезных проектах стараюсь не надеяться на браузер пользователя, особенно если пара лишних часов разработки принесет не только эстетическое удовлетворение, но и плюсик к кроссплатформенности
Конечно, для приложений в соцсети это не применимо — туда и войти без js нельзя. Но есть вещи, для которых об этом надо думать.
Из личного опыта — система микрокредитования, пара тройка бабушек из глубинок России не смогли вернуть кредит, т.к. форма для банка генерировалась на лету ajaxом и перегенерировалась на лету при изменении суммы. Форму бабушки видели, но форма всегда сабмитилась неизмененная с начальной суммой, которую заплатить бабушки не могли. Объяснить им про js оказалось нереально, а потеряли на этом несколько тысяч. Да и процент таких на сайтах ориентированных на старшее поколение много выше, и куки у многих отключены, и ие6 встречается чаще.
У нас страница вида «самые популярные активности за 5 минут», на ней же еще несколько блоков с контентом, валидным в течение минут 5-10. Конечно, второй уровень кеша, как раз memcache, работает и разгружает бд (выборки довольно тяжелые, оптимизировать их дальше уже не получается). кеш nginx понадобился уже чтобы эту самую страницу не дергать (даже обращение в мемкеш и отрисовка с учетом нескольких бэкендов не давала нужного rps), а nginx кеширует эту страничку на 5 минут и высвобождает очень много ресурсов. Т.е. вместо обращения к php, а оттуда в memcache мы отдаем с диска уже сохраненную страницу.
Или имеется в виду хранить кеш nginx в memcache вместо диска?
Up. перечитал комментарий, даже не думал о ручном формировании кеша nginx Оо. Вы определили моё занятие на несколько ночей вперёд.
Да, спасибо, понял, роботы придут и закешируют половину страниц сайта, при этом кеш будет никак не использован простыми пользователями с нормальными заголовками. Над fastcgi_cache_key думать и думать, мы не думали по причине отсутствия роботов как класса в приложении (мы не индексируемся)
Вот тут habrahabr.ru/post/124684/ написано про сброс кеша nginx, правда по 1 странице, что наверное не очень удобно. Возможно, можно делать reload nginx изменив ключ кеша (подмешать туда текущую версию сайта, например), но затирать кеш ни одним из возможных способов мне еще не доводилось.
Такие url конечно у нас никак не кешируются (передается X-Accel-Expires: 0).
Насчет $http_if_modified_since $http_if_none_match — могу ошибаться, но также закешируется, даже если переданы не будут (ключ кеша будет просто другой), но не уверен, потестирую.
В моем случае этот кеш использован для приложения в социальной сети, в котором без кеша отдается верхний фрейм (в котором как раз все utm и прочее пишутся в статистику), а все контентные страницы имеют короткие урлы с минимумом параметров, одинаковые для всех пользователей.
Ваш комментарий натолкнул на мысль попробовать задавать имя кеша отбрасывая GET параметры на некоторых страницах, (чтобы site.ru/?asd и site.ru/?asdasd кешировались в один файл), тем более кейсы для этого у меня уже есть, спасибо за идею!
На самом деле очень заманчиво, в планах освоить. Меня очень привлекают ajax запросы своей экономией траффика, но юзеров с отключенным javascript по-прежнему достаточно, так что ssi меня ждёт.
Там, кстати, программируются тоже всяческие животные, а код выглядит примерно как «вперёд 100, налево 90, натянуть скин бегущей лошади 1, натянуть скин бегущей лошади 2».
Согласен, можно забивать на таких пользователей, но только если потеря пары процентов пользователей не будет связана напрямую с потерей пары процентов прибыли.
Я до сих пор теряюсь — для себя делаю на js, на серьезных проектах стараюсь не надеяться на браузер пользователя, особенно если пара лишних часов разработки принесет не только эстетическое удовлетворение, но и плюсик к кроссплатформенности
Конечно, для приложений в соцсети это не применимо — туда и войти без js нельзя. Но есть вещи, для которых об этом надо думать.
Из личного опыта — система микрокредитования, пара тройка бабушек из глубинок России не смогли вернуть кредит, т.к. форма для банка генерировалась на лету ajaxом и перегенерировалась на лету при изменении суммы. Форму бабушки видели, но форма всегда сабмитилась неизмененная с начальной суммой, которую заплатить бабушки не могли. Объяснить им про js оказалось нереально, а потеряли на этом несколько тысяч. Да и процент таких на сайтах ориентированных на старшее поколение много выше, и куки у многих отключены, и ие6 встречается чаще.
Или имеется в виду хранить кеш nginx в memcache вместо диска?
Up. перечитал комментарий, даже не думал о ручном формировании кеша nginx Оо. Вы определили моё занятие на несколько ночей вперёд.
Насчет $http_if_modified_since $http_if_none_match — могу ошибаться, но также закешируется, даже если переданы не будут (ключ кеша будет просто другой), но не уверен, потестирую.
В моем случае этот кеш использован для приложения в социальной сети, в котором без кеша отдается верхний фрейм (в котором как раз все utm и прочее пишутся в статистику), а все контентные страницы имеют короткие урлы с минимумом параметров, одинаковые для всех пользователей.
Ваш комментарий натолкнул на мысль попробовать задавать имя кеша отбрасывая GET параметры на некоторых страницах, (чтобы site.ru/?asd и site.ru/?asdasd кешировались в один файл), тем более кейсы для этого у меня уже есть, спасибо за идею!