Компания
87,35
рейтинг
21 марта 2011 в 14:04

Разработка → Архитектура и платформа проекта Одноклассники

Архитектура и платформа проекта Одноклассники


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

Базовая статистика

До 2.8 млн. пользователей в онлайне в часы пик
7,5 миллиардов запросов в день (150 000 запросов в секунду в часы пик)
2 400 серверов, систем хранения данных
Сетевой трафик в час пик: 32 Gb/s

Архитектура

Слоеная архитектура:

• presentation layer (презентационный слой или попросту WEB сервера, формирующие HTML)
• business services layer (сервера, обеспечивающие подбор и обработку данных)
• caching layer (кеширование часто используемых данных)
• persistence layer (сервера БД)
• common infrastructure systems (системы логирования статистики, конфигурации приложений, локализация ресурсов, мониторинг)

Презентационный слой:

• Используем свой фреймворк, позволяющий строить композицию страниц на языке JAVA, используя собственные GUI фабрики (оформление текста, списки, таблицы, портлеты).
• Композиция страниц состоит из независимых блоков (обычно портлетов), что позволяет обновлять информацию на экране частями, используя AJAX запросы. Такой подход к навигации позволяет избавиться от постоянных перезагрузок страницы, тем самым важные функции сайта (Сообщения, Обсуждения и Оповещения) всегда доступны пользователю. Без javascript страница полностью работоспособна, кроме функциональностей, написанных на GWT — при переходах по ссылкам она просто полностью перерисовывается.
• Функциональные компоненты как Сообщения, Обсуждения и Оповещения, а также все динамичные части (шорткат меню, фотометки, сортировка фотографий, ротирование подарочков) написаны, используя фреймворк Google Web Toolkit.

Подбор, обработка и кеширование данных:

Код написан на Java. Есть исключения – некоторые модули для кеширования данных написаны на C и C++.
Java потому, что это удобный для разработки язык, много наработок в различных сферах, библиотек, open source проектов на Java.
На уровне бизнес логики располагаются порядка 25 типов серверов/компонентов и кешей, которые общаются между собой через удаленные интерфейсы. Каждую секунду происходит порядка 3 000 000 удаленных запросов между этими модулями.
Для кеширования данных используется «самописный» модуль odnoklassniki-cache. Он предоставляет возможность хранения данных в памяти средствами Java Unsafe. Кешируем все данные, к которым происходит частое обращение. Например: информацию из профайлов пользователей, группы пользователей, информацию о самих группах, конечно же, граф связей пользователей, граф связей пользователей и групп, праздники пользователей, некоторую мета информацию о фотографиях и т.п.
Для примера, один из серверов, кеширующий граф связей пользователей, в час пик способен обработать около 16 600 запросов в секунду. CPU при этом занят до 7%, максимальный load average за 5 минут — 1.2. Количество вершин графа > 85 миллионов, связей 2 500 миллиона (два с половиной миллиарда). В памяти граф занимает 30 GB.

Распределение и балансировка нагрузки:

• взвешенный round robin внутри системы;
• вертикальное и горизонтальное партиционирование данных как в базах данных, так и на кеширующем уровне;
• сервера на уровне бизнес логики разбиты на группы. Каждая группа обрабатывает различные события. Есть механизм маршрутизации событий, т.е. любое событие (или группу событий) можно выделить и направить на обработку на определенную группу серверов.
Управление сервисами происходит через централизованную систему конфигурации. Система самописная. Через WEB интерфейс можно поменять расположение портлетов, конфигурацию кластеров, изменить логику некоторых сервисов и т.д. Измененная конфигурация сохраняется в базе данных. Каждый из серверов периодически проверяет, есть ли обновления для приложений, которые на нем запущены. Если есть – применяет их.

Данные, сервера БД, резервные копии:

Общий объем данных без резервирования – 160 TB. Используются два решения для хранения и сервирования данных – MS SQL и BerkeleyDB. Данные хранятся как минимум в двух копиях. В зависимости от типов данных, копий может быть от двух до четырех. Имеется ежесуточный бэкап всех данных. Каждые 15 минут делаются резервные копии накопившихся данных. В результате такой стратегии резервного копирования максимально возможная потеря данных – 15 минут.

Оборудование, датацентры, сеть:

Используются двухпроцессорные, 4-х ядерные сервера. Объем памяти от 4 до 48 GB, в зависимости от функционала. В зависимости от типов и использования данных, они хранятся либо в памяти серверов, либо на дисках серверов, либо на внешних системах хранения.
Все оборудование размещено в 3 датацентрах. Всего около 2 400 серверов и систем хранения данных. Датацентры объединены в оптическое кольцо. На данный момент на каждом из маршрутов емкость составляет 30 Gb/s. Каждый из маршрутов состоит из физически независимых друг от друга оптоволоконных пар. Эти пары агрегируются в общую “трубу” на корневых маршрутизаторах.
Сеть разделена на внутреннюю и внешнюю. Сети разделены физически. Разные интерфейсы серверов подключены в разные коммутаторы и работают в разных сетях. По внешней сети WEB сервера, общаются с миром. По внутренней сети все сервера общаются между собой.
Топология внутренней сети – звезда. Сервера подключены в L2 коммутаторы (access switches). Эти коммутаторы подключены как минимум двумя гигабитными линками к agregation стеку маршрутизаторов. Каждый линк идет к отдельному коммутатору в стеке. Для того, чтобы эта архитектура работала, используем протокол RSTP. При необходимости, подключения access коммутаторов к agregation стеку осуществляются более чем двумя линками. Тогда используется link aggregation портов.
Agregation коммутаторы подключены 10Gb линками в корневые маршрутизаторы, которые обеспечивают как связь между датацентрами, так и связь с внешним миром.
Используются коммутаторы и маршрутизаторы от компании Cisco. Для связи с внешним миром мы имеем прямые подключения с несколькими крупнейшими операторами связи
Сетевой трафик в часы пик – 32 Gb/s

Система статистики:

Существует библиотека, отвечающая за логирование событий. Библиотека используется во всех модулях. Она позволяет агрегировать статистику и сохранять ее во временную БД. Само сохранение происходит с помощью библиотеки log4j. Обычно храним количество вызовов, максимальное, минимальное и среднее время выполнения, количество ошибок, возникших при выполнении.
Из временных баз вся статистика сохраняется в DWH. Каждую минуту сервера DWH ходят во временные базы в production и забирают данные. Временные базы периодически очищаются от данных.

Пример кода, который сохраняет статистику об отосланных сообщениях:

public void sendMessage(String message) {
   long startTime = LoggerUtil.getMeasureStartTime();
   try {
       /**
        * business logic - send message
        */
        LoggerUtil.operationSuccess(LogFactory.getLog({log's appender name}), startTime, "messageService", "sendMessage");
    } catch (Exception e) {
        LoggerUtil.operationFailure(LogFactory.getLog({log's appender name}), startTime, "messageService", "sendMessage");
    }
}


Наша система DWH хранит всю статистику и предоставляет инструменты для ее просмотра и анализа. Система построена на базе решений от Microsoft. Сервера баз данных – MS SQL 2008, система генерации отчетов – Reporting services. Сейчас DWH – это 13 серверов, находящихся в отделенной от production среде. Некоторые из этих серверов обеспечивают операционную статистику (т.е. онлайн статистику). Некоторые отвечают за хранение и предоставление доступа к исторической статистике. Общий объем статистических данных — 13 TB.
Планируется внедрение мультиразмерного (multi-dimension) анализа статистики на основе OLAP.

Мониторинг

Мониторинг разделен на две составляющие:

1. Мониторинг сервисов и компонентов сайта
2. Мониторинг ресурсов (оборудование, сеть)
Первичен мониторинг сервисов. Система мониторинга своя, основанная на оперативных данных в DWH. Есть дежурные, чья обязанность мониторить показатели работы сайта и в случае каких-либо аномалий предпринимать действия для выяснения и устранения причин этих аномалий.
В случае с мониторингом ресурсов, следим как за “здоровьем” оборудования (температура, работоспособность компонентов: CPU, RAM, дисков и т.д.), так и за показателями ресурсов серверов (загрузка CPU, RAM, загруженность дисковой подсистемы и т.п.). Для мониторинга “здоровья” оборудования используем Zabbix, статистику по использованию ресурсов серверов и сети накапливаем в Cacti.
Оповещения о наиболее критичных аномалиях приходят по смс, остальные оповещения отсылаются по емейлу.

Технологии:

• Операционные системы: MS Windows, openSUSE
• Java, C, C+. Весь основной код написан на Java. На С и С+ написаны модули для кеширования данных.
• Используем GWT для придания динамики WEB интерфейсу. С использованием GWT написаны такие модули как Сообщения, Обсуждения и Оповещения
• WEB сервера – Apache Tomcat
• Сервера бизнес логики работают под JBoss 4
• Балансировщики нагрузки на WEB слое – LVS. Используем IPVS для балансировки на Layer-4
• Apache Lucene для индексирования и поиска текстовой информации
• Базы данных:
MS SQL 2005 Std edition. Используется во многом потому, что так исторически сложилось. Сервера с MS SQL объединены в failover кластера. При выходе из строя одной из рабочих нод, standby нода берет на себя ее функции
BerkeleyDB – для работы с BDB используется своя, внутренняя библиотека. Используем BDB, C реализацию, версии 4.5. Двухнодовые master-slave кластера. Между мастером и слейвом родная BDB репликация. Запись происходит только в master, чтение происходит с обеих нод. Данные храним в tmpfs, transaction логи хранятся на дисках. Каждые 15 минут делаем бэкап логов. Сервера одного кластера размещены на разных лучах питания дабы не потерять обе копии данных сразу.
В разработке новое решение для хранения данных. Нам необходим еще более быстрый и надежный доступ к данным.
• При общении серверов между собой используем свое решение, основанное на JBoss Remoting
• Общение с SQL базами данных происходит посредством JDBC драйверов

Люди:

Над проектом работают около 70 технических специалистов. Из них 40 разработчиков, 20 системных администраторов и инженеров, 8 тестеров.
Все разработчики разделены на небольшие команды (1-3 человек). Каждая из команд работает автономно и разрабатывает либо какой-то новый сервис, либо работает над улучшением существующих. В каждой из команд есть технический лидер или архитектор. Он ответственен за архитектуру сервиса, выбор технологий и подходов. На разных этапах разработки к команде могут примыкать дизайнеры, тестеры и системные администраторы.
Например, существует отдельная команда сервиса Группы. Или команда, разрабатывающая коммуникационные сервисы сайта (такие как системы сообщений, обсуждений, ленту активности). Есть команда платформы, которая тестирует, обкатывает и внедряет новые технологии, оптимизирует уже существующие решения. В данный момент одна из задач этой команды – разработка и внедрение высокоскоростного и надежного решения для хранения данных.

Основные принципы и подходы в разработке

Разработка ведется небольшими итерациями. Как пример жизненного цикла разработки можно привести 3-х недельный цикл:
0 неделя — определение архитектуры
1 неделя — разработка, тестирование на компьютерах разработчиков
2 неделя — тестирование на pre-production среде, релиз на production среду

Практически весь новый функционал делается «отключаемым». Типичный запуск новой «фичи» выглядит следующим образом:
1. функционал разрабатывается и попадает в production релиз
2. через централизованную систему конфигурации функционал включается для небольшой части пользователей. Анализируется статистика активности пользователей, нагрузка на инфраструктуру
3. если предыдущий этап прошел успешно, функционал включается постепенно на все большей аудитории. Если в процессе запуска нам не нравится собранная статистика, либо непозволительно вырастает нагрузка на инфраструктуру, то функционал отключается, анализируются причины, исправляются ошибки, происходит оптимизация и все повторяется с 1-го шага

Best practices, tricks & tips

Специфика работы с СУБД:

• Мы используем как вертикальное, так и горизонтальное партиционирование, т.е. разные группы таблиц располагаются на разных серверах (вертикальное партиционирование), а данные больших таблицы дополнительно распределяются между серверами (горизонтальное партиционирование). Встроенный в СУБД аппарат партиционирования не используется — вся логика располагается на уровне бизнес сервисов.
• Распределенные транзакции не используются — все транзакции только в пределах одного сервера. Для обеспечения целостности, связанные данные помещаются на 1 сервер или, если это невозможно, дополнительно программируется логика восстановления данных.
• В запросах к БД не используются JOIN даже среди локальных таблиц для минимизации нагрузки на CPU. Вместо этого используется денормализация данных или JOIN происходят на уровне бизнес сервисов. В этом случае JOIN происходит как с данными из БД, так и с данными из кеша.
• При проектировании структуры данных не используются внешние ключи, хранимые процедуры и триггеры. Опять же для снижения нагрузки на CPU серверов БД.
• SQL операторы DELETE также используются с осторожностью — это самая тяжелая операция из DML. Стараемся не удалять данные лишний раз или используем удаление через маркер — запись сначала отмечается как удаленная, а потом удаляется фоновым процессом из таблицы.
• Широко используются индексы. Как обычные, так и кластерные. Последние для оптимизации наиболее частых запросов в таблицу.

Кеширование:

• Используются кеш сервера нашей собственной разработки, реализованные на Java. Некоторые наборы данных, как например профили пользователей, социальный граф, и т.п. целиком хранятся в кеше.
• Данные партиционируются на кластер кеш серверов. Используется репликация партиций для обеспечения надежности.
• Иногда требования к быстродействию настолько велики, что используются локальные короткоживущие кеши данных полученных с кеш серверов, расположенные непосредственно в памяти серверов бизнес логики.
• Кеш сервера, кроме обычных операций ключ-значение, могут выполнять запросы по данным, хранящимся в памяти, минимизируют таким образом передачу по сети ненужных данных. Используется map-reduce для выполнения запросов и операций на кластере. В особо сложных случаях, например для реализации запросов по социальному графу, используется язык C. Это помогает повысить производительность.
• Для хранения больших объемов данных в памяти используется память вне кучи Java (off heap memory) для снятия ненужной нагрузки с Java GC.
• Кеши могут использовать локальный диск для хранения данных, что превращает их в высокопроизводительный сервер БД.

Оптимизация скорости загрузки и работы страницы

• Кешируем все внешние ресурсы (Expires и Cache-Control заголовки). CSS и JavaScript файлы минимизируем и сжимаем (gzip).
• Для уменьшения количества HTTP запросов с браузера, все JavaScript и CSS файлы объединяются в один. Маленькие графические изображения объединяются в спрайты.
• При загрузке страницы скачиваются только те ресурсы, которые на самом деле необходимы для начала работы.
• Никаких универсальных CSS селекторов. Стараемся не использовать типовые селекторы (по имени тэга).
• Если необходимы CSS expressions, то пишем «одноразовые». По возможности избегаем фильтров.
• Кешируем обращения к DOM дереву, а так же свойства элементов, приводящие к reflow. Обновляем DOM дерево в «оффлайне».
• В GWT используем UIBinder и HTMLPanel для создания интерфейсов.

Полезного чтения! Будем рады вопросам.
Автор: @Odnoklassniki_ru
Одноклассники
рейтинг 87,35

Комментарии (181)

  • +16
    Очень интересная статья, спасибо.

    Не думал что на таких высоконагруженных серверах используются серверные Windows :)
    • +3
      Особенно не думалось что используется связка Win + Apache
      • +12
        Под Win работает только MSSQL сервера, Apache Tomcat — под Linux
        • 0
          Очень странная связка.

          Обычно я слышу про MySQL+php, Oracle+java, MSSQL+ASP.NET

          Но в чем эффективность такого решения? Я понимаю, что «так исторически сложилось», но все-таки разработчики, которые первыми продумывали архитектурные решения, чем-то мотивировали свой выбор?
          • 0
            имхо, исторически было asp.net + mssql

            а остальные технологии насаживали на ходу.
        • +1
          очень интересные цифры, вызывает уважение, несмотря на то, что одноклассниками не особо пользуюсь, я не из таргет группы, но красиво — 150К запросов в секунду.

          правда интересно, ничего не имею против MS SQL, но как то в энтерпрайз джава мире принято использовать всякие oracle\sybase (не будет помянут всуе). интересно, были ли какие то проблемы специфические для MS SQL, просто любопытно, каковы впечатления?

          и еще очень интересно — а кэши ваши самописные, неужто никакие стандартные решения не подошли типа coherence\ehcache\hibernate? или просто сложилось исторически?
          • +1
            Наши кеши «интеллектуальные» и содержат в себе специфическую логику например: для уменьшения ненужного трафика, для синхронизации с базой, для более оптимальной чистки устаревших данных и т.д. в зависимости от задачи.

            Что каксается coherence — он стоит не малых денег.
            • +3
              понимаю, вполне могу представить заточенный под приложение кэш
              а про кохеренс да, есть такой момент. но тут каждый сам решает, мой работодатель решил все таки вложиться деньгами, пока не жалеем
              спасибо за ответ. удачи вам — моя мама вас очень любит :)
        • 0
          А почему никто не произности postgresql? Говорят, что ей можно заменить MS SQL и работает опять же везде.
          • 0
            А для pg есть какой-нибудь аналог rs?
            • 0
              что такое rs?
              • 0
                Reporting services.
                • 0
                  Это прямо скажем не мое поле (почему и завел речь), но я вижу, что PostgreSQL дружат с Crystal Reports. Понятно, что интегрированного решения нет, но 3rd party, скорее всего будет несколько, в зависимости от задач.
                  • 0
                    Есть также jasper reports(http://jasperforge.org/), что за зверь не знаю и с Reporting Service от MS сравнить не могу.
    • 0
      Если используют Java, то думаю все равно под какой системой запускать, JVM отрабатывает одинаково.
  • –3
    SQL операторы DELETE также используются с осторожностью — это самая тяжелая операция из DML. Стараемся не удалять данные лишний раз или используем удаление через маркер — запись сначала отмечается как удаленная, а потом удаляется фоновым процессом из таблицы.

    И что, и с аккаунтами пользователей так? Или просто помечаете, как удаленные?
    • +1
      Да. Все удаление происходит через некоторое время. На каждый тип данных создаем задачи на удаление, которые ваполнятся в будещем. В конечном итоге для удаленной сущности произойдет удаление всех данных относящихся к удаленному объекту.
      • +4
        Сделайте [strong]внятную[/strong] кнопку в интерфейса «пометить аккаунт на удаление».
        Стирать можете месяц-квартал, но удаление аккаунта должно быть.
        А то затуманили ерунду «закрыть аккаунт», «игнорируете невозможность удаления».
  • –3
    7,5 миллиардов запросов в день (150 000 запросов в секунду в часы пик)
    2 400 серверов, систем хранения данных
    Сетевой трафик в час пик: 32 Gb/s

    После простых рассчетов получаем:
    62,5 запроса/сек на сервер в часы пик
    13 мб/с на сервер.

    А теперь вопрос — вы специально гоняете аппаратуру вхолостую или в этом есть сакральный смысл (т.е. возможен вариант лавинообразного роста)

    Или в описания закралась ошибка?

    • +8
      Не все сервера одинаковые, поэтому делить 150 тыс/ на общее число серверов некорректно.
      • +14
        Скажем так «не совсем корректно»
        Количество обрабатываемых запросов в секунду, деленное на количество серверов — это скорее не количественная, а качественная характеристика.

        Приведу пример — на один сервер «вконтакте» приходится около 500 запросов/сек и до 600 в часы пик.
        На один сервер facebook после введения Hip-hop приходится около 800 запросов/сек

        Т.е. минимум в 8 раз больше.

        Наврядли характер нагрузки этих проектов сильно отличается от характера нагрузки «одноклассников»

        Кроме того, эти проекты написаны на php, а о его быстродействии большинству здесь уже известно.

        Кроме того, команда «вконтакте» на данный момент — это 40 человек (против 70 у Вас)

        В итоге делаем вывод, что или эффективность вашей архитектуры низка сама по себе, или вы специально не позволяете загрузке уходить дальше 15% рубежа.
        • +1
          В фейсбуке PHP транслируется в С++ код, а затем С++ компилируется. За счёт этого и достигается такая высокая продуктивность кода
          • 0
            Да, но вы же понимаете, что компилируется он в очень высокоуровневый C++-код, который от интерпретатора не так сильно отличается?
            • +1
              Интерпретатор всегда _намного_ медленнее за компилируемый код + в Фейсбуке используют только некоторые из возможностей PHP (источник не помню).

              Несколько цитат из: developers.facebook.com/blog/post/358/

              >> With HipHop we've reduced the CPU usage on our Web servers on average by about fifty percent, depending on the page

              >> PHP is a scripting language with dynamic, weak typing. <...> Whenever possible our generated code uses static binding for functions and variables. We also use type inference to pick the most specific type possible for our variables and thus save memory.
              • 0
                Скорее всего вы правы и там какой-то особенный, хип-хоп-предсказуемый код. А еще интересно какие он ошибки выдает (ну не сегфолты же).
            • 0
              Но тем не менее интерпретатор выполняет код на ходу, а c++ уже готовый бинарный код — разница как минимум должна быть заметна невооруженным глазом.
              • 0
                > Но тем не менее интерпретатор выполняет код на ходу, а c++ уже готовый бинарный код

                Готовый бинарный код, который делает все на ходу)
                • 0
                  Ну вы поняли что я хотел сказать) Только HipHop велосипед еще тот. Только такой монстр как facebook мог себе позволить такой велосипед. На других проектах проще было бы переписать на python/ java/ c++/ etc. и не парится.
                  • 0
                    В том-то и дело, что не очень. То есть там все очень от реализации зависит. Можно сделать сверхабстракции для универсальных переменных на всех типах, да еще чтоб ошибки вменяемые выдавало, но боюсь, что этот код будет куда медленнее интерпретатора. Так что наверняка прирост в скорости за счет каких-то ограничений, благодаря которым код на плюсах не слишком абстрактный, а не просто за счет компиляции.
          • +1
            что-то мне кажется, что Facebook давно уже все критичные к производительности компоненты переписал на C++
            несмотря на все громкие заявления про дополивание PHP, наверняка он по большей части работает как шаблонизатор/компоновщик
    • +4
      Под количеством запросов имелись ввиду запросы, приходящие от пользователей к нашим фронтендам (HTTP + AJAX). Фронтендов в данный момент у нас порядка 150
      • +2
        Но кроме фронт-энд серверов у Вас имеется целая инфраструктура, созданная для качественного увеличения показателя запросы/сек? Просто если весь удар приходится только на эти 150 серверов, то смысл держать остальные 2000 машин? просто «на всякий случай»?

        Просто я не вижу смысла содержать столь огромный парк серверов для довольно средних показателей, и я хочу узнать — может Вы совершаете еще какие-то операции, о которых не указано в статье?
        • +1
          У нас 150 фронтэндов и 150 000 запросов в сек. Т.е. 1000 запросов/сек рендеринга на сервер.
          Осталные сервера — базы данных, статистика, кеши, специфические сервисы…
          Я думаю у вас нет сомнений, что в выше упомянутых проектах кроме веб серверов с PHP есть и другая инфраструктура.

          • –1
            Верно, но я выше написал, что даже при инфраструктуре больших размеров «вконтакте» обрабатывает большее количество запросов на сервер, минимум в 8 раз при сходном характере нагрузки.

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

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

            Спасибо за статью.
            • +7
              Если есть желание сравнить инфраструктуры разных соц. сетей, приводите объективные критерии и желательно цифры основанные на каких-то более менне достоверных источниках.

              Например, та информация, которая доступна по facebook и вконтакте мне лично говорит об обратном. Например для facebook фигурировала усреденная оценка количество запросов страниц к колеству севреров в месяц — 7млн. В нашем случае ~ 90 млн. Так же не в пользу вами выше упомянутых проектов отношение пользователей к количеству серверов.
              Так что не очень понятно, откуда такие оценки.
        • +4
          Мы привели показатель количества запросов в нашей статье сознательно как раз для того, чтобы можно было сравнить нагрузку на нашу инфраструктуру, с нагрузкой на других сайтах. На каждый запрос нужно подготовить и отослать ответ. По той информации, которую можно найти в Интернете, количество подобных запросов у Вконтакте — 11 миллиардов в день, у Twitter-а 6 миллиардов запросов в день к API, LinkedIn — 40 миллионов просмотров страниц в день, Facebook — 200 миллиардов просмотров страниц в месяц. Каждый пользовательский запрос на просмотр страницы конечно порождает различное количество запросов внутри инфраструктуры. Количество этих запросов сравнивать нельзя так как оно зависит от пострения платформы. А платформы у разных сайтов разные.
        • 0
          Просто если весь удар приходится только на эти 150 серверов, то смысл держать остальные 2000 машин? просто «на всякий случай»?

          Вы оправдываете свой ник
    • –1
      Совершенно с вами согласен. Цифра 2400 сразу бросается в глаза и хочется узнать зачем так много…
      • –3
        Ну, кто-то оптимизирует код, запросы, структуру БД, а кто-то покупает сервера.
        Что умеют, то и делают.
        • +14
          вы так говорите, будто смасштабировать нагрузку на две с половиной тыщи машин — это проще, чем оптимизировать код.
          • –4
            проще, чем и оптимизировать код, и смасштабировать нагрузку.
        • +2
          покупать сервера межу прочим очень дешевый способ, так что это очень логично.
          • –4
            дешевле не значит лучше. Да и всему есть предел.
            А о качестве кода прямо и косвенно говорит:
            во-первых, приведенный пример в топике (обычно хвастаются самым лучшим)
            и во вторых, откровенно тормозной интерфейс (чему там тормозить-то? но ведь тормозит)
            • +17
              Слушайте, вы делаете какие-то далекоидущие выводы на основе псевдокода, что не очень-то хорошо характеризирует именно вас. Не нравится Одноклассники и хочется об этом сказать всем, так и напишите, зачем такие сложные логические цепочки: «пример не понятный, но лучше думать что гавно, значит у них весь код гавно, значит там работают идиоты, делают проект гавно и пользуются им идиоты, а я такой в белом»? Кому от таких размышлений станет лучше? И так хабр мусорными комментариями забит.

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

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

              Не знаю что тормозит в интерфейсе, не видел после первой версии, сделайте исследование, выложите на хабр, может вас пригласят на работу.
              • –6
                А Ваш комментарий не «мусорный»? не думали его в виде личного сообщения отправить?
                Теперь по теме:
                Приведенный код не говорит об «узком месте», он говорит о подходе — когда исключения скрываются и вызывающий код ничего не знает о результате вызова.
                Далее: я обеими руками «за» увеличение производительности системы любыми доступными способами, в том числе и за счет увеличения количества однотипных серверов.
                В какой-то момент времени увеличение производительности системы (за счет оптимизации кода) даже на 1% — даст высвобождение десятков серверов.
                А уже обсосанное здесь со всех сторон число запросов на 1 сервер дает нам понять что либо сервера не нагружены (а это не рентабельно, а значит маловероятно), либо код далеко не оптимален.
                • +5
                  А зачем оптимизировать на 1%, если это требует работы программистов? Сравните стоимость оптимизации и цену на сервера. Сравните с тем, что если бы код оптимизировался на 3 месяца дольше, то новая фунциональность появилась бы на 3 месяца позже. Например если бы платные приложения появились позже, то за эти месяцы компания не получила бы прибыль, а программисты кушать таки просили. Вот и получится цена оптимизации.

                  Еще раз, стоимость железа — это самая маленькая часть проекта, обычно до 10% в IT компаниях, если больше то уже вызывает вопросы.
                  • –1
                    Возмем 1% от 2400 сферических серверов в вакууме. Получим 24.
                    24 даже самых дешевых сервера это сколько программисто-месяцев? Так что целесообразность даже в этом случае есть.

                    На счет недополучения прибыли Вы не совсем правы. Процесс оптимизации может идти параллельно разработке; он может проводится (а в некоторых случаях должен) проводиться неким третьим лицом. Чтобы был так сказать «взгляд со стороны» на проблему.

                    откуда цифра 10%? имхо это больше относится к компаниям разрабатывающим софт, а не оказывающим услугу. Или у хостеров тоже до 10%?
                    • –1
                      Вы готовы предоставить точные цифры для подтверждения своих слов, или просто потелепать языком хотите? Если первое, то начните с этого, а если не в теме, то лучше не телепать языком зря. Я думаю в одноклассниках подумали над оптимизацией, прикинули что выгодней, а не сломя голову побежали покупать сервера.
                      • +1
                        ключевой слово и у Вас и у меня: «я думаю».
                        про 10% Вы так и не ответили.
                        • 0
                          Ключевое действие у меня — никаких утверждений. Я высказал лишь стандартное действие стандартного разработчика, учитывая что в статье автор пишет что они думают неделю над архитектурой, значит они могут себе позволить подумать и над производительностью. Про 10% Вы не меня спрашивали.
                          • +1
                            извините, проглядел ник.
          • 0
            Дешево, конечно, но правило «больше связей, выше вероятность отказа» до сих пор работает.
            А если еще вспомнить про первый закон Мерфи, то 502 ошибка может стать нередким явлением по вечерам.
            • +5
              Весь ваш организм это большое количество связей, но он был изначально так спроектирован и продолжает работать. Если архитектура построена с нацелом на связи то она может так работать долго и успешно. Мне как раз больше не понравилась иерархия типов серверов, 25 разных видов — это наверное ад для администрирования и выстраивания взаимодействий, похоже людям как раз за это и платят деньги.

              Архитектура в которой можно для увеличения производительности воткнуть еще пару сотен серверов самая правильная. Законы Мерфи цитировать в треде об архитектуре, уж простите, но моветон.
              • +2
                В вопросах построения архитектуры я тоже руководствуюсь принципом «чем проще, тем дольше проработает»

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

                Все это — плата за сложность и за то, что каждая часть выполняет только свою узкую функцию.

                Топология связей человеческого тела — это сильноветвящееся дерево, где опорными узлами являются спинной и головной мозг.

                Кроме этого абсолютно все операции приходится проводить на продакшене, и никакой версионности.

                Поэтому, как организм, человек совершенен, но как компьютерная система он ужасен.

          • 0
            способ дешевле (в перспективе) — сделать всё по уму и сокращать количество железа :)
    • +1
      Это только запросы со стороны конечного пользователя. Сереверов много для обеспечения работы разных сервисов/компонентов. Если интересны данные по запросам по всем серверам, то такое тоже есть — Прошелся по серверам EJB/Cache/SQL/BDB/WEB/Remote Service/Components и получилос 5'026'666 запросов/сек в час пик. На сервер получается ~2000 запросов/сек в час пик.
      Серверов много, так что данные примерные. Есть опасения, что что-то мог упустить.
      Так-же и разброс на количеству запросов на тип сервера тоже большой. К примеру на граф приходится ~16K запросов.
      • –3
        Т.е. количество внутренних запросов в десятки раз больше (а именно примерно в 30 раз)?
        Таким образом в среднем необходимо выполнить 30 запросов к разным серверам для выдачи одного рендера?

        Вы считаете это приемлемым?

        Меня бы за такое сначала капитально вздрючили, а потом повесили мою фотку над кофеваркой с подписью «Этот человек — основная причина скоропостижной смерти серверов».

        • +4
          Какое кол-во запросов на один физический сервер будет нормальным при нашем объме информации и какаю будет конфигурация данного сервера?
          • +2
            Удовлетворительное значение — не более 15 запросов ( в среднем ).
            При этом точность попадания в кеш должна быть не ниже 60%
            Вероятность использования данных, генерированных заранее, но не попавших в кеш из-за относительно редкого использования не менее 20%, все остальное может генерироваться.

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

            В этом плане к идеалу максимально приблизился facebook
            Подчерпнуть сжатую информацию об его архитектуре можно в заметке www.insight-it.ru/masshtabiruemost/arkhitektura-facebook/
            • +3
              А кто сказал, что у нас запросы выполняются последовательно? Если действительно есть необходимость и есть возможность, то запросы идут параллельно. Так что я бы не утверждал, что на пользовательский запрос требуется 30 последовательных запросов по внутренней инфраструктуре.

              Данные естественно кешируются — от экранных портлетов до конкретных сущностей. Попадание в кеш >75%. К примеру кластер кеша метаинформации по фотографии работает 130000/5833 запросов/сек. (где 5833 запроса в базу за недостающими данными).
    • –1
      Запросы принимают несколько серверов, которые смотрят наружу.
  • +4
    Абсолютные цифры смотрятся внушительно, наверное на это и был расчет. А как дело в сравнении с другими? Чем ваш подход, ваша система лучше/быстрее/надежнее/… чем..., ну скажем так другие системы?
  • 0
    Вопрос не совсем технический, больше политический. Что происходит с удалёнными учётными записями после их удаления?
    • 0
      «запись сначала отмечается как удаленная, а потом удаляется фоновым процессом из таблицы»
      • 0
        Я имел ввиду не запись в БД, а все данные пользователя.
        • +1
          Так происходит практически с любыми данными пользователя
  • +2
    Странный пример кода. Как код, вызывающий функцию sendMessage(String message) узнает об успехе/неудаче при отправке сообщения?
  • 0
    1. факапы часто бывают? ;)
    2. про тестирование не написали. оно есть?
    • 0
      Написали же: 8 тестировщиков. Видимо, тестирование есть ]:-)
      И еще ниже про тестирование кода (на 1 неделе итерации).
  • –11
    Месяц назад пытался зарегистрироваться, СМС так и не пришла. Раз 5 пытался запросить сообщение повторно, но его так и нет до сих пор. Оператор Билайн.
    • +1
      Ну если это такая техническая фишка, то ок.
  • +4
    Заинтересовал ваш фреймворк:
    «Используем свой фреймворк, позволяющий строить композицию страниц на языке JAVA, используя собственные GUI фабрики (оформление текста, списки, таблицы, портлеты).»

    Он когда-нибудь появится в open source?

    Если слишком наглый вопрос, простите =)
    • +1
      Могу заблуждаться, но разве на Java мало web-фреймворков?
      • 0
        Не мало.

        Но интересно, что же использует «одноклассники».

        Вон, ребята из FB же выложили hiphop.
    • 0
      Давно когда-то были идеи все отдать в opensource. В реальности на запуск и последующую поддержку opensource проектов может уйти много времени, но его как всегда нет.
  • +19
    риторический вопрос: когда у вас будет всё нормально и стабильно работать? )
    • +7
      зачем?
      • +9
        «зачем?» — тоже риторический вопрос ;)
    • 0
      Даже на быстрых соединениях сайт тормозит. Пробывал с разных браузерах.
      • +1
        Подробнее, что именно тормозит? Загрузка страницы, переход по внутренним страницам, отправка сообщений или комментариев...?
        • 0
          загрузка и javascript медленный
        • +2
          сообщения, переход по страницам, просмотр фотографий…
        • +1
          Не знаю как сейчас, но когда у меня стоял 1.6 GHz Athlon 1GB ОЗУ, то открытие страницы вешалось на несколько секунд джавакскриптом. Я люблю открывать несколько вкладок одного сайта, но такой функционал я не мог выносить…
          Поэтому я купил себе новый комп )))
  • +1
    Пожелние организационное: многие знакомые периодически теряют аккаунты, пусть даже они сами пароли забывали, это не проблема, проблема в том что процедура восстановления пароля не срабатывала, сам несколько раз пробывал, в смс приходит проверочный код из 3 цифр, а нужно ввести 4.
    Возможно этот пост не к месту, извиняюсь… мне как бы уже все равно, с момента попытки восстановить пароль уже прошло слишком много времени, может кому другому это поможет. (Писал в письма даже в поддержку корпорации, но там накормили завтраками и забили.)
    • +1
      да, есть сложности при восстановлении, сейчас работаем над обновлением системы, пока писать можно сюда socialsupport@odnoklassniki.ru
      • +1
        Тоже странная тема, по логину конектится, по email нет…

        Несколько раз терял аккаунт, забавно если честно :)
  • +1
    Масштабно!
  • 0
    А для организации очередей что используете?
    • +75
      бабушек
    • +8
      Пропускаем очередь через Berkeley DB — QUEUE. Далее есть кластер java серверов для обработки заданий. На каждом из этих java серверов запущено N потоков. Каждый поток обрабатывает свою партицию из очереди.
      • +1
        Спасибо за ответ, а про раздачу статики можете поподробней рассказать? Судя по заголовкам используется Resin — в чем его приемущества перед тем же nginx?
        • 0
          «Работает и не трогай.» =) Пока нет проблем с текущим решением и причин менять на что-то новое.
      • 0
        А как добиваетесь отказоустойчивости очереди Berkeley DB?
        Каковы требования по надежности, насколько плохо потерять задание, которое попало в очередь? Потерять в результате фэйла железяки/ОС и т.д.
        • 0
          Для надежности данных используется родная Berkeley DB master-slave репликация базы. Особых проблем с QUEUE базой не наблюдалось.

          Если задание попало в очередь, то потерять данные будет уже сложно (пока не теряли). Пишутся логи на диск и постоянно идет реплика на другой сервер. Надежность на 100% не ожидаем (специфика сервиса работающего с данной очередью).
          В худшем случае при «hardware fail» на мастер сервере потеря составит <1 минуты работы сервиса. При этом значительного эффекта на систему не ожидаем. Сама система переходит в синхронный режим работы, пока проблемы с очередью не будут решены.

          В случае же транзакций по платным сервисам ожидаем 0% потери данных. Тут уже процесс реализован на основе MS SQL.
          • 0
            Опишите, пожалуйста, более подробно, как вы добиваетесь посредством MS SQL 100% сохранение данных и высокой доступности одновременно! Это жутко интересно. Репликация данных осуществляется за счет приложения или стандарных инструментов MS SQL? Синхронно или асинхронно? В общем, чем больше подробностей, тем круче.
            И да, спасибо за статью!
  • +2
    Скучновато немного — добавить бы пару графиков, диаграмм соединений серверов например, было бы значительно интереснее. Так получилось интересным только глубоко техническим специалистам.
    Но все равно спасибо
    • +6
      И коннекшн стринги пожалуйста!
  • +3
    Интересная статья. Спасибо.
  • 0
    А можно узнать, что примерно хранится в MS SQL а что в BerkleyDB? На первом, я так понимаю, статистика и отчеты бегают.
    • 0
      Данных много. Так что привиду только несколько примеров.
      SQL — сами пользователи, группы.
      BerkeleyDB — фотографии, система сообщений, новостная лента.
  • +3
    public void sendMessage(String message) {
       long startTime = LoggerUtil.getMeasureStartTime();
       try {
           /**
            * business logic - send message
            */
            LoggerUtil.operationSuccess(LogFactory.getLog({log's appender name}), startTime, "messageService", "sendMessage");
        } catch (Exception e) {
            LoggerUtil.operationFailure(LogFactory.getLog({log's appender name}), startTime, "messageService", "sendMessage");
        }
    }


    вот молодцы, как константы хорошо пределяют. Кстати, в чем крутость этого кода?
    • +16
      это, видимо, лучшая часть кода была :)
      • 0
        и приведен весь код метода
    • +1
      Никакой крутости. Все как раз очень просто. Этот код привели как пример того, как просто мы сохраняем статистику по времени выполнения операции, ее успешном (или неуспешном) завершении.
      • –1
        убогое решение:

        1. Dы глотаете исключения — никто и никогда не узнает в чем же была ошибка.

        2. название LoggerUtil никак не ассоциируется с сбором статистики
        поддерживать и не дай бог делать рефакторинг для этого кода крайне не удобно, более удобныеб гибки
        • –1
          сори, случайно запостился недописаный комент
          должно быть так

          убогое решение:

          1. Вы глотаете исключения — никто и никогда не узнает в чем же была ошибка.

          2. название LoggerUtil никак не ассоциируется с сбором статистики

          3. Поддерживать и не дай бог делать рефакторинг для этого кода крайне не удобно

          4. Более удобные и гибкие решения уже написаны до вас, поэтому мне кажется, что вы изобрели тругольное колесо
          • +1
            Категоричное суждение. Возможно вы слишком буквально восприняли наш пример.
            Конечно же это не готовый кусок кода. Там например нет объявления класса, импорта необходимых пакетов и т.п.

            LoggerUtil — это наш внутренний класс, которому просто надо передать что сохранить, а он сам знает куда сохранить и как это сделать.

            Я абсолютно согласен с вами что удобные и гибкие решения для логирования написаны до нас. Как написано в статье, мы как раз используем одно из них: библиотеку log4j (http://logging.apache.org/log4j/ или www.log4j.ru/)
    • +1
      А еще тут нет названия класса, не указан java packaga и непонятные Log* классы, которые не описаны в приведенном коде.

      Это ведь просто пример, что для сбора статистики просто делаем 1,2,3.
  • 0
    Логирование выглядит странно. Очень экстенсивно я бы сказал. Наверное применение AOP было бы здесь в самый раз. Да и наружу ошибка у вас не выдается.
    • 0
      AOP для сбора статистики тоже используется. Конкретно используется aspectj.
  • 0
    > В разработке новое решение для хранения данных. Нам необходим еще более быстрый и надежный доступ к данным.
    А не поделитесь, какое?
    • +2
      На java много всего в последнее вмемя написали. Смотрели/смотрим на: Cassandra/HBase/Tarantool/Voldemort/Redis/Kafka/Krati
    • 0
      Тема вообще интересная. Думаю может получиться хорошая статья — что, как, почему и к чему пришли.
  • +5
    Не могли бы Вы пояснить одну странную штуку?
    Вроде как все популярные интернет-проекты стараются по максимуму использовать геолокацию.
    В правилах же Одноклассников есть такая штука, как Принципы рассмотрения приложений, где один из пунктов гласит:
    Geo-location services — Не принимаем
    Это пережиток прошлого или какая-то своя политика?
    • 0
      Данный запрет относится к iframe приложениям. К мобильным\десктопным приложениям данный пункт не относится. Также в документации — каждый конкретный случай рассматривается отдельно- поэтому если у вас есть отличное приложение — пишите, договоримся.
      • 0
        Окей, спасибо, надеюсь договоримся :)
  • +3
    чето какая то сборная солянка: java c++ mssql bercleydb windows linux + куча своих костылей наработок, для полноты не хватает серверов на разных архитектура, *bsd, php, nosql уж в кучу… не знаю как сейчас у вас, но раньше было просто мега тормознуто
    • –1
      Ничего не изменилось.
  • +4
    Исходники выложите?
    • +4
      public void sendMessage(String message) {
         long startTime = LoggerUtil.getMeasureStartTime();
         try {
             /**
              * business logic - send message
              */
              LoggerUtil.operationSuccess(LogFactory.getLog({log's appender name}), startTime, "messageService", "sendMessage");
          } catch (Exception e) {
              LoggerUtil.operationFailure(LogFactory.getLog({log's appender name}), startTime, "messageService", "sendMessage");
          }
      }


      Уже выложили :D
  • –3
    Ни одной картинки :(
    Коли о слоях говорите приложили бы что-нибудь для более быстрого понятия. Тем более в таком случае куда интересней сетевая взаимосвязь между слоями.
    • –18
      Саттья выглядит как на «отъ**ись» :(
      А ведь интересно.
  • +3
    Теперь понимаю почему в одноклассниках все тормозит и очень долго открывается.
    На дешевых тарифах в инет(до мегабита) даже зайти сложно.
  • +50
    Описание красивое. Выглядит так, что описание Бурана или Шаттла какого-нибудь блекнет. Кажется, что это вершина ИТ и того, что с ней может сделать человек.

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

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

    Простите, конечно, если обидел.
  • +5
    индусы нервно курят в сторонке…
  • 0
    Знакомая помогала мужу с регистрацией в одноклассниках и по глупости указала email своего аккаунта. Регистрация прошла успешно, а вот доступ к своему аккаунту оказался потерян. Техподдержка просто ничего не ответила.
    • 0
      ей нужно поменять в логине значок "@" на "."
      • +8
        Это вообще логично? Боюсь спросить: а чем это обосновано?
  • +1
    А что одноклассники еще не загнулись? :3
  • –7
    А почему вы не используете JSF 2.0 вместо GWT и настоящую кластерную СУБД с распределением нагрузки, а не жалкое её подобие MS SQL Server?
    • 0
      Место упомянутого Вами JSF у нас занимает тот самый фреймворк, генерирующий UI компоненты HTML.
      GWT же придаёт динамику на странице, а также на нём реализована функциональность Сообщений, Обсуждений и Оповещений.
      • –1
        >Место упомянутого Вами JSF у нас занимает тот самый фреймворк, генерирующий UI компоненты HTML.

        Это я понял. Но я спросил: «почему?».

        Ответ, видимо, будет в духе:
        1) остановились на этом фреймворке, потому что это модно;
        2) традиционно игнорируем стандартные фреймворки Java входящие в JavaEE;
        3) команде разработчиков лень переучиваться и осваивать что-то новое, она занимается обслуживанием того, что уже сделано.

        Да и про СУБД хотелось бы услышать ответ на вопрос: почему не используются нормальные кластерные решения с прозрачным распределением нагрузки на несколько серверов.
        • 0
          >почему не используются нормальные кластерные решения с прозрачным распределением нагрузки на несколько серверов.

          Разве такие решение существуют? А можно ссылочку?
          • –1
            Пример: PGCluster – синхронизирующаяся репликационная система с мультимастерной композиционной схемой для PostgreSQL.
            • +1
              Можно пожалуйста пример продукта работающий на данном решении? Желательно с дополнительной информацией: сколько машин в кластере, какая нагрузка на одну машину, объем данных.
              • –2
                www.opennet.ru/openforum/vsluhforumID13/337.html#5
                Сообщение от Синн on 11-Май-07, 09:06 
                что могу сказать
                столкнулись с той же проблемой. Нагрузка на базу при начальных условиях была около 3,000,000 транзакций в день.
                Поняли сразу что без кластера и loadbalance'ра не обойтись
                Тестировались PGCluster и slony.
                Первый был очень удобен, синхронизировал всё сам вплоть до создания таблиц и сам же делал балансировку, но как только уронили кластер с 16 млн. записей, система не встала. Минус был в том, что на кластер пришлось затратить, 2 дата ноды, 2 репликатора, 2 failover балансировщика на carp инхерфейсах.
                Сейчас тестируется slony, нагрузка таже. база уже 38 млн. записей. ронялась 2 раза, 1 раз система встала колом на 1 день, мастер обогнал слэйва на 10 млн. записей, после устранения проблемы на слэйве, система заработала на полную через 30 минут. при этом всё транзакции продолжали фиксироваться. Минус как известно в конфигурировании.
                сейчас закупаем оборудование для построения кластера уже на ксеонах.
                Вывод: Мы выбрали слона, как более устойчивую систему от сбоев. Удобство администрирования было отодвинуто на последнее место.
                • 0
                  Слоны — это не кластер, используем его на работе. Это ассинхронная мастер-слейв репликация. PGCluster — сплошной гемор, это ясно. А у ребят из одноклассников полноценный кластер БД. Так что ничего удивительного.
                  • 0
                    Как это не кластер? Тогда какую роль выполняет Load Balancer по-вашему?

                    >А у ребят из одноклассников полноценный кластер БД.

                    Ну, да. Один MS SQL Server работает, другой на подхвате, если первый грохнется. :))
                    • +1
                      Насчет MS SQL, вот цитирую:

                      >вертикальное и горизонтальное партиционирование данных как в базах данных

                      Работая со Slony slav-ы будут немного отставать от мастера. У них же все синхронно за счет выбора реплики на клиенте. Да и на сколько я понимаю, со Slony можно писать только в master. А читать с реплик и то немного устаревшие данные. Недокластер какой-то.
          • 0
    • +3
      >жалкое её подобие MS SQL Server

      Ойой, а вот и гуру по базам данных подтянулись :D
      Посмеши нас
  • 0
    google chrome под macOS
    при открытии своей страничке не возможно попасть в сообщения. Это бывает часто в вечерние часы. Возможно это баг Хрома. Возможно ява скрипт подвисает. Но по клику не возможно загрузить сообщения и др. кнопки вверху не работают. Но если открыть в новой вкладке, то все ок.
    • 0
      Похожая проблема, проявляющаяся одновременно во всех браузерах. Грешу на какую-нибудь баннерорезку.
  • +1
    Отличная статья. Переведите на инглиш и обязательно отправьте на highscalability.com/
  • +1
    Мне интересно используется ли long polling или вебсокеты? Или асинхронные запросы пингуют сервера?
    • +1
      Используется long polling. На серверной стороне любой компонент системы может узнать online пользователь или нет и на каком из web сервере открыто его соединений. Так что при необходимости любой компонент может отправить нотификию пользователю в открытое соединение.
  • +1
    А как интересно предпродакшн организован? Я имею ввиду откуда берется аудитория для предпрода?
    • +1
      есть тестовая группа серверов на которой обкатывается версия перед деплойментом на весь портал
    • +1
      Средствами LVS заводим/выводим реальных пользователей на тестовую группу.
  • 0
    когда можно будет ожидать поддержку IE9? и JumpList например?
    • 0
      На данный момент реализована только поддержка «Pinned Sites», а именно ссылки на 5 разделов: «Моя страница», «Друзья», «Гости», Мои игры" и «Оценки»
  • +1
    Если можно, прокомментируйте подробнее эту строчку: «Встроенный в СУБД аппарат партиционирования не используется — вся логика располагается на уровне бизнес сервисов.» Какие минусы партицирования на уровне СУБД?
    Также хочется понять почему вы не используете хранимые процедуры? Каким образом прямые запросы в БД уменьшают нагрузку на CPU?
    • +6
      В системах с такой нагрузкой как у одноклассников обычно самым узким местом являются БД. Вы либо упираетесть в CPU либо в диск. Причем БД масштабируются хуже всего.
      Поэтому мы стараемся снять нагрузку с базы данных как можно больше. Для снятия нагрузки на диск при чтении используются кеши. Для снятия нагрузки на CPU мы стараемся не использовать хранимые процедуры и сложные запросы.

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

      По поводу встроенных механизмов в СУБД. Кластерные решения СУБД не способны масштабироваться до такого предела и очень дороги. Большинство высоконагруженных систем используют горизонтальное и вертикальное масштабирование на уровне бизнес логики.
  • +1
    Я конечно не эксперт в javascript, но с этой кухней немного знаком. Вот если честно, что происходит в момент, когда введены данные для входа на сайт и нажата кнопка Войти? Фаерфокс виснет намертво на 1-2 секунды. Может вам нужно подыскать джаваскриптера с прямыми руками? :)
    • +1
      На самом деле в момент нажатия на кнопку «Войти» происходит простой POST формы посредством submit кнопки.
      Виснет намертво = процесс Фаерфокса кушает CPU 100% в течении одной двух секунд?
      • 0
        Это оно и значит. Фаерфокс зависает как неотвечающее приложение. Версия 3.6.х
  • +1
    Спасибо, что приоткрыли завесу тайны :)

    А почему в Одноклассниках не используют нагрузочное тестирование? Тогда бы и выкладка была бы спокйонее и жизнь проще.
    • 0
      Нагрузочное тестирование есть, но в основном на стадии внедрения каких либо новых технологических решений или при запуске нового сервиса с нестандартными решениями.

      Делать синтетическое нагрузочное тестирование при каждом update на всю систему давольно накладно по времени. Своего рода нагрузочное тестирование происходит на тестовой группе серверов с реальными пользователями.
      • 0
        А по нашим оценкам при должной постановке процесса покрывать регресионными нагрузочными автоматическими тестами большую часть изменяющихся компонентов сервисов в стратегическом плане оказывается очень выгодным. И админам очень нравится :)

        Александр, а кто занимается нагрузочным тестированием? Если я правильно понимаю ситуацию, то сами разработчики? А какими инструментами пользуетесь?
        • 0
          Специально выделенных людей нет. Ответственный разработчик за разработку нового продукта занимается нагрузочным тестированием.

          Тестируем в основном разного рода «back end» системы. Иногда при тестировании используем JMeter, но
          в большинстве случаев это просто консольное java приложение, которое генерит нагрузку на систему.

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

          Для примера: при тестировании новой системы хранения данных мы параллельно сохраняли данные в старую и новую систему. При чтении данных сравнивали результат из обоих систем. После устранения всех узких мест и ошибок начинали переход на новую систему хранения данных. Логика написанная для тестрования в конечном итоге использовалась для плавного перехода на новую систему хранения данных.
  • +1
    Здравствуйте, а не хотите ли попробовать раздавать статику Одноклассников (CSS/JS и иконки) через CDN? Это может ускорить выдачу, особенно в СНГ и в городах за Уралом. Если интересно — пишите!
  • +3
    Все системы проходят тщательное нагрузочное тестирование. Тестировние проводиться с учетом особенностей эксплуатации и по возможности реальных данных. Во время тестов за системами внимательно наблюдают, все что вызывает подозрения изучается.
    Но, даже 3х и более кратная синтетическая нагрузка не всегда выявляет все проблемы, особенно связанные с длительной эксплуатацией. Иногда проблемы возникают в результате незначительных изменений уже работающего функционала. Тогда, если есть возможность то откатываемся, если нет то стараемся чтобы пользователи это не почуствовали.
  • 0
    Всё круто, кроме исходного кода страницы.
    • 0
      Он генерируется автоматически. GWT
      • 0
        Я знаю. Впрочем, у фейсбука не лучше ))
  • –1
    Рискну начать холивар.

    PHP — говно. Java — круто. С точки зрения тру-программистов — однозначно.

    НО!

    Вконтакте — рулез. Одноклассники — говно. С точки зрения бизнеса — однозначно.
    Не говоря про фейсбук.

    Вот и говори потом людям, которые хотят все делать на PHP, что Java — это АОП, IoC, Spring, Hibernate, и вообще written once — run anywhere. Ведь Facebook-то на ПХП!

    ПХП — это, несомненно, круто, по соотношению цена-качество. Куда лучше чем дотнеты всякие, хотя бы потому, что не привязано к одному производителю.

    В общем, надо писать сайты на плюсах.
    • +1
      А LinkedIn где в этой вашей картине мира?
  • +1
    Как пользователь Одноклассников, хотя и очень редкий, хочу сказать спасибо за недавноее обновление UI. Месяца 2 назад и ранее — открытие каждой страницы вешало браузер на пару секунд. Поэтому невозможно было открывать сразу несколько вкладок. Но сейчас это исправлено.
    Было просто жутко))
  • 0
    Извините, а можно поподробнее рассказать о роли JBoss в данной архитектуре?
    Какую роль он выполняет? Что из его внутренностей используется?

    Спасибо.
    • +1
      На практике мы используем очень мало возможностей JBoss: транзакции, пул конекций к ДБ и ремоутинг
      • 0
        А почему версия старая (4)? Есть проблемы с переходом на новые версии?

        И еще вопрос — как вы сервисы на жбоссах деплоите? Мы вот отказались от контейнеров в пользу встраиваемого сервера + упаковка в deb.
        • 0
          Как уже писали ранее: «Работает — не трогай». Не видим смысла.
          У нас по старинке: один EAR или WAR на инстанс JBoss'а. Всё выкладывается специальном скриптом, который используется для всех компонентов. Работает отлично.
    • +1
      JBoss выполняет роль контейнера компонентов бизнес логики. На него поступают бизнес запросы и бизнес операции от фронтендов, которые он и выполняет, запрашивая данные при необходимости от других сервисов — БД, ремотные кеши, другие специализированные сервисы.
      На этих компонентах также реализована логика партиционирования данных по серверам MSSQL.

      Кроме упомянутого Сашей, еще используются stateless beans, для простых сущьностей используются entity beans с bean managed persistance.
      • 0
        Спасибо за ответ.
        А какая версия EJB?
        • 0
          Jboss 4.5, соответственно версия ejb 2.1.
          • 0
            Спасибо.
          • 0
            OMG
  • 0
    Нужно было писать на Perl!
  • 0
    Какая версия Zabbix используется? Код стандартный или используются какие то специфичные патчи? Если до то какие? Используется распределенная система мониторинга? Какая БД используется для хранения данных системы мониторинга? Какое количество хостов итемов и триггеров? «Требуемое значение быстродействия сервера»? Конфигурация сервера(ов) мониторинга?
  • –1
    Взяли бы еще хорошего дизайнера интерфейсов в команду…

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разработка