Наверх ▲

Интеграция открытых технологий и взаимодействие со сторонними проектами в условиях высоких нагрузок

Олег Илларионов Олег Илларионов Разработчик социальной сети ВКонтакте.

Олег Илларионов: Начать хотелось бы с беседы о создании XMPP-сервера.

Дело в том, что задача создать XMPP-сервер оказалась для нас нестандартной. В целом все представлялось довольно привычным и простым. XML – мы привыкли использовать этот язык – и всё остальное было довольно стандартным, за исключением того, что в данном случае мы вынуждены были держать многочисленные соединения.

Каждый пользователь у нас "висит". Т.к. он может находиться в таком состоянии час, два, день, неделю, нам нужно держать одновременно много соединений. PHP не смог помочь нам в этом, поэтому мы были вынуждены искать другие технологии.

Сначала мы стали рассматривать готовые сервера, которые уже были: EJabber, Jabber E2 и др. И пришли к выводу, что реализовать XMPP-протокол и работать с ним не так сложно, как интегрировать все с существующей инфраструктурой: сервером личных сообщений и контакт-листом. Нужно оповещать, когда кто-то вошел в сеть или вышел из неё - в общем делать много вещей.

Поэтому мы поняли, что гораздо дешевле и проще создать что-то свое. Мы стали думать, что именно нам было необходимо.

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

Мы предъявляли к инструментам следующие требования.

  • Это должен быть язык высокого уровня (из категории Python, JavaScript, PHP).
  • Он должен довольно быстро работать, не сжирать все CPU, чтобы нам хватило нескольких серверов для Jabber сервера.
  • Так как у нас очень много соединений, мы не могли работать с базой, диском и блокировками. Нам нужен был неблокирующий ввод-вывод.
  • Наличие инфраструктуры. У нас используется много баз (MySQL, Memcached). Нам нужна была такая инфраструктура, чтобы можно было работать на этой платформе с тем, что у нас уже было.

Решением проблемы стал node.js. На этой платформе можно очень быстро создавать веб-сервера. Фактически мы написали Jabber сервис всего за 2 недели. Остальное время ушло на дебаг, ускорение, тестирование и пр. Кроме того, он удобен в плане блокировки и обладает требуемой инфраструктурой. На тот момент она отвечала всем нашим требованиям.

Даже MySQL, работа с которой не всегда окрашена светлыми тонами, там была и хорошо работала. 

Дальше я хотел бы рассказать, с какими проблемами мы столкнулись. Самое страшное – это нагрузка. Когда мы проводили тестирование на локальном компьютере, все прошло гладко. Но потом появились проблемы.

У нас нетипичная ситуация. Мы не обычный XMPP-сервер. У нас большие контактные листы. Я тестировал на большом количестве соединений от самого себя и видел, что это не очень хорошо работает, потому что контакт-лист – за 400 друзей.

Высокая активность online/offline. Это тоже очень большой минус, потому что люди все время входят и выходят. В основном это обусловлено тем, что сессия на сайте длится всего 15 минут. Если человек отошел от компьютера на 15 минут, потом вернулся и ткнул еще на какую-то кнопку, он вышел-вошел. Эти выходы-входы постоянно повторяются. Получается, что несколько раз в минуту кто-то выходит и кто-то входит. У нас происходит постоянный обмен трафиком с клиентами.

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

Все, что нам было нужно, это ужимать их на лету. Причем отправлять их клиенту мы можем только в формате base64, потому что есть некоторые возможности. Протокол позволяет посылать просто ссылки на них, но большинство клиентов в таком виде не воспринимает аватарки. Если мы хотим, чтобы это работало везде, нам нужно их в XML base64. Все это надо делать на лету.

Человек просит свой контакт-лист, и для каждого пользователя мы ему – base64, его аватарку, все 400 человек. Все это должно произойти за несколько секунд. Таких пользователей может быть много.

Последний пункт – это личные сообщения. Для личных сообщений архитектурно нельзя было взять и одно соединение на тысячу человек. Настолько сложна архитектура на данный момент, что для личных сообщений каждого пользователя нужно держать отдельное соединение. В целом это довольно проблематично. Когда мы имеем 10 тысяч пользователей на одном сервере, нам тяжело держать 10 тысяч соединений с AIMP серверами. Их меньше. Несмотря на это, для каждого пользователя должно быть свое соединение.

Сразу хотел бы поделиться цифрами, чтобы потом их обсудить.

В среднем 60-80 тысяч пользователей online. Пик был после написания в блоге, на следующий день вечером – 150 тысяч. Это было тяжело. На тот момент 4 сервера были максимально загружены. Все шло нормально, но я уже побаивался. Я смотрел на телефон каждые 15 минут, проверял, все ли работает.

В целом когда мы только писали об этом на "Хабрахабре", реакция была совсем незначительной. Все совершенно спокойно держал один сервер. Два других (на тот момент у нас было 3 сервера) мы использовали для выката апдейтов. Очень просто: спереди был прокси, мы что-то изменили – на другой сервер, и всех пускаем на другой сервер. Старые оставили на старом. Очень удобно, потому что таким образом мы совершенно безболезненно выкатываем апдейты.

Дело в том, что на node апдейтить код не так просто. Можно, конечно, делать hot reloading, перезаливать все заново, переопределять все функции. Но это не совсем правильно. Тогда осуществлять дебаггинг было бы совершенно невероятно, потому что была бы гарантирована утечка памяти.

Базы данных используются в основном для кэширования и хранения групп. У каждого пользователя есть свои группы. Каждый пользователь может определить кого-то в одну группу, кого-то в другую.

Сначала мы использовали стандартные списки ВКонтакте. ВКонтакте можно создать список, люди будут в разных категориях: одинх – сюда, других – тюда. Но мы пришли к выводу, что это неправильно. Списки ВКонтакте – это  личная вещь. Они используются для ограничения приватности. Эти же списки нужны для показа того, какие люди к каким относятся.

Поступило много жалоб. Люди не хотели видеть списки приватности у себя в клиенте, чтобы другие пользователи их тоже не видели. Иначе было бы нехорошо. Поэтому пришлось быстро, «на коленке» это исправлять и хранить в MySQL.

Сначала мы хотели использовать Mongo, но знающие люди посоветовали, что не стоит использовать две рискованные технологии одновременно. Это опасно. В принципе, это правильно, потому что MySQL работал хорошо. На этих же 5 серверах распожены 3 раздробленных базы (точнее на трёх серверах, поскольку они мощные других двух).

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

Сразу хотелось бы определиться со статистикой. Все было самописное, мы очень просто могли собирать статистику. Хотелось бы поделиться, с чего люди заходят. Если честно, я был удивлен. Хотя бы тем, что Adium обогнал мой любимый Pidgin. Но дело даже не в этом. Я даже не знал о существовании MobileAgent’а, например. Но в целом люди заходят через QIP. Это очень хорошо. QIP хорошо относится к нашим серверам, гораздо лучше, чем Miranda, с которой трафик ужасен.

С какими проблемами мы столкнулись. В node сложно с памятью. Она не теряется, там хороший garbage collector, но нужно быть очень аккуратными, потому что возникает очень много corner case’ов. Мы пишем сложную систему – XML. Разные случаи - разные клиенты. Все они по-разному работают, и ошибки неизбежны. В определенный момент возникает ошибка. У кого-то оборвалось соединение, тут сработал callback, там нужно что-то дать, у кого-то чего-то нет. И все обвалилось.

В этот момент нельзя предсказать, что из этого выйдет. Может случиться так, что память теряется. Причем долгое время память "утекала", и мы видели, что у нас остаются "висячие" пользователи.

Что мы сделали? Мы написали цикл, который пробегается по всем пользователям, смотрит, когда в последний раз от этого пользователя приходило сообщение. Если он не отсылал сообщения какое-то время (по-моему, 180 секунд), то он отключается. Периодически, раз в 50 секунд, посылаются пинги. Если ответ на пинги не приходит (пользователь ничего не отправлял за 80 секунд), он полностью удаляется отовсюду. Таким образом, удалось избавиться от всех "утечек" памяти. 

Другая проблема – это openSSL. В целом node – готовый инструмент. Его можно использовать на стадии производства (продакшн), если речь не заходит про openSSL. С ним - много проблем. Из-за него приходилось разбираться в коде node, в коде C++. Пришлось даже отправить патчи в сообщество. Но и это ещё не все.

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

В целом, конечно, это ужасная ситуация, потому что довольно много клиентов использует openSSL по default’у (примерно 20%). OpenSSL довольно тяжело работает: он сильно нагружает процессор, тратит его ресурсы и является причиной 90% багов.

Далее хотелось бы рассказать о виджетах и кроссдоменном взаимодействии. Мы очень много делаем в этом направлении. Это одно из важных направлений, потому что в последнее время мы стремимся к открытости и хотим дать веб-мастерам больше возможностей.

Как это можно сделать? По сути, виджет – это довольно простая вещь. Мы даем веб-мастеру кусок HTML-кода, он размещает его у себя и получает нечто подобное тому, что изображено на слайде.

Но на самом деле все не так просто. Мы не можем дать веб-мастеру информацию о пользователе. Мы не можем дать ему возможность «залайкать», комментировать что-либо без ведома пользователя, комментировать (особенно если это пойдет к нему в статус). Поэтому мы должны разграничить доступ. Как это делается? Естественно, это осуществляется iframe’ом на другом домене.

Но, делая это, мы лишаем доступа самих себя. Нам тоже нужно общаться с родительским окном и передавать информацию.

Например, нам нужно изменить размер iframe или передать что-либо разработчику. Что делать? Нам нужно использовать некоторые инструменты, чтобы передать данные из iframe'а наверх. Что можно предпринять? В post message есть стандартная функцияы, которая работает в большинстве браузеров, решая эту проблему. Она работает в большинстве браузеров, но не во всех.

Кроссбраузерность становится очень большим камнем преткновения. Можно видеть, что здесь, в принципе, основной браузер – Firefox 3, Chrome, Opera, IE. Но пользователей более ста браузеров – около 10%. Это много. Поэтому нужно искать выходы из сложившейся ситуации.

Сначала мы решили поступить очень просто и взяли готовую библиотеку. В самом начале был Flash-посредник. Мы его использовали там, где нет postMessage, но быстро поняли, что это решение неидеально, поскольку Flash тоже есть не у всех. Кроме того, он медленно работает и тормозит вкладки.

Мы стали использовать готовые технологии и взяли easyXDM. Это библиотека, которая разрешила все наши проблемы. Мы поставили ее. И все, казалось, заработало. В обычных приложениях ВКонтакте (iframe-приложениях) все работает до сих пор. Там стоит easyXDM. Хотя на самом деле это будет работать так всего лишь около недели.

Дело в том, что там есть клиентская библиотека XDM connection. Мы обновили версию. Она может работать с новой библиотекой, которую мы написали вместо easyXDM. Но так как у всех еще кэш, мы не можем просто взять и обновить. Мы ждем, пока кэш очистится у всех. Где-то две недели назад это было сделано. А через две недели всё можно будет смело обновлять. Больше кэша ни у кого уже не останется.

Был easyXDM, но были и проблемы. Когда мы стали использовать его в виджетах, то нам начали жаловаться мастера, что ничего не работает. Были разные ситуации. У кого-то переопределен JSON, причем переопределен в самый неожиданный момент (сначала JSON был нормальным, а потом – бац – он подключил какую-то библиотеку, там новый JSON, у которого нет функции parse_ini_file()). Имелись также проблемы: у него был JSON, он стал пeреопределенным, там даже есть функция parse_ini_file(), но работают они в некотором роде странно. Например, списки преобразовываются в строчку.

Были странные проблемы, например, с переопределениями. Вроде все нормально, но возникает ошибка – и ничего не работает. 

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

Мы стали анализировать возможные способы. Самый примитивный – это hash родительского окна. Как мы можем обмениваться информацией с iframe? Мы можем менять hash родительского окна. Мы можем что-то записать туда, быстренько это считать, пока не поздно, и быстренько убрать. Если мы будем делать очень быстро, то клиентские скрипты будут работать. Они не заметят этого.

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

Более продвинутый способ – использовать дополнительный iframe с hash. Внутри нашего iframe мы создаем еще один iframe (звучит ужасно, но это не самое страшное). В этом дополнительном iframe’е мы меняем hash и передаем ссылку родительскому. Родительский может дотянуться через iframe внутрь и увидеть hash, потому что они на одном домене.

Но у этого способа есть большой минус. Разработчику приходится "вешать" себе на host специальный файл. У нас он назывался easy receiver. Собственно, Easy XDM тоже его использовал. Разработчикам, чтобы их сайты работали в старых браузерах, требовалось положить к себе в файлы и виджеты, и open API. В принципе многие до сих пор так и делают, хотя из документации мы это убрали.

Это тоже не совсем правильно. Все должно быть проще.

Мы стали смотреть, как можно сделать по-другому, какие есть ещё способы. Выяснилось, что существует некий nixTransport. Он появился в Easy XDM - оттуда мы ее и взяли.

У Internet Explorer’а есть одна особенность: если мы создаем некую функцию на Visual Basic, то мы можем до нее дотянуться. Мы создаем ее сверху, а изнутри, через window.opener мы можем до нее дотянуться, что-то туда передать или выполнить. Это позволяет нам общаться. Причем быстро, потому что это нативная передача, без всяких посредников.

Что самое главное – это работает и в 6-м, и в 7-м IE. На 5-й мы не смотрим, потому что его практически не существует, слава Богу. Но это решает проблему пользователей IE. Мы стали использовать этот способ.

Вторая категория браузеров, которая нас волновала больше всего, это Firefox.

У Firefox’а тоже нашлась замечательная особенность – frameElement. Это очень интересное свойство. Насколько я знаю, в новых версиях его уже нет. В новых версиях есть postMessage, там все хорошо, мы можем передавать строчки. В старых мы можем присвоить iframe’у какую-нибудь функцию или несколько функций.

Из внутреннего iframe’а мы можем обратиться к этому iframe’у, к этим функциям через frameElement. Мы берем window.frameElement и эти функции – и они работают.

Конечно, для безопасности там есть некоторая защита. В window.name мы кладем специальный ключик и благодаря ему делаем так, чтобы кто угодно уже не мог вызвать родительскую функцию (какой-нибудь iframe на странице из некоего таргетирга).

По сути, мы перекрыли почти все браузеры, потому что осталась только Opera (начиная с 9-й версии). С Opera’ой, конечно, отдельная история. В связи с Opera 9.5 было очень много жалоб, потому что ей пользуется очень много людей. Это удивительно.

Она вылетала, когда postMessage использовался неправильно. Там есть postMessage, но не дай Бог как-то проверить, что он существует (там, где его нет) - все вылетит напрочь.

Но в Opera, в принципе, все работает. Что касается Opera 8, то пользователи ей практически не пользуются. Если они не увидят какой-то виджет, то, мне кажется, можно не обращать на них внимания. Например, в нашем частном случае гораздо больше пользователей на работе просто заблокировали ВКонтакт и тоже не видят виджетов.

Кстати говоря, с этой проблемой мы некоторое время боролись. Дело в том, что мы не можем держать виджеты на другом домене, потому что нам нужно иметь куки. Будет странно, если всех пользователей мы будем авторизовывать, перебрасывать. ВКонтакте у всех есть куки, поэтому "виджить" он должен авторизованно.

Проблема была в том, что если ВКонтакте заблокирован, то браузер не мог потянуть библиотеку Open API. Сначала мы об этом не подумали. Мы вообще сначала не думали о том, что Контакт может быть где-то заблокирован.

Но потом нам стали жаловаться. Оказалось, что есть страница, где сверху подключен скрипт, но он не грузится. Что происходит?

Что мы сделали? Во-первых, один из способов – асинхронная загрузка (когда скрипт подключается не сразу, а по тайм-ауту). Это один из способов.

Второй способ. Мы открыли всю статику через user API. Тоже удобно, потому что от user API пока никто не отказывался, слава Богу. Userapi.com или userapi.ru – просто мы взяли другие домены. Это тоже решило проблему.

Теперь некоторые данные: что в итоге получилось? У нас есть easyXDM, он весит 17 килобайт. В минифицированном виде он "весит" 4,5. FastXDM в минифицированном варианте "весит" совсем не 4,5. Я просто забыл измерить.

В неминифицированном виде он "весит" 6,3 килобайта. Но в минифицированном виде он будет "весить" совсем мало, потому что мы сделали очень хитрую вещью.

Мы решили разделить браузеры на хорошие и нехорошие. В хорошем браузере мы просто можем использовать небольшую обертку вокруг стандартного postMessage. А в нехороших браузерах мы будем загружать дополнительную библиотеку, где будет все остальное, чтобы у нас было минимум кода.

Таким образом, если в браузере нет JSON или еще чего-то, он автоматически считается нехорошим, несмотря на то что он в целом хорош. Если JSON переопределен, подключена хитрая библиотечка, которая бы переопределила JSON, то браузер тоже считается нехорошим. Библиотека будет подгружаться в нормальный JSON (библиотека называется JSON), она хорошо все сжимает и достаточно безопасна.

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

Наверное, последняя тема, о которой я расскажу перед тем, как придет Павел и расскажет, как все было в далеком 2006-м, - это интеграция со сторонними сервисами. Как мы строили взаимодействие со всякими Twitter, Share и т.д.

На самом деле все не так тривиально, как кажется. С нашего рабочего сервера, который принимает запросы, мы не можем обратиться к twitter’у. Это плохо по целому ряду причин. Например, есть Coral, который "зависает" и оставляет соединения, теряется память.

Есть и другие проблемы. Это может быть небезопасно.

Мы используем примерно такую структуру. Создается большая очередь. Причем специфическая очередь, потому что мы не можем взять какую угодно очередь. Нам нужно, чтобы все было безопасно. Мы должны понимать, что сисадмины очень часто перезагружают серверы, которые будут выполнять запросы Twitter, потому что у них очень часто кончаются коннекты. Лучше не представлять, что там творится. С очередью нам нужно работать очень аккуратно.

Как это делается? Мы берем небольшую очередь на memcache, небольшую очередь на MySQL (потому что там все может долго продержаться), кидаем туда запрос, что хочет пользователь. Когда наш скрипт хочет взять что-то с очереди, он говорит: «Я читаю что-то из MySQL». Данный способ можно считать правильным, потому что если вдруг все "упадет", то ничего не будет запрошено второй раз.

У нас везде стоят timestamp’ы, мы знаем, что, во сколько и откуда мы вытащили. Не дай Бог что-то "вырубится", все будет хорошо. Очень сильно в этом помогает Memcache.

Поставив Memcache lock, сервер снимает данные, начинает их обрабатывать и снимает Memcache lock. Если он не обработает данные, они не вынутся из базы, но при этом их никто не прочитает в течение некоторого времени. Беря данные, он сразу вписывает в них новые timestamp’ы. «Я их взял, поэтому 60 секунд их никто не имеет права трогать».

Через 60 секунд, если у нас что-то не получилось и он не смог записать, что все выполнено, кто-то другой возьмет данный запрос и выполнит его до конца.

Что делать, если у нас на сайте обновляется слишком много статусов и довольно приличная аудитория пользуется экспортом Twitter? В стандартном Cron мы не можем поставить нечто чаще, чем на минуту. Но это не проблема. Мы можем написать небольшой скрипт, который вызывает это раз в секунду. Он выполняется минуту, и раз в секунду вызывает скрипт.

Мы можем делать это все более динамично. Мы делаем Ajax-запрос о том, что кто-то хочет что-то "зашарить" и нам возвращается адрес другого специального load-сервера, который может делать внешние запросы, может обратиться к этому сайту, который хотят "зашарить". Затем клиент обращается к этому серверу и получает от него результат, информирующий о том, что лежало на этом сайте (некий заголовок, картинка, информация).

После получения результата он выкладывает его спокойно на сервер, и в итоге ссылка "шарится".

Отдельно хотелось бы рассказать про детали. Раз мы выступаем перед такой аудиторией, то хотелось бы анонсировать здесь новую деталь: мы стали поддерживать теги в Share openGraph.

Это перспективное направление, потому что нам нужно знать, что на этой странице, какой контент на ней размещен. Это необходимо, чтобы адекватно его показать (например, в подсказке при наведении на какую-то ссылку и в других случаях). Нам нужно показать, что там было. Если разработчик сайта укажет у себя в openGraph теге, что это type – какой-либо movie, site name – некий «КиноПоиск», то в подсказке высветится, что это определенный фильм с некоторым бюджетом и соответствующими параметрами.

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

Перед тем, как закончу, хочу затронуть еще один интересный момент. Как можно классно выдергивать фотографии, которые относятся к конкретной статье на сайте. Может быть, вы заметили, что в последнее время в сети ВКонтакте подбирается как раз та фотография, которая подходит к данной статье.

Это делается очень просто. Мы берем alt у фотографии и сравниваем его с заголовком. Если сайт оптимизирован специалистами SEO, то абсолютно точно alt фотографии будет похож на заголовок. Мы считаем количество перестановок букв между заголовком и текстом, необходимое для того, чтобы преобразовать одно слово в другое по словам. В целом получаем схожесть фраз.

На этом, наверное, хотелось бы закончить.

Вопросы:

Надо сказать, что из этого мы приобрели много плюсов. В итоге мы не тратили кучу времени на интеграцию. Мы очень быстро все интегрировали. Язык позволял это делать действительно быстро. Там все инструменты были.

Не очень много времени мы потратили и на реализацию протоколов. В итоге мы получили некий «велосипед», который немного сомнителен в том плане, что это не готовый веб-сервер, а только некая прослойка. Любой разработчик не может у себя поставить и использовать как полноценный jabber-сервер. Там нет ничего.

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

Вопрос из зала:
За сколько вы научили работать node.js с openSSL?
Олег Илларионов:
Сейчас в той версии, которая есть в репозитории, самая серьёзная проблема следующая. Если, например, у вас много пользователей и все работает, то может прийти какой-то нехороший пользователь и вызвать ошибку в openSSL.
У меня получилось эмулировать ситуацию довольно просто. Я начинал соединение, делал can’t shake, а потом посылал незашифрованные данные. В openSSL возникала ошибка. В таком случае все сообщения пользователей, которые будут что-то отправлять на сервер, будут обрезаться до тех пор, пока кто-то новый не подключится и в самой библиотеке openSSL что-то не исправит.
Это решалось очень просто на самом деле. Как я решил эту проблему? В случае подобной ошибки я возвращаю не минус 2, а 0. Ничего нигде не обрезается.
Но я решил, что не стоит коммитить эту ветку, потому что это не совсем правильно. Нужно лезть в код openSSL, смотреть, как он взаимодействует с этими бинингами. К сожалению, на это не было времени.
Вопрос из зала:
Что вы скажете об API?
Олег Илларионов:
API там очень низкоуровневое.
Вопрос из зала:
Нет, вообще.
Олег Илларионов:
Относительно API ВКонтакте?
Вопрос из зала:
Да. Ситуация в следующем. Недавно было открыто приложение. Сейчас в документации на первой странице есть такая строка: «Для авторизации используйте компонент «браузер». Очень здорово, если мы работаем в X-коде или в Legal Studio. Там либо подтянется движок Internet Explorer’а, либо надо там что-нибудь сломать. Если в нашем каркасе нет браузера, под которым мы хотим разработать десктопное приложение для ВКонтакте, будет ли вводится что-то более приемлемое, например, для авторизации?
Олег Илларионов:
Естественно. Много жалоб было от разработчиков Java-приложений для телефонов, где, естественно, даже никакой надежды на браузер нет (в старых телефонах). Мы много над этим думали и собираемся использовать для таких случаев open AOS с пин-кодом (пользователю дается пин-код, который он вводит в приложение и авторизуется).
Это будет несколько позже, потому что мы занимаемся тем, что нам нужно настроить HTTPS на всех серверах (это занимает время). Для того чтобы сделать AOS, нам нужен HTTPS.
Вопрос из зала:
Теперь ВКонтакте будет доступен по HTTPS, как, допустим, Gmail?
Олег Илларионов:
Это еще не факт. Возможно, будет сделано ограничение в динамике и переход на новую версию, потому что фронтов мало, а HTTPS трафик надо обрабатывать на фронтах.
Вопрос из зала:
В чем причина openSSL-ошибки?
Олег Илларионов:
Я думаю, что причина кроется во взаимодействии, но не могу сказать точно. Дело в том, что я докопался до кода "Си". Там эта проблема присутствовала. Там возвращалась openSSL-ошибка, но неизвестно, чем она была вызвана. Возможно, она была вызвана неправильной обработкой node. Ошибка возникает внутри openSSL, но ее причиной, возможно, стал не openSSL, а неправильная запись в него данных.
Очень сложно "дебажить" эти случаи, потому что такие ошибки возникают довольно редко и в нестандартных ситуация (когда пользователи пишут что-то очень неправильное, или у них пропадает соединение в какой-то момент).
Вопрос из зала:
Я бы хотел коснуться темы "сборщика мусора" (англ. garbage collector). Он у вас прямо волшебным образом работает, не зависает на несколько секунд или минут. Нормально справляется со всеми задачами.
Олег Илларионов:
Он не зависает, но бывают моменты, когда он вдруг инициируется и собирает мусор. Это может достигать целых ста миллисекунд, но случаев с секундами не было. В принципе, мы не используем принудительную сборку мусора, хотя это возможно. Мы экономим ресурсы, хотя мы пытались делать с принудительной сборкой и поняли, что это все-таки не совсем правильно.
Вопрос из зала:
Какие у вас отношения с Facebook? Вы на них, мягко говоря, похожи.
Олег Илларионов:
Насколько я понимаю, никаких проблем с соцсетью Facebook нет. Мне кажется, было бы глупо, если бы идея социальной сети принадлежала одному сайту, если бы была только одна социальная сеть в мире и никто бы не больше пытался сделать нечто подобное. Некоторые похожие черты есть – это понятно. Но надо сказать, что некоторые вещи мы придумали сами, а некоторые – первыми сделали. Мне кажется, в этом году это особенно заметно. Мы не стараемся быть похожими на них, но стараемся давать пользователям максимум того, что сейчас можно сделать в области социальных сетей.
Вопрос из зала:
Вопрос по поводу API. Вы планируете какую-то функцию для работы с группами? В частности, интересует загрузка видео через API именно в группы.
Олег Илларионов:
Разговоры об этом когда-то были. Правда, не про видео, а про фотографии. В целом, если посмотреть на список задач, которые у нас есть, его хватит на несколько лет. Но я думаю, что движение во всех направлениях в области API будет, и особенно в том, о котором вы упомянули.
Вопрос из зала:
Вы делаете какое-то нагрузочное тестирование перед тем, как что-то выпустить в "продашн"? Если делаете, то какое?
Олег Илларионов:
Смотря чего. Что вас интересует?
Вопрос из зала:
Например, та же XMPP-информация.
Олег Илларионов:
XMPP – конечно. Есть скрипт, который имитирует много Олегов Илларионовых, которые соединяются с сервером. Другие вещи (некоторые "продакшн" на PHP) тестируются другим способом. Когда выпускаются какие-то сомнительные вещи, которые могут все повалить, выпускаются сначала на первый миллион, потом чуть больше – с градацией. Даже иногда сначала на первые 10 тысяч, а потом все больше, больше, больше.
Вопрос из зала:
Есть "продакшн" баз данных. Вы делаете репликацию, когда проводите тестирование или этим вообще не приходится заниматься?
Олег Илларионов:
Идёт тестирование на пользователях. Первая тысяча, первые 10 тысяч – если мы видим, что пользователи слишком сильно грузят базу данных, то мы ставим больше кэширования на memcache и так далее. Надо сказать, что не все ВКонтакте работает на MySQL. Многие вещи работают на специальных движках "Си". Есть небольшая команда, работающая с "Си", которая занимается этим. Особенно нагруженные вещи, естественно, работают на "Cи".

Комментарии

Нет ни одного комментария

Только пользователи могут оставлять комментарии

Возможно, вам будет интересно:

Вадим Макеев

Вадим Макеев

Веб-евангелист из Opera Software, руководитель и редактор проекта Веб-стандарты, автор блога о технологиях Пепелсбей.net. Организатор конференций РИТ и Web Standards Days, докладчик и активный участник многих других. Автор идеи проекта Zen Coding и движка для презентаций Shower.

Вадим Макеев (Opera Software) затрагивает "наболевшую" тему префиксов в CSS и говорит о будущем этой технологии.

Видео и презентация доклада Германа Клименко на WhaleRider 2012.

Филипп Торчинский

Филипп Торчинский

С 1994 года популяризирует открытые технологии и UNIX-решения. Работал экспертом по ОС Solaris в Sun Microsystems и Oracle. Автор двух книг по администрированию UNIX и Solaris.

Преподаватель и евангелист Solaris Филипп Торчинский говорит реальном опыте построения сетей с единой аутентификацией, но без Active Directory.