Наверх ▲

Что мы знаем о производительности интернет-проекта или как вылечить зуб, если неизвестно какой болит?

Сергей Рыжиков Сергей Рыжиков Генеральный директор компании "1С-Битрикс"
View more presentations from HighLoad2009.

Сергей Рыжиков: Меня зовут Сергей Рыжиков, я генеральный директор компании «1С-Битрикс». Сегодня я хотел бы поговорить о том, что мы знаем о производительности вообще. Я неслучайно провел аналогию с лечением зубов, я специально добавил в название эту фразу – «как вылечить зуб, если неизвестно, какой болит». На сегодняшний день у нас очень большая практика в сфере тестов, нагрузок и экспертиз производительности. В определенном смысле это мое хобби – помогать людям что-то корректировать, разбираться с теми или иными проектами и сложностями в области производительности. И неоднократно я наблюдал ситуацию, когда лечили совсем не то, что болело. Часто ищут какую-то опеределенную ошибку, а проблема может оказаться совсем в другой области.

Попробую обойтись без слова «Битрикс»… я постараюсь не использовать свое выступление как рекламу, но в то же время буду говорить о некоем опыте, который мы приобрели, помогая нашим клиентам и партнерам добиваться оптимальной производительности. В последнее время я говорю, что мерилом успеха является удовлетворенность клиента… Я буду в первую очередь говорить об этой характеристике, а не просто о производительности как о заоблачной величине. Почти никого не  интересует, исполняется ваша страница 0.01 или 0.1, всех интересует выполнение задач и отличная работа. И вот для того, чтобы клиент сказал: «Да, это отлично!» - у вас должно быть три составляющих.

Первая из составляющих – это конфигурация сервера и оборудования. То есть важно, где вы разместили решение, как это работает, каково аппаратное обеспечение. Обязательно – платформа. В данном случае мы не будем говорить о конкретных платформах, на которых вы что-то разрабатываете. Это может быть только язык, это может быть Zend Framework, это может быть «Битрикс», это может быть другая платформа – у нее есть свои особенности, характеристики и зачастую у нее есть свои настройки, которые вы тоже должны понимать и учитывать. Еще одна важная вещь – качество разработки.

Однажды в Питере на конференции мне довелось обедать с коллегой из IBM. И, собственно, за обедом он спросил меня: «Расскажи, а как вам удается обеспечивать качество внедрения? Во-первых, при вашей невысокой цене на продукт, во-вторых, при таком массовом количестве партнеров?». Партнеров тогда было почти 4 000. Я ответил: «Ну, ты знаешь, мы боремся, учим». Немножко рассказал, но сказал, что проблемы есть, мол, а как вы? Он говорит: «А мы практически к каждому проекту приставляем нашего куратора». То есть, когда его внедряют, есть человек, который смотрит, помогает разработчикам… И все равно, говорит, проблемы есть.

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

Как решают вопросы с конфигурацией?

Начинают быстро-быстро расти: хостинг, VPS, виртуальные, свой сервер, два сервера, кластер. Ну, кто-то так решает проблему. В принципе, это тоже метод, и, кстати, не всегда самый дорогой. Очень часто это один из самых дешевых способов увеличить производительность.

Конфигурация – PHP, Apache, Nginx, memcache. Кстати, вот Nginx – это вообще замечательная вещь, великолепный продукт, классный, но почему-то никто не думает, какова его роль в системе. Его поставили, но даже не сделали так, что статику отдает Nginx. Он все отдает… а на деле он отдает нам только статически HTML, но не отдает графику. Предложить заглянуть в log-файл – этого вообще не делают. Или, например, стоит рассказать про случай, когда мы проводили опрос, а клиент пожаловался: «Вот, раньше все работало хорошо, а потом вдруг стало медленно работать». Заглянули в конфигурацию PHP, посмотрели php.ini, а у него на сто процентов заполнен кэш прекомпилятора! Стоило его увеличить буквально на 16 МБ, как производительность выросла в 10 раз.

Как помочь, чтобы это решали быстрее?

Я не буду останавливаться на старых вещах. Когда-то я делал доклад на HighLoad++ - по конфигурации, по производительности систем и рассказывал много про методику, которую мы исследовали или которую создавали. Я не буду сейчас останавливаться на технике, потому что все вы с этим сталкивались. Мы много работаем с PHP, много работаем с .NET, и вы все решали те или иные задачи. Поэтому в общем, банальные и простые вещи я, наверное, пропущу.

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

Качество разработки для нас очень важная проблема.

Я думаю, что для любого фреймворка, который поставляется на рынок, это очень существенно. Это всегда дилемма. С одной стороны, ты стремишься дать гибкость и говоришь: «Вот вам платформа, вы можете использовать эту API-функцию, вы выберете данные, вы получите результат». Но кто голову отключал? Это удивительно, что нужно клиенту построить пункт меню, в котором есть, например, топ двадцать элементов, например из наших инфоблоков, – это дерево товаров. Выбирают из пятидесяти тысяч товаров, все сортируют, отрезают пять, после чего их вставляют и даже забывают кэшировать. Обычное меню, например, в итоге весит пять тысяч запросов в базе данных. На каждом хите. Конечно, любой сервер и хостер готовы убить такого клиента. В итоге его "железо" не функционирует нормально.

Ну, и бывают странные разработчики. Например, в шаблон страницы встраивают обращение к GISMETEO. То есть не асинхронно, а напрямую. Конечно, страница вызывается две-три секунды, и то это от погоды зависит, да? Иногда бывает, что и очень медленно. В итоге клиент просто в панике и умоляет ему помочь. И он даже не может понять, где что не так: проблема в разработке, в платформе или в хостинге? Как раз в таких ситуациях и бывает, что купили два сервера, а быстрее работать ничего не стало. Но оно и не станет быстрее, потому что мы, собственно, лечим не тот зуб. Ну, это такое общее рассуждение на тему высоконагруженных проектов.

Да, безусловно, высокая нагрузка – это очень важный фактор, причем нагрузка - это всегда недостаточное количество ресурсов по отношению к тому, что вы собираетесь обработать. Критериев может быть много: и посещаемость, и пиковая нагрузка, и объемы данных. Уже упоминалось, что есть целый ряд критериев, который приводит, например, к регрессии производительности. И в принципе, на основе своего банковского опыта и опыта работы в компании я могу сказать, что очень важно периодически мониторить проект, потому что база данных может накопить большие объемы. Анализ запускают редко, очень сильно может измениться план исполнения. И вот таких вот нюансов, особенностей, существует достаточно много.

Ну, так как же вылечить "правильный" зуб?

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

Мы начали сертифицировать тарифные планы. То есть мы садились обсуждать их с хостерами, помогали им сделать их, но этого далеко не всегда было достаточно.

Собственно, о программе сертификации…

Вы знаете, когда у хостера, например, идет DDoS-атака, он начинает "закручивать" все, что только можно. Вам должны были выделить столько памяти – вы столько не получаете. Вам должны были дать столько места – его не будет. Причем, опять же, какова объективная реальность? Хостер наполняет сервер до состояния, пока он не перегрузится, так? Потом, опять же, поскольку это "коммунальная квартира", то кого-то пик, у кого-то высокая посещаемость. В итоге начинают отгружать сервера на другие. Очень-очень плавающая нагрузка, причем самое досадное, что ее невозможно проконтролировать. То есть мы их сертифицируем, но качество обеспечить не можем – клиент не удовлетворен. Не прошла такая засада.

Мы стали учить разработчиков.

Параллельно мы стали помогать разработчикам решать задачи, обучаться конфигурированию систем и повышать качество разработки. На данный момент у нас двенадцать тысяч сертифицированных специалистов, но, знаете, это все равно не очень помогает. Хорошо помогло, когда мы сделали сертификацию внутри обязательной программы. Специалисты прошли курс, тесты сдали формально. Но когда начинаешь исследовать собранную конфигурацию и спрашиваешь: «Почему вы на Apache не ограничили maxusers? У вас при стрессовой нагрузке начинается свопинг системы, в итоге получится общая регрессия, и ничего работать не будет. В учебнике же написано: поставьте не больше, чем у вас есть там памяти, ресурсов и так далее». Ну, админ говорит: «Я решил, что так будет удобнее, быстрее». Он физику не очень хорошо понял, ответить-то он ответил, сертификацию прошел, но корректировать ничего не стал.

Мы решили все очень честно рассказать о нашем продукте. У нас есть много отладчиков, которые позволяли вывести каждый фрагмент, каждый компонент, время исполнения, SQL, сам SQL-запрос, откуда вызван – из нашего кода, из ядра, из компонента и так далее. Ищите, пожалуйста. Кстати, на первом этапе это очень хорошо помогло, но по мере роста проектов этого все равно оказывается недостаточно.

Самое главное, что нас, наверное, не устраивало в предыдущем положении, – это то, что клиент не мог контролировать качество работы. Это всегда самая главная проблема. Клиент не может проконтролировать ни платформу, ни настройки продукта, ни конфигурацию сервера.

Как мы решили поступить? Мы выпустили специальное решение, которое назвали «Монитор производительности».

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

Я помню, что у Agnitum (это наши давние клиенты) однажды была проблема. Перезванивает мне их IT-директор и говорит, что все жутко тормозит. Я говорю: «А что ты видишь в топе?» Он говорит: «Системная нагрузка восемьдесят процентов». Это верный диагноз. Знаете, я как раз совсем недавно подсел на «Доктора Хауса» и говорю: «Это очень хороший симптом». Это отличная возможность сказать, что это не наша проблема, потому что наш продукт системную нагрузку не создает. Буквально за несколько минут выяснили, что при их нагрузке и установленном времени жизни сессии в TMР-каталог сваливается по два миллиона файлов, конечно, никакая файловая система… На факт открытия сессии она тратит реально по десятку секунд, создавая огромную дисковую нагрузку.

Конфигурация PHP... Если успею, немножко расскажу о ней… и о тестах производительности. Мы три базы поддерживаем, здесь на иллюстрации MySQL – запись, чтение и изменение. Но это не самое главное, это вспомогательная информация. Мы научились тестировать конфигурацию вообще, и мы выводим то, что мы называем «абсолютной характеристикой системы», которая позволяет вам оценить, как она работает. Вот на этой иллюстрации результат производительности 51.99 и среднее время отклика 0.0192.

Что это означает? Кстати, обратите внимание, здесь есть колонка «эталон». «Эталон-30», и у него время отклика 0.03 и дальше. Кстати, у него быстрее работает и процессор, и диск, но почему-то эта машина оказалась выше. То есть результат вот этого числа не есть перемножение по каким-то хитрым формулам, реально это вспомогательная информация, которая может позволить вам обнаружить неисправность.

Как получается эта цифра? Если вы работаете и делаете замеры на обычной стационарной машине, без нагрузки, вы получите постоянно повторяющееся число. То есть реально вы будете видеть, что сейчас там 51 у вас есть. Если вы будете делать тест, например, на хостинге, в период пиковой нагрузки, вы, во-первых, не получите такое количество процессорных тиков, вы увидите реально… Мы не частоту меряем, мы не можем этого сделать на своем уровне, мы считаем фактическую производительность, которая вам достается. И то же самое вы посчитаете по другим запчастям. Например, при нагрузке наш проект с 45 может просесть до 21. Это, в общем, приемлемо, но это помогает делать выводы или значения. Вот здесь, как раз на этом мониторе показано, что есть три основные вкладки: «Конфигурация», «Битрикс» и «Разработка». Вот эта вот часть конфигурации как раз тестирует соответствие "железа", определяет, насколько оно адекватно работает в конкретный момент. Очень важно, что цифра будет меняться.

Конфигурация PHP выполняет целый ряд тестов – по размерам кэша, настройкам, там есть несколько параметров, которые очень существенно и сильно влияют на производительность PHP как такового. Сделав эту часть, мы сделали следующий кадр.

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

И следующий момент – это тестирование качества разработки. Как мы решили подойти к этому вопросу?

Здесь представлен скриншот, на котором я перед тем, как написать в блог, сделал замер производительности.

Я нажал «тестирование производительности» и в течение пяти минут мой сервер собирал время исполнения каждой страницы. Время исполнения, компоненты, скорость работы, все выполненные скрипт-запросы и целый ряд других вещей – он это складирует, собирает, и в результате за 300 секунд я собрал 1056 хитов, хотя это была суббота, одиннадцать утра, но, тем не менее, оказалось, что нагрузка в общем большая. И что я увидел? Как директор, который никогда не знал, как собран наш проект, я увидел, что одна страница «Жизнь» занимает шестьдесят процентов ресурсов. То есть ее потребление нагрузки – шестьдесят процентов от всей нагрузки, которую создает интернет-проект. Это 543 хита и среднее время там 0.4. Там есть детальный анализ, сейчас у меня, по-моему, иллюстрация там будет. Я на самом деле очень рассчитывал показать вживую и взял с собой ноутбук, но мне сказали, что при сегодняшних средствах автоматизации это нереально. Просто там трансляция идет в разные составляющие. Интернет-то тут есть, а вот транслировать с экрана не получается. Посмотрев на эти цифры, я понял, что у нашего проекта есть серьезные проблемы... Я уже перешел на эту страницу «Жизнь», как она у нас называется, и проанализировал ее детально.

Это тоже составная часть системы мониторинга, где мы разбираем производительность проекта на пролог, ядро, агенты, шаблоны, рабочую область и целый ряд других вещей. Но цель этой части – позволить, в течение буквально нескольких минут, сделать полный срез того, как работает проект. И ведь действительно получалось так: есть у тебя SQL-отладчик или вообще отладчик кода, ты ходишь по всем страницам, вроде все на месте, а оказалось, что вот эта страница создает проблемы… Такая нагрузка создается не людьми, а роботами. Потому что именно роботы, увидев на одной странице ленту новостей, нажимают стандартный компонент, а там не была убрана галочка «все». И несколько тысяч новостей раскладываются в одну ленту.

На другом табе стояла фотогалерея, и там робот тоже нажимал «все» и тоже рассматривал большое количество фотогалерей. Наши контент-редакторы занимаются сборкой сайта, и тут девчонки не подумали – разместили компоненты, настроили, и это их устраивало. Но с точки зрения производительности это очень ущербно и совсем не то, что было необходимо. О "Мониторе" много хотелось бы сказать, но, наверное, не сейчас. Собственно, выпустив этот продукт, мы смогли еще одним элементом помочь клиентам и партнерам решать проблему. Вот за этот продукт мы готовы отвечать.

Другой пример приведу из жизни. Когда мы только выпустили этот "Монитор производительности", на форуме нас стали обсуждать. Ребята стали размещать скриншоты – у меня вот на таком хостинге такой замер, а у меня такой. А один, например, увеличил производительность с шести единиц до шестидесяти двух, просто выполнив рекомендации по PHP для неоптимального PHP. Это вот, я считаю, как раз те самые трамвайные остановки, из-за которых жалко, в общем, что проект так работает. А один пишет на форуме: «...вот, я как раз и знал, что «Битрикс» работает очень медленно. Именно в области статистики». Вот посмотрите, он приводит селект из таблицы "Best Toplist", которая содержит десять записей. Селект выполняется, там даже присоединений никаких нет – 1,8 секунды. Ну, все, конечно, можно сказать, что это «Битрикс».

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

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

Сделан он под VMware, уже, кстати, готова такая машина для амазоновского EC2, мы готовим такую машину для «Виртуоза», и, наверное, для XenАpp Citrix появится. Идея этой виртуальной машины в том, что она уже собрала и аккумулировала весь наш опыт по конфигурированию системы. Мы, в принципе, считаем, что мы не системные администраторы, но в то же время мы проделали это… на самом деле, потребовалось порядка трех или четырех месяцев, чтобы подготовить такую конфигурацию. Она у нас скомплектована на Ubuntu, кстати, амазоновский на Fedora, Nginx двухуровневый с Zend Server CE, MySQL. Сразу поддержка HTTPS, поддержка InnoDB в базе, geoIP - целый ряд вещей перечислен. Виртуальный сервер буквально за несколько минут готов к развертыванию. Вы получаете защищенную конфигурацию с ключиками-файерволлами, и эта конфигурация не для «Битрикса» специально, она вообще для PHP. То есть там приложено много усилий, чтобы PHP-приложения работали быстро и не потребляли лишних ресурсов. Это конфигурация, работающая на 256 мегабайт памяти и, пожалуй, на любом виртуальном хостинге, который есть сегодня. И вот этот замер в 51 единицу – это как раз был виртуальный хостинг, дающий виртуальную машину VMCO. Ведь раньше мы должны были брать VDS и вручную настраивать, тратя время.

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

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

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

Вопросы и ответы

Вопрос из зала:

Будьте добры, приоткройте нам завесу тайны, как вы индекс общий считаете?

Сергей Рыжиков: Как мы считаем индекс? Фактически мы исполняем специальный фрагмент ядра и платформы, который, ну, в большинстве своем показывает типовую работу большинства проектов, как нам кажется. То есть мы стараемся не просто сделать перемножение характеристик… вот это вот время отклика, это реальное время отклика, например, такого ядра или такого фрагмента. И как результат, мы вычисляем общее время исполнения. То есть, например, вот на этом хостинге, это VMCO, на виртуальной машине VMware, 256 мегабайт памяти, один гигагерц, выданная машина. Я был удивлен, потому что я думал, что вот файлы и процессор, они больше всего влияют на характеристику. Но мы, когда делали замеры эталонной машины, брали обычный комп. То есть это не был сервер, не была серверная архитектура. А у этих ребят, у них сервера, шины, трансфер, скорость. Видимо, какие-то характеристики самой конфигурации при более медленном железе дают значительно лучший прирост производительности. Вот это как раз для нас был пример, что конфигурация очень сильно влияет.

Вопрос из зала: При введении новых версий вашей системы процедура измерения производительности используется?

Сергей Рыжиков: При введении новых версий используется ли процедура? Мы сами тестируем, вы имеете ввиду? Вообще, у нас есть сегодня отдельный отдел по безопасности, отдельный – по нагрузкам. В целом, самая большая проблема с нагрузкой – это эмуляция в соответствии, ну, как бы, реальной среды. У нас есть несколько внутренних серверов, например, на одном пятьсот тысяч элементов и данных в инфоблоках. И мы на нем проверяем и импорт, и экспорт, и другие вещи, но важен характер данных, важно, как индексы построились. Если у вас однотипные данные – инселективность индекса будет не очень высокая. И вот эмуляция этой ситуации не всегда проста, поэтому, используя как раз этот монитор, вот основные отзывы сегодня партнеров – «за несколько минут нашли проблему». Ее действительно очень тяжело локализовать, даже если десятки страниц, варианты, параметры, выборы приводят к тому, что ты не знаешь, что именно медленно работает. Тут видишь сразу.

Вопрос из зала: Вопрос про ваш подход, насколько я понимаю, он заточен именно на использование технологий Apache, PHP. Мой вопрос в следующем – насколько ваш подход может быть применим с использованием других – вместо PHP другой язык?

Сергей Рыжиков: Принципиально никакой разницы, на мой взгляд, нет. Все равно три составляющих лягут в основу. Есть, например, проекты, на которых сами разработчики пишут что-то похожее на монитор. Иногда просто скидывают в лог, чаще всего это SQL-запросы. Людям нужно, особенно, если есть класс абстракции, они включили лог-файл, проанализировали запросы и говорят: «Ни один не тормозит. У нас проблем с производительностью нет». А как оказывается, иногда, например, страницы генерируют размер в девятнадцать мегабайт. И получается, что там и буфер, и ряд… то есть получается, что она создает стрессовую ситуацию для всей системы. Поэтому. Я не раз видел подобную методику, как бы не такой монитор, а что-то похожее, которая собирает и время исполнения, и запросы, то есть позволяет в общем анализировать. Насколько я понимаю, у «Майкрософта» есть ряд подобных инструментов. Мы делаем и готовим такой продукт для .NET-версии, такую вот часть. Потому что считаем, что методика не отличается.

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

Сергей Рыжиков: Я готовых реализаций не видел, мы на самом деле другую хотим экспертизу накопить – мы хотим собрать цифры и замеры по разным проектам, по разным хостингам, то есть своего рода кейсы. Я сейчас в форумах стараюсь обсуждать такую часть, когда люди делают замер, делают ряд рекомендаций, а мы на самом деле пытаемся понять, хорошо мы помогли или нет. Вот если замер наш не помог, значит, нужно выполнить какой-то набор рекомендаций. Один из выводов, который я уже обозначил, мы, например, включили на вкладке «Битрикс», здесь, собственно, будет оптимизация, анализ таблиц базы данных. И мы будем рекомендовать это делать не реже, чем раз в месяц. Потому что реально этого не делают. Обычный аналайз, для того же Oracle или для MS или чек-тэйбл, репэйр зачастую помогают решить много проблем с базой данных.

Вопрос из зала: То есть вы предлагаете сделать памятку и чек-лист – вот это надо обязательно делать с такой регулярностью?

Сергей Рыжиков: Фактически мы будем этого требовать, потому что… кстати, это число замеров будет выводиться на главный дисплей продукта в админке, где и безопасность. И мы пока не решили, но размышляем делать периодически замер, например, раз в несколько часов и показывать – оптимальная или не оптимальная производительность. Для того, чтобы клиент лучше мог следить за динамикой, за тем, как все работает.

Вопрос из зала: Мониторинг, то есть?

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

Вопрос из зала: Спасибо, вы ответили.

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

Вопрос из зала: Вопрос по базам данных.

Сергей Рыжиков: Последний вопрос.

Вопрос из зала: Ваш продукт использует различные базы данных? Точнее, может использовать?

Сергей Рыжиков: Да, MS SQL, Оracle и MySQL.

Вопрос из зала: Ваши предпочтения и ваш опыт по выбору межу этими базами данных.

Сергей Рыжиков: Да-да, мы с самого начала поддерживаем три базы, безусловно, это, наверное, основная часть проекта, особенно, когда речь идет о больших объемах и когда идет накопление данных, грамотное администрирование данных очень важно. Вообще, когда начинали, MySQL был очень слабым. Сегодня «пятерка» – прекрасный продукт, в целом. Я могу сказать, что, например, большущие проекты работают на MySQL и зарабатывают десятки миллионов долларов, и это никак им не мешает. То есть для большинства проектов MySQL сегодня более чем достаточно. В целом я поклонник Оracle. Это, наверное, сказывается мой бэкграунд банковский и какое-то знание архитектуры. Я знаю некоторые особенности архитектуры, которые сильно позволяют ему выигрывать в общих замерах. Вот если MySQL и MS SQL, они в общем, по моим сегодняшним представлениям, примерно сравнимы, то Оracle, на мой взгляд, впереди планеты всей, и реально на нем мы рекомендуем, развертываем real application кластерá. То есть, когда клиенты хотят нон-стоп систему, два, например, под Oracle, два – под вэб и с возможностью вводить и выводить ноды. Пока ничего, кроме Оracle, не рекомендуем. Пытались на MySQL, там есть кластер, но он не дает той отдачи и производительности, на которую рассчитываешь. Поэтому посмотрим, может, ситуация изменится. Все, спасибо большое!

Комментарии

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

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

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

Джош Беркус (Josh Berkus)

Джош Беркус (Josh Berkus)

Член команды PostgreSQL, специалист по БД.

Несерьезная техническая презентация Джоша Беркуса о реляционных и нереляционных базах данных.

Олег Илларионов

Олег Илларионов

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

Олег Илларионов (ВКонтакте) рассказывает об изменениях принципов работы с вебом и отвечает на вопросы о самой популярной российской соцсети.

Николай Кондратов

Николай Кондратов

Технический руководитель почтовой службы Mail.ru.

На примере "Mail.ru" рассмотрен вариант переноса и усовершенствования службы поддержки высоконагруженного сервиса.