Любопытная статья исследователей из университета “University of California Santa Barbara” PDF тут.

Исследователи перехватили контроль над ботнетом Torpig и ковыряли его 10 дней, пока владелцы не накатили обновление и не вернули управление себе. За это время стало понятно какого вида информацию он собирает, как он это делает, как защищается от перехвата управления и на какое поведение юзеров он рассчитан.

Авторы утверждают что Torpig это одно из самых продвинутых crimeware на сегодняшний день. У него самая лучшая программная архитектура, самые остроумные способы воровства данных, самая лучшая топология управления. Также Torpig наносит самый большой финансовый ущерб.
Оценка экономической эффективности $3-300 млн в год. Из упражнений спамеров, ботнеты похоже становятся серьёзным бизнесом.

Работает это всё следующим образом

Инсталяция

Взламываются популярные сайты и вставляется ссылка на специальный JavaScript. Браузер скачивает и выполняет вредоносный JavaScript, код в котором пытается залинковать свою dll в проводник (explorer.exe) используя известные уязвимости самого браузера, его плагинов или ActiveX объектов. Уязвимости перебираются по кругу пока одна из них не сработает. Дальше все операции выполняются как будто бы самим explorer.exe - вполне себе уважаемым процессом. Теперь загружается драйвер ядра, который подменяет оригинальный disk.sys на себя и затирает Master Boot Record (MBR)
Всё, шаг №1 выполнен - руткит Mebroot поставлен. Фокус тут в том, что после перезагрузки Mebroot выполняется самым первым, раньше чем загрузится OS и остается практически невидимым для антивирусного ПО.

Сам по себе Mebroot ничего плохого не делает, но это только платформа для других модулей которые и делают всяческие гадости. Итак, сразу после перезагрузки, каждые два часа Mebroot соединятеся с Mebroot C&C server и качает модули, например Torpig. Все соединения шифруются. Теперь и шаг №2 выполнен - Torpig установлен.

Torpig вставляет линкует свою dll в Service Control Manager (services.exe), проводник и 29 другиз популярных программ, например браузеры - IE, Firefox, Opera, FTP клиенты - CuteFTP, LeechFTP, e-mail клиенты - Thunderbird, Outlook, Eudora, мессенжеры - Skype, ICQ и такое прочее. Теперь Torpig может просматривать все данные которые эти программы манипулируют, выделять интересные куски, например логины с паролями. Каждые 20 минут Torpig закачивает всё что он там насобирал на сервер.

Топология управления

Тут интересное архитектурное решение, если адрес этого C&C сервера известен и более менее постоянен, то его легко можно отфильтровать тем самым нейтрализовав утечку данных. Исторически ботнеты это делают следующим образом - имя домена статично и не меняется, но очень часто меняются IP серверов куда замаплена DNS запись - это делает блокировку по IP не эффективной. Недостаток тут очевиден - статическое доменное имя. Mebroor и Torpig вместо этого генерируют доменные имена по специальному алгоритму, если домен заблокирован, не отвечает на запросы по ботнетовскому протоколу или не существует - генерируется следующее имя и так до победного конца.
Тут надо помнить, что регистрация домена стоит денег, но владельцам ботнета нет необходимости регистрировать все имена - достаточно удерживать контроль над хотя бы одним из доменов который сгенерируют боты. В этой силе кроется и слабость. Если алгоритм известен и предсказуем, нужно зарегистрировать следующий домен которому подчинится ботнет.

Именно так авторы статьи и перехватили управление. На 10 дней.

К чести оригинальных программистов ботнета следует заметить, что эти 10 дней не прошли даром. Они поменяли алгоритм генерации доменных имен, усложнили и внесли недетерменизм. Это сразу сделало перехват управления экономически не выгодным, например новая версия Conficker генерирует 50,000 доменных имен в день, если все их регистрировать это выливается в большие расходы - $91 - $182 млн.

Остроумные способы воровства данных

Тут старый добрый фишинг поднятый на новый уровень. В своём конфигурационном файле Torpig читает имена банковских сайтов. Если юзер посещает такой сайт, Torpig вставляет HTML форму прямо в страницу сайта. Это происходит прямо в DOM-e браузера. Определить это очень трудно - URL сайта верный, стили и картинки соблюдены, и даже SSL тут не спасёт. Все сертификаты верны. Пользователя просят якобы подтвердить свою личность введя номер карты, налоговый номер и прочее.

За 10 дней, Torpig наворовал 300ооо логинов с паролями, 1600 номеров кредитных карт и 8300 логинов в онлайн банкинг. Всего в забеге участвовало 180ооо инфицированных хостов.

Саму цетовую схему взял тут. Недостаток оригинального файла - это полный export всего подряд, а нужно всего только цвета поменять.

Объясняет, как latency коррелирует с прибылью, почему сайты вообще медленно грузятся в браузере и рассказывает как это можно исправить. Утверждает он следующие интересные вещи:

Влияние latency на доход

Google: +500 ms  -20% traffic
Yahoo: +400 ms  -5-9% full-page traffic
Amazon: +100 ms  -1% sales

На конференции Velocity 2009 докладчикам от  AOL, Google, Microsoft и Shopzilla задали вопрос “почему это важно - уделять внимание производительности?”

• Microsof (Bing): увеличение времени отклика на 2 секунды это -1,8% запрос/пользователь и -4,3% дохода с пользователя
• Google: увеличение времени отклика на 400 ms это -0,59% запрос/пользователь
• AOL: 25% падение количества page hits при удвоении времени отклика
• Shopzilla: Ускорение с 7секунд до 2х дало +25% page hits, +7-12%  дохода и 50% экономия на железе

Почему сайты медленно грузятся?

Согласно Souder-а причины могут быть следующие:

• Тормозит back-end
• Тормозит front-end
• Тормозит интернет

Steve говорит, что 80-90% всего времени тратится на front-end и соответсвенно оптимизировать надо как раз эту часть в первую очередь. И дешевле всего и эффект виднее.

Как исправить

Вот его 14 правил:

1. Делать меньше HTTP запросов
2. Использовать CDN
3. Не забыть про Expires
4. Использовать Gzip компрессию
5. Все стили на верх страницы
6. Все скрипты - вниз
7. Избегать CSS expressions
8. Выносить JS и CSS во внешние файлы
9. Уменьшать DNS lookups
10. Сжимать JS
11. Избегать redirect-ов
12. Выкинуть повторяющийся JS
13. Не забыть про ETags
14. Сделать AJAX контент cacheable

Сама презентация поясняет основные приёмы ускорения загрузки страниц:

• сначала грузим только то, что надо для отображения станицы, затем всё остальное
• 6 способов загрузить JS и чем они отличаются
  XHR Eval, XHR Injection, JS in Iframe, JS DOM Element, JS Defer, document.write Script Tag
• как прятать от пользователя что мы ещё не все загрузили (индикатор загрузки в браузерах)
• несколько неблокирующих способов грузить JS
• способы вызова/инициализации JS со страницы, он называет это “coupling techniques”
  hardcoded callback, window onload, timer, degrading script tags, script onload
• какие домены лишние, а какие наоборот надо добавить в round-robin DNS
• почему для статики HTTP 1.0 лучше чем HTTP 1.1
• фокусы с flush() на разных языках
• эффективные и не эффективные CSS

Область практической применимости очевидна и огромна. “Deployed Software” это коммерческий софт. Утверждается, что лучше всего работает в кластерах, уязвимости обнаруженные на одном из хостов, автоматически накатываются на все остальные.

Идея такова:
это самое “Deployed Software” постоянно мониторится на подозрительную активность, например переполнение буферов, подозрительные передачи управления и прочее некорректное поведение. Это само по себе не новость, обычно после обнаружения такой активности приложение прерывается, при повторении - блокируется.

Тут на самом деле две проблемы:

• Если система high availability - ни о каком прерывании или блокировках не может быть и речи.
• Скорость латания дыр в коммерческом софте не велика - буквально через месяц программисты выпускают патч.

Новость тут в том, что ClearView, так называется система, обещает чинить баги и устранять уязвимости в реальном времени без рестартов и человеческого вмешательства.

ClearView сначала собирает статистику поведения во время нормального выполнения, они называют это “инвариантами выполнения”, затем отслеживает активность, при обнаружении подозрений автоматически патчит бинарный код пытаясь восстановить “инварианты выполнения”. Умеет сама тестировать различные варианты исправлений, накатывать и откатывать заплатки. Т.е. фактически пытаться держать систему в устойчивом состоянии, фильтруя input или блокируя и исправляя код.

P.S.
Ещё два шага и программы будут писать сами себя.

В июле этого года Google запустил like/unlike в Google Reader. Человек читает статью - она ему интересна - человек отмечает ее как “понравилось”.

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

Это полезно, но не очень интересно, намного интереснее применить эту собранную гуглом статистику в своих целях. Например можно фильтровать статьи в RSS потоках по количеству проголосовавших и читать только самое интересное. Можно смотреть на свой собственный RSS и видеть что читателям интересно, а что нет. А можно смотреть на RSS конкурентов и снова видеть что народу нравится.

Этакий digg или stumbleupon в миниатюре и совершенно бесплатно.
Ну а теперь как это сделать

Здесь и далее я буду использовать термин RSS как собирательный образ для всех синдикативных протоколов.

Широко известный факт, что Google Reader отдает нормализованные, агрегированные им RSS потоки. Надо только сформировать правильно URL:

http://www.google.com/reader/public/atom/feed/<url encoded feed URL>

Например для http://www.engadget.com/rss.xml это выглядит как

http://www.google.com/reader/public/atom/feed/http%3A%2F%2Fwww.engadget.com%2Frss.xml

Заглянув в source агрегированного Google Reader RSS/Atom потока видим такие теги

<gr:likingUser>00319180390340199299</gr:likingUser>
<gr:likingUser>09803098588727110477</gr:likingUser>
<gr:likingUser>09419458535147286956</gr:likingUser>
<gr:likingUser>01041706060102840430</gr:likingUser>
<gr:likingUser>16152963933826181588</gr:likingUser>
<gr:likingUser>02215958792577066354</gr:likingUser>

Это ID юзеров которые отметили статью как “понравилось”. Можно даже воспользоваться Social Graph API и посмотреть кто же эти люди такие. Или можно посмотреть что эти люди расшарили. Что бы понять как это работает смотрите src линков.

Так как все эти <gr:likingUser> теги видны всем без авторизации то можно автоматически отфильтровывать статьи с низким порогом “понравилось”. Можно вычислять точно количество “понравилось” и делать далеко идущие выводы.

Прямо в RSS потоке Google Reader отдает не более 100 user ID. Но если нужно знать точное число можно сконструировать URL вида

http://www.google.com/reader/api/0/item/likers?i=<gr:original-id>&output=<json|xml>

и пересчитать их всех. Например: JSON, XML

Хорошо работает для популярных, англоязычных RSS. Чем меньше аудитория тем разумеется хуже работает crowd-sourcing.

Трудно сказать зачем они это затеяли, может потому, что они всегда так делают, но вероятнее всего Microsoft продолжает строить свой software stack для Azure. Velocity = memcached, Dryad = Hadoop + Hive/Pig и т.д.

Но интересно не это, интересна архитектура проекта - наворотили знатно. Velocity умеет всё, умеет как memcached быть простым key-value со стандартным алгоритмом consistent caching и LRU вытеснением - так MS позиционирует Velocity для Web. А может быть сложным кешем с репликацией и гарантированной availability, со сложным routing, с transparent in-process cache с автоматическим обновлением локальных даных, умеет уведомления о изменеии состояния данных, умеет тэги и т.д. такое Velocity MS готовит для enterprise.

В общем, всё о чём можно только мечтать - Velocity умеет. На довесок - REST API, несколько видов упраления памятью, несколько видов блокировок (sic!), кворумы в репликации, failover, горячее добавлеие новых узлов.

Я просто терясь в догадках, зачем кешу всё это. Тут не хватает только disk persistence что бы построить non-sql DB который заткнёт за пояс всё что есть на сегодняшний день.

Замечательная PowerPoint презентация об архитектуре проекта - Project “Velocity”: Under the hood
И статья в MSDN http://msdn.microsoft.com/en-ca/library/cc645013.aspx

Самый распространенный пример - измерение времени отклика сервера на запрос. Допустим у нас всё есть:
- сервер для каждого запроса вычисляет execution time, складывает в счётчик
- сервер умеет отдавать значение счётчика по внешнему запросу
- есть monitoring сервер который собирает значения каждый poll interval, хранит, агрегирует и рисует графики

Решение в лоб - измерять мгновенное значение счётчика - особого смысла не имеет, при poll interval в одну или пять минут, мы получим мгновенное значение производительности системы измеренное по последнему запросу. Если все 5 минут до этого исполнялись запросы по 2секунды или больше, а последний был легкий на 20ms мы увидим только 20ms. Или наоборот.

Стандартное решение - скользящее среднее по последним N запросам. Решение работает замечательно, пока N запросов выполняются за время меньшее poll interval. Если нагрузка падает, получается вот такое вот:

Между полночью и 4-мя часами утра либо не было запросов вовсе, либо было меньше N. Значение скользящего среднего не менялось и создаётся обманчивое впечатление, что сервер обрабатывал все запросы за 6ms.

Ниже, тот же счётчик, только с другого сервера где скользящее среднее было модифицировано.

Картина видна гораздо лучше. Видно где были запросы, а где не было.

Модификация довольно простая. Кроме параметра N - размера окна для скользящего среднего. Вводится ещё один параметр - T, время забывания (expiration time), все значения в окне, старше T не учитываются при подсчёте среднего.

Выбор T (ms) для данного значения poll interval (ms) - это другая интересная проблема.
Если T << poll interval, (много меньше) будут потерянные значения
Если T >> poll interval, (много больше) будет график #1
В первом приближении, можно принять T = 2 * poll interval

Жили были item-ы и было у них sequential numeric id.

То, что оно sequential - это тяжелое наследие царского режима, потом пришли большевики, но ничего сделать было уже нельзя.

#0

И вот, при Николае-батюшке, было это autoincrement поле в MS SQL, item-ы получали id при вставке и никто горя не знал. Очевидно для того, что бы узнать это id на клиенте надо вставлять item-ы один за другим.

#1

Нагрузка возросла - власть поменялась, хостов баз данных стало больше одного, генерацию вынесли в отдельную таблицу. Простой инкремент. Продолжали вставлять один за другим.

#2

Нагрузка возросла - сделали вставку item-ов сразу пачками, а генерацию соответсвенно тоже поменяли, что бы генерировать сразу на всю пачку за один запрос. Стандартная hi-lo процедура (см ниже). Скажем, если вставляется 10 записей - один запрос на генерацию 10 ids.

#3

Нагрузка возросла - сделали пре-генерацию id наперёд блоками и кеширование этого блока на клиенте. Скажем, если вставляется 10 записей - один запрос на генерацию 1000 ids. 10 используются сразу, а 990 ждут следующего раза.

При порядка 700 витках (threads), которые всё время пишут в базу, эффект поразительный.

А вот если бы сесть и подумать, можно было бы сразу с последнего пункта начать…

hi-lo cхема выглядит так:

Таблица в БД

CREATE TABLE IDTable(
TableName varchar(255) NOT NULL,
NextID bigint NOT NULL,
CONSTRAINT IDTable1_PK PRIMARY KEY CLUSTERED( TableName ASC)

SQL запрос на генерацию примерно так

DECLARE @LocalTempTable  table(id int)
DECLARE @NEXTID INT
DECLARE @CNT INT

BEGIN TRAN
SELECT @NEXTID = (SELECT NextID FROM IDTable WITH (UPDLOCK) WHERE TableName = @@TABLENAME)
SET @CNT = 0
WHILE(@CNT < @@COUNT)
BEGIN
INSERT INTO @LocalTempTable(id) VALUES(@NEXTID + @CNT)
SET @CNT = @CNT + 1
END
UPDATE IDTable WITH (UPDLOCK) SET NextID = @NEXTID+@CNT WHERE TableName = @@TABLENAME
COMMIT
SELECT id FROM @LocalTempTable

Где TABLENAME это имя последовательности, а COUNT это размер пачки.

Самый интересный фокус тут это SELECT … WITH (UPDLOCK). Клиенты делают запросы указывая размер пачки, а потом либо тратят ее всё как в случае #2 либо кешируют часть про запас, как в случае #3.

Некоторые размер пачки хранят прямо в таблице, отсюда и название. У этого подхода есть одно достоинство - можно централизованно управлять сколько ID создать. Но это же одновременно и недостаток - часто нужно здесь создать1000 штук, а тут только 10.

Вот тут есть не плохой обзор доступных способов получения ID

Обычные распределённые системы, RDBMS и J2EE контейнеры, целостность ставят во главу угла. Все эти фокусы с блокировками и распределенными транзакциями даются дорогой ценой. Эта цену большие распределенные системы платить не готовы, им нужно прежде всего availability. Поэтому Google, Amazon и некоторые другие крупные компании построили свои собственные инфраструктуры.

Werner Vogels, Amazon VP & CTO, популярно объясняет почему двух фазный коммит это плохой выбор если нужно строить scalable систему. Он ещё, ведет блог All things Distribtued для тех кому интересно.

Для того что бы система расширялась нужны асинхронные, stateless сервисы, а целостность приходится компенсировать сложными согласованиями-компенсациями в случае ошибок. Ну и конечно, модель данных оказывает существенное влияние на производительность. Чем проще - тем быстрее. Тут можно вспомнить про Dynamo от Amazon и MapReduce/BigTables от Google.

CAP Theorem-а утверждает, что система может удовлетворять не более двум требованиям из трех: целостность (consistency), доступность (availability) и терпимость к разделению (partition tolerance).

Где:
целостность (consistency) - гарантирует, что все клиенты всегда прочтут одинаковые данные, в не зависимости к какому узлу в кластере они обратились. Операция записи атомарная для всех узлов.

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

терпимость к разделению (partition tolerance) - гарантирует, что система остается работоспособной даже если авария сети приведет к образованию двух или более под-кластеров.

У этой теореме существует формальное доказательство. Работа 2002 года, ссылается на публикации конца 80-х начала 90-х.

Processor - 2 quad-core Intel Xeon 2.5GHz CPUs
Memory - 8 GB ECC RAM
Storage - 4×1 TB SATA disks
Network - Gigabit Ethernet

Это конфигурация Hadoop-узла в 4000-ном кластере на сентябрь 2008 года. Характеристики этого самого “сommodity hardware” конечно меняются со временем, но картина становится более-менее понятной.

Что бы примерно прикинуть сколько это стоит - вот голые факты - мы в Viigo за один такой хост платим $1132 USD в месяц. Fully managed hosting @ RackSpace. Free incoming traffic. Годовой контракт. Конечно, если бы мы эти хосты там арендовали сотнями, то цена пошла бы вниз.

“Commodity” не означает “самое дешевое”, дешевые хосты зачастую собраны из самых дешевых комплектующих, которые выходят из строя чаще чем более дорогие (но всё равно “сommodity” класса) детали. Если кластер состоит из десятков, сотен или тысяч машин, дешевые комплектующие выходят боком. Более частые поломки - выше затраты на обслуживание. С другой стороны, машины класса “база данных”, то же не самый лучший выбор - отношение цена/производительность у них так себе. И даже тот факт, что их надо будет меньше что бы построить кластер с заданной производительностью, компенсируется тем, что выход из строя одного такого хоста окажет больший эффект на всю систему в целом.

Рекомендую.

News of Jackson’s death spread quickly online, causing many websites to experience technical difficulties under the unanticipated swell of users. Google announced technical difficulties after a sudden swell in searches for “Michael Jackson” led the company to believe it was under attack from hackers, while social networking site Twitter reported a crash after record numbers of users used the site to spread the news of Jackson’s death.[175] Wikipedia experienced technical difficulties, and crashed at 3:15 PDT reportedly due to excessive edits and user overload.[167]

wiki

Я тоже сначала думал что нас в Viigo атакуют. Трафик обычных запросов прыгнул на 15% в течении 10-20 минут. Трафик запросов к рекламным банерам - на 40%. Целый час потратил, что бы понять кто все эти люди и откуда они взялись. Мысль про Джексона приходила в голову, но я ее отмёл как несостоятельную.

Если бы мне кто-то сказал, о таком несколько дней назад, я бы не поверил…

«Вы — руководитель проекта, который начинается с завтрашнего дня и заканчивается ровно через год. Все планы утверждены, команда подобрана, роли определены. И вдруг… Становятся известны результаты проведенного маркетингового исследования, которые говорят о том, что конкурирующая компания планирует выпуск такого же продукта с той же функциональностью, но месяцем раньше. Ваш топ-менеджмент настаивает на завершении проекта тремя месяцами раньше.»
Из ограничений: нельзя уменьшать функциональность и качество, увеличивать объём ресурсов и стоимость.

Что должно сразу приходить в голову хорошему руководителю проекта?
Ему должны сразу приходить идеи и идеи во множестве.
Например

В конечном счёте всё равно либо придётся вносить изменения в функциональность (не обязательно в сторону ухудшения, но однозначно в сторону уменьшения трудоёмкости), либо находить «из воздуха» дополнительные ресурсы (не те, за которые платит компания): увеличение рабочего дня на энтузиазме (что плохо), привлечь десяток студентов-программистов на практику, организовать юзабилити-конкурс на лучшее решение сложной задачи и т. п. Так или иначе, за эти ресурсы просто заплатят другие: сотрудники, студенты, участники конкурса.

Или вот

1) вторым быть проще (не помню, где читал)
2) вы не уточняете, увеличивать стоимость чего нельзя. если речь идет только о разработке, то можно увеличить маркетинговый бюджет
3) есть утопические варианты вроде саботажа =)
4) группировка функциональности и запуск «облегченной» версси продукта за 6 месяцев, и выпуск полной за 12.

Отсюда

Intro session - Todd Lipcon, Cloudera
Voldemort - Jay Kreps, Linkedin
Cassandra - Avinash Lakshman, Facebook
Dynomite - Cliff Moon, Powerset
HBase - Ryan Rawson, Stumbleupon
Hypertable - Doug Judd, Zvents
CouchDB - Chris Anderson, couch.io
VPork - Jon Travis, Springsource
MongoDb - Dwight Merriman, 10gen
Infinite Scalability - Jonas S Karlsson, Google

Начинают появляться слайды и видео докладов. Кому интересно - могут пройти в закрома. Хорошее место Silicon Valley, всё самое интересное происходит там. В Торонто какие-то убогие сборища в последнее время происходят только. Вот Microsoft рассказывает про OpenSource. Молодой человек на главной странице, очевидно, олицетворяет target группу.

Ссылается на работы Lamport-а 1978 года, это тот самый кто придумал такие алгоритмы для distributed computing как Vector clock и Paxos. Довольно странно читать научные работы 30-ти летней давности и отчеты о самых свежих, bleeding-edge, программных разработках, которые эти самые работы используют. То ли програмная индустрия безнадежно отстаёт от учёной мысли, то ли учёная мысль вырвалась вперед.

Вот и Last.fm присматривает key-value storage для себя
http://www.metabrew.com/article/anti-rdbms-a-list-of-distributed-key-value-stores/
пишет Richard Jones, бывший Last.fm CTO. Коментарии к посту тоже интересны.

The law of big numbers insures that all probabilities becomes certanties.

Очень удобно, никаких дополнительных программ, только браузер. Перед инсталляцией нужно не забыть поставить PHP development module

apt-get install php5-dev

А потом обернуть нужный код в

xhprof_enable();

<some code is here>

$xhprof_data = xhprof_disable();

и готово.

Я для удобства обернул вообще все вызовы, и отдавал ссылку на страницу с собранной статистикой прямо в HTTP header. Выглядело вот так

// start profiling
xhprof_enable();

<some code is here>

// stop profiler
$xhprof_data = xhprof_disable();
include_once $XHPROF_ROOT . "/root/xhprof/xhprof-0.9.1/xhprof_lib/utils/xhprof_lib.php";
include_once $XHPROF_ROOT . "/root/xhprof/xhprof-0.9.1/xhprof_lib/utils/xhprof_runs.php";
$xhprof_runs = new XHProfRuns_Default();
$run_id = $xhprof_runs->save_run($xhprof_data, "xhprof_foo");
header("x-company-name-profile: http://xhprof.company-name.com/index.php?run=$run_id&amp;source=xhprof_foo");

xhprof.company-name.com прописал в hosts на своём компьютере. А на сервере добавил в конфигурацию Apache виртуальный хост

<VirtualHost *:80>
    ServerName xhprof.company-name.com
    DocumentRoot /root/xhprof/xhprof-0.9.1/hprof_html
    <Directory /root/xhprof/xhprof-0.9.1/hprof_html>
        AllowOverride All
    </Directory>
</VirtualHost>

Любопытно конечно сравнить с другим профайлером - XDebug

Если я правильно понимаю результаты с официальной страницы Kestrel даёт  227.5 транзакций в секунду на 2.5GHz 2008 model Macbook Pro.

В то время как ActiveMQ даёт 2000 транзакций в секунду на более медленном Intel Celeron 2.4 GHz.

И я даже не буду вдаваться в размеры самих сообщений, потому что сравнение будет ещё больше в пользу ActiveMQ.

И какой смысл в существовании Kestrel?

“…One of the most important changes they introduced to improve performance in the last nine months is moving from a Ruby messaging middleware to a custom build JVM-based messaging middleware written in Scala.”

говорит Evan Weave

А вот и оригинальная презентация

Плохое решение

Multipart/mixed MIME messages.

Так как HTTP протокол полон приятных сюрпризов, то есть ещё один способ втиснуть несколько request-ов в один, и соотвественно несколько respons-ов тоже, в один. Всё, что надо сделать - это указать “Content-Type: multipart/mixed”. А затем аккуратно перечислить все что надо. Разделительные символы прилагаются.
Вот пример

POST /batch-proxy HTTP/1.1
Host: example.org
Content-Type: multipart/mixed; boundary=batch

-batch
Batch-Operation: POST /my/resource1
Host: example.org
Content-Type: application/xml
<?xml version="1.0″?>
<entry xmlns="...">...</entry>

-batch
Batch-Operation: DELETE /my/resource2
Host: example.org
If-Match: "ABC123XYZ"

Выглядит замечательно, не так ли? Снимается проблема ~37% overhead в трафике, так как можно текст передавать как текст, а двоичные данные как двоичные данные. Правда на этом достоинства и кончаются. А проблемы всё теже самые, и не REST и security hole, и не прозрачность в общем, смотри выше по списку.

Кроме того, надо помнить, что MIME был создан для передачи 8-битного текста через 7-ми битный SMTP. Да в нём есть много интересного, но HTTP не является MIME совместимым протоколом. Есть тонкие различия вызванные в основном тем, что HTTP оптимизировался для передачи данных через двоичные соединения + обратная совместимость, а у MIME были совсем другие проблемы - вроде ограничения на максимальную длинну строки в e-mail. Всех желающих углубится в эти различия приглашаю ознакомится с секцией 19.4 RFC2616

На практике всё это означает, что клиенту и серверу нужно иметь качественный парсер MIME сообщений. Не просто продвинутый HTTP клиент, но и такой довольно экзотический парсер. По этому пути пошли ребята из Microsoft построив свою ADO.NET Data Services Framework а также в Google - batching для GData. Если вам такой путь приемлем - то для Java есть бесплатный mime4j, а для .NET есть комерческий Mime4Net.

Для тех, кто не хочет возится с MIME есть уж совсем плохое решение

Совсем плохое решение

XML/JSON mark-up
Берем и решаем задачу в лоб. Конвертируем всё в текст, для разметки используем XML или JSON.
Пример с JSON

POST /batch-proxy HTTP/1.1
Content-Type: application/json
Accept: application/json
X-HTTP-Method-Override: BATCH
[
 {
   "method" : "PUT",
   "url" :  "http://someserver.com/some/resource/url",
   "body" : "<request body goes here>",
   "If-Match" : "xxxxxxxxxxx"
 },
 {
   "method" : "GET",
   "url" : "http://someserver.com/some/resource/url2"
 },
]

Пример с XML

POST /batch-proxy HTTP/1.1
Content-Type: application/xml
Accept: application/xml
X-HTTP-Method-Override: BATCH
<?xml version='1.0'?>
 <batch xmlns:b='http://batch.someserver.com/schema'>
  <b:request verb='put' uri= http://someserver.com/some/resource/url'>
   <b:headers>
    <b:header name='Content-Type' value='text/xml; charset=UTF-8' />
    <b:header name='Content-Length' value='XXX' />
   </b:headers >
  <b:body>
    <![CDATA[ ... ]]>
  </b:body>
 </b:request>
 <b:request verb='get' uri='http://someserver.com/some/resource/url2'>
  <b:headers>
   <b:header name='Accept' value='text/xml' />
  </b:headers >
 </b:request>
</batch>

Очевидно, что XML намного более избыточен, но решение следует принимать на основании доступности того или другого парсера. Ответы сервера выглядят точно также.

Таким образом:

• Каждая операция состоит из “конверта”, который содержит HTTP заголовки и тело запроса
  • “method” and “url” обозначают соотвественно HTTP verb и URL операции
  • “body”, обязательное только для POST и PUT, содержит данные которые были бы переданы в стандартом теле HTTP request/response
• Произвольные HTTP заголовки тоже могут быть указаны как в request так и в response

А вот так например может выглядять response содержащий двоичные данные

200 OK
Content-Type: application/json; charset=UTF-8'
[
 {
  "code" : 200,
  "Content-type": "application/octet-stream",
  "Content-transfer-encoding": "base64",
  "body": "PGh0bWw+CiAgPGhlYWQ+CiAgPC9oZWFkPgogIDxib2R=="
 }
 {
  "code" : 200,
  "Content-type": "application/octet-stream",
  "Content-transfer-encoding": "base64",
  "body": "PGh0bWw+CiAgPGhlYWQ+CiAgPC9oZWFkPgogIDxib2R=="
 }
]

Что же плохого в этом решении? А все из списка приведенного в самом начале статьи. Всё что ни возьми - всё и плохо, и не REST. И тем не менее этот подход является самым простым для реализации. А простотой не стоит пренебрегать.

Есть несколько приёмов которые помогут предложить пристойные ответы на список недостатков. Можно

• запретить запросы ко внешним серверам
• запретить рекурсивные запросы к самому себе
• ограничить количество запросов в пакете
• ограничить общее время выполнения всего пакета и высылать на клиент HTTP error code 206 - Partial Content, в случае превышения
• прекращать выполнение всего пакета после первой же ошибки
• использовать протокол HTTP 1.0 при исполнении запросов в пакете
• декларативно отказаться от атомарности операций
• декларативно отказаться от оптимизации порядка или распаралеливания выполнения запросов
• принимать только операции типа GET

«Идеальное» решение

HTTP 1.1 протокол изначально поддерживает приём-передачу нескольких request-response. Для этого нужны persisted connections, pipelining и chunking см ниже.

Клиент открывает соединение, пишет туда request-ы, читает respons-ы. Кроме очевидных требований о поддержке этих persisted connections, pipelining и chunking на сервере и клиенте, есть ещё одна неприятность -  протокол требует, что бы клиент выслал заново все свои запросы сделанные в рамках этого pipelined соединения если оно прервётся в середине сеанса. А для того, что бы эту перепосылку можно было сделать без опаски, все запросы должны быть idempotent, т.е. только GET, HEAD, OPTIONS, PUT и DELETE. Это решение действительно очень хорошее с точки зрения REST - URI уникально адресуют ресурсы, HTTP headers означают правильные вещи и обрабатываются правильным образом, все транзитные сервера видят HTTP метод и могут, что-то правильное по этому поводу предпринять.

Однако, это «идеальное» решение существует главным образом на бумаге. Persisted connections не поддерживают мобильные устройства. Не все HTTP клиенты умеют читать chunked responses и использовать pipelining, привет AJAX рещениям. Да что chunked responses - для многих библиотек послать PUT запрос - уже проблема. Финальным аккордом тут является отсутствие поддержки метода POST в HTTP pipelining.

Раз «идеальное» решение не подходит, вернёмся к идее тунелирования HTTP протокола внутри HTTP.

Что такое persisted connections, pipelining и chunking:

Persisted connections

По умолчанию все соеднинения в HTTP 1.1 постоянные. Сервер не закрывает соединение сразу после обработки запроса тем самым позволяя клиенту использовать это соединение опять и опять. Если клиент желает получить несколько ресурсов с одного и тогоже сервера получается большой выигрыш в производительности. Вместо того, что бы открывать несколько соединений, все запросы пройдут по этому единственному каналу. Как клиент так и сервер могут оборвать этот канал с помощью HTTP header «Connection: close». Интересно, что запросы-ответы не обязаны быть строго последовательными, другими словами, клиент не обязан ждать ответа на первый запрос, а может сразу делать следующий и следующий, это становится возможным благодаря

Pipelining

Клиент посылает серию запросов, а сервер возвращает ответы в том порядке в котором были получены запросы. Часто бывает, что содержимое ответа генерируется динамически и сервер не знает точную длину которую следовало бы поместить в HTTP header Content-Length. Это нормально, в HTTP 1.1 в отличие от HTTP 1.0 заголовок Content-Length не является обязательным.

Так как Content-Length не передаётся, то нужен какой-то механизм, который бы сообщил клиенту, где кончается один response и начинается следующий. HTTP 1.1 решает эту проблему с помощью

Chunking

В случае динамических ресурсов, когда response не содержит Content-Length, он содержит Transfer-Encoding: chunked. Само же тело содержит куски с указаннием длины индивидуального куска. Кусок нулевой длины отмечает конец respons-а. Тут, пользуясь случаем, передаю привет IE6, который виснет, если ему этот последний кусок не передать.

Зачем я это всё рассказываю - в большинстве случаев, все эти технические детали скрыты в HTTP библиотеках или даже в абстракциях самого языка, но если мы уж собрались строить HTTP внутри HTTP то это надо понимать.

Что же делать? К сожалению существует только плохое решение и очень плохое.



продолжение см часть III “Плохие” решения

Если вы разрабатываете REST API, то рано или поздно к вам придут ваши клиенты с просьбой сделать пакетную обработку. Сделать так, что бы сервер приимал произвольный набор запросов одним пакетом и отправлял назад все результаты тоже одновременно. Это касается не только GET запросов, а любых методов - PUT, POST, DELETE и т.д. Ответы тоже будут разные, и будут содержать различные типы данных - например текст в различных encoding-ах и charset-ах, или двоичные данные в произвольном формате. В общем случае, скажут они, было бы полезно уметь обрабатывать пакеты любых HTTP запросов, в том числе запросы к внешним серверам которые необходимо исполнить последовательно с запросами к серверам из локальной сети.

С первого взгляда это кажется замечательной идеей. Клиент делает единственный POST запрос, получает единственный ответ и здорово экономит на сетевых задержках. На самом деле, здесь столько подводных камней, что вы сможете пожалеть что вообще с этим связались. Но выбора обычно нет. Что же тут плохого? Посмотрим сначала на

Религиозные проблемы REST

• Очевидно, что URI этого прокси одинаков для пакетов любых запросов - на вход поступауют произвольные запросы, на выходе мы имеет произвольные ресурсы. Значит этот URI перестаёт уникально идентифицировать ресурсы которые этот прокси обрабатывает
• Требуемая операция содержится не в HTTP verb, а в теле запроса. И несмотря на то, что POST request вроде как является non-idempotent & non-safe - внутри может быть что угодно - как набор совершенно безобидных GET запросов, так и действительно non-idempotent POST запросы, а может быть и вовсе некоторая смесь из них. Только клиент и сервет знают, что же там такое внутри. HTTP метод перестал быть понятным для всех транзитных серверов, таких как HTTP прокси и кеши
• В зависимости от набора запросов в пакете, сервер может создать новые ресурс(ы), обновить или удалить старые, или просто вернуть запрошенный ресурс. Некоторые из этих запросов могли завершиться с ошибкой, а другие были успешными. Передать эту информацию обратно клиенту в HTTP header нелегко, значит она будет втиснута в body ответа. Значит response тоже перестал быть прозрачным для всех транзитных серверов

Ну вот и всё, что бы из REST сделать SOAP больше ничего не нужно. На самом деле, стало даже хуже, чем если бы SOAP использовалось с самого начала - транзитные сервера теперь не знают у каких request/response HTTP headers значат то, что написанно в спецификации, а у каких уже ничего не значат.

Существуют также и

Прочие недостатки пакетирования запросов

Каким бы образом это решение не было бы сделано, результат будет являться тунелированием HTTP протокола внутри HTTP протокола. Задумайтесь на секунду, что это значит.

• Клиенты должны понимать все тонкости HTTP, и не только на этапе создания пакета запросов, но также они должны иметь обработчики ошибок, повторов и т.п. Они должны уметь обрабатывать все фокусы HTTP протокола - chunked и gzipped ответы. Перенаправления и HTTP headers
• Транзитные сервера перестанут кешировать, исчезнет поддержка ETag, If-Modified-Since и т.п. А умные load-balancer-ы перестанут load balance-ить
• Сломается “conversation pattern” если таковой будет подразумеваться конечным сервером.
• Огромная дыра в security, привет системным администраторам
• ~37% overhead в трафике из-за преобразования двоичных данных в текст, а также неизвестный CPU overhead на сервере и клиенте что бы эти данные кодировать-декодировать
• Поддержка атомарности выполнения всего набора запросов
• Определение порядка выполнения запросов в наборе

На самом деле, если заглянуть в спецификацию протокола HTTP 1.1 то можно увидеть, что существует «Идеальное» решение


продолжение см часть II “Идеальное” решение

В свете инструментации кода, мониторинга и сбора статистики не смог пройти мимо довольно интересных средств визуализации. Нельзя сказать, что такого раньше совсем не было, можно только сказать - что такого качество, даже за деньги, ещё поискать надо. Итак, о Google Chart API,  Google visualization API и о том, как сложно сделать простую вещь.

В декабре прошлого, 2007-го года, Google открыл доступ к своему Chart API. Идея очень простая - специально сконструированный URL возвращает картинку. Использование бесплатно, упоминают некий предел в 250ооо вызовов в день (~3 в секунду) после которого надо договариваться с гуглом отдельно.

Вот пример -

http://chart.apis.google.com/chart
?chxt=x,y,r,t
&cht=lc
&chd=s:cEAELFJHHHKUju9uuXUc
&chco=76A4FB
&chs=200x125

Типов графиков много, есть даже такие экзотические как этот

или этот - географические карты

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

Идеальная замена генерации графика внутри браузера средствами JavaScript. Нагрузку перенесли с сервера на клиент, и теперь ещё раз с клиента на сторонний (Google) сервер. Не ясно, насколько забота о нагрузке клиента актуальна сегодня, но в 2006-том, когда я последний раз этим занимался, было очень актуально.

В этом месте опытные товарищи должны были вспомнить о практическом ограничении длины URI в HTTP. Так как данные передаются прямо в URL - то запихнуть туда можно их вполне ограниченное количество. См предложенные способы кодирования входных данных.

Особенно опытные должны были также подумать о интернационализации. Тут всё плохо - поддержки нет, даже если вы не забудете сделать urlencode текста набранного не латинскими буквами.

Для публичного сайта, или стартапа какого - это просто клад. С коммерческим применением не всё ясно - можно ли себе позволить полагаться на внешний сервис? Как быть если сервис завтра исчезнет? Что если данные по которым это всё генерируется - private? и т.д.

С архитектурной точки зрения - сервис просто конфетка - яркий пример того, как сложно сделать простую вещь.

На этом дело, впрочем, не закончилось, и спустя полгода, весной 2008-го Google выпускает Google Visualization API. Теперь визуализация ещё сложнее - DHTML и flash. Правда и возможности шире. Вот пример - выглядит просто потрясающе

Графики эти не просто интерактивные, данные могут быть подгружены динамически - тут надо либо самому их отдавать особым образом (JSON, CSV) смотреть как именно, либо закачать в документ Google Spreadsheets. Там целое локальное API смотреть API вокруг этого наворочено.

Любопытно, что мелкий временной процесс и тут не просто отобразить, самый мелкий шаг этого графика - 1 час. Если со статическими графиками ещё можно было что-то придумать - то тут уже всё - никак нельзя.

Кроме такого выдающегося контрола, есть таблицы с сортировкой по клику, интерактивные столбики, пироги и географические карты смотреть что ещё есть . Везде JavaScript и Adobe Flash т.е. решения довольно тяжеловесные, что не умаляет конечно, простоту анализа отображенных данных.

Отличная демонстрация на живом бизнес примере - Google Analytics практически полностью построен на этих графиках.

Всё опять совершенно бесплатно. Никаких ограничений вроде 250ооо вызовов, только Google Term of Service

Меня не отпускает ощущение, что легко визуализировать только относительно статические данные, а с динамикой придётся либо основательно повозиться (JavaScript code) либо устроить себе агрегирующий код на сервере, с которого и кормить цифрами эти контролы.

Paul Tyma, автор, конечно немножко обманщик - он сам себе заказчик и волен менять условия как ему вздумается, но в остроте ума ему не отказать.

Paul Tyma два раза молодец - вместо того, что бы письма форвардить куда скажут - он только показывает их на своём сайте, крутит рекламу и в ус себе не дует.

На таких как Paul Tyma надо равняться!
Java guy, работал в Google, теперь трудится как CTO в компании которая делает известный обфускатор кода - Dotfuscator для .Net

Тут Paul в третий раз молодец - для Java разве продашь что-то? так, срам один, а на любителях Microsoft и заработать не грех.

Есть набор юнит тестов (nunit) на C#, которые на самом деле не юнит, а вовсе даже acceptance/functional tests. Есть также желание их запускать через web. Нету только возможности. В стандартной поставке nunit есть GUI runner, есть консольный runner, а вот ASPX runner-a нету.

Покопавшись в интернете я нашёл некий runit 2.4.2, даже вместе с исходниками. Как и следовало ожидать, работать он отказался. Сначала жаловался на несоответствие assembly-ей, потом, после пересборки из исходников стал имитировать работу, рисовать web интерфейс, но тесты всё равно не запускает. Говорит - TestFixtureSetUp exception и всё тут. Пол дня воскресенья убил, уже наверно мог своё написать… Сдался, выкинул runit, а проблема всё равно осталась.

Можно конечно в CruiseControl.NET подцепить, как проект без исходников и артефактов, но как-то оно там не к месту вроде…

В общем рынок поразительно пуст - для functional tests предлагаются монстры вроде QEngine, QTP и прочего. На другом конце спектра питоновский twill. А по-середине - ничего нет. А делов-то! REST API протестировать, куда уж проще.

Справедливости ради, стоит заметить, что с Java было бы ничуть не легче. Я поначалу нашёл замечательный RestClient (с исходниками) Обрадовался ужас как, думал - вот оно торжество разума над Microsoft, даже поучаствовал в коллективной разработке и дописал command line interface туда. Но по зрелому размышлению, если отринуть красивое GUI, это ничуть не лучше nunit тестов, а даже и хуже:

• программистам придётся писать на Java, в то время как основной проект на С#
• web gui все равно нет
• дебага нет, статической проверки ошибок нет, IDE нет
• добавил туда поддержку JSON (30 минут) код теста с assert-ами разросся, начал добавлять поддержку XML посмотрел на размер тестов, ужаснулся

В общем так и докатился до nunit тестов.

Как народ функциональное тестирование REST API организует - ума не приложу, похоже никак, или на коленке пишет что-то своё.

Выглядеть оно обещает вот так

Народ на форумах вроде не жалуется. Надо как руки дойдут попробовать. К сожалению AppManager уже всё равно куплен.

Вот 5-ти минутное среднее

а вот 30-ти минутное

Пользуйтесь, кому надо.

Украина : Политика Заголовки Полные новости
Бизнес Заголовки Полные новости
Киев Заголовки Полные новости
Мир Заголовки Полные новости
Россия Заголовки Полные новости
Мир о нас Заголовки Полные новости

Исходный код вот тут korrespondent.net.php и тут korrespondentnet-politics.php

Классик личного брэндинга Томас Гэд отмечает, что для эффективного самопродвижения личность должна развиваться в четырёх направлениях:

• функциональном - профессионализм
• менторском - способность учить, менять жизнь других людей
• социальном - контактность
• духовном - наличие более высоких целей, чем у обычного профессионала; ощущение своей миссии

Мне кажется эти мысли достойны того, что бы стать личными планами.

Любопытно также, что направления развития приведены в порядке возрастания сложности реализации. Первые цели три легко объяснимы и успешность их достижения будет прямо отражаться на благосостоянии, но мысль о “более высоких целях” достаточно туманна в разрезе IT.

Очевидно, что это не маркетинговые девизы и лозунги коорпораций, это что-то во что надо верить и чего планомерно добиваться. Но какая “особая миссия” может быть у “обычного профессионала”?
Впрочем, для некоторых этот вопрос уже решён.

смеха ради прошёл тест.  Полгода наверно не брал в руки шашек, а серьёзно так и никогда не брал. Если бы в гугль подсматривал наверно ещё бы круче сдал

Настоящие имена компаний изменены, но при желании узнаются. Сохраню пожалуй себе на случай если пропадёт статья.
Жизнь внутри пузыря

Чувствую себя маленькой шестеренкой в большом часовом организме Microsoft. Я уже и забыл как это. Никогда не испытывал никаких неприязненных чувств к MS, всегда считал да и продолжаю считать holy war-ные дела большими глупостями. Но разница с Java миром сильно режет глаз.

.Net это мир чистогана в империи MS. Шаг влево, шаг вправо, прыжок на месте карается тщетным чтением MSDN. Все что нужно среднестатистическому программисту уже сделано в core .NET, если это не сделано - значит это продаётся вот тут и тут за $1000+, если это не продаётся, значит это ересь.

Забавно видеть как такое заботливо прокопанное русло неотвратно приводит ко всё большему и большему vendor-binding. Это как карусель, на которой весело ехать, но тяжело соскочить.

Наверно если бы я был Microsoft я бы тоже себя так вёл, в конце концов мы тут не благотворительностью занимаемся, но не приятно чувствовать как тебя тянут куда-то.

P.S. А сам язык C# - хорош да.

The biggest drawback of contracting is its unpredictability. You never know when you will be working or for how long. While you work the money may be very good, but contracts can end without warning and it may take longer to find a new contract than you expected. If your technical skills are highly specialized, you may have to travel around the country to keep busy or you may have to settle in a particular area, like Silicon Valley, where demand for your skills is strong.
Another drawback to consulting is that over time you may burn out on being a gypsy and begin to feel that in spite of all your labor you never build anything lasting. As you move from project to project you learn and forget the details of dozens of systems, while you form and break relationships with dozens of coworkers. This can be exciting for the first few years, particularly when coupled with high earnings. But after a while, many people find it hard to keep on living this way.
Yet another challenge of contracting is that contractors are almost always hired to do the kinds work they have done before. If you are a C++ programmer, you’ll be offered C++ contracts. If you’re a DB2 specialist you’ll get jobs that involve DB2 databases.

When recruiters offer you ever increasing rates for doing the same kinds of work over and over again, it is hard to turn them down and hunt for the rarer contracts that let you learn new things that enhance your skills. Because of this, over time it can become increasingly difficult to get paid experience using new technology.
Eventually you may get stuck in a software ghetto, able to find work only in the handful of companies that still need people with your obsolescing skills.

Из этой вот книжки.

Bad command or the file name. Good try, though.

Поковырялся.

Сдал экзамен на BrainBench на мастера.
Фигня этот ваш PHP.

А книжка хорошая, кому PHP за неделю нужно - рекомендую. Как справочник не годится, для справочника лучше родной документации не нашёл ничего, но как обзор - хороша. Я искал что-то вроде PHP for Java Developers, не нашёл - видимо такого в природе нет.

По его мнению, если бы крупный фирмы собирались бы увольнять сотрудников, то ещё год назад они бы начали останавливать и откладывать проекты, перетасовывать людей внутри компании, искать им работу и соответственно сокращать заказы на внешних консалтеров. Он говорит, что такого он не наблюдает даже сейчас. Приводил в пример BMO, TD и BNS

Marcelo Carvalho, IT manager in San Francisco, считает что, купив Yahoo MS распишется в своем собсвенном бессилии строить большие интернет системы на OS Windows:

I do not know if anybody, including Marat Glazer, the Los Angeles software
developer who wrote the “Microsoft’s Yahoo Bid Genius” Talk Back letter, has
understood the layer beneath a Microsoft Corp. (MSFT)-Yahoo Inc. (YHOO) deal.

The potential deal is not the same as two petroleum companies merging by just
putting together their respective 6% and 22% market shares, changing the plastic
banners at the gas stations, and at most, deciding from whom to continue buying
drill bits.

It is an entirely different beast.

Microsoft runs on the Windows platform and it has proved inadequate to run big
Internet companies. There is not one big Internet company - and I mean “BIG”
like Google Inc. (GOOG), Yahoo, Amazon.com Inc. (AMZN), eBay Inc. (EBAY) and
such - that runs on Windows besides Microsoft. Its software platform has been a
disaster supporting its search engine, email and other free services.

On that front, Microsoft is being beaten by Google and Yahoo, both running on
open source software, which has shown to be much more efficient than Windows
servers. Of the top 500 supercomputers about 80% now run on Linux, including the
top two, which run on the SuSE Linux Enterprise Server.

Now here comes the big issue!
Will Microsoft move Yahoo to Windows?
If so, Microsoft will go broke because this is just what hasn’t worked well.

If the company does not, it will be signing the Windows platform obituary
because when people realize that Microsoft itself can run on Linux and does not
need Windows, they will follow through.

To my knowledge the simple fact of Microsoft bidding to buy Yahoo means that
Microsoft has thrown in the towel on its operating system, and that the Windows
platform is a thing of the past.

Вот эти две очень хороши

А вот Speed Up Your Site - оказалась откровенно слабой, как и MySQL Cookbook

Где только время найти это всё читать…

[client]
#password = your_password
port = 3306
socket = /tmp/mysql.sock

[server]
port=3306
socket=/tmp/mysql.sock
user=mysql
datadir=/var/db/mysql/
basedir=/usr/local
max_connections=3000
max_connect_errors=10
table_cache=2048
max_allowed_packet=1M
binlog_cache_size=1M
max_heap_table_size=64M
sort_buffer_size=64K
join_buffer_size=1M
thread_cache=16
thread_concurrency=16
thread_stack=196K
query_cache_size=0
ft_min_word_len=4
default_table_type=MYISAM
transaction_isolation=REPEATABLE-READ
tmp_table_size=64M
skip-locking
server-id=1
innodb_status_file=0
innodb_data_home_dir=/var/db/mysql/
innodb_data_file_path=ibdata1:100M:autoe
xtend
innodb_log_group_home_dir=/var/db/mysql/
innodb_buffer_pool_size=500M
innodb_additional_mem_pool_size=20M
innodb_log_file_size=900M
innodb_log_files_in_group=2
innodb_log_buffer_size=8M
innodb_flush_log_at_trx_commit=1
innodb_lock_wait_timeout=300
innodb_locks_unsafe_for_binlog=1
innodb_thread_concurrency=0

Попробовал - хорошая штука. Свою такую за $218 не написать конечно.
Ещё пробовал перловые innotop-1.6.0 и mytop-1.6
Как говорится - “… жалкое подобие левой руки”, зато бесплатно.

The good news is that SQL Relay’s performance here is comparable to PHP’s persistent connections. The reason is because SQL Relay has already established X number of Oracle (or MySQL) connections and strives to maintain that number continually. Then, your PHP app connects and disconnects from the SQL Relay server, which is lightweight.

Getting everything to run smoothly does take a fair bit of tuning and careful management of your SQL Relay connections. If you have leaky code that doesn’t disconnect properly, you can still flood your connection pool, no pun intended. Wish I had benchmarks but, the main thing is that SQL Relay offers similar performance and won’t flood your database with connections, both of which are good things.

Выглядит заменчиво, надо посмотреть - вероятно это дешевая альтернатива domain data separation при больших нагрузках

Про консалтерские компании разного размера:

Пропорции талантливых программистов у них вполне средние - 1 умный на 9 болванов, и хотя они нам и своим работникам говорят, что они очень беспокоятся об их профессиональном росте, но выражается это только в том, что они время от времени оплачивают технические курсы. Никакого реального менторинга у них нет, в частности потому что программистов гоняют с проекта на проект под разных начальников, так что никто никогда не может создать отношений больше чем на несколько месяцев…

и вот ещё

…живут по принципу волка ноги кормят. Они все время в поисках людей, берут без разбору и бросают на проект не глядя.

И чуть далее в коментариях про зарплаты которые они им платят:

…просто никто не рассуждает “хоть парень и не просит, но он гений, а потому дадим-ка ему по верхней границе”. Все рассуждают “парень сейчас зарабатывает Х, дадим ему Х+5 он будет рад”. А Х, между тем, прямо зависит от того как часто этот парень меняет работу или скандалит с начальством за зарплату (если сидит на одном месте).

Всё в точку.

География ru_java

География моих френдов так сказать.

alekro 

совершенно справедливо указал, что зря я не люблю встроенную имплементацию JAXP в 1.4 и,  что Xalan уже включен в J2SE 1.4, а я просто готовить его не умею. И действительно как оказалось, Xalan содержит классы для XPath, только они называются по другому и вообще всё немножко не так, как в JDOM, и работает медленее. Зато никаких новый jar-ов не надо.

minusOneExpression = new XPath("/game/principal/@noBid='true'", null, null, XPath.SELECT);
XObject containsLateBid = minusOneExpression.execute(new XPathContext(), doc.getFirstChild(), null);
containsLateBid.bool()

noBidExpression = XPath.newInstance("/game/principal/@noBid='true'");
Boolean result = (Boolean) noBidExpression.selectSingleNode(doc);
result.booleanValue()

• The only reason to introduce DB cluster cache is to make that cluster error prone, otherwise we should not care
• InfoQ managed to build new UI for JForum
• concept of lazy authorization:
  to create a user record for each new customer who enters website and put a special info into cookies. So next time same user shows up same DB record will be used. Whenever that half-registered users logs out a new “logged out” DB record is created making a pair. So that half-registered user can log in and log our switching between records inside that pair. When that user decides register himself the old “logged in” record is being populated with data.
• Magnolia as a content replication system
• DWR brings/makes accessible Java classes to the JS client
• Some cool AJAX engine - Prototype
• Floyd Marinescu wrote some allegedly nice books

I always tought of a servlet as the ‘beginning’ of my application so I saw a need for a framework like Struts. But if you think of the servlet container, as the ‘beginning’ of the application, the servlet becomes nothing more than an equivalent of a Struts Action class. ActionServlet does the same things the container does. It reads its configuration file and delegates processing to configured actions. The container reads its configuration file and delegates processing to configured servlets. If one thinks of a Servlet as an Action then everything seems redundant. The container is basically Struts minus some utility classes. interesting!

How many times have you looked at the Javadoc for a class and wondered whether it was thread-safe?^[8]
[8] If you’ve never wondered this, we admire your optimism.

1) Increase innodb_buffer_pool_size to 80% of memory of dedicated host. At least give it 265M. Here under is a snippet from mysql.ini

set-variable=innodb_buffer_pool_size=256M
set-variable=innodb_additional_mem_pool_size=20M

Without any further optimization it gives you 50% performance gain (against old setting of 32Mb)
2) Increase innodb_log_file_size to 25% of innodb_buffer_pool_size

set-variable=innodb_log_file_size=64M
set-variable=innodb_log_buffer_size=8M

Packaged with optimization above it can shave you up to additional 10%
3) Make sure that for read-only transactions your switched ON auto commit setting. And then switched it back for read-write tasks. Set read-only settings properly to JDBC statement as well.
Here you will see drastic improvement if you treated read-only transaction wrongly i.e. committed and rolled back them yourself from DAO
4) Make sure that you execute operation with DB concurrently. I was able to get 30% improvement when running 8 threads. There is a catch here though – by default internally MySQL holds 8 threads to serve DB requests. Make number of threads here and there consistent.
5) Change isolation level to READ-UNCOMMITTED if it possible (default for InnoDB is REPEATABLE READ)

set-variable=transaction-isolation=READ-UNCOMMITTED

My tests show that gain here is almost negligible around 4%

Дневник программиста:
Понедельник: Поставил JBuilder- кайф!
Вторник: Поставил Intellij IDEA - вечный кайф!
Среда: Потрахался с Eclipse - слабое подобие левой руки!

Поставил сегодня Eclipse - после IDEA кажется ужасным, все те маленькие штучки которы мне облегчали жизнь там тут отсутствуют.
Знающие люди говорят, что нужно плагинов наставить.
Наставил.
Colorer сломал там внутрях что-то и Eclipse перестал узнавать файлы *.java
Пока нашел кто виноват, пока снес, мама дорогая…
Неужели $400 USD не стоят избавления от всего этого?

Качаю MyEclipse всего $30 USD в год, может лучше станет…