все необходимые методы модуля теперь в Yii::app()->user, т.е. для получения данных любого юзверя достаточно написать Yii::app()->user->user($user_id)
так же атрибуты моделей user и profile (Yii::app()->user->first_name) что удобно использовать в лейаутах
юзайт транк в yii-user там больше возможностей (например CWebUser, можно теперь не писать Yii::app()->getModule('user')->… а достаточно Yii:app()->user->...)
я не говорил, что нужно вообще избавиться от индексов
в некоторых БД есть решения по поводу блокировки таблицы при записи
а вот скорость все-таки критична, особенно при их изобилии
Что значит не поддерживает? Не сумели настроить или что? Нет — идите книги читайте как настроить httpd (или что там еще).
кроме httpd в мире еще существуют сотни веб-серверов, а также способы запустить PHP
Нет, не поэтому. Потому что когда вы делаете include вы будете точно знать где файл ищется. На phpclub.ru где-то есть прекрасная статья об использовании полных путей.
имелось ввиду не скрипты, а статический контент (изображения, видео, архивы и т.д.) т.к. они действительно могут находиться физически на другом сервере (статику отделяют при масштабирование, одни из первых этапов отделить Frontend и Backend).
Снова таки, не в том дело. Не в том дело, что гугл аналитикс молодец. А в том, что делать статистику можно внешним js-файлом (да да, так же, как и гугл аналитикс). Это позволяет погрузить статистику (в будущем, если надо!) на другой сервак, + если тот сервак упадёт (или вообще статистику отключить) — ничего не случится с сайтом.
Здесь дело в том, что если статистика будет считаться средствами цмс, то это как минимум + 1 INSERT в БД, даже при небольшой нагрузке просто упадет сайт из-за таблицы статистики, но почему-то многие стараются запихнуть это в цмс (одна из распространенных ошибок)
это уже выходит за рамки обычного хостинга и в примере рассматривалось распределение не на два сервера, их количество и тип зависит от нагрузки, а так же контента и специфики сайта.
Так же апач универсальная вещь, но как и все универсальные вещи он уступает узконаправленным веб-серверам, а так же MySQL Master-Slave имелось ввиду как мимнимум два разных физически сервера БД, работающих в простой связке репликации пишем на Master, читаем со Slaves.
ммм… я хотел донести смысл до тех кто сейчас делает мелкие проекты на своем движке, не вкладывая в них много денег и сил, что он будет спокойно спать зная, что если вдруг на его чудо сайт обрушится шквал посетителей, но он всегда сможет быстро среагировать и без особых проблем его масштабировать.
«не используйте memcached — на другом сервере его может не быть. Как и MySQL.»
не понял связи со статьей…
А масштабируемый код, думаю, по другим принципам пишется:)
Я рассматривал именно случаи не прогнозируемого взлета посетителей, встречал много блогов которые могли из-за одного поста привлечь сразу тысячи посетителей.
Если сразу рассчитывать на большую аудиторию разрабатывая стартап, не думаю, что кто-то выберет PHP для реализации ;) да и остальные компоненты LAMP (ну кроме Linux конечно).
Вообще достаточно, т.к. в условии указано «если файл существует» иначе запрос обработает скрипт и если надо возратит Error 404, а вот обзор папок я думаю вообще не нужен…
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ index.php
но у многи в .htaccess такой лес встречал, что… причем даже у многих коммерческих CMS
Правило №8: наиболее частая операция в web, как ни крути, — это SELECT, а там индексы помогают.
Помогать-помогают, но время записи в таблице увеличивается и иногда их лучше вынести в отдельную таблицу и делать выборку по ней. Во время записи в БД таблица блокируется, добавляется запись и обновляются индексы и только после этого все остальные могут ее читать. Следовательно, чем больше индексов, тем больше потребуется времени для их обновления.
Да и еще забыл написать, что нужно фиксировать длину текстовых полей например varchar(20), т.к. в MySQL используются статические буферы под которые соответственно выделяется память.
Да 11 пункт, очень специфичный, но дело в том, что проект из практики по мере его роста проходит не один этап масштабирования и код кочует с одного сервера на другой (например запустить PHP под FastCGI — производительность увеличиться), потом раскидывается на несколько, что тоже приводит к ряду проблем и все зависит от выбранного вами ПО. Я думаю в следующем посте стоит рассмотреть один из стандартных случаев масштабирования LAMP систем и на его примере попробовать решить эти задачи.
яж не стал рассуждать про РИТ как например partizan, а просто выложил сслыки на материалы по конференции, т.к. на мой взгляд более полно их никто и не выкладывал.
так же атрибуты моделей user и profile (Yii::app()->user->first_name) что удобно использовать в лейаутах
в некоторых БД есть решения по поводу блокировки таблицы при записи
а вот скорость все-таки критична, особенно при их изобилии
Perl, Ruby, Python, Java, C/C++
кроме httpd в мире еще существуют сотни веб-серверов, а также способы запустить PHP
имелось ввиду не скрипты, а статический контент (изображения, видео, архивы и т.д.) т.к. они действительно могут находиться физически на другом сервере (статику отделяют при масштабирование, одни из первых этапов отделить Frontend и Backend).
Здесь дело в том, что если статистика будет считаться средствами цмс, то это как минимум + 1 INSERT в БД, даже при небольшой нагрузке просто упадет сайт из-за таблицы статистики, но почему-то многие стараются запихнуть это в цмс (одна из распространенных ошибок)
Так же апач универсальная вещь, но как и все универсальные вещи он уступает узконаправленным веб-серверам, а так же MySQL Master-Slave имелось ввиду как мимнимум два разных физически сервера БД, работающих в простой связке репликации пишем на Master, читаем со Slaves.
не понял связи со статьей…
Я рассматривал именно случаи не прогнозируемого взлета посетителей, встречал много блогов которые могли из-за одного поста привлечь сразу тысячи посетителей.
Если сразу рассчитывать на большую аудиторию разрабатывая стартап, не думаю, что кто-то выберет PHP для реализации ;) да и остальные компоненты LAMP (ну кроме Linux конечно).
но у многи в .htaccess такой лес встречал, что… причем даже у многих коммерческих CMS
Помогать-помогают, но время записи в таблице увеличивается и иногда их лучше вынести в отдельную таблицу и делать выборку по ней. Во время записи в БД таблица блокируется, добавляется запись и обновляются индексы и только после этого все остальные могут ее читать. Следовательно, чем больше индексов, тем больше потребуется времени для их обновления.
Да и еще забыл написать, что нужно фиксировать длину текстовых полей например varchar(20), т.к. в MySQL используются статические буферы под которые соответственно выделяется память.
Да 11 пункт, очень специфичный, но дело в том, что проект из практики по мере его роста проходит не один этап масштабирования и код кочует с одного сервера на другой (например запустить PHP под FastCGI — производительность увеличиться), потом раскидывается на несколько, что тоже приводит к ряду проблем и все зависит от выбранного вами ПО. Я думаю в следующем посте стоит рассмотреть один из стандартных случаев масштабирования LAMP систем и на его примере попробовать решить эти задачи.