Как стать автором
Обновить
0
0
Михаил @mishamx

Пользователь

Отправить сообщение
Пивка и пообщаться, каждый поделится своим опытом)
Попробую распечатать табличку :D
место выберем по ситуации (есть несколько предложений), а кто будет опаздывать пишите в личку.
Для отображаете можно использовать виджеты полей, а если поля обязательные, то необходимо добавть свой валидатор (other_validator).
все необходимые методы модуля теперь в 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->...)
include тебе в помощь)
Походу мне намеренно заминусовали карму, теперь не могу постить, позже гдде-нибудь еще выложу как и обещал продолжение…
я не говорил, что нужно вообще избавиться от индексов
в некоторых БД есть решения по поводу блокировки таблицы при записи
а вот скорость все-таки критична, особенно при их изобилии
на начальной стадии помогает, а потом на помощь приходит memcached
а это уже кто на чем может ;)
Perl, Ruby, Python, Java, C/C++
Что значит не поддерживает? Не сумели настроить или что? Нет — идите книги читайте как настроить 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, а просто выложил сслыки на материалы по конференции, т.к. на мой взгляд более полно их никто и не выкладывал.

Информация

В рейтинге
Не участвует
Откуда
Москва и Московская обл., Россия
Дата рождения
Зарегистрирован
Активность