Привет всем. Сегодня я поведаю о своей разработке для Rails 3 — MongodbLogger. Начнем по порядку.
Rails приложение по-умолчанию складывает логи запросов в папку logs. Сами по себе логи очень удобная штука — они помогают посмотреть какие запросы идут в ваше приложение, посмотреть trace ошибки и прочее. В них можно дописывать дополнительную информацию. Хотя файловый лог прост и эффективен, но у него есть определенные ограничения: при использовании множество веб-серверова, лог у каждого свой; нет простого доступа. Запись в РСУБД решает вопросы централизации и простого доступа логов, но сразу возникают другие проблемы: схема таблицы не настолько гибка, как может быть структура лога; запись может быть недостаточно быстра; чистка старых логов — задачи на Ваших плечах. И тут на помощь приходит MongoDB.
В своей книге Парадокс выбора («The Paradox of Choice» by Barry Schwartz) Барри Шварц приходит к интересному выводу относительно осуществления выбора человеком:
«Люди выбирают не на основе того, что важнее, а основываясь на том, что легче всего оценить.»
Здравый смысл подсказывает, что из всех вариантов вы должны выбрать тот, который наиболее важен для вас, хотя на самом деле люди обычно выбирают тот, который удобен для них, легок в понимании. Очень часто мы делаем это, потому что не хотим тратить время на исследования, разбираясь в вопросе для принятия обоснованного решения. Политики редко избираются на основе того, что большинство людей проводят исследования о их политических программах. Они избираются потому, что люди запомнили сообщение, которое политики распространили, и потому, что они слышали об этом политике раньше.
На конференции попасть получается не всегда, а умных людей послушать хочется. Решил собрать воедино скопившиеся ссылки на видеоматериалы. Надеюсь кому то пригодится.
Известные
Yet another Conference от Яндекс 2010 2011 — раз, два, три
С ростом популярности web-приложения его поддержка неизбежно начинает требовать всё больших и больших ресурсов. Первое время с нагрузкой можно (и, несомненно, нужно) бороться путём оптимизации алгоритмов и/или архитектуры самого приложения. Однако, что делать, если всё, что можно было оптимизировать, уже оптимизировано, а приложение всё равно не справляется с нагрузкой?
Также мы постараемся до конца года выложить доклады с HighLoad++ в Power Point.
Хорошего вам дня!
UPD. Уважаемые хабраюзеры! Мы хотим еще раз извиниться за невысокое качество видео, которое, тем не менее, решили выложить, т.к. знали, что темы HighLoad-a для вас крайне важны и интересны и наряду с негативным фидбеком получили очень много позитива, благодарностей и просьб продолжать выкладку докладов.
Завтра, 29 декабря, как мы уже обещали, на «Хабре» также будут выложены презентации всех докладов в PPT. В хорошем качестве ;)
Все началось с того, что я стал системным администратором у одного провинциального Интернет-провайдера. Помимо администрирования различного рода ресурсов, мне в присмотр достался один молодой, но бурно развивающийся ресурс. Ресурс представлял из себя классический LAMP проект. Сайт, на котором генераторами контента являлись обычные пользователи. * К слову, в то время я ничего не понимал в *nix системах, хоть и все сервера которые мне достались, были именно на нем, разбирался я во всем этом достаточно быстро.
Как обычно бывает с ресурсами, набирающими популярность, железки на которых все крутится, перестают справляться. Ресурс стоял на стареньком двухпроцессорном сервере, на котором крутились практически все сервисы для пользователей. В то время начальство не воспринимало ресурс как нечто стоящее вложений, поэтому, к моему сожалению (а позже – счастью), денег под новую железку мне не выделяли.
