Один из инженеров GitHub рассказал (http://shayfrendt.com/posts/upgrading-github-to-rails-3-with.../) об организации завершившейся неделю назад миграции инфраструктуры с устаревшего форка фреймворка Ruby on Rails 2.3 на более актуальную ветку Rails 3. Миграцией занимались 4 инженера в режиме полного рабочего дня в течение 6 месяцев. Кроме снятия огромного бремени по сопровождению уже официально не поддерживаемой кодовой базы, обросшей горой надстроек и патчей, переход на Rails 3 позволил добиться существенного снижения нагрузки на серверы.
<center><a href="https://github-images.s3.amazonaws.com/skitch/rails3-vs-rail... src="http://www.opennet.me/opennews/pics_base/0_1410849748.png" style="border-style: solid; border-color: #e9ead6; border-width: 15px;max-width:100%;" title="" border=0></a></center>
Миграция была проведена постепенно: на фрондэнд-серверах была обеспечена возможность одновременного применения Rails 2.3 и 3, что позволило отлаживать работу новой версии на небольшом срезе реального трафика, постепенно перенося нагрузку со старой конфигурации на новую.<center><a href="https://github-images.s3.amazonaws.com/skitch/rails3-request... src="http://www.opennet.me/opennews/pics_base/0_1410849698.png" style="border-style: solid; border-color: #e9ead6; border-width: 15px;max-width:100%;" title="" border=0></a></center>
URL: http://shayfrendt.com/posts/upgrading-github-to-rails-3-with.../
Новость: http://www.opennet.me/opennews/art.shtml?num=40597
Почему не 4?
а он уже был 6 месяцев назад? и был ли он тогда "готов для гитхаба"?
http://weblog.rubyonrails.org/2013/6/25/Rails-4-0-final/> June 25, 2013
ну норм, вот теперь им ещё 6 месяцев будет чем заняться)))
круто \m/
Да, нынче модно заменять рельсы прямо под поездом. Иногда, правда, случаются фэйлы, как в московском метро.
хм, а странно что нет подобных новостей с bitbucket.org, ведь они тоже сейчас уже на относительно свежей версии Django 1.6.5 сидят.
С Джангой это проще намного.
это почему?
У неё деприкейшен полисес похожи на энтерпрайсные, соответственно нет таких проблем с переходом на более свежие версии как у ROR.
> хм, а странно что нет подобных новостей с bitbucket.org,Потому что bitbucket мало кому вперся и о том что там творится - знают полтора избранных.
Если бы написали на C, сервера бы вообще простаивали.
ну да, потому что они бы всё ещё писали
А если бы написали на ассемблере, сервера сами бы начали вырабатывать и закачивать ток обратно в электросеть.
А если бы писали на Brainfuck?
!
> А если бы писали на Brainfuck?Тогда постепенно образовался бы искусственный интеллект, который захватил бы сервера под свое управление, объявил себя покемоном и дальше - ну вы поняли.
Ну,... если в клаву встроить генератор от нажатий, то можно даже обогреть Силиконовую долину,
хоть какая-то польза будет от кнопкодавов.
Первая картинка прокомментирована так:> For example, we found it important to monitor the amount of time
> spent per request in object garbage collection...
> Knowing immediately if a change you’ve deployed is affecting your
> users' experience is a good thing.То есть, он говорит так, будто эта картинка -- что-то хорошее. Но мне лично неочевидно это: вообще, когда мне приходится использовать языки с GC, я наоборот стремлюсь к тому, чтобы GC как можно реже бы использовался, в идеале не использовался бы вовсе. Ну, там, выделяя всё что можно на стеке, не выделяя вовсе, повторно используя выделенное -- есть масса способов. Но судя по картинке, после смены версии GC начал отжирать больше времени в процентном отношении. Что в этом хорошего?
Хорошего в этом может быть то, что абсолютное время, проводимое в гц могло не поменяться, т.е. запросы стали обслуживаться быстрее.
>> spent per request in object garbage collectionСначала себе создадим сложности, а потом будем их героически решать. Иначе неинтересно.
>>> spent per request in object garbage collection
> Сначала себе создадим сложности, а потом будем их героически решать. Иначе неинтересно.Да-да, мы знаем: надо на ассемблере писать. Никаких искусственных сложностей.
