Oduvan’s Web Blog

Вопервых insight-it.ru – один из моих любимых форумов. Интересный, популярный.

В нем очень часто описаны архитектуры популярных сервисов. В этот раз я наткнулся на твитер. Все как всегда, правда они пишут на рельсах, поэтому техническая часть мне была не особо интересна. А вот итоги в конце статьи, мне очень понравились. Очень четко описаны ключи к успеху хорошего сервиса.

Перечислю их тут ( для себя), но вам лучше перейти на саму статью

• Общайтесь со своим сообществом. Не прячьтесь и не пытайтесь решить абсолютно все проблемы самостоятельно. Много отличных людей будут готовы помочь, достаточно лишь попросить.
• Рассматривайте вашу стратегию масштабирования как бизнес-план. Соберите советы помощников для того чтобы облегчить для себя принятие решений.
• Стройте свой проект сами. Twitter потратил много времени, пытаясь приспособить готовые решения других людей, которые казалось бы должны работать, но это оказалось не совсем так. Лучше построить какие-то вещи самостоятельно, чтобы иметь высокую степень контроля над ситуацией и иметь возможность привносить новые возможности как только они понадобились.
• Ставьте перед своими пользователями разумные ограничения. На обычных пользователей это не повлияет, но когда кому-нибудь взбредет в голову попытаться сломать систему (а такой человек рано или поздно найдется) – они сыграют свою роль и спасут работоспособность системы.
• Не делайте базу данных центральным узким местом системы, врядли Ваше приложение на самом деле требует гигантских операций по объединению данных из нескольких таблиц. Используйте кэширование, или проявите свою смекалку для поиска альтернативных способов достижения того же результата.
• Предусмотрите возможность сегментирования с самого начала, тогда перед Вами всегда будут открыты пути для дальнейшего масштабирования.
• Очень важно вовремя осознать, что сайт начинает работать медленно. Сразу стоит задуматься о системе отчетов для отслеживания потенциальных проблем.
• Оптимизируйте базу данных:

  - Индексируйте все таблицы, Rails не будет делать это за Вас.

  - Используйте “explain” для анализа выполнения запросов. Результаты могут не совпадать с Вашими ожиданиями.

  - Денормализуйте данные. Один только этот совет порой может спасти ситуацию. Для примера, в Twitter хранят все ID друзей каждого пользователя вместе, это позволило избежать многих ресурсоемких запросов.

  - Избегайте комплексного объединения данных из нескольких таблиц.

  - Избегайте сканирования больших наборов данных.

• Кэшируйте все, что только можно.
• Тестируйте все максимально тщательно:

  - Когда Вы развертываете приложение, Вы должно быть уверены, что оно будет работать корректно.

  - Они используют полный набор средств для тестирования. Таким образом, когда произошла неполадка в кэшировании, они узнали о ней еще до того как она на самом деле произошла.

• Длительно функционирующие процессы стоит оформить в виде daemon’ов.
• Используйте уведомления об исключительных ситуациях в совокупности с ведением логов, это необходимо для своевременного реагирования на них.
• Не делайте глупостей!

  - Масштаб проект несколько меняет понятие “глупость”.

  - Пытаться загрузить 3000 друзей в память одновременно может заставить сервер временно перестать функционировать, хотя когда друзей было всего 4 – этот механизм прекрасно работал.

• Большая часть производительности зависит не от использованного языка программирования, а от продуманной структуры приложения.
• Превратите свой сайт в открытый сервис с помощью создания API. Их API является ключом к успеху Twitter. Он позволяет пользователям создавать постоянно расширяющуюся экосистему вокруг Twitter, соревноваться с которой не так-то просто. Вы никогда не сможете сделать столько же работы, сколько смогут Ваши пользователи для Вас, Вам просто не хватит креативных идей. Так что не стесняйтесь, откройте свое приложение и сделайте интеграцию Вашего приложения с другими максимально простой и удобной!

Сегодня таки добил эту тему, наконец-то. Короче сейчас еще как всегда куча работы, поэтому пока память еще свежа выкидываю все, что нашел.

начнем с перла.


#!/usr/bin/perl -C

это из perldoc почитаете, позволяет автоматом кодировать СТД потоки.

в нем же есть прагма utf8 как минимум необходима для обозначения того, что скаляры, которые используются в коде утфные ( необходимо при этом сразу следить, чтоб и исходники были утфные). Да и вообще функционал предоставляет полезный:

upgrade, downgrade добавляет или убирает утфный флаг

encode, decode кодирование и декодирования текста

is_utf8 проверяет, является ли стринг – утфным.

далее от перла перемещаемся к DBI, а именно к DBD::mysql

вот такая у меня сейчас функция коннекта:


sub init_dbh{
my $self = shift;
my $dbh = DBI->connect_cached("DBI:mysql:database=conveyor;host=127.0.0.1", 'root', '',{AutoCommit => 1, RaiseError=> 1, PrintError =>0});
$dbh->{'mysql_auto_reconnect'} = 1;
$dbh->{'mysql_enable_utf8'} = 1;
$dbh->do('SET NAMES utf8');
return $dbh;
}


я думаю тут и так все без слов понятно. Если что, по ссылке выше все это мона почитать.

ну и наконец-то мускул.

в конфиге устанавливаем все кодировки, все возможные и невозможные:


[client]
default-character-set=utf8
[mysqld]
collation_server=utf8_unicode_ci
character_set_server=utf8
default-character-set=utf8


далее, заходим через консоль в бд., вводим “status”, все должно быть утф:

Server characterset: utf8
Db characterset: utf8
Client characterset: utf8
Conn. characterset: utf8


если в базе не утф, то
ALTER DATABASE database_name CHARACTER SET utf8;
каждую таблицу проверяем:
SHOW CREATE TABLE table_name;
если чарсет не утф, то
ALTER TABLE table_name CONVERT TO CHARACTER SET utf8;
кодировки могут быть индивидуально установленны у полей, их также необходимо менять
ALTER TABLE table_name MODIFY column_name VARCHAR(255) CHARACTER SET utf8;

по плану все, если чо забыл, то в коментах мне можно помочь исправить сею несправедливость.

Итого, что я слышал, и что мне понравилось на YAPC::Russia .

Профилирование перл кода. В принципе все модули, о которых рассказывалось – все хорошо документированы.

Devel::DProf

Devel::Profiler

Devel::DProfLB

(в принципе все они равносильны, необходимо поочередно выбирать, кого лучше юзать)

Devel::DProfPP – необходим для парсинга исходящих данных от профайлера

Devel::SmallProf

Devel::FastProf

Devel::NYTProf

(перл инлайн профайлеры)

DBI::Profile

DBIx::Profile

(профайлинг DBI)

Дальше буду тестить, вводить в свои проэкты. О результата буду рассказывать позже.

про ПОЕ был доклад хороший, быренько пробежались по всем аспектам.

Для себя запомнил:

POE::XS::Queue::Array

Надо потестить, попробовать. Модуль работает с очередью задач.

Стандарты кодирования. И сразу ссылка автора.

http://www.reg.ru/coding_standards

По модулям:

Perl::Critic

Module::Starter::PBP – также из рекомендаций из «Perl Best Practices»

App::perlstyle

http://perldoc.perl.org/perlstyle.html – на перлдоке

http://perltidy.sourceforge.net/ – тулса для очистки “perltidy –pbp”

Другие о япси:

http://www.insight-it.ru/life/yapcrussia-2008-may-perl/

очередная попытка завести свой блог.

По большей части тут будут заметки для меня, чтоб не забыть.

не исключено, что кто-то будет сюда случайно попадать… не дай бог, что-то читать… не стесняйтесь… критику я люблю, конструктивная критика помогает развиваться.