AWS как хранилище данных

По состоянию на март 2010 года в Amazon S3 хранится 102 миллиарда объектов, если принять за основу расчеты Is number of objects true indicator of Amazon S3 growth? – 18 миллиардов объектов соответствуют 10 Пт данных, то получаем что сейчас в S3 хранится около 50 Пт данных ( на март 2010 ). Почти наверняка это заниженная оценка, поскольку для хранения петабайт данных Amazon S3 предоставляются специальные условия – видимо есть спрос на хранение таких объемов данных в S3. Если же брать EC2, то только предоставление дискового пространства для запущенных instances требует как минимум 8 Пт ежедневно – см Amazon provisioning 7 petabytes of storage per day.

AWS как вычислительный ресурс

Согласно Amazon’s EC2 Generating 220M+ Annually ( данные на октябрь 2009 ) – 80 процентов серверов приходится на зоны US, в сумме около 40 000 физических серверов, примерно одна пятая инфраструктурных мощностей EC2 используются для нужд сервисов обслуживающих amazon.com. Распределение по типам инстансов :
amazon ec2 usage rates

Amazon Web Services по прежнему лидер рынка – см State of the cloud – 2010 August
-

И на “сладкое” – анатомия instance id и расчет количества ежедневно запущенных instance – Amazon EC2 usage estimates – около 50 тысяч инстансов в пределах одной геозоны в сутки ( данные на Oct, 2009 ).

:
amazon zone eu-west-1.

По горячим следам презентации в мейл.ру хочется немного дополнить мои ответы на вопросы из зала :
Q : Какова производительность EC2 instance ( по сравнению с реальным железом )?

A: Картинка ниже должна ответить на данный вопрос ( не забываем что в линейке EC2 есть и гораздо более производиельные instance чем m1.medium ),  по теме произвоительности EC2 ( и других клауд провайдеров )  можно посмотреть эту небольшую подборку ссылок – Cloud providers perfomance tests and monitoring.

Q: Трафик с EC2 – сколько стоит входящий трафик и сколько исходящий? Насколько оправдано например будет вынести краулинг веба в EC2 ?
A: Как я и сказал – внешний входящий трафик бесплатный, исходящий наружу стоит некоторых денег – см EC2 pricing. Трафик внутри сети ( в пределах региона ) – бесплатный. Теперь о деталях – исходящий трафик бесплатный до 1 ноября 2010, после будет тарифицироваться по 10 центов за Гб – так что времени бесплатно скачать весь интернет осталось не так много :-) При цене в 10 центов за Гб скачать весь рунет ( по данным яндекса 140 тысяч Гб только текста ) будет стоит 14 000 USD, а если говорить о инкрементальном апдейте в 2 Тб ( что вполне близко к реальности ), то один стоимость трафика достаточно невысока – всего 200 USD. Внешний трафик ( наружу ) – один Гб в месяц – бесплатно, далее в зависимости от объёма цена колеблется от 8 до 15 центов за Гб. Другая приятная для анонимного краулинга особенность EC2 – действительно большой выбор ip адресов – имеется возможность размещения instance в достаточно широком диапазоне подсетей и более того в разных географических регионах.

Q : Как ведут себя instance EC2 в некоторых нештатных ситуациях ( например когда кончаются сокеты или память ), какие там установлены лимиты?
A: Для меня неясно насколько поведение ОС под Xen отличается от ее поведения на настоящем железе, особенно в крайних ситуациях. Очевидно что все настройки лимитов на guest-OS доступны для редактирования, но также очевидно что всё это никак не влияет на настройки host-OS. Официальная точка зрения инженеров Amazon состоит в том, что то все лимиты устанавливаются также как и под реальным железом ( root + ulimit ) и запуск OC под системой виртуализации не играет тут никакой роли. Из найденных пользователями фич можно посмотреть по этому поводу например Get around EC2 filesystem limits (sort of), а вообще подозреваю что поведение будет иметь фичи не столько связанные с тем что мы запускаем сервер под EC2/Xen, сколько зависеть от образа который мы запускаем.

Q: Поддерживается ли hibernate в EC2 ? ( можно ли поднять приложение, “прогреть” кэш и сохранить это состояние, а потом когда нужно быстро поднять сервер? )
A: Для начала каким образом можно было бы сделать Hibernate – для этого необходимо к instance примонтировать EBS устройство ( отформатировать его и тп ) и сделать туда hibernate выключив instance – shutdown в данном случае означает что мы потеряли данный instance навсегда, EBS хранилище при это естесственно остается существовать и его можно примонтировать к любому другому запущенному instance. Таким образом hibernate можно реализовать как например запуск нового instance такого же типа с автоматическим монтированием EBS с hibernate данными и восстановлением состояния системы из данных с этого EBS устройства. Насколько я могу судить эта фича достаточно востребована, но как я вижу, пока не реализована – см. EC2 Hibernate, Hibernating Ubuntu on EBS boot EC2 instances.

ps. Из остального – если хочется что-то cloud computing но на местной, российской площадке – посмотрите на Оверсан Скалакси.

На конференцию cloud-разработчиков и архитекторов CloudCamp приглашаются докладчики и спонсоры. CloudCamp – это сообщество клауд-энтузиастов-волонтеров которые организуют и проводят по всему миру технические конференции посвященные cloud computing и близким технологиям. Планируется проведение этого мероприятия и в Москве. Формат – выступления на клаудную и смешанную тематику, доклады участников и доклады спонсоров мероприятия. Так как докладчиков-не-спонсоров бывает намного больше чем отведенного времени, то список докладов выбирается путем голосования среди участников конференции, доклады спонсоров идут вне конкурса. Мероприятие является некоммерческим, спонсорское участвие требуется только на оплату авиабилетов и гостиницы для организатора со стороны cloudCamp ( Yosu Cadilla ) и помощи с помещением ( часто это проводится либо в конференц румах компаний спонсоров ), плюс кофе брейки и пицца для участников.

Со всеми вопросами можно обращаться ко мне ( bokov-aleksej dog yandex.ru , skype : alexey_bokov ) или в linkedin группу CloudCamp Russia Cloud Computing UN-conference.

То о чем так долго твердили большевики клауд евангелисты случилось – HPC на EC2 таки пришло ( см – New Amazon EC2 Instance Type – The Cluster Compute Instance ) в виде HVM виртуализации ( Xen/CentOS ) вместо паравиртуализации ( Xen/много_разных_ос ) используемой в EC2 сейчас. Ожидается что виртуалки запускаемые под HVM будут сильно быстрее, сеть обещают 10Гбит, что безусловно хорошо. Создавать HPC кластеры как обычно можно через API парой команд – создать имя кластера, и второй командой запихнуть в этот кластер столько то виртуалок :

$ ec2-create-placement-group bokov_super_cluster -s cluster
$ ec2-run-instances ami-2de43f55 --type cc1.4xlarge --placement-group bokov_super_cluster -n 8

ami-2de43f55 – это CentOS ( ничего другого пока нет – не поддерживают HVM ? ), 8 – сколько нодов в кластере,
cc1.4xlarge – тип ноды ( Quadruple Extra Large – 33.5 ECU (EC2 Compute Units), 23 GB of RAM, 1690 GB storage ).

HPC кластеры от EC2 базируются на самом мощном инстансе из линейки AWS который запускается под HVM, причем в случае с Cloud Compute cc1.4xlarge стоит дешевле ( 1.60 против 2.40 ) чем в случае простого, не HPC-кластерного, использования. Доступно все это пока только в одном регионе – us-east ( физический локайшн серверов, конечно же пользовать все это можно из любой точки мира ), постепенно думаю что расширят ее и на другие регионы. Как уже упоминалось из операционок доступна сейчас только CentOS, для других ОС Amazon предлагает делать образы самостоятельно, но имхо лучше подождать немного пока этого не сделают. И еще немного по поводу производительности -  как утверждается в New Amazon EC2 Instance Type – The Cluster Compute Instance народ из AWS сделал кластер из 880 HPC узлов с производительностью 41.82 MFlops (запускали High Performance Linpack запущенный на 880 инстансах Cluster Compute (7040 cores) – что пример равно 146 месту в top500 суперкомпьютеров.

Если совсем-совсем честно, то конечно же HVM это все равно Xen и всё равно виртуализация, что имеет свои явные плюсы в виде скорости _скалирования_ кластера, но и по сравнению с “просто железом” верхняя планка по производительности ( в пике? ) все равно будет ниже. Из HPC + cloud computing еще раз хочется отметить Penguin On Demand – это HPC кластеры on demand ( cloud computing!) из “настоящего” hardware, без виртуализации. Penguin-ы уповают на то что их cloud будет сильно быстрее в смысле общего времени выполнения задач. Подробно в POD я пока не копался – остаётся открытым вопрос про API ( свое ПО для управление кластерами Penguin-ов – SkyId ClusterWare + TaskMaster Suite + Integrated Managed Framework, API явно есть, не понятно как из своих приложений управлять кластером ) и про то насколько быстро кластер будет скалироваться – с одной стороны конечно Pay-As-You-Go, но тем не менее SLA не гарантируют и про динамическое изменение размеров кластера сказано что “can be rapidly scaled by Penguin so POD can grow its capacity as needed” ( POD = Penguin On Demand, по умолчанию в нем доступно 1280 ядер, видимо платить надо за все сразу? ), интересно а если надо уменьшить размер кластера ? Еще небольшое замечание – Penguin-On-Demand на сегодня также как и Amazon HPC работает с CentOS.

И немного о сравнении производиельность 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.
    microsoft contribute code to linux

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

    Get Adobe Flash playerPlugin by wpburn.com wordpress themes