Спасибо за статью. Действительно верные мысли. Правда с историей Б вы немного ошиблись. :)
Пункты моей статьи были действительно ориентированы на повышение производительности сервера (т.к. прижало), однако это не главная цель. Пользователям становилось не комфортно посещать ресурс, исправить это и было основной целью. Достигается же это, путем повышения производительности.
В принципе, по каждому пункту в моей статье, пользователи наблюдают ускорение в работе. О пользователях мне тоже приходится думать, т.к. я сам являюсь пользователем ресурса ;)
Еще когда не был хабраюзером, читал эту тему и была идейка.
При посещении главной страницы — ставить юзеру куку с датой.
При переходе на какую-либо из страниц, вести отсчет от этой даты.
При переходе снова на главную — заменять куку.
:)
Вообще, пока не появится человек, который по увольняет всех без суда и следствия, пока не поставит жесткий контроль за каждым рублем, пока не начнет думать о России (дада, я помню, Наша Раша) вместо своего кармана — у нас ничего не измениться.
Не соглашусь о конфиденциальности. На работе они слуги народа, который их выбрал и доверился им. Хотя конечно вы правы, они не согласятся и такая идея не пройдет.
ИМХО: Я солидарен с автором, что все стало бы прозрачно и ясно. Но это идеальный случай. На практике чиновник может написать на сайт кучу лжи которую ни как не оспорить, ведь такие микроблоги будут вести либо сами, либо при помощи секретаря.
Встретился с губернатором Муховозной области. Обсудили урожай картошки, проблемы урожая и колорадского жука, нехватку финансиравания и выработали план на следующий год.
будет звучать как
Встретился с губернатором Муховозной области. Попилили миллиард, придумали отмазу — куда делся, закинули удочку еще на один и выработали план на следующий год.
у нас:
— очень много SELECT'ов и INSERT'ов в большие таблицы
— частые COUNT
— отсутствие LIKE (как уже говорил, знаю что зло, но за переделку огромной груды кода взяться не было возможности)
Еще на заре ресурса я хотел перейти на InnoDB… вроде и время позволяло и мощностей было прилично, отключил страницы где используется LIKE и запустил… железо продержалось 10 минут, при это время критичных запросов резко возросло…
Будь у текущего ресурса будущее, скорее всего, взялся бы за переписку многих вещей и пошел бы на встречу к InnoDB. И дошел бы медленно, но верно — к более надежной БД. Но теперь смысла нет.
YSlow же измеряет скорость загрузки всей страницы с ее компонентами… Т.е. он анализирует заголовки, сжатие, попадания в кеш и прочее… а статья о времени генерации страницы… т.е. о скорости обработки php скриптов
Но все же, на разных страницах по разному… от 71 до 83
Ну вот смотрите. Пример — главная страница:
— Состоит из 20 блоков, почти в каждом блоке есть 1-2 sql-запроса. При добавлении отсутствующих индексов, время выполнения запроса уменьшается. Соответственно страница генерируется быстрее.
— Содержимое многих блоков обновляется не часто, поэтому имеет смысл кешировать это содержимое. В результате полное избавление от sql-запроса при обращении к странице и как следствие страница генерируется еще быстрее.
Так же без тюнинга sysctl количество открытых соединений с сервером становится огромным. В результате в часы пик, пользователь может получить страницу сгенерированную за 0,09 секунд лишь через секунды 2. Настройка сетевой системы серверов, от этого избавляет.
Вообще каждое улучшение сразу же заметно конечному пользователю по времени генерации страницы. Да и банальная связь, в часы пик, когда сервера перегружены они и отдают контент медленнее, когда им «полегчало» — они отдают контент быстрее.
Я потому и сделал заметочку, что я только разбирался во всем и о существовании php-акселераторов не знал. Начни я это делать сейчас, с текущим багажом знаний, порядок был бы совершенно иным, но статья же все-таки в первую очередь история развития :)
Насчет встроенного кеширования конечно же не забыл. Вообще очень много было убито времени на подборки оптимальных конфигов системы, nginx, php-fpm и очень много на mysql. Но я почему-то не посчитал нужным добавить это в статью, через это в любом случае проходить каждому и это очевидный факт :)
Т.к. я раскрыл некий план дальнейшего развития ресурса, мне пока не хотелось бы называть его.
Возможно в следующей статье по оптимизации уже новой CMS я расскажу о нем более открыто. Если уж очень интересно, расскажу в ЛС ;)
habrahabr.ru/blogs/microsoft/106494/
Пункты моей статьи были действительно ориентированы на повышение производительности сервера (т.к. прижало), однако это не главная цель. Пользователям становилось не комфортно посещать ресурс, исправить это и было основной целью. Достигается же это, путем повышения производительности.
В принципе, по каждому пункту в моей статье, пользователи наблюдают ускорение в работе. О пользователях мне тоже приходится думать, т.к. я сам являюсь пользователем ресурса ;)
При посещении главной страницы — ставить юзеру куку с датой.
При переходе на какую-либо из страниц, вести отсчет от этой даты.
При переходе снова на главную — заменять куку.
:)
ИМХО: Я солидарен с автором, что все стало бы прозрачно и ясно. Но это идеальный случай. На практике чиновник может написать на сайт кучу лжи которую ни как не оспорить, ведь такие микроблоги будут вести либо сами, либо при помощи секретаря.
Встретился с губернатором Муховозной области. Обсудили урожай картошки, проблемы урожая и колорадского жука, нехватку финансиравания и выработали план на следующий год.
будет звучать как
Встретился с губернатором Муховозной области. Попилили миллиард, придумали отмазу — куда делся, закинули удочку еще на один и выработали план на следующий год.
— очень много SELECT'ов и INSERT'ов в большие таблицы
— частые COUNT
— отсутствие LIKE (как уже говорил, знаю что зло, но за переделку огромной груды кода взяться не было возможности)
Еще на заре ресурса я хотел перейти на InnoDB… вроде и время позволяло и мощностей было прилично, отключил страницы где используется LIKE и запустил… железо продержалось 10 минут, при это время критичных запросов резко возросло…
Будь у текущего ресурса будущее, скорее всего, взялся бы за переписку многих вещей и пошел бы на встречу к InnoDB. И дошел бы медленно, но верно — к более надежной БД. Но теперь смысла нет.
Но все же, на разных страницах по разному… от 71 до 83
P.S. но я не видел, спасибо!
— Состоит из 20 блоков, почти в каждом блоке есть 1-2 sql-запроса. При добавлении отсутствующих индексов, время выполнения запроса уменьшается. Соответственно страница генерируется быстрее.
— Содержимое многих блоков обновляется не часто, поэтому имеет смысл кешировать это содержимое. В результате полное избавление от sql-запроса при обращении к странице и как следствие страница генерируется еще быстрее.
Так же без тюнинга sysctl количество открытых соединений с сервером становится огромным. В результате в часы пик, пользователь может получить страницу сгенерированную за 0,09 секунд лишь через секунды 2. Настройка сетевой системы серверов, от этого избавляет.
Вообще каждое улучшение сразу же заметно конечному пользователю по времени генерации страницы. Да и банальная связь, в часы пик, когда сервера перегружены они и отдают контент медленнее, когда им «полегчало» — они отдают контент быстрее.
Насчет встроенного кеширования конечно же не забыл. Вообще очень много было убито времени на подборки оптимальных конфигов системы, nginx, php-fpm и очень много на mysql. Но я почему-то не посчитал нужным добавить это в статью, через это в любом случае проходить каждому и это очевидный факт :)
Возможно в следующей статье по оптимизации уже новой CMS я расскажу о нем более открыто. Если уж очень интересно, расскажу в ЛС ;)