Неожиданно поступила задача разобраться почему определенный сайт не работает столь быстро сколь хочется. В основе его CakePHP, в связке с Apache и MySQL. В статье описание процесса поиска узких мест и приведение в порядок на столько, на сколько это возможно.

Название сайта светить не буду — думаю, программисты сами узнают. Скажу лишь, что это приложение для социальной сети нагрузкой 70-150 тысяч посетителей в обычное время. Все усложняется тем, что периодически производится рекламная рассылка, которая привлекает около 200-300 тысяч посетителей за пару часов.

Итак, под катом описание всей борьбы на протяжении 4 дней.

Говорят, если вы торгуете конфетами, то весь год медленно и печально теряете деньги, и только в две последние недели декабря отрываетесь и получаете сверхприбыль. Если вы торгуете цветами — ситуация похожа, только вы работаете примерно в ноль и отрываетесь на 8 марта.


^{«Кардиограммы» бизнес-циклов}

Почти каждый бизнес — от торговли водкой до IT-проектов — имеет сезонные колебания. Их нужно учитывать в циклах подготовки, разработки, в финансах и в технических моментах перед пиком (вроде резервирования каналов).

20 апреля в Москве прошел первый российский Dribbble Meetup. На этой неформальной конференции для дизайнеров выступили десяток сильных и интересных специалистов, представленных в одной из главных тематических социальных сетей Dribbble. Это Алишер Якупов (Одноклассники), Денис Пахалюк (Ramotion), Павел Грозян и Сергей Кудряшов (MacPaw), Дмитрий Провоторов (Мануфактура), Игорь Степахин (Fidel Solutions), Роман Храмов (Cuberto), Александр Киров (Mail.Ru Group), Сергей Рачок и Виталий Трикоз (SODA). Было много практически полезных рассказов и историй из жизни компаний с живым и веселым диалогом со слушателями.

Прим. переводчика — В оригинале использовался всем знакомый термин «software engineer». Так как русский его аналог «инженер-программист» используется в повседневной речи редко, пришлось использовать слово «разработчик» как наиболее близкое. Также профессия «short-order cook», с которой автор сравнивает положение многих разработчиков в индустрии, была переведена как «мальчик на побегушках» — мне кажется, что она отлично отражает суть проблемы отношения к разработчикам. Наконец, я старался везде вместо слов «to code» и «programming» использовать «разрабатывать» и «разработка» из-за сложившемся в русском языке негативном смысле слов «кодировать» и «программирование» как примитивных процессов перевода требований в машинные инструкции низкого или высокого уровня.

Автор оригинальной статьи — Nickolas C. Zakas, известный фронтенд разработчик и JavaScript-евангелист в свое время проработавший более пяти лет в Yahoo. Это запись из его блога, в которой он говорит о том, почему с разработчиками так сложно договориться и что с этим делать.

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

Одна из главных мыслей той статьи заключалась в том, что разработчики говорят «нет» слишком быстро. Эта мысль тут же въелась мне в мозг и долго отказывалась вылезать оттуда. Мне хотелось воскликнуть: «Но подожди, ты же не понимаешь, почему мы говорим „нет“!». Тут же появился миллион других защитных аргументов. На самом деле она, конечно, права — мы правда слишком быстро говорим «нет», причем не только дизайнерам, а вообще всем. Это побудило меня поразмыслить над психологией разработчиков и тем, что составляет нашу истинную суть.

Существует несколько типов проектов,
для которых вывод геоинформации является
необходимым: сайты по недвижимости, каталоги компаний,
каталоги достопримечательностей, доски объявлений и другие.
Для этих сайтов я решил разработать плагин к goolge API 3 и Яндекс API 2.

Основные требования:

1. Возможность подключения без глубокой подготовки данных на сервере, а именно, используя только уже имеющиеся географические координаты объектов.
2. Простой протокол подготовки и передачи данных.
3. Быстрый клиентский кластеризатор с ДВУМЯ типами меток: кластер и группа. Кластер — несколько объектов, расположенных рядом. При клике кластер “раскрывается”, то есть увеличивает зум пока объекты будут на расстоянии, большем чем расстояние кластеризации. Группа — несколько объектов в одной точке (на минимальном расстоянии). При клике на группу на любом зуме выводится список объектов в группе.
4. Отображение до 10000 точек с использованием кластеризатора.
5. Отображение в ie7, на мобильных устройствах (iPad первого поколения).
6. Шаблонизация на клиенте двух инфоокон — группового кластера и самого объекта.
7. Использование спрайта для меток.
8. Возможность использования неограниченного количества типов меток (иконок) для разных типов объектов.
9. Возможность использования нескольких размеров иконки для разного диапазона зума.

В статье я опишу несколько подходов, которые были использованы для реализации этого плагина.

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

Оптимизация показов — большой процесс, одной из частей которого является сохранение и анализ цепочки событий, связанных с жизненным циклом баннера — показ, клик, конверсия, … всё это начинается с сохранения записей о событиях. Каждое из событий происходит на одном из множества серверов, причем, по понятной причине мы стараемся обслужить всю цепочку в одном месте — в этом случае не нужно заботиться о том как собрать в целое разбросанные части. Но в реальной жизни случается что угодно — сервера падают, сеть не работает, софт апгрейдится или перегружен — в общем, по многим причинам обслуживание последовательных событий иногда происходит на разных серверах и даже в разных датацентрах и к этому нужно быть готовым.

Задача которую нужно было решать — каким образом хранить, искать, модифицировать информацию о последовательности событий при следующих условиях:

• события могут происходить на разных серверах и в разных датацентрах (восточный и западный берег США, Европа)
• интервал между событиями — от долей секунды до нескольких дней
• к моменту получения завершающего события (например конверсия) информация обо всей цепочке должна быть на руках
• время жизни информации — примерно десять дней, после чего она должна быть удалена, желательно автоматически, через TTL
• темп чтения/записи событий — сотни или тысячи в секунду
• Время ответа: желательное — до 10мс, допустимое — в пределах 50мс, максимальное — до 100мс
• информация должна быть доступна «всегда» — независимо от аварий железа, сети, апгрейдов
• система должна легко масштабироваться: добавление новых серверов, датацентров должно происходить прозрачно для остальных сервисов (допустима деградация времени ответа в заданных пределах).

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

За последние пару лет я потратил много времени на дебаггинг чужих тестов. Это была интересная работа, иногда расстраивающая, но всегда поучительная. Кто-то может подумать, что в тестах нет багов, но конечно баги есть везде, и тесты не исключение.

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

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

Музыканты-любители с сайта hooktheory.com решили найти закономерности в современной поп-музыке. Они провели статистический анализ аккордов 1300 песен и опубликовали результаты: какие созвучия чаще всего встречаются в музыке и как они взаимодействуют между собой.

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

В статье «12 тыс рублей за сайт. Есть ли бизнес за МКАДом?» я писал про наш подход к разработке сайтов на базе разработанной внутри компании технологии. На момент написания той статьи, мы выпускали «под ключ» 24 сайта в месяц. Это больше чем один сайт в день силами команды из 8 человек.

После рассказа на хабре о нашей технологии количество заявок на разработку сайтов выросло в несколько раз. Только за март 2012 было выставлено около 60-ти коммерческих предложений и, большая часть из них превращалась в договора.

И тут наше производство затрещало по швам. Практически сразу заявки стали становиться в очередь, менеджеры начали путаться в проектах, дизайнеры стали проситься в отпуск. Ситуация становилась поистине напряженной…

---

UPD. Вторая версия бенчмарка тут: eric.themoritzfamily.com/websocket-demo-results-v2.html

---

Предупреждение: если у вас есть претензии к бенчмарку и/или к коду, бенчмарк выложен на Гитхабе, что позволяет вам править баги самим или сообщить о багах автору.

Подробнее о проблеме 10000 соединений: ru.wikipedia.org/wiki/Проблема_10000_соединений

Как с проблемой 10000 соединений через вебсокеты справятся Erlang, Go, Haskell (Snap), Java (Webbit), Node.js (websocket) и Python (ws4py)?

Здравствуй Хабрачитатель! Сегодня я расскажу о том, чем помог не так давно своим друзьям геодезистам, аэрофотосъемщикам. Мои друзья занимаются, проще говоря, съемкой Земли с борта самолета, для этого у них имеется некоторое оборудование и программное обеспечение, и часть из него хотелось бы им усовершенствовать. В этом году возникла идея создать программный модуль автоматической компенсации угла сноса платформы на которой установлена аэрофотосъемочная камера. Ранее это производилось в некотором ручном режиме (платформа очень старая) вычисляя угол сноса можно было произвести поправку платформы через некоторое устройство. Проблема была в вычислении и дальнейшей компенсации этого угла… собственно если интерес к данной статье не пропал, то прошу под кат (осторожно 7 Мб gif'ок)…

Рост аудитории интернет-пользователей и интернет-проектов выводит геосервисы на новый уровень.
Если раньше большинство проектов с использованием «карт» оперировали с десятками и сотнями точек, то сейчас уже речь идет о сотнях тысяч точек.
В статье будут рассмотрены несколько юзкейсов для геосервисов и способы их реализации для google API 3 и нового yandex API 2.

Привет Хабр, сегодня я расскажу немного про использование osm для предприятий и b2b.
А именно, как и зачем перейти от google maps api к osm, openlayers и счастью.

Краткое введение

В наши дни все понимают насколько простой задачей является угон незащищенной http сессии.
И останавливать от повсеместного внедрения может только цена на покупку сертификата, www.startssl.com решает эту проблему, раздавая бесплатные сертификаты (Class 1). Verified (Class 2) стоят копейки.

Когда-то давным давно угораздило меня попасть в мир учетных систем, да не просто учетных, а работающих через Web. Много воды утекло с тех пор, много систем родилось, некоторые из них уже погибли. Это очень динамичный мир. В этом мире множество систем, от брутальной, умудренной сединами 1С, до совсем молодой Acumatica. Есть гламурненькие Эльба с FinoBox, есть и крутой Мегаплан, есть мой любимый, суровый, но симпатишный Oreodor. Во всех них очень умные формы, ещё более умная (чем пользователь) навигация, ну, и таблицы! Давайте подойдем ещё ближе.

Все это Web, все это работает, все функционально, а функционала много.

«Одной из самых перспективных технологий социальных коммуникаций представляются геолокационные сервисы (Location-based services – LBS), позволяющие определить местоположение пользователя/мобильного абонента.
CNews (Подробнее: www.cnews.ru/reviews/index.shtml?2012/06/06/492022»)

Команда Mediagates полностью разделяет эту точку зрения. Поэтому сегодня мы хотим рассказать Хабрасообществу, как мы разрабатывали геолокационные сервисы для нашего проекта — Mediagates.ru. Пост включает в себя выбор картографического сервиса, описание задач, трудностей и алгоритмов решения.

О проекте Mediagates.ru

Чтобы было понятно, о чем вообще речь, сначала пару слов о проекте. Основной задачей «Медиагейтс» является объединение профессионалов в области музыки: артистов, продюсеров, промоутеров, площадок и прочих. Более подробно о возможностях проекта, а также его архитектуре мы расскажем в ближайших постах здесь, на Хабре. Пока же можно прочитать пост о проекте у нас на сайте.

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

Не знаю, как вы, уважаемый читатель, а я всегда поражался контрасту между изяществом базовой идеи, заложенной в концепцию двоичных деревьев поиска, и сложностью реализации сбалансированных двоичных деревьев поиска (красно-черные деревья, АВЛ-деревья, декартовы деревья). Недавно, перелистывая в очередной раз Седжвика [1], нашел описание рандомизированных деревьев поиска (нашлась и оригинальная работа [2]) — настолько простое, что занимает оно всего треть страницы (вставка узлов, еще страница — удаление узлов). Кроме того, при ближайшем рассмотрении обнаружился дополнительный бонус в виде очень красивой реализации операции удаления узлов из дерева поиска. Далее вы найдете описание (с цветными картинками) рандомизированных деревьев поиска, реализация на С++, а также результаты небольшого авторского исследования сбалансированности описываемых деревьев.

С появлением мобильного веба наш интернет стал снова плохим, а устройства медленными. 3G, 4G, Wi-Fi… — они, конечно, где-то есть, но когда очень надо, то как правило скорость падает до околомодемной и получается, что наши мобильный устройства «каменного века» попадают в условия современного объема информации. Даже в центре города (правда на 15-м этаже) значок мобильного интернета может показывать волшебную букву Е, намекающую о том, что уж лучше не тратить нервы и потерпеть. Лучше уж использовать нативную версию какого-то веб-сервиса, чем каждый раз ждать, загружать по мегабайту, чтобы отправить короткое сообщение. Нативную версию веб-сервиса... Понятное дело маркетинг, гонка приложений. Однако, же пользователи выбирают нативные веб-приложения, которые работают быстрее, не качают кучу ресурсов, хотя им приходится периодически его обновлять.

Эта статья о том какими путями можно оптимизировать загрузку и инициализацию JavaScript.

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

Приветствую любителей облачных вычислений.
Предлагаю посмотреть на сравнение сервисов Windows Azure Blob Storage и Google Cloud Storage (при этом автор не забывает упомянуть и про Amazon AS3).

Я подумал, что неплохо было бы написать статью по сравнению хранилища Google App Engine и Windows Azure. В этой статье мы сравним Windows Azure Blob Storage и Google Cloud Storage.