Disclaimer: Эта статья не о том, «какой я умный и какой Гугл тупой». Эта статья о некоторых неочевидных проблемах и особенностях Google AppEngine (GAE), о которых было бы неплохо знать тем, кто хочет начать работать с «империей зла» :-)


Гугл сделал много отличных вещей – поиск, почта без спама… Гугл получает кучу наших приватных данных, но мы продолжаем пользоваться им, потому что оно так классно работает…
Некоторое время в IT-шных кругах поднялось достаточно шума об AppEngine, и я решил попробовать поработать с ним в моём новом проекте.

Я выбрал Python с гугловским framework-ом чтобы получить наилучшую совместимость и скорость. Начал я с тестов производительности, и результаты были…

Недавно понадобилось впервые за долгие годы написать в саппорт Microsoft, обычно я привык решать проблемы самостоятельно, но тут вопрос был не технический.

Оказалось, что сделать это не так просто для простого смертного, но за 20 минут нашел на microsoft.ru страницу с которой можно отправить сообщение. Достаточно оперативно мне ответили по электронной почте, и запросили дополнительную информацию. Я ответил, и уже было решил, что дело сделано, но тут пришел ответ:

После опубликования статьи Intel Atom colocation последовали баталии тут на хабре, и в логове хостеров (на hostobzor-е). Ценой нечеловеческих усилий :-) таки удалось убедить некоторые компании, что это(colocation неттопов) может быть выгодно. Предлагаю читателям хабра поучаствовать в первом размещении неттопов в ДЦ (М-101, Москва) — подробности под катом.

Напоминаю — это возможность поиметь свой сервер с 2-4Гб памяти, нормальным каналом и дисковым IO по цене завалящего VPS.

Кстати, хороший пример того, как хабр может сделать мир лучше :-)

Осознал сегодня, что хочу заколохостить mini-ITX сервер. Много мощностей не нужно, потому хватит и Атома. Были бы знакомые с корбиной — поставил бы на 10Мбит и в ус бы не дул, но к сожалению нет таких, а на Yota отдача ну просто никакая. Хостеры готовы ставить на коло, но лишь с небольшой скидкой. Можно брать VDS — но там свои ограничения(особенно мало памяти), и негарантированная скорость по диску. Ну и есть dedicated «дедушки» за 50$/месяц. Вобщем, ситуация грусная, и я решил покопать немного вопрос colocation/dedicated server на Intel Atom, результаты под катом.

Хочу поделится с читателями результатами многочасового мучения с производительностью VMWare. Сначала результат, потом лирика:

ОС: Windows 2003 Server
VMWare 6.5 (вероятно и другие версии) при больших объемах дисковых операций (серверные приложения) начинает жестко тормозить (падение скорости в десятки раз) после активного использования в течении нескольких часов. И это не фрагментация.

Решение:
В .vmx файле описания виртуальной машины дописываем:

MemTrimRate = «0»
sched.mem.pshare.enable = «FALSE»
mainMem.useNamedFile = «FALSE»

MemTrimRate можно настроить и через GUI, Options->Advanced->Disable memory page trimming

После этого все начинает работать в соответствии с ожиданиями (летать :-) ).

Многих хабрачитателей иногда волнует вопрос хостинга SVN. В интернете полно вариантов захостить SVN репозиторий, с ценой порядка 10-15уе в месяц, но смущает одно: хостинг репозитория — намного более ответственное дело, нежели хостинг сайта. В коде — ваши «сверхценные идеи», от аптайма сервера и надежности бэкапов напрямую зависит работа вашего бизнеса. Некоторые выбирают все же хостить SVN в серьёзных компаниях. Хорошее сравнение по параметрам тут: http://www.svnhostingcomparison.com/, open-source кстати можно захостить в неплохом месте на букву G ;-).

Другие же, как и я, решают хостить SVN на своём VDS / Dedicated сервере. На этом вопросе я и остановлюсь, рассказав заодно немного о вариантах запуска/настройки svn сервера (в том числе относительно новых — шифрование/аутентификация SASL и хранение в FS). Выльеться все это вам в 3-4$/месяц, в полный контроль за бэкапами и доступом к серверу. Пожертвовать придется 30 минут драгоценного времени на настройку.

Целевая аудитория: начальный — средний уровень опыта работы с Linux.
PS. Я в курсе что FreeBSD is not Linux ;-)

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

На хабре уже обсуждали анонс подобных девайсов, сейчас же их уже можно свободно купить, например на Савёловском рынке (правда 90% продавцев говорят «eSATA?» И услышав ключевое слово «16Гб» сразу кидаются за первой попавшейся «черепашьей» USB флешкой :-) ). Речь идет об OCZ Throttle, выпускаемой размерами 8, 16 и 32Гб. Эта флешка давно была моей мечтой, с её рекламируемыми «30Мб/сек запись и 90 чтение». Я был уверен, что такая флешка — отличный подарок любому Гику или матёрому сисадмину :-) Вчера я её наконец получил, и хочу поделиться с хабрачитателями впечатлениями :-)
PS. Я купил 8Гб за 1300 рублей, уверен можно найти и дешевле.

В данный момент стоит вопрос о разработке высокопроизводительного веб-приложения, которое могло бы выдерживать миллионы хитов в день.
Целевая нагрузка от 1000 хитов в секунду и выше (вплоть до заполнения гигабитного канала).

Имел ли кто-либо из читателей опыт разработки веб-приложений на С++? Предлагаю обсудить сложности и ограничения.
Подразумевается что приложение не будет иметь утечек памяти(и соответственно проблем со стабильностью), и 2-3-х кратное увеличение цены разработки по сравнению с PHP приемлимо.

Какие варианты вижу я:

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

Про nVidia CUDA хабровчане уже наслышаны, теперь настал черед и AMD Brook+. Brook+ позволяет вам писать программы на С и запускать их на видеокартах AMD (ну и как опция — автоматически можно сгенерировать CPU версию со средним качеством кода). Достижимая производительность — порядка 600млрд операций на AMD 4870.

NB: Статья — краткое введение, не стоит ожидать освещения тут всех аспектов программирования на Brook+ :-)

Для своего нового проекта я как раз сейчас устанавливаю рабочее окружение, и ключевое место в нем занимает баг/таймтрекер+wiki. Платные реализации извесны (тот же Basecamp, Fogbugs, updatelog.com), но хотелось найти что-то что хостится на моём сервере. Из извесного и хорошо работающего — это Bugzilla (с очень скромным функционалом), Trac(есть все, но только 1 проект), и вот только что наткнулся на «новый» проект (около 3-х лет ему) — Redmine. Практически аналог вышеупомянутых платных сервисов, но бесплатный. Проблема для меня в том, что он написан на Ruby On Rails, и как оказалось деплоймент ROR приложений может быть не слишком простым (по крайней мере для таких новичков в этом деле как я). Так как хостинг не специализируется на Ruby, Passenger-а нету. В конечном итоге оказалось что это все не так уж и сложно :-)

Достоинства удаленной работы очевидны — меньше ограничений в поиске специалистов с нужной квалификацией, возможность нанимать людей за пределами МКАД, меньше расходов на ведение бизнеса. С другой стороны, есть и проблемы: наиболее значительные — со стороны организации работы. Последние 4 года я работаю тим лидом распределенной группы программистов (3-15 человек в разное время) для зарубежного заказчика, и хочу поделиться с хабрадевелоперами опытом такой работы :-)

Здесь и далее имеется ввиду следующая организация труда:

1. Заказчик (+on-site команда опционально) в офисе где-нибуть в Европе/США.
2. Тим лид распределенной команды — где-то на бескрайних просторах exUSSR.
3. Члены распределенной команды — также где-то на бескрайних просторах exUSSR.

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

Часто возникает желание посмотреть отуда приходят люди на ваш сайт, дабы пойти туда почитать что про нас любимых пишут, и рьяно вступить в полемику не отходя от кассы. Казалось бы, такая популярная штука как Google Analitycs должна делать это, но есть одна проблема — в отчете отрезаются GET-параметры, и если вы видите что ссылка с огромного форума, то вам еще предстоит найти нужную тему, что отнимает время (стоит упомянуть, что Google Analitycs требует дополнительного JS кода на страницах, что также отнимает время и трафик).

Аватары и фотографии

• Похоже хабра уменьшает фотографию, чтобы они влазила в квадрат 300x300, предлагаю уменьшать по квадрату 450x300
• Предлагаю чуть увеличить качество jpeg при перепаковке. Если оригинальная фотография уже влазит в квадрат 450x300 — не перепаковывать (остается оригинальное качество, если размер меньше например 100кб)
• Для аватарок — чуть увеличить качество, не перепаковывать если размер 48x48, предлагаю сделать аватарку в комментариях тоже 48x48(как справа-сверху аватар залогиненого пользователя), чтобы она была слева от всего коммента, а не только заголовка. Очень уж мелко получается.

Стиль комментариев

Было бы неплохо иметь возможность переключиться в линейный стиль комментариев. Когда у топика 300 комментов, ездить туда-сюда неудобно (даже с мега-удобной «штукой справа»)

Автоматически показывать то, что комментируем как <blockquote></blockquote>. Т.е. то же дерево отображается линейно, по дате, родитель показывается в блоке <blockquote></blockquote>.

Человек так же как и в древовидном режиме нажимает ответить под любым комментом, но сам текст не цитирует (т.к. он вставляется автоматом при отображении). Сумбурно получилось, спрашивайте, если неясно, могу сделать прототип :-)

В линейном режиме уже и pagination можно будет добавить наконец-то :-)

PS. Не знаю, нужно ли разделять на два топика, или одной кучей. Если нужно, разделю.

Многие видели моё введение в современные технологии высокопроизводительных вычислений и оценки производительности, теперь я продолжу тему более подробным рассказом о технологии CUDA.
Для тех кто не смотрел предыдущие серии: CUDA позволяет писать и запускать на видеокартах nVidia(8xxx и выше) программы написанные на С++ со специальными расширениями. На правильных задачах достигается значительное превосходство по производительности на $ по сравнению с обычными CPU.
Достижимая производительность — 1 трлн и выше операций в секунду на GTX295.

NB: Статья — краткое введение, покрыть все ньюансы программирования под CUDA в одной статье вряд ли возможно :-)