У парня и так был огромный ЧСВ, а запущенный по новостям сюжет поднял его в размер over 9000 и распиарил парня. Переиграли, короче, с подростком в его максимализм.
Не знаю, у журналистов же тоже должна быть своя «клятва Гиппократа». А так радикально настроенные воинствующие интернет культуры парня наверное уже совсем на потолок загнали.
Хотя он наверное порядком умнее своего окружение, и главное чтобы после таких «успехов» он встал на одну сторону баррикад с другими разработчиками открытого ПО, а не был озлоблен на весь мир.
Ну есть томограф. Тогда для измерения процентов использования мозга нужно ответить на два вопроса:
1) Как с помощью него численно измерить активности мозга? (Т.е. нужно построить меру активности мозга)
2) Как вычислить значение, которое отвечает за максимум.
Если вы считаете что про 10% — это правда, и не можете ответить на эти два вопроса, то вас вполне могли ввести в заблужение «авторитетностью».
1) Потому что это уже не будет преждевременной оптимизацией. Я к тому, что нужно смотреть где и что в конкретном проекте кешируем. Всё кешировать фреймворком без ведома программиста — ничего хорошего…
2-3) Да это выход, но не панацея. Вот есть проект с большой нагрузкой. Пусть тот же каталог с авторами и их произведениями. Я хочу в кабинете автора выложить список его десяти последних произведений с последним комментарием в отзывах. Итого: текст + избыточность серилизации, да помноженное на количество авторов. То есть в данном случае будет просто так жраться оператива, потомучто даже если на главной у нас 200 человек в секунду, то где-то на авторе явно меньше.
Всё-таки таких штук на автокасте делать не стоит.
4) if( $var = $memcache_obj->get(md5( $result_sql_query ))) return $var;
1) Это всё предварительная оптимизация, что достаточно бессмысленно.
2) Если есть уникальный ключ кешировать почти бесполезно, в силу пункта 3.
3) Кеш нужен только в разрезе всяких крупных десятиэтажных запросов (А особенно с подзапросами без точных условий) и тут не совсем понятно когда этот кеш должен скидыватся.
Если взять ваш пример, то допустим я вывожу 10 последних книг, в которых были коментарии.
TTL поменьше, и весь вопрос? Ну-ну.
4) Вообще не вижу особых технических проблем, по которым это нельзя сделать в любой ORM очень небольшими усилиями.
В лихие девяностые по телевидению была реклама памперсов: они были ободрены «союзом педиатров России». И на каждой пачке так писали. А на этом выросло и новое поколение журналистов…
Просто интересно.
Вообще, я ненавижу, когда говорят нужно есть (белки/витамины/ненасыщенные жиры/углеводы/каши/морковь/чеснок/итп), потому что всегда важен баланс веществ. НУЖНО ЕСТЬ ВСЁ!
Не знаю, у журналистов же тоже должна быть своя «клятва Гиппократа». А так радикально настроенные воинствующие интернет культуры парня наверное уже совсем на потолок загнали.
Хотя он наверное порядком умнее своего окружение, и главное чтобы после таких «успехов» он встал на одну сторону баррикад с другими разработчиками открытого ПО, а не был озлоблен на весь мир.
1) Как с помощью него численно измерить активности мозга? (Т.е. нужно построить меру активности мозга)
2) Как вычислить значение, которое отвечает за максимум.
Если вы считаете что про 10% — это правда, и не можете ответить на эти два вопроса, то вас вполне могли ввести в заблужение «авторитетностью».
То что вы говорите, в разрез расходится с «Author::dao()->getById(42); вернет кешированную запись из того кеша который настроен»…
2-3) Да это выход, но не панацея. Вот есть проект с большой нагрузкой. Пусть тот же каталог с авторами и их произведениями. Я хочу в кабинете автора выложить список его десяти последних произведений с последним комментарием в отзывах. Итого: текст + избыточность серилизации, да помноженное на количество авторов. То есть в данном случае будет просто так жраться оператива, потомучто даже если на главной у нас 200 человек в секунду, то где-то на авторе явно меньше.
Всё-таки таких штук на автокасте делать не стоит.
4) if( $var = $memcache_obj->get(md5( $result_sql_query ))) return $var;
2) Если есть уникальный ключ кешировать почти бесполезно, в силу пункта 3.
3) Кеш нужен только в разрезе всяких крупных десятиэтажных запросов (А особенно с подзапросами без точных условий) и тут не совсем понятно когда этот кеш должен скидыватся.
Если взять ваш пример, то допустим я вывожу 10 последних книг, в которых были коментарии.
TTL поменьше, и весь вопрос? Ну-ну.
4) Вообще не вижу особых технических проблем, по которым это нельзя сделать в любой ORM очень небольшими усилиями.
То есть, только излишний вес?
Просто интересно.
Вообще, я ненавижу, когда говорят нужно есть (белки/витамины/ненасыщенные жиры/углеводы/каши/морковь/чеснок/итп), потому что всегда важен баланс веществ. НУЖНО ЕСТЬ ВСЁ!