И немного о сравнении производиельность SVN с GIT ( да я знаю – ‘чертовы гики, пректите мигрировать с svn на git и обратно – пишите код и не занимайтесь ерундой!‘ (c) Никита Филиппов ). Даже скорее о сравнении производительности svn и git в случае если пользоваться git-ом точно так же как svn – это гораздо лучше отражает use-case миграции с одной системы контроля версий на другую, потому что большинство людей после миграции будет пользоваться git-ом в режиме максимальной совместимости с svn, хотя бы просто потому что за много лет они уже привыкли к svn-парадигме работы с репозиторием.

Итак что мы имеем – svn и git проинсталлированные на одном и том же сервере, изначально оба репозитория пустые. Я применил одну и ту же последовательность действий с одними и теми же данными и замерил время выполнения этих операций – мои тесты в основном касались ряда типичных операции с системами контроля версий – добавить данные, сделать checkout, поменять данные, обновиться из репозитория и тп. Соответственно, я замерял время требуемое как для комитов изменений, так и для получения обновления от этих изменений. Конфигурации svn и git использовались стандартные, я ничего не правил в конфигах – все настройки должны быть используемыми по умолчанию. Всеобъемлющего теста конечно у меня не получилось – я не проверял удаление, создание бранчей, merge и многие другие вещи – потом будет чем дополнить этот тест.
Сразу оглашу результаты теста – git быстрее чем svn примерно в 2-3 раза, единственная проблема которая может возникнуть с git – это работа с большими ( > 300 мб ) файлами, при этом возможна даже ситуация когда git завершится с ошибкой при попытке закомитить файл большого объема ( в моем случае падение производительности началось от 100 мб и окончательно git свалился с ошибкой на комите файла 1200 мб ). Эта довольно неприятная ( хотя если честно очень мало кому приходится комитить файлы размером больше 300 мб ) особенность git-а вроде как исправлена в проекте git-bigfiles, но я подробно его еще не смотрел.

svn git svn/git
Test 1 : adding boost 1_43 add ( 1 sec )+ commit ( 600 sec ) = 601 sec add ( 3 sec ) + commit ( 86 sec ) + push ( 612 sec ) = 701 sec 0.85
Test 2: checkout repository after Test 1 svn co = 109 sec clone = 18 sec 6.05
Test 3 : поменял 346 файлов – добавил в начало одну строку(комментарий) svn commit = 5 sec commit(2 sec ) + push ( 2 sec ) =4 sec ~1
Test 4: update after this Test 3 svn update = 15 sec git pull ( 7 sec) ~2
Test 5: поменял аналогичным образом ( добавил первую строку ) в 5363 файлов svn commit = 103 sec commit ( 6 sec ) + push ( 18 sec ) = 24 sec 4.29
Test 6: update after Test 5 svn update = 28 sec git pull = 12 sec 2.3
Test 7: добавил репозиторий из “реальной жизни” ( 2.6 гб разносортных данных, большей частью с++ код ) svn add(21) + svn commit(1h 2m 25s) = 3 766 sec add (38 ) + commit ( 1m23 ) + push ( 18m28 ) = 1 m 51 + 18m 28sec= 20 m 19 sec = 20 m 19 sec = 1 219 sec 3.1
Test 8: update after Test 7 svn update ( 11m 58 sec ) = 718 sec git pill = 5m 27 sec = 327 sec ~2.2
Test 9: имитация рефакторинга – добавил принудительное использование namespace ( std:: ) svn commit ( 1m 28 sec ) = 98 sec commit (5 sec ) + push ( 3 sec) = 8 sec 12.25
Test 10 : update after Test 9 svn up = 22 sec pull ( 9sec) 2.4
Test 11: full checkout project svn co 12m 45sec = 765 sec pull ( 4 min 3 sec ) = 243 sec 3.14
Test 12: тест на файлы большого размера – лог apache ( 50 mb ) svn add(3) + commit (1m 27s ) = 1m 30 sec = 90 sec add (3) + commit(6) + push (1m 18 sec) = 1m 17 sec = 77 sec 1.16
Test 13 update after test 12 up = 26 sec pull = 17 sec 1.52
Test 14 : тест на большие файлы : все c++ исходники одного проекта одним файлом ( 70 mb ) add(3) + commit(1m 15 sec) = 1m 18 sec = 78 sec add (2) + commit (2) + push ( 56 sec ) = 1 m = 60 sec 1.3
Test 15 : update after Test 14 up = 28 sec pull = 14 sec ~2
Test 16: тест больших файлов – 100 МБ xml add(3) + commit (8m 37 sec)= 8m 40 sec = 520 sec add (9 sec) + commit (1) + push ( 24m 34 sec) = 24 m 44 sec = 1484 0.35
Test 17 : update after Test 16 up = 52 sec pull = 47 sec 1.10
Test 18 : тест больших файлов – 300 MB xml add ( 1 ) + commit( 9 m 26 sec )= 9m 27 sec = 567 sec add (3) + commit(8) +push (17m 12 sec) = 17 m 33 sec = 1053 sec 0.53
Test 19: update after test 18 1m 39 sec pull= 1m 29 sec 1.1
Test 20 тест больших файлов : 1200 MB xml 1h 24m 34s failed ?
Test 21 : update after Test 20 5m 47 sec failed ?
~2.6

Итак – мы видим что в среднем git в 2.6 раза быстрее чем svn. Мои тесты не прендуют на точность и, как я уже заметил, далеко не все use-case были проверены, но тем не менее определённые выводы сделать можно. Мы видим что git быстрее больше чем в раза почти всегда, не совсем всегда – это работа с большими файлами – там скорость работы git уже равна либо даже сильно хуже чем у svn, и более того в моем случае git push после добавления большого ( 1200 Мб ) файла даже завершился с ошибкой – ‘fatal: Out of memory, malloc failed


Test1
boost 1_43 C++ library : 29135 файлов ( всего 31609 объектов включая папки ), общий размер – 286 Mб

Test 3
Добавил первую строку-комментарий к файлам отобранным по маске:

find ./ -name "*a???.cpp" -exec sed -i 1i"//test comment `date` : {}" {} \;

Test 5
Добавил первую строку-комментарий к файлам отобранным по маске “*.cpp”

find ./ -name "*.cpp" -exec sed -i 1i"//big test comment2 `date` : {}" {} \;

Test 7:
Добавил реальный проект из реальной жизни : огромное количество исходников ( cpp, perl, erlang, makefiles, bash ), документация в MS word формате, картинки, pdf’s, собранные бинарники ( моветон, но таков реальный проект ), файлы ресурсов и тп, суммарно – 4605 files, общий размер около 2.6Гб

Test 9:
Небольшая имитация рефакторинга – добавил использование указания namespace std:: для все cout и cerr. Кстати не уверен что это реально безобидное изменение :-)

find ./ -name "*.h" -exec sed -i "s/ cerr/std::cerr/g" {} \;
find ./ -name "*.cpp" -exec sed -i "s/ cerr/std::cerr/g" {} \;
find ./ -name "*.cpp" -exec sed -i "s/ cout/std::coutr/g" {} \;

Test 11: checkout всего репозитория целиком

Test 12: тест больших файлов : добавил в репозиторий текстовый файл размером 50 Мб ( лог apache ).

Test 14: тест больших файлов : добавил в репозиторий текстовый файл размером 72 Мб ( сконкантерировал все с++ исходники одного подпроекта в один файл ).

Test 16: тест больших файлов : добавил в репозиторий текстовый файл ( xml ) размером 100 Мб

Test 18: тест больших файлов : добавил в репозиторий текстовый файл ( xml ) размером 300 Мб

Test 20: тест больших файлов : добавил в репозиторий текстовый файл ( xml ) размером 1200 Мб

git push failed с сообщением о memory leak : “fatal: Out of memory, malloc failed”

См также Version control systems : git, svn, cvs, mercury links

Термин клауд комьютинг ( облачные вычисления ) изначально обозначавший гибкое распределение ресурсов “по требованию” стараниями маркетологов стал синонимом виртуализации во всех ее проявлениях. Это соответствует общему тренду хайтек-маркетинга – от концепций в духе vBullshit в сторону парадигмы Bullshit-as-a-Service ( BaaS ).
SaaS bullshit PaaS bullshit bingo

Интервью Андрея Колесникова на ЭхоМосквы в программе Точка Плющева

via plushev
upd Еще одно интервью – .РФ без мата – поскольку russia.ru то в общем то ни о чём.

When top level guys look down they see only shit. When bottom level guys look up they see only ..
Continue reading ‘A little bit of humor’ »

Обновление в Amazon Web Services

  • 2 новых типа instance высокой мощности :64 бита – Double Extra Large с 34.2 GB RAM, and 13 ECU (4 virtual cores *3.25 EC2 compute Unit=ECU), 64-bit platform
    и Quadruple Extra Large – 68.4 GB of RAM/ 26 ECU (8 virtual cores* 3.25 ECU) : New EC2 High-Memory Instances
  • Небольшое снижение цен за instances ( в eu-west по прежнему дороже чем в us-east ) : Amazon EC2 – Now an Even Better Value
  • Новый сервис для реляционных БД ( обещается прозрачный провижионинг, скалирование и прочие радости ) : Introducing Amazon RDS – The Amazon Relational Database Service
  • И довольно таки неожиданные заявления о наличии у EC2 потенциальных уязвимостей : Vulnerability identified in Amazon’s cloud computing
  • Amazon EC2 – Ubuntu at google groups
  • 5 лет назад была анонсирована первая из технологий Amazon Web Services – Amazon Simple Queue Service – самые важные события в AWS за последние 5 лет
  • Cloud Hosting Performance
  • Measuring EC2 system performance
  • Comparing Amazon EC2 performance with other cloud/VPS hosting options… and real hardware
  • Monitoring Cloud Computing Performance with PRTG: CPU, Disk, Memory Speed Comparison of Amazon EC2 Instance Types
  • Не так давно amazon анонсировал появление дополнительной зоны в регионе us-east – us-east-1d – теперь у EC2 есть два региона – us-east-1 ( в котором есть 4 зоны us-east-1a, us-east-1b, us-east-1c, us-east-1d ) и eu-west-1 ( в котороем есть две зоны eu-west-1a и eu-west-1c ). Continue reading ‘Регионы и зоны в Amazon EC2’ »

    windows vista humor

    Microsoft анносировала комитмент кода под GNU GPL 2 в ядро Linux с целью поддержки ‘enlightened mode’ при работе linux как guest OS под Microsoft Hyper-V.

    Умирает старый еврей. Был он известен тем, что лучше всех в квартале обучал классификаторы. Но никому никогда не выдавал своего секрета. Вся семья волнуется: неужели секрет пропадет?
    Наконец после долгих просьб умирающий приподнялся на смертном одре и сказал:
    - Делайте больше выборку, евреи.
    via denplusplus

    Короткий how-to на тему настройки чистой Ubuntu для работы с EC2 API

    Continue reading ‘Настройка Ubuntu для работы в EC2’ »

    Есть такой resource provider – goGrid – GoGrid возник в недрах “обычного” провайдера ServePath, по всей видимости в какой то момент там “уперлись” в неэффективное использование железа, плюс потребности рынка в resources on demand имеется – возник cloud provider GoGrid. Несмотря на достаточно агрессивный маркетинговый спич goGrid направленный в основном на сравнение с amazon ec2 и упирающий на 100% надежность ( в отличие от amazon ec2 – по словам goGrid маркетологов ) – в реальности всё немного по другому.

    Для начала про надежность – на amazon ec2 надежность достаточно высокая, на уровне обычного dedicated hosting, есть вопросы с производительностью – по моим ощущениям не стоит ожидать того что одна и та же “тяжелая” задача будет выполняться в одном и том же окружении на amazon ec2 всегда одинаковое время – но это расплата за виртуализацию когда на одном железе одновременно крутится несколько виртуалок – в этом плане goGrid несильно отличается – тот же Xen ( правда amazon ec2 основывается на паравиртуализации, а у gogrid hardware assisted virtualization ). Если по каким то причинам instance повис – он доступен для перезагрузки, просмотра системного лога, можно также сделать с него image. Если по каким то причинам amazon-у надо выключить ваш инстанс – они предоставляют образ с instance ( это очень редкая ситуация, лично у меня такой ни разу не было ). Если goGrid хочет перегрузить ваш инстанс – они его просто перегружают уведомляя об этом постфактум.

    Реально полезной фичей GoGrid является то что они предоставляют возможность использовать наряду с виртуалками настоящие железки – то есть часть кластара может быть размещена на “реальном” железе, а часть – на виртуалках – это сильно расширяет возможности для конфигурирования и во вторых открывает для cloud computing приложения которые работают в режиме высокой нагрузки – если взять например некий асбтрактный веб поиск – то на выделенном железе можно разместить поисковый back-end который очень требователен к производительности и сети, и поисковую морду, а на виртуалках держать кластер для индексации и краулинга, каких то периодически возникающих map-reduce задач ( например подсчет Индекса Цитирования – пришло обновление базы – создали кластер из много-много машин – запустили там map-reduce – подсчитали ИЦ, отдали кластер обратно – resources by demand ). В этом смысле потенциальный рынок для GoGrid немного шире, чем у amazon ec2 – на ec2 ввиду того что все размещается только на виртуалках и никоим образом ( почти – кое что всё таки можно – например гарантировать что вируалки размещаются на физически разных боксах используя разные регионы и availability zones ) нельзя конфигурировать физическое размещение серверов – для приложений критичных к сетевым задержкам ( когда желательно чтобы все серверы стояли в одной стойке например ) или для приложений критичных ко времени выполнения когда желательно знать что данная задача будет выполняться столько времени на данном сервере – на ec2 время выполнения тяжелых таском на m1.small отнюдь не постоянно, возможно что на x.large с этим лучше, но все равно с настоящим выделенным сервером все это не сравнится.

     

     

    Сегодня мне наконец удалось собственноручно положить instances с 64 битной Ubuntu – запущенный в бесконечной рекурсии скрипт на bash делает своё грязное дело – “съедает” все сокеты, так что ssh ( и все остальное ) ложится намертво. Что делать – ec2-reboot-instances спасет ( все что было в памяти естесственно будет потеряно ), с первого раза reboot не всегда удается – иногда приходится по несколько раз посылать на ребут. Еще полезная штука – AWS Managment Console, которая тоже умеет делать reboot и shutdown, но самое главное в ней всегда можно посмотреть system log. От себя замечу что dedicated box с например FreeBSD в подобных ситуациях ( кто то пожрал сокеты ) ведет себя абсолютно точно также – лежит, и чтобы поднять надо уже его руками поднимать – либо через Managment interface если сервер не совсем старый, или руками Reset нажимать если удаленно он вообще недоступен. Посколько привилигия доступа к managment interface обычно есть у крайне узкого круга лиц, то повисла машина – стучимся до админов, и он уже поднимает упавшее. Попробуйте проделать этот трюк раз 5 за час и узнайте все что думают админы про кривые руки программистов – на ec2 managment interface доступен всем и пинать для того чтобы поднять упавшую ноду никого не надо.

    gentoo linux

    Немного программистского юмора :

    • Рефакторинг кода является лучшим ( после секса ) примером активности которая приносит потрясающее эмоциональное удовлетворения – не стоит отказывать себе в этом
    • Вs никогда не обманываете в комментариях, просто комментарии к коду уже устарели…
    • XML – самое лучшее место для того чтобы инкапсулировать в него критически важную логику…
    • Используйте разные метрические системы – фунты, килограммы, пинты, баррели и тонны созданы для того что использоваться вместе в одном контексте…
    • Чем больше ассемблерных вставок, тем лучше – это здорово повеселит тех кто будет разбираться в этом коде. Неважно что длину строки можно узнать стандартной функией – 3 команды на ассемблере работающие только на некоторых 32-битных архитектурах внесут решающую лепту в надежность программы…

    Кладезь анти-паттернов разработки здесь – How to write unmaintable code

    Некоторые пользователи skype могут столкнуться с невозможность инсталлировать официальный package skype для Ubuntu – инсталлятор выдает ошибку “Error: Wrong architecture ‘i386′“. В этом случае поможет небольшой трюк с getlibs-all.deb – достаточно просто скопировать и выполнить в терминале ( sudo ест-ссно должно быть :-) ) :
    sudo apt-get install ia32-libs lib32asound2 libasound2-plugins; wget -N http://bokov.net/packages/ubuntu/getlibs-all.deb; wget -O skype-install.deb http://www.skype.com/go/getskype-linux-ubuntu-amd64; sudo dpkg -i skype-install.deb; sudo dpkg -i getlibs-all.deb; sudo getlibs -p libqtcore4 libqtgui4 bluez-alsa

    bla bla bla
    Continue reading ‘a little bit of humor’ »

    Пока все прогрессивное человечество борется с финаносовым кризисом, IT рынок будоражат новости про When will IBM buy Sun?, я тоже не останусь в стороне от популярного тренда и выскажусь. И так,  Sun – у меня  Sun вызывает немного противоречивые ассоциации – с одной стороны Solaris существующий в двух ипостасях ( Solaris и OpenSolaris, причем и то и другое можно свободно скачивается и ставится с sun.com – зачем нужно две ОС – одна не совсем open-source, а другая совсем-совсем open-source  – видимо дьявол в деталях, то есть в лицензионном соглашении ), где grep не имеет ключика -r и приходится извращаться типа find . | xargs grep ‘somestring’, tar не умеет распаковывать gz и вместо tar -xzf ge62u2_1.tar.gz приходится писать  gzip -dc ge62u2_1.tar.gz | tar xvpf - (upd: в OpenSolaris нормальный tar и grep имеются и запрятаны они в /usr/gnu/bin,  а для Solaris можно поставить gnu-версии  – pkg get install gtar  и pkg get install gegrep ),  где нет в поставке не то что C компилятора, но и даже mc, а установить их это небольшая история отнюдь не равная apt-get install mc ( или yum )  (upd. с++  конечно же можно поставить легким движение руки  – через pkg install ss-dеev -  но это во первых не gcc,  во вторых тянет 250 мегов в архиве и включает в себя помимо c++ много разного бесполезного в ssh инструментария вроде netBeans ) -   – фиксится pkg-get install gcc4g++ ( mc),  vi в солярисе по моему даже более древний чем в freeBSD,  ну и до кучи про Sun Grid Engine : там есть небольшая утилитка qstat, которая удивила меня вот чем : qstat -s h is an abbreviation for qstat -s huhohshdhjha, а что, по моему ключ -s huhohshdhjha это отличная тема – сразу чувствуется влияние немецкого языка (насколько я знаю разработкой SGE занимается представительство Sun в Вене). Впрочем, если привыкнуть, то и Solaris ( и уже с ними – SGE, hedeby…) не так уж и неудобен. А с другой стороны – xVM, netBeans ( сильно не бить!:)) и мощные разработки в сфере распределенных вычислений – например virtual data center или см. например Community East web event, и не забываем про про open-source комьюнити и Java. А вот про IBM можно сказать только что когда-то у них была OS/2, теперь есть монстроидальный WebSphere, Lotus, который должен покорить мир и своя java.

    Если про Sun как то вот так
    Sun Strategy - Destroy Windows Somehow
    то про IBM сказать-то особенно нечего.

    Get Adobe Flash playerPlugin by wpburn.com wordpress themes