Пользователь
0,0
рейтинг
20 февраля 2009 в 21:34

Администрирование → Прогрессивные технологии, как способ выжать из сервера максимум

Вступление


Просто красивый rrdtool =)
Забавно, но когда программист разрабатывает какой-либо продукт, он редко задумывается над вопросом могут ли на одну кнопку в один момент времени нажать одновременно 2000 человек. А зря. Оказывается могут. Как ни странно но большинство движков, написанных такими программистами, очень плохо ведут себя под большими нагрузками. Кто бы подумал, а всего один лишний INSERT, не проставленный index, или кривая рекурсивная функция могут поднять load averages чуть ли не на порядок.

В этой статье я опишу как мы, разработчики проекта, сумели выжать из одного сервера с Pentium 4 HT / 512Mb RAM, максимум, держа одновременно 700+ пользователей на форуме и 120,000 на трекере. Да, проект этот — торрент трекер. Предлагаю сразу оставить в стороне разговоры о копирайтах и правах, мне это не интересно, что действительно интересно — это HighLoad.

Для начала опишу проект таким, каким он был:

Обычный торрент трекер на движке TorrentPier (он же в девичестве phpbb 2.x)
  • Сервер на FreeBSD 6.0
  • Pentium 4 HT / 512Mb RAM
  • Web-сервер Apache
  • База MySQL
  • Вся логика на PHP

То есть практически LAMP

Вкратце сразу распишу последовательно те шаги которые мы предприняли:
  • Установка на сервер opcode cache
  • Замена apache на nginx
  • Кэширование некоторых промежуточных выборок в НЕ RDBMS
  • Перевод ключевой части (читай трекера) на C++
  • Оптимизация сетевого стека FreeBSD, а также её обновление до последней -STABLE
  • Оптимизация MySQL
  • Кэширование BB-кодов
  • Переписка кода на использование SphinxSearch
  • Профайлинг кода и установка средств мониторинга
  • Разборка запросов из MySQL slow query log

Теперь о каждом пункте поподробнее

Установка на сервер opcode cache


Он нужен всегда! Установка php-cache дало 300%+ производительности, потратив 15 минут времени.
Кэши бывают разные: eAccelerator, xCache, APC и т.д… Мы остановились на последнем, из-за хорошей скорости и возможности хранить в нём пользовательские данные

Замена apache на nginx


Apache — тяжёлый и медленный, сначала стоял как основной web-сервер, потом перед ним был поставлен nginx, отдающий статику и сжимающий ответы gzip'ом. Далее от apache отказались вообще в пользу связки nginx+php-fpm (если быть точным на тот момент это был spawn_fcgi, но сейчас такой вариант лучше). Связка в те времена была не самая популярная для production, но у нас она работала замечательно!

Кеширование некоторых промежуточных выборок в НЕ RDBMS


RDBMS — это зло. Оно удобно, но за удобство надо платить. В данном случае скоростью. А нам именно она и нужна. Так, что часть результатов самых популярных и не критичных к актуальности запросов к мускулу мы закешировали в APC. Сразу предчувствуя множество вопросов почему не в memcached… Как бы вам ответить… мне уже надоело даже это слово слышать memcached,memcached,memcached как будто это панацея от всего. Его не предлагают последнее время разве, что только от диареи. В нашем случае выбор пал на APC ибо он не использует TCP соединение и из-за этого работает в разы быстрее. Темболее пока у нас всё отлично крутится на одном сервере и нам распределённое хранилище не так уж и нужно.
Вы можете выбрать любое другое key/value хранилище, не обязательно хранящее данные в оперативной памяти.
Но весьма вероятно, что в вашем случае memcached/memcachedb/memcacheQ будут лучшим вариантом.
Вообще была идея сделать многоуровневую кэш-прослойку в которой php искал значение в глобальных переменных, потом в APC, далее в memcached, а лишь потом лезет в базу SELECT'ом. Но так как проектом занимаемся в свободное от учёбы/работы/семьи время, то до этого пока не дошло.


Перевод ключевой части (читай трекера) на C++


120000 активных пиров создают не мало коннектов к nginx, что ещё хуже, так каждый из них дёргает php, который дёргает мускул. Вам не кажется что ето уж слишком? Нам тоже так показалось. Один из наших разработчиков собрался с силами и переписал код XBTT под фронтенд TorrentPier'а. Оно того стоило, теперь клиент обращается к трекеру на 2710 порт, который держит в памяти табличку с пирами, там его быстро находит, делает что надо и отдаёт ответ пиру обратно. Раз в минуту скидывает результаты в базу. Всё прекрасно. +100000% производительности.
Вот результаты теста, когда мы поставили время анонса — 1 минута
input (rl0) output
packets errs bytes packets errs bytes colls drops
20K 0 2.5M 16K 0 1.5M 0 0

PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
10 root 1 171 52 0K 8K RUN 1 538.6H 47.12% idle: cpu1
6994 root 1 108 0 98140K 96292K CPU0 0 3:57 33.98% xbt_tracker
11 root 1 171 52 0K 8K RUN 0 595.0H 31.20% idle: cpu0
35 root 1 -68 -187 0K 8K WAIT 0 17.1H 21.14% irq21: rl0
12 root 1 -44 -163 0K 8K WAIT 0 482:57 9.96% swi1: net

[root@****] /usr/ports/devel/google-perftools/> netstat -an | wc -l
24147

Цена вопроса 100 Метров памяти и 30% загрузка однго проца. Итого получается, что с такой же загрузкой можно держать примерно 8 Миллионов пиров на одной машине при получасовом времени анонса

Оптимизация сетевого стека FreeBSD, а также её обновление до последней -STABLE


В последних версиях FreeBSD 6 очень хорошо переработан планировщик 4BSD, а в 7ке так вообще есть такая приятная вещь как ULE, с которой мускул работает в разы шустрее на SMP
Также в любой высокопроизводительной инсталяции FreeBSD нужно крутить sysctl, я рекомендую это делать по Сысоеву

Оптимизация MySQL


База данных это то, во что рано или поздно упирается любой проект, мы не исключение.
В то время myisam у нас использовался по двум причинам
  • он используется по-умолчанию
  • в нём есть FULLTEXT индекс для поиска по форуму

Так мы потратили немало времени крутя буферы. Особенно в этом помог tuning-primer.sh
В дальнейшем планируется перевод базы на Xtradb. В любом случае нам пока хорошо — база влезает в память =)

Кэширование BB-кодов


Оказывается phpbb «на лету» преобразовывает bbcod'ы в html. Не хорошо. Закешировали сгенерированный html код в отдельном поле базы данных для каждого поста/подписи. В итоге база потяжелела почти в 2 раза, зато сайт начал летать.

Переписка кода на использование SphinxSearch


Как-то читал презентацию фликера, по поводу того как они у себя делали поиск. Так как база у них на innodb они сделали отдельную ферму Master-MultipleSlaves на myisam, чтобы обрабатывать на ней поиски. Что ж, мы не так богаты, сервер у нас только один. Ещё один наш разработчик, взяв волю в кулак, перевёл весь поиск по сайту на сверхбыстрый SphinxSearch. Результат превзошёл все ожидания. Сервер опять залетал.
Как косвенный эффект это позволило нам ввести просто супер-мега-удобный rss со встроенным поиском, который почти не грузит сервер.

Профайлинг кода и установка средств мониторинга


Странно, но многие этим ещё не пользуются. А зря. Если не знаешь где находится bottleneck устранить его невозможно. Для этого мы напихали в php код hook'ов профайлера, а на сервер установили munin.

Разборка запросов из MySQL slow query log


Тут классика! 20% запросов к базе занимают 80% времени. Приглядитесь может и у вас так. А после разбора логов, подписок FORCE INDEX к запросам и закоментирования нескольких строчек в php загрузка в час пик упала в два раза, а главная страница начала грузится в 10(!!) раз быстрее.
В общем очень рекомендую проводить такую операцию раз-два в год или после введения множества мелких нововведений. Очень помог инструмент mysqlsla.

Вместо послесловия


Вот как несколькими шагами мы превратили обычный LAMP в комплексную систему. Сейчас мы живём на обычном Core2Duo 2Ггц с 3Гб оперативки, сейчас ноутбуки в магазинах продаются «покруче», но нам хватает, а загрузка в час пик не поднимается выше 1.5 при 200000 тысячах пиров и ~500 пользователях форума. Интересно каких объёмов потребовался бы парк если бы мы тупо росли горизонтально используя LAMP и репликацию?
Посмотрим как всё изменится когда нам перестанет хватать одного сервера.

Если вы дочитали до этого момента, то тема вам интересна. Чтож, тогда добро пожаловать в блог Серверная Оптимизация!

UPD: исправил опечатки и неточности
Алексей @SaveTheRbtz
карма
445,1
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Администрирование

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

  • НЛО прилетело и опубликовало эту надпись здесь
    • +1
      Простите пряника… А поменять апач на другой на сервере платного хостинга можно самому или это только службу хостинга спрашивать?
      • +1
        другой- имею ввиду nginx
      • +4
        Вряд ли они на это пойдут. В статье имелся ввиду свой сервер (отдельный тазик), а не казенный.
  • +5
    То что доктор прописал!
  • +4
    клева :) А блог появился сегодня? :) Примерно год назад абсолютно аналогичным образом зародился и блог «Клиентская оптимизация»
  • +2
    Столько вкусного! Спасибо!
  • +2
    Спасибо за статью. Очень интересно.

    Может вы сталкивались с такой проблемой в munin. При временном подскоке нагрузки на сервер, munin не обновляет инфу, в итоге график за последние сутки выглядит вот так.
    • +2
      у мунина есть лог, где обычно написано что-то вроде такого:
      2009/02/20-12:25:15 Plugin timeout: ****: Interrupted system call (pid 25026)
  • –1
    Автар ты мозг! Как долго я мечтал о подобной информации! Спасибо за статью! Очень интересно!
  • –1
    Мммм… сколько вкусностей. Автору респект!
  • 0
    Глупо. Когда не хватит памяти, перейдете на memcached, придется переписывать PHP. Когда упретесь в серверную часть на C++ — придется переписывать. Основная задача при highload нагрузках это проектирование с возможностью спокойного роста, не хватает мощностей — купили сервер под memcached, и опять летаем.
    • +4
      Вот для вас и написан комментарий серым =) APC всё равно будет быстрее, так что часть особо часто используемой инфы лучше убрать в него благо 128 метров ему отдать не жалко, то чего в нём не найдём будем искать в memcached.
      По умному это вроде называется en.wikipedia.org/wiki/Chain-of-responsibility_pattern
      А цепь выглядит как Глобальные_переменные_php-APC-memcached-SQL

      Но до этого чувствуется ещё далеко.
      • 0
        Вы как-то неправильно используете кэширование. К примеру социальный портал в 10к активных пользователей кушает около 4гигов memcached. Есть разноуровневое кэширование, как данных из таблицы, так и сгенеренного html куска кода — или к примеру в вашем случае относительно RSS — всего RSS потока, и отдача его nginx`om без PHP вообще.

        PS: APC между прочем тормоз
        • 0
          В место APC какой op-code кешер предлагаете
          И, если не секрет, какой template engine используете?
          • +1
            APC хорош для кеширование опкода, он плох для хранения данных в нем. Хорош тем что войдет в PHP 6. В ядро, и будет дефолтным — значит и поддержка будет соответствующая.

            plain php, кусок HTML кода подгружается с ob_start, обрабатывается в контроллере, потом ob_get_clean отдается и кешируется в memcached. От templater`ов отказались за производительностью. nginx получает html код из memcached. PHP запускается редко в fastcgi. плюс в этой схеме это возможность горизонтального роста, до любого колл серверов. никоим образом не уменьшая скорость работы, хоть при 10к и 1 сервере, хоть при 1кк и 10 серверами. скорость будет одинаковой.
  • +12
    В нашем случае выбор пал на APC ибо он не использует TCP соединение и из-за этого работает в разы быстрее.

    Как же надоело слышать «memcached работает через TCP соединение и поэтом тормозит»! Не умеете — не беритесь.
    Когда мы начинали использовать memcached, уткнулись в то же самое, бутылочное горло где-то на уровне 30мбит/сек.

    Только во отличии от множества граждан, включили голову, перевесили memcached на loopback (а в вашей ситуации, когда всё на одной машине -можно и на сокет) и забыли о проблемах со скоростью доступа к memcached навсегда

    • +9
      если интересно, могу развернуть, что я имею в виду под «перевесили memcached на loopback»
      • +2
        Давайте, вполне возможно я вас не до конца понял.
        • 0
          у нас система стоит на нескольких машинах, фронтэнды состоят из memcached и смотрящих в него nginx. (ngx_http_memcached_module)

          В первом варианте бэкэнд соединялся с memcached по внешнему IP, писал туда, nginx смотрел туда же. Получили 30мбит на 100мбит канале(синтетический тест)

          После этого memcached-у было сказано слушать на всех доступных интерфейсах, и ngx_htp_memcached_module был воткнут не во внешний IP, обращения к которому проходят через весь стек OSI, даже если это твой собственный IP, а в 127.0.0.1 Синтетика показала 92мбита на 100мбит канале, мы этим удовлетворились.

          • 0
            а как вы второй сервер заведете через loopback?
            • 0
              в смысле?
              • 0
                извините, после лазания целый день по горам, внимательность к вечеру понижается :( вопрос снят
                • 0
                  ну да, скорость записи нам не критчна, зато критична распределенность. Пишем по внешнему IP. Зато критична скорость чтения, читаем по 127.0.0.1

                  Если бы memcached умел одновременно слушать и TCP и сокет, то читали бы через сокет, а так — увы :((
    • +2
      Мы как раз и пробовали через loopback, проблема была не в пропускной способности, а в времени выборки(latency).
      Нам важно получить данные из кеша как можно быстрее, чтобы сразу же отдать их пользователю. У APC, по нашим тестам, это получалось куда лучше. Но через сокет мы не пробовали, учтём на будущее. Спасибо.
      • 0
        ну так а latency у memcached — O(1)
        Иди O(1) у мемкешед больше, чем O(1) у APC? :)
        • 0
          меньше, суть в росте. APC вы на второй сервер никак не перенесёте.
          • 0
            _Я_ и не собираюсь :) У меня в продашене крутятся memcached-ы, и я ими зело доволен :)
        • +1
          Надо будет потестить скорость чтения из APC и memcached(пусть даже работающего через сокет)
          Чувствуется скорость чтения на небольшой базе будет у APC больше
          (Мы в apc храним сессии и по мелочи фигню. В итоге набирается не более 10к записей, так что скорость выборки O(1) тут мало на что влияет, а вот скорость соединения весьма критична)

          В любом случае если дойдут руки, протестирую, выложу в этом блоге.
          • 0
            Будет здорово :)
          • –1
            Ещё можно добавить eaccelerator, xcache, mysql query cache и простые файлы.
            Для memcache и mysql можно ещё добавить вариант с pconnect.
            • 0
              злые языки утверждают что pconnect никакой принципиальной разницы по сравнению с connect не даёт… где-то я даже на мега-тест натыкался
              • +1
                Выигрыш pconnect примерно в 5 раз. Это точно. Но есть 2 момента:
                1) Нет практически никакой разницы, если коннект через сокеты.
                2) Как только вы первый раз нарветесь на косяки с mysql_insert_id возненавидите pconnect лютой ненавистью.
                • 0
                  через pconnect стоит гонять лишь запросы на чтение.
        • +5
          O(1) говорит о постоянном времени работы алгоритма, независимо от входных данных. Любые две программы будут работать с большей вероятностью с разным O(1), чем с одинаковым. В случае FastCGI + APC, как я понимаю, при каждом коннекте доступ к shared memory APC уже имеется, поэтому коннектится не надо, в отличие от мемкеша. Это первый момент, не столь критичен (loopback, socket, etc.). Мне видится, разность скорости в самой идее добычи информации — что memcached, что APC в любом случае используют всяко-разные O(1) хэш-функции для поиска данных, поэтому принцип поиска один и тот же, но в случае с APC мы имеем доступ к разделяемой памяти между процессами — они ее видят, как свою собственную память и лочат только при записи, а в случае мемкеша мы гоняем данные по транспорту, дергаем определенное количество раз mem_cpy, что занимает время. Поэтому shared memory намного быстрее, но ее не поюзаешь в распределенной системе, если это не shared memory в каком-нибудь специально спроектированном супер-кластере со своим аппаратным чудо-супер-пупер-контроллером. ИМХО.
      • +1
        Если же вы хотите быстро-быстро читать со стороны бэкэнда, то не знаю, как у вас, а у нас (perl) есть например Cache::Memcached::Fast, автор провозглашает 6-ти кратное ускорение.
        • –6
          да в общем бред… поменяли тут, переписали там, это не сервер-сайд оптимизация а переписка движков, если бы были приведены примеры оптимизации и изменения этоих движков, ей бы цены не было. А так просто самопиар, и желание услашать «восторг публики».

          В общем седьмая вода на киселе.

    • +3
      > Не умеете — не беритесь.
      Так вот они как раз и не берутся :)

      Какой смысл в memcached, если все на одной машине? При разнесении частей кэшер поменять совсем не сложно.
  • –2
    Спасибо, очень познавательно
  • 0
    Отличная статья. Поскольку изучаю вопрос с нуля, то уже опробовал многие методы. Сейчас один сервер стоит на Apache+Nginx, второй только на Nginx, пока тестовый, планирую окончательно на него перебраться в скором времени :)

    Надеюсь, блог серверная оптимизация будет полезным, сам постараюсь туда писать результаты экспириенса :_)
    • 0
      избави меня бог от таких админов…
      Вы сначала разберитесь в отличиях ОС, потом постарайтесь разобраться как устроены разные fs, научитесь настраивать, к примеру, кеши дисковой подсистемы линуха их тайминги объемы (вы наверное не видели как система захлебывается от слишком большоко количества свободной памяти — которую она радостно забирает под write cache и при снижении нагрузки — все занятые 10-16 гигов начинает таки писать на диск (кстати этим страдает стандартная конфигерация Gutsy).
      В общем вопрос надо не изучать — а проводить стресс тесты и манипулируя параметрами базы, апача, нгинкса и ядра системы учиться на практике.
      • +1
        научитесь настраивать, к примеру, кеши дисковой подсистемы линуха их тайминги объемы (вы наверное не видели как система захлебывается от слишком большоко количества свободной памяти — которую она радостно забирает под write cache и при снижении нагрузки — все занятые 10-16 гигов начинает таки писать на диск

        Если у вас система захлебывается от такого типичного паттерна и закидывает в память 10-16 гиг данных, то у вас явно что-то не так. К примеру СУБД не тюнилась вообще и работает с настройками по умолчанию. Хотя вот в указанном вами случае желательно выделить памяти побольше.
      • +1
        Абсолютно не спорю и не оспариваю свое дилетантство :) Вопросом и экспериментами пришлось, как и многим в приниципе, заняться не от хорошей жизни. А поскольку занимаюсь некоммерческими сайтами, с не очень большой посещаемостью, то от моих действий никто серьезно пострадать не может. Производительность серверов потихоньку наращиваю за счет оптимизации MySQL, изучения Nginx, всего, что может помочь.
        Как раз именно поэтому недавно и понял, что без тестового сервера, который можно мучать до беспамятства — никуда :) Благо slicehost очень демократичные цены на VPS имеет.
        Спасибо за предостережения и рекоммендации :) Кстати, то что Убунта не совсем правильное решение для сервера, это уже понял на опыте.
  • +2
    и мы идем примерно по такому пути, но
    — memcached таки более подходит для кеширования результатов запросов (если в будущем планируется добавлять сервера) :)
    — трекер писали с нуля на C++ (свой код и оптимизировать и искать ошибки в нем как-то проще)
    — сейчас с PHP переходим на Java, т.к. работает в разы быстрее первого + много других плюсов
    • +2
      как я понимаю у нас разница в масштабах. у вас офис, штатные программеры, возможность свой трекер с нуля писать, у нас же всё в исключительно свободное время, поэтому выбор идёт в первую очередь — что меньше времени потребует. над переводом морды на JForum думали изначально, но столько времени просто нет
      • +1
        ну небольшая разница есть, но весь программинг делался исключительно мной до недавнего времени, а у вас вон сколько программеров ;)
        на JForum мы тоже смотрели вначале, но как-то он нам не приглянулся. сейчас на своем фреймфорке практически всю морду уже сделали… вот баги ловим и будем в продакшн запускать :)
  • –24
    Это регрессивные технологии. Однако очень популярные по одной простой причине:
    все хотят крутить баннеры, дрочить на рейтинг и банить юзеров.

    Прогрессивные технологии в p2p это DC++. Verlihub написан на C++ и действительно много держит и обходится без всей псевдополезной мишуры вебфорума.
    • +14
      Дададаа!!! Как я ждал этого первого человека который начнёт Hollywar Torrent vs DC++

      Хотите напишите пост про оптимизацию Verlihub на примере RusDC 1.2.x вас никто не останавливает. Ну или создайте опрос про предпочитаемые p2p сети в специальном блоге, зачем тролить-то?

      • –12
        А вдруг кто-то не понимает чем вы На Самом Деле вы занимаетесь? :)
        Так что это даже не холивар.
      • 0
        Меня торренты подбешивают тем, что нельзя взять тупо и скачать — я не жадный ни на контент (слава Богу, в России живу), ни на трафик (он бесплатный, ибо), но то, что выкладываю я, народ не особо качает (битлы с пинк флойдом — видимо уже не модно), посему рейтинг у меня моментально падает и приходится идти на другой трекер. А в остальном, вполне себе крутая вещь!
        • +2
          на самом деле ситуация с торрентами в россии и в мире принципиально отличается. в мире есть огромные полностью свободные трекеры и индексы типа пиратской бухты или мининовы. там не надо регистрироваться, берёшь и тупо качаешь. закрытые (приватные) трекеры есть, но они менее популярны. Россия же как всегда идёт своим путём, самый популярный трекер рунета — закрытый, с учётом трафика, регистрацией и т.п. несколько открытых трекеров есть, но о них мало кто знает.
          • +2
            о, как! не знал — спасибо за информацию)
          • 0
            менталитет у нас, что ли такой — скачал — свалил, потому на открытых трекерах раздачи умирают практически моментально
          • 0
            Вот только качество контента благодаря модерации на этом закрытом форуме поддерживается в разы лучше, чем на так называемых открытых.
            Пиратская бухта и мининова — просто две большие помойки по сравнению с торрентс.ру. А еще есть, например, what.cd, закрытый трекер. Там за шаг влево, шаг вправо — пожизненный бан. Зато качество на высоте!
            • 0
              естественно. и скорости намного выше. и сиды на открытых трекерах с раздач через несколько недель разбегаются.
        • +2
          кто мешает сидировать популярные раздачи для подъема рейтинга?
          Раз уж трафик «бесплатный ибо»?

          Приносите пользу сообществу и не будет проблем с ним. :)
          • 0
            Чтобы что-то раздать — это что-то надо сначала скачать :)
            • +1
              Можно, пока есть рейтинг, качать текущие главные раздачи, даже если они тебе не нужны и потом их сидировать ради подъема рейтинга.
              Я например таким образом на torrents.ru держу у себя рейтинг примерно 1:10 в пользу трекера. себе качаю то что мне интересно, а чтобы качать то что мне интересно — сидирую все подряд. :)
            • +2
              на многих закрытых трекерах есть «золотые раздачи»
    • +2
      Не согласен — торрент чем удобен: ты знаешь, что ты качаешь, это регламентируется правилами самого торрент-трекера. В отличие от, через DC++ ты не знаешь, что ты качаешь, в результате люди просто решили выбрать лучшую вещь, вот и всё
      • –3
        Так создайте сайт, выкладывайте скрины и magnet-ссылки, сделайте возможность комментировать.

        Ах, вы не сможете снять раздачу? Некого забанить? Ой, какая жалость!
        • 0
          Ну напишу я сайт. Это разве заставит ВСЕХ приходящих на DC хаб делать описание к каждому выложенному файлу? Torrent-трекеры хороши уже тем, что при при использовании этой p2p технологии гораздо проще создать такую ситуацию, при которой у всех выложенных в раздачу файлов будет подробное описание со скринами и т.п… Мне DC все же представляется распределенной FTP-файлопомойкой.
          • –3
            Простите, а зачем пытаться создавать какую-то ситуацию? Вы рассуждаете как владелец трекера с рейтингом.
            Хорошие файлы попадут на сайт, рано или поздно. Не очень хорошие — все равно найдутся свободным поиском.
            В любом случае это лучше красненьких огоньков и вечной надписи tracker timeout.
            • 0
              Для того чтобы рассуждать как владелец трекера с рейтингом, нужно сначала стать владельцем трекера с рейтингом. Я пока таковым не стал и в каком-то обозримом будущем этого делать не планирую. Но как пользователя, меня привлекает именно концепция трекеров (причем, почему обязательно с рейтингом? посмотрите тот же TPB: там тоже есть описания, не смотря на отсутствие рейтинговой системы), но никак не DC-сетей.
            • 0
              Раньше я тоже думал что DC лучше, я, правда, пользовался ed2k. Ну, вроде не надо париться со сбором торрент-файлов выкладыванием их на трекер, держать рейтинг.

              Но часто найти что-то дельное там нереально, потому что даже при поиске по маске получаешь кучу абсолютно левых результатов, которые, причём, никак не описаны. И даже если вдруг нашёл что искал, нет никакой гарантии что там нужный язык или качество. Мало того просто огромное количество раз закачка вдруг останавливается и всё — жди, не жди, уже не докачать.
              Но последней каплей стало то, что скачав несколько клипов с совершенно определёнными названиями, обнаружил в них банальные порноролики.
              Больше я ed2k не пользуюсь.

              Не спорю, DC и ed2k имеют право на жизнь, идея, сама по себе, замечательная, но это проканает только в полностью сознательном высокоморальном обществе. Получается, что на планете Земля это не возможно (ну разве что скандинавы могут попробовать).
        • +2
          А что вы так зацыклились на банах. В Дц тоже можно банить. Но, как было сказанно выше (или ниже), дц — это помойка. Что там банить то? А закрытый тракер, это культурное общество — со ввоими правилами. Не ты тнужен тракеру, а тракер нужен тебе. Это как привилегия. Была недавн остатья про what.cd — чтоб туда пость, надо пройти собеседование. Вам нравится анархия? Ну тогда DC для вас. Я предпочитаю торренты, где банят быдло, удаляю неправельные раздачи, оставляя только качественные.

          Не понимаю ваши доводы в пользу дц — рано или поздно появится. Мне не надо поздно, мне надо рано, надо 0day.

          Вобщем IMHO вы не правы. Может вас обидел кто на тракере? Забанили… теперь всех грязью поливаете.
          • –4
            DC это, прежде всего, технологическое превосходство: оптимизированный софт, продуманный протокол и отсутствие костылей на php, о преодолении которых написали целую героическую статью. Просто есть другой путь для масштабирования с гораздо меньшими трудностями.

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

            Впрочем, после того как докажут вину и пособничество владельцев трекера в преступлениях, остальные задумаются и над DC. Все там будем.
            • 0
              НЕ обязательно наличие костылей. НЕ обязательно применение именно пхп. Тут просто кому как удобнее. Хочу — могу коллекцию *.torrent файлов просто выложить к себе на FTP, хочу — активурую встроенный в uTorrent трекер. И тогда помимо самой программы-трекера каких-то веб-морд на пхп (и каком либо другом языке программирования) не понадобится. Это то же самое, как если бы я нашел реализацию DC-хаба на пхп и опираясь на это начал пытаться гнобить саму идею DC-сетей.

              По поводу каталогов спасибок и повышений — попросите гугл, он покажет кучу трекеров, где такого не существует. Forum-based хранилище *.torrent файлов — это еще не все что существует в природе, поверьте. Модераторы же и баны существуют и в DC, не находите? Ну точнее не из коробки, а если установить соответствующие скрипты. Но. Соответственно, и в том же торрентс.ру теоретически сам движок позволяет поснимать со всех модераторские полномочия, снять все баны и удалить учетки администраторов, запретить комментировать созданные раздачи. Станет так же как и вы пытаетесь представить в этом абзаце дц сеть. Удобны ли будут такие изменения? Мне — нет.
              • 0
                И где же эти все не костыли? Вы читали о чем статья? О марафонском беге на костылях.

                Да, в чистом виде DC-клиент не так уж удобен. Поэтому нужно к хабу создавать сайт-каталог. И не обязательно один. И не обязательно привязанный к хабу. Даже с лычками и спасибками можно, если уж на то пошло. Будет удобно.
                • 0
                  Пф. Да, читал я о чем статья. Вам процитировать ваш первый комментарий к ней или сами вспомните и поймете что говорили о технологии в целом а не об описанном в этой статье?

                  По поводу сайтов уже высказался. Мне куда удобнее торренты. пусть с подсчетом рейтинга, но удобнее. Впрочем я того что этот подсчет ведется даже не замечаю, т.к. строго придерживаюсь правила «скачал сам — дай скачать другим».
                  • 0
                    Я говорил о технологиях описанных в статье.
                    Все это не нужно если подойти к проблеме с другого конца.
                    Но именно из-за таких как вы, которые вбили себе в голову, что DC это непременный бардак, трекеродержатели вынуждены будут закупать серваки.
        • –1
          И в итоге вы придёте к системе торрентов.
        • –1
          И в итоге вы придёте к системе торрентов.
        • 0
          И в итоге вы придёте к системе торрентов.
          • 0
            Простите, сглючило =(
          • 0
            О чем я и говорю. Только без надоевших tracker timeout. Потому что проивзодительный софт уже давно написан. Не на php.
    • –1
      Cпасибо разсмешили в воскрестное утро. Direct Connect прогресивное? Ахахахах. Как появились торренты он просто умер. УМЕР. У меня он даже не установлен.

      Псевдополезной мишуры? Ахаха. Я вижу описание торрента, в каком качестве фильм, САМ или DVDRip. Могу скрины посмотреть. А в вашем дц помнится все фильмы почти были фильм.avi, сиди и гадай что там.

      Следить за новинками навернео тоже очень удобно в dc, правда? Как дебил каждую минуту сидеть и тырчиться в поиске. А тут тебе по рсс пришлют, что закачали фильм, всё как у людей.

    • –1
      Чувак, выучи хотя бы мат-часть перед тем, как делать подобные клоунские заявления.

      DC++ — клиент под винду.
      DirectConnect — p2p-протокол.

      Разные вещи, да?
      • –1
        А правда, что QIP на самом деле ICQ и Ксерокс на самом деле копировальный аппарат? Все и так поняли.
        • 0
          Скажи линуксоиду «выйди в мирк» или маководу «скинь мне файл в квип» — прочувствуешь разницу.

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

    Все же через Е пишется:) 7 раз правильно написали и один раз ошиблись:)

    Ps Не занудства ради, а красоты для.
  • +1
    Apache — тяжёлый и медленный, сначала стоял как основной web-сервер, потом перед ним был поставлен nginx, отдающий статику и сжимающий ответы gzip'ом. Далее от apache отказались вообще в пользу связки nginx+php-fpm (если быть точным на тот момент это был spawn_fcgi, но сейчас такой вариант лучше). Связка в те времена была не самая популярная для production, но у нас она работала замечательно!

    Связку nginx + apache(worker)/mod_php/opcode_cache не пробовали? Просто у php в fastcgi есть проблема. Она заключается в том что это нифига не fastcgi :) Worker используется вместо forker не зря. Это довольно сильно уменьшает нагрузку, к тому же apache в такой схеме отдает только динамику и ничего больше. Ну и самое главное при mod_php opcode_cache может держать байткод в памяти и доставать его очень быстро.

    Один из наших разработчиков собрался с силами и переписал код XBTT под фронтенд TorrentPier'а.

    Не поделитесь? :) У нас конечно машинка тащит, но такое хотели делать сами, но пока отложено до лучших времен.
    • +4
      Тут выложено под GPL
      torrentpier.info/viewtopic.php?p=18182#p18182
    • +1
      XBTT+TorrentPier выкладывался тут и тут но можно попросить автора темы дать доступ в SVN
    • 0
      на что уменьшает нагрузку worker vs forker (preforked i mean)? на цпу/память?
      • 0
        Именно CPU/память. Треды жрут меньше к тому же в режиме worker работает конвеерный режим и треды не могут быть использованы повторно.
        • 0
          тфу. Могут быть использованы повторно.
    • 0
      Не подскажите на каких версия апача и пхп оно сейчас стабильно работает с worker?
      • 0
        2.2.x и 5.2.6. Учтите что перед использованием такой связки надо проверить необходимые вам расширения на threadsafe если они не threadsafe то все же прийдется использовать forker, но при этом кеш байткода будет болтаться в памяти, что все же скажется положительно на производительности.
        • 0
          На больших нагрузках глохнет намертво. Подозреваю что из-за отсутствия количества свободных слотов. При этом если увеличить количество воркеров еще, то тачка с 4Гб на пиках залазит в своп.
          Есть мнение, что проблема скорее в тредовом php чем в апаче, но сути это не меняет, связка так-себе.
          Может, конечно, я не умею готовить эту связку, но пока что в продакшене и у других тоже не видел.
          • +1
            Больше дело в самом PHP. Только вот результаты на apache prefork + mod_php не особо лучше будут.

            PS Если у вас большая нагрузка то лучше по возможнсти выкинуть php :) Java себя лучше показывает, в том числе и при увеличении нагрузки.
    • 0
      А теперь расскажи, как используя mod_php можно обеспечить безопасность сервера, если на нём более одного сайта.
      • 0
        В случае больше одного сайта используем mpm_itk и не жужжим.
    • 0
      А теперь расскажи, как используя mod_php можно обеспечить безопасность сервера, если на нём более одного сайта.
      • 0
        См. выше. Читать не умеем да?
        • 0
          Извиняюсь, это глюк хабра, который вроде бы потерял моё первое сообщение.
          Посмотрел на тесты mpm_itk, но двухкратное падение на динамике и 10 кратное падение на статике уж очень некрасиво.
          • 0
            А подругому у вас не получится. Даже при замене на php-fpm fork на клиента никто не отменял. К тому же в этом случае теряется совместимость с .htaccess и приложения приходится серьезно пилить. Apache лучше всего использовать в связке с nginx где apache отвечает за динамику а nginx за статику и работу с медленными клиентами. В этом случае у вас нет проблемы 10 кратного падения на статике, а двухкратное падение на динамике это увы то за что приходится расплачиваться безопасностью.
            • 0
              Сейчас использую mod_fcgid (fastcgi), падения по сравнению с mod_php нет.
              Из минусов — все существующие кешэры под php создают свой пул под каждого потомка.
              Удивительно, но ни в одном из них программисты никак не сделают общий shared кэш для всех процессов. APC уже год собирается.
              .htaccess при этом работает.
              • 0
                В случае php fastcgi не имеет смысла так как он не работает там как fastcgi.
    • 0
      +500 Неоднократно проверено nginx + apache(worker)/mod_php лутче чем nginx + forked php. Правда меня за ето заминусовали бешеные фанатки толи Сисоева, толи php-fpm. Кто гонит на apache — просто не умеют его готовить.
      Очередная статья на тему: «Как Охуенно Вася и Коля разогнали свой гробик». Нудно уже ИМХО.
  • +1
    Отличная работа и описание, вот только непонятно, изначально стояла задача запустить все на таком железе? По моему это боршь переписывать трекер на си++ именно для запуска на Pentium 4 HT / 512Mb RAM, в данный момент проще обновить конфигурацию железа, т.к. по стоимости и времени это гораздо выгоднее.
    Сами столкнулись с проблемой высокой нагрузки городского торрент-трекера, но одно объявление на форуме и благодаря пользователям теперь работаем на 2*XeonE5410 + 8Gb RAM
    • +1
      изначально железо было хуже, был 2006 год, когда только начался появляться массовый широкополосный инет в крупных городах, наплыв народа на все трекеры был огромный, и на торрентс.ру который тоже не справлялся с нагрузкой и постоянно падал. рекламы первое на трекер на ставили, так что баблос на железо был ограничен. и как только выпадёт свободных пара дней — подкручивали что-то по мелочи, вроде легчало
    • 0
      Как правило оптимизация ПО требует меньшего количества телодвижений чем установка мощной машины.
      • 0
        прямо сейчас, кстати, наблюдаю обратную ситуацию — люди вместо оптимизации берут второй сервер — но у них типа рост и оптимизацией заниматься особо некогда, наращивают функциональность :)
        • 0
          Зависит от проекта. Если при при его создании была заложена масштабируемость то почему бы и нет :)
          • 0
            проект звучит слишком гордо, не было никакого «проекта», заложенной масштабируемости и прочих модных слов, зато есть load average под 40 и полное непонимание чего там где и как жрёт ресурсы… ну и деньги на второй сервер, да и на 3ий думаю найдут :)
            • 0
              не то чтоб я говорил что это правильно, но так есть, и в некоторых случаях даже работает :)
            • 0
              БГГ. Ну флаг им в руки. Все один фиг им прийдется как-то это дело оптимизировать. Или бабло на сервера кончится или добавление серверов станет делом более сложным чем оптимизация :)
              • 0
                так и будет, тогда всякие слоу квера аналайзеры и пригодится :)
      • +1
        Как правило месячная зарплата 3-4 програмеров больше стоимости даже «взрослого» сервера. И часто намного дешевле смасштабироваться горизонтально еще на один сервер, чем пару месяцев «рефакторить» код трех, а то и пятилетней давности
        • 0
          Как правило это зависит есть ли у вас программеры эти или нет. Если есть то тут начинаются варианты.

          PS За МКАД месячная зарплата 3-4 программеров меньше стоимости взрослого сервера :)
          • 0
            Средний HP DL360G5 в конфиге 2 x Quad Xeon 5420, 2x72GB SAS 10k, 4GB RAM, P400i стоит около $5к.
            Зарплата программера большего вебпроекта даже за МКАД будем считать не меньше 35 т.р. Это пусть 5 программеро-месячных окладов.
            Но вы представьте себе теперь «рефакторинг» кода пятилетней давности на проекте с посещаемостью под 100к уников в сутки. Это займет у этих пяти программеров от пары месяцев до полугода в лучшем случае. Конечно зависит от объема кода. Но его много… (вообще я это смотрю на коллег из такого проекта и со 100% понимаю — что им проще втыкать машину, правда оптимизируют они постепенно свои наработки тоже, но это не самоцель)
  • 0
    Это пять!
  • НЛО прилетело и опубликовало эту надпись здесь
    • +3
      для их проекта — да. Но если бы оптимизацию проводил знающие люди за пару дней — то это бы обошлось явно меньше покупки нового сервера и его обслуживания.

      С клиентской оптимизацией ситуация еще хуже — тут серверами особо делу не поможешь.
    • +5
      c10k никто не отменял — с течением времени проект либо дохнет, либо развивается, а вместе с развитием растет и нагрузка — нельзя вечно железом отстреливаться, не помогает ;)
      Чем раньше решишь проблему с оптимизацией, тем меньше потратишь времени в будущем. Время программиста конечно подороже, чем железо (хотя наш новый сервер с двумя 4-х-ядерными ксеонами и 16-ю гигами мозгов стоит больше, чем я получаю денег… причем, в несколько раз), но время пользователей еще дороже — чем меньше время отклика, тем меньше вероятность, что пользователь уйдет с сайта и не узнает, что можно отправить волшебную смс, получить за это виртуальную ерунду, к примеру и озолотить тем самым на копеечку компанию-владельца ресурса, а вместе с ней и ее программистов. Упущенная выгода — смертный грех любого бизнеса, имхо +)
      Да и потом, неужели неинтересно решать задачи по оптимизации? Можно вывить кучу багов, начиная с какого-нибудь алгоритма, заканчивая архитектурой самого проекта — это куда интереснее, чем железки крутить, имхо))

      Впрочем, лично я и от закручивания винтиков кайф ловлю, а наблюдение за компиляцией системы меня просто в транс вводит — особенно, когда gcc ни одного писка не выдает при -Wall, как в случае с nginx'ом ;))
    • 0
      Боюсь, что приведенная выше оптимизация стоит дешевле :)
    • +1
      а потом ещё надо умножить на количество работающих таких трекеров.

      однажды сделанная оптимизация и клонирование её на сотню инсталяций окажется дешевле апгрейда сотни машин.
  • 0
    Что на картинке?
    • +3
      Рандомный скрин с rrdool из гугла =)
  • +2
    tuning-primer.sh — очень хорош, везде его использую, а также дополнительно еще вот это:
    wiki.mysqltuner.com/MySQLTuner
  • +1
    спасибо, прочитал с удовольствием!
  • +1
    Если кому интересно, то вот тут уже есть трекер который был написан специально для xbtt. xbtit.com/
    • +1
      это уже скорее оффтоп, но пару лет назад я искал — оказалось что XBTT прикрутили практически ко всем популярным php-трекерам. не все бесплатные, сейчас вроде даже к phpBB3 прикрутили но баблос хотят. сам автор XBT, Olaf van der Spek, писал морду к… IPB по-моему, так что выбор «морд» к XBTT широкий, на любой вкус есть.
      • 0
        У меня есть тоже мечта идиота. Прикрутить его к Django или другому питоновскому фрэймворку)
        • 0
          Взять оригинальный трекер BitTornado — он на питоне :)
  • 0
    Спасибо за статью, достаточно интересно.
  • 0
    Солидарен с автором по подходу к оптимизации :-)
    В том чтоби поставить парк серверов вместо одного теряется искусство расработчика :-)
  • 0
    > супер-мега-удобный rss со встроеным поиском
    Это как? Не очень понятно, как в rss может быть поиск.

    P.S.: отличнейшая статья!
    • +1
      Видимо для каждого поиска можно получить rss-ленту, в которой будут свежие результаты.
      • 0
        именно так
  • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      разрешите не считать ваше мнение авторитетным
      • НЛО прилетело и опубликовало эту надпись здесь
  • +2
    В избранное не медля :)
  • +2
    Использую аналогичную связку nginx+ memcached + php + apc. Хочу немножко добавить, для отладки очень удобно использовать xdebug с включенным profile и скармливать полученные данные kcachegrind. Сразу видно кто и где тормозит.
    • 0
      Да, классная тулза! Почему-то мало кто ее использует, хотя сайт xdebug'а о ней активно вещает. Все от valgrind'а пошло ;)
  • 0
    молодцы!
    очень красиво показали, как много можно выйграть, когда кодеры заодно с админами.
  • +1
    расскажите, пожалуйста, подробнее о запросе, в котором вы оказались умнее оптимизатора (с помощью FORCE INDEX)
    • 0
      есть мод к phpBB который показывает несколько последних тем. там запрос с проверкой прав доступа и т.п. и заканчивается на ORDER BY id-последнего-поста LIMIT 5; поле, естественно, проиндексировано, но в WHERE стоят условия и на другие поля, видимо поэтому мускул использовал другие индексы, после чего делал дисковую сортировку результата и отбирал 5 первых строк. добиться от него, чтобы он выбирал по индексу последние посты, пока не наберётся нужный LIMIT тупым переписыванием запроса сходу не получилось, хинт с явным указанием имени индекса помог. есть подозрение, что мускул предпочитает индексы, поля которых фигурируют в WHERE, а не в ORDER BY, но глубоко на эту тему не гуглили и не экспериментировали. надеюсь понятно написал, если надо — могу сам запрос привести.
      • +1
        до этого что-то подобное было в RSS где тоже надо было отобрать несколько последних сообщений с ещё большим числом условий, но подробностей сейчас не помню и по-моему хватило хинта STRAIGHT_JOIN
      • 0
        покажите условие и show create table, если не сложно :-)
        • 0
        • –3
          Count : 1.81k (34.57%)
          Time : 10414 s total, 5.744071 s avg, 2 s to 19 s max (0.00%)
          95% of Time : 9173 s total, 5.326945 s avg, 2 s to 12 s max
          Lock Time (s) : 3 s total, 1.655 ms avg, 0 to 1 s max (30.00%)
          95% of Lock : 0 total, 0 avg, 0 to 0 max
          Rows sent : 8 avg, 6 to 136 max (4.99%)
          Rows examined : 69.97k avg, 69.94k to 70.23k max (33.25%)

          Query abstract:
          SELECT t.topic_id, t.topic_title, t.topic_last_post_id, p.post_time FROM phpbb_topics AS t, phpbb_posts AS p WHERE t.forum_id NOT
          IN (N44) AND p.topic_id = t.topic_id AND p.post_id = t.topic_last_post_id AND t.topic_moved_id = N ORDER BY t.topic_last_post_id DESC LIMIT N;

          Query sample:
          SELECT t.topic_id, t.topic_title, t.topic_last_post_id, p.post_time FROM phpbb_topics AS t, phpbb_posts AS p WHERE t.forum_id NOT
          IN (0, 395, 394, 51, 58, 142, 117, 128, 137, 290, 556, 559, 276, 277, 278, 279, 280, 281, 282, 283, 284, 285, 287, 288, 298, 305,
          309, 310, 311, 312, 381, 404, 397, 403, 409, 421, 420, 427, 495, 500, 555, 571, 575, 667) AND p.topic_id = t.topic_id AND
          p.post_id = t.topic_last_post_id AND t.topic_moved_id = 0 ORDER BY t.topic_last_post_id DESC LIMIT 6;

          mysql> explain
          +----+-------------+-------+--------+----------------------------------------------------+----------+---------+---------------------------------------+-------+-----------------------------+
          | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
          +----+-------------+-------+--------+----------------------------------------------------+----------+---------+---------------------------------------+-------+-----------------------------+
          | 1 | SIMPLE | t | range | PRIMARY,forum_id,topic_moved_id,topic_last_post_id | forum_id | 2 | NULL | 69817 | Using where; Using filesort |
          | 1 | SIMPLE | p | eq_ref | PRIMARY,topic_time | PRIMARY | 3 | northon_okroshka.t.topic_last_post_id | 1 | Using where |
          +----+-------------+-------+--------+----------------------------------------------------+----------+---------+---------------------------------------+-------+-----------------------------+
          2 rows in set (0.09 sec)


          slow-log+explain
          • 0
            почему было не сделать составной индекс forum_id + (topic_moved_id) + topic_last_post_id

            ps: всегда думал, что NOT IN, равно как != не используют индексы при выборке

            «A B-tree index can be used for column comparisons in expressions that use the =, >, >=, <, <=, or BETWEEN operators»
            • 0
              (topic_last_post_id,forum_id) можно было бы попробовать, но оно и сейчас отлично работает, поэтому трогать не хочется, вдруг не поможет. конкретно этот запрос можно вообще по p.post_id делать, а индекс topic_last_post_id выкинуть. но замену на ORDER BY p.post_id мы пробовали — не помогло без хинтов.
              • +1
                >> (topic_last_post_id,forum_id) можно было бы попробовать
                отсутствие смысла в этом составном индексе вам покажет переписывание запроса в явную форму с INNER JOIN… ON…

                >> вдруг не поможет
                не поможет. потому что см. выше.

                >> но замену на ORDER BY p.post_id мы пробовали — не помогло без хинтов.
                мде…

                свой совет я дал. ваше дело — прислушаться к нему или нет.

                моё видение проблемы: вместо использования очевидного решения и создания составного индекса на используемые в выборке по ОСНОВНОЙ ТАБЛИЦЕ вы посчитали, что вы умнее оптимизатора mysql и построили костыль-полумеру, которая, и вполне логично, работает немного лучше оригинала.
                • +1
                  1) любой оптимизатор не идеален, он не знает того, что знает программист. в данном случае идёт выборка специфических данных — 6 последних постов, оптимизатор же решает задачу в общем виде, поскольку не знает специфики выбираемых данных.

                  2) составной индекс бесспорно тяжелее простого. фильтр по forum_id в большинстве случаев ничего не отбрасывает — практически все форумы открыты, активность в закрытых очень небольшая, поэтому в большинстве случаев результат выборки по простому и составному индексу совпадут.

                  3) какое поле будет первым в составном индексе принципиально. оптимальный план выполнения данного запроса — частичный обход индекса на topic_last_post_id пока не найдётся 6 подходящих строк, в большинстве случаев ими будут самые первые 6.

                  4) явная форма JOIN тут роли не играет. оптимально обходить строки phpbb_topics по индексу topic_last_post_id в обратном порядке, выбирать строку таблицы и проверять условия, если ОК — выбрать соотв. строку из phpbb_posts по первичному ключу. т.е. JOIN должен быть самым последним.

                  5) если Вы предлагаете составной индекс, где первым полем будет forum_id — будет такой полный JOIN с последующей дисковой сортировкой, ибо обход будет не по сортируемому полю до лимита.

                  6) если topic_last_post_id вообще не индексировать, то оптимальным планом исполнения будет обход по post_id, построчный JOIN с phpbb_topics по первичному ключу, проверка условий, пока не наберётся нужный лимит. без хинтов такого плана добиться тоже не удаётся.
                  • 0
                    >> 3) какое поле будет первым в составном индексе принципиально. оптимальный план выполнения данного запроса — частичный обход индекса на topic_last_post_id пока не найдётся 6 подходящих строк, в большинстве случаев ими будут самые первые 6.
                    да что вы говорите? он будет использоваться в части объединения. у вас же проблемы в другом месте.

                    >> 4) явная форма JOIN тут роли не играет. оптимально обходить строки phpbb_topics по индексу topic_last_post_id в обратном порядке, выбирать строку таблицы и проверять условия, если ОК — выбрать соотв. строку из phpbb_posts по первичному ключу. т.е. JOIN должен быть самым последним.
                    явная форма JOIN покажет вам несостоятельность вашей идеи. вы глазками своими увидите, что тот индекс не пришей кобыле хвост.

                    >> 5) если Вы предлагаете составной индекс, где первым полем будет forum_id — будет такой полный JOIN с последующей дисковой сортировкой, ибо обход будет не по сортируемому полю до лимита.
                    индекс, который я предлагал, абсолютно никак на объединение не влияет
                    • 0
                      1) явная форма: phpbb_topics AS t JOIN phpbb_posts AS p ON p.topic_id = t.topic_id AND p.post_id = t.topic_last_post_id

                      2) есть 2 способа выполнения запроса. либо мы сначала собираем все данные (join+where), сортируем, и потом возвращаем первые 6 строк. либо мы начинаем обходить данные в порядке необходимой сортировки, т.е. от максимального topic_last_post_id к минимальному, и как только набрали указанное в LIMIT число строк — остановить обход.

                      3) обходить в нужном порядке можно по индексу, где первым полем стоит либо t.topic_last_post_id, либо p.post_id. предложенный Вами индекс этого не позволяет.

                      4) в каком месте, по вашему, у нас проблемы?

                      5) опишите подробно план исполнения запроса с ипользованием предложенного Вами индекса.
                      • 0
                        >> 4) в каком месте, по вашему, у нас проблемы?
                        в предложении этого: "(topic_last_post_id,forum_id) можно было бы попробовать"

                        5. WHERE + ORDER BY будут использовать один и тот же индекс, соответственно как для выборки, так и для сортировки. опять же — потому как в индексе данные хранятся отсортированные, то никаких дополнительных действий mysql выполнять не будет, а остановится после получения 6 записей. INNER JOIN, который будет выполняться по составному индексу p.topic_id + p.post_id на этот процесс никак влиять не будет.
                        • 0
                          1) что-то я не понял. то Вы пишете «отсутствие смысла в этом составном индексе вам покажет...», то, наоборот, настаиваете на подобном индексе?

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

                          3) данных в индексе недостаточно. например, там нет поля topic_title. поэтому дополнительные действия мускул выполнять будет — построчно читать данные из самой таблицы.

                          при этом оптимизатор сначала оценивает, какую долю записей позволяет отбросить индекс. ибо построчное обращение к таблицы намного медленее чем её полное сканирование подряд без индекса. поскольку условие NOT IN, я не исключаю что оптимизатор решит вообще индексов не использовать, а сделать FULL TABLE SCAN. с хинтом он заведомо будет использовать указанный индекс, потому я и написал «попробовать».

                          4) никакого составного индекса «p.topic_id + p.post_id» не существует.
                          • +1
                            1. где?

                            2. согласен. был невнимателен.

                            3. и что? в вашем запросе они точно так же читаются с винта.

                            4. его можно создать (sic!), именно это я посоветовал попробовать.

                            ps: да, возможно я немного поторопился со своей «критикой». простите :-[
  • +1
    >Мы остановились на последнем, из-за хорошей скорости и возможности хранить в нём пользовательские данные

    eAccelerator с этим тоже прекрасно справляется, более того может выступать как session handler, заменив стандартный файловый.
  • +1
    А что вам такую красивую картинку нарисовало с графиком загруженности?
  • 0
    И какова же итоговая разница, между голым LAMP'ом и всей этой оптимизацией — было бы интересно знать.
    • +1
      Несоизмеримо. Дефолтный LAMP умирал на 150 посетителях на форуме и пиров не больше 600-750 мог держать. Сейчас теоретический максимум гдето в районе 8-8.5 Миллионов пиров и 2500 одновременных посетителей форума.
    • 0
      замечу что разница не только количественная, но и в качестве предоставляемых «услуг».

      обмен данными торрент-клиентов с трекером происходит каждые 5 минут, на других — до 50 минут, поэтому новые пиры быстрее находят друг друга. поддерживается scrape, на многих php-движках он вообще отключен.

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

      качество поиска выше. поищите «s.t.a.l.k.e.r» например. у многих слова короче 2-3 букв не индексируются вообще.
  • 0
    >«Темболее пока у нас всё отлично крутится на одном сервере и нам распределённое хранилище не так уж и нужно.»

    «Забавно, но когда программист разрабатывает какой-либо продукт, он редко задумывается над вопросом масштабированности. А зря. Оказывается надо.»

  • +2
    Спасибо, очень интересно.

    Вопрос — есть ли на рынке фрилансеры / компании, оказывающие подобные услуги? Если нет, то почему (вряд ли из-за отсутсвия спроса, хотя он и невелик, но есть и его легко увеличить просветительскими статьями, дающими людям понять, что вместо покупки новых серверов за 4-10 тысяч долларов каждый, можно просто нанять человека для проведения оптимизации). Если небольшой объём работ позволяет сэкономить тысячи долларов, это может стать выгодным бизнесом, близким по марже к торговле кокаином текущему бизу по восстановлению данных (самая высокая цена клика в Директе и общие цены по 50 долларов за востановленный гигабайт) и в отличае от него не требующий специального железного оборудования типа стендов.

    Просто когда неделю назад пытался найти админа для LAMP-вебсервера, с платного размещения на weblancer.net, форума админов и объявы на своих проектах с посещаемостью 7 тыс. хостов в сутки, не получил ни одного отклика, хо тя стоимость в вакансии указана не была и можно было бы хоть для интереса узнать «а сколько платите?».
    • 0
      Спрос на действительно качественные услуги невысок, потому что больших проектов, которые бы имели существенную стоимость владения пока сильно меньше прочих. Многие люди очень сильно удивляются, когда слышат, что стоимость владения железками в большом проекте в разы больше фонда зп. Но и на фриланс многие такое отдавать не решаются. Оптимизация инфраструктуры — это не просто разово гайки покрутить по объявлению — обычно это целый комплекс процедур, начиная с отстраивания грамотных процедур мониторинга, заканчивая регулярным анализом «здоровья», участия в проектировании, админских делах и т.д. поскольку грамотный тюнинг экономит сотни тысяч долларов в год и выше (чем крупнее проект — тем выше значимость этих услуг) — в крупных компаниях уже есть отдельные performance-группы — как правило «кросс-функциональные» — то есть разбирающихся и в администрировании и программировании проекта. Если нужен совет где таких людей искать — пишите личку.
    • +1
      А зачем покупать сервера за 4 — 10 тысяч (я ни в коей мере не против оптимизации кода — наоборот). Но приличный сервер можно собрать тысячи за 2 (TWIN Core Quadх8Гбх320Гб в корпусе 1 U на платформе Intel), а тысяч за 5 можно уже собрать совсем монстра на SuperMicro TWIN.
      P.S. Для людей, считающих, что сервер может быть собран только вендором, отвечающим за его качество, можно прикинуть добавочную стоимость от вендора (порядка 200%) и попробовать пересчитать ее на классические гарантии при сборке из запчастей (3 года — платформа=хорошей гарантии вендора, + 1 год — винты (суммарно не более 10% стоимости сервера) — если они будут лететь регулярно на следующий день после окончания гарантии — даст удорожание сборки на 20% — соответственно от прибыли вендора остается 180%), + 1 год — процессоры (20% стоимости сервера — если будут ломаться как винты, от прибыли вендора останется 140%), ну и память (как правило с пожизненной гарантией).
      Конечно, собрать сервер — дело несколько более сложное, чем тачку домой, но, мне кажется, трата 2 — 3 дней на изучение материала, в данном случае, себя окупит.
      А на новом сервере провести оптимизацию и тонкий тюнинг софта.
      • 0
        4 это обычный 1u, например такой как собран мной под свои проекты:
        Платформа ASUS RS162-E4/RX4, 2 Xeon 51xx (не помню точно индекс), 8 Gb Fb-Dimm, LSI 8300XLP (барейка опциональна, стоит 5 штук рублей, ищется долго) для 5-го рейда, винты Seagate SAS 15-тысячники 3 штуки по 146 Gb, винт SATA 7200 на 1.5 терабайта 1 штука. Самый обычный сервер без извратов и без лишнего (давайте не будем спорить о том что можно и програмный рэйд поднять). Итого 110-115 штук, т.е те самые 4 тыс (покупался частично до падения курса рубля и соотвествующего подорожания компонентов).

        Многоюнитовые же монстры, содержащие десятки 2.5-дюймовых дисков (формат становится модным) в каком-нибудь рэйде 6+0, или какие-нибудь Intel X25E могут и подороже 10 штук стоить, наверняка. Точно не знаю, не интерсовался, т.к. пока нагрузки позволяют.

        P.S. Но мы отклонились от темы оптимизиции. А она, безусловно, нужна. Вопрос, насколько просто её произвести: поднять nginx вместо Апача можно быстро. А вот написать скрипты для mem cached или перелопатить чужой движок уровня IPB или Джумлы — уже сложнее и подчас проще докупить железок. Т.е. прежде чем проводить оптимизицию, нужно провести анализ: что можно сделать, сколько это будет стоить (я рассуждаю как работадатель — хоть сам и немного гик, но не программист и не администратор LAMP-систем, максимум могу мускул ребутнуть когда подвиснет) и какой результат хотя бы примерно принесёт. А там уж смотреть, что выгоднее.
      • +1
        Бренды рулят и это неоспариваемо.

        P.S. После вылета памяти в кеше контроллера, державшего 6-ти терабайтную полку в почтовом сервере на 250к юзеров и замены ее в течение ТРЕХ часов НОЧЬЮ (с 1 до 4:30 включая дозвон до московского супорта, отзвон местного инженера и ночные гонки до склада) я обоснованно могу сказать — ни одна супермикра ни за какие деньги не сможет такой гарантии обеспечить (это было HP если что)
        • 0
          супермикра, говорят, вообще скоро не сможет гарантии обеспечить.
        • 0
          Экстрим)))). У нас, в этом плане ситуация чуть проще — наш провайдер держит дата-центр в закрытом институте, и доступ к серверам в нерабочее время мягко говоря затруднен (конечно, я слышал, бывает и по-другому, но на московском рынке, к сожалению, ситуация типичная). Ну а в рабочее… дайте подумать… наверное, на замену памяти ушло бы часа полтора (включая дорогу до провайдера).
          • 0
            В рабочее время полтора часа ушло бы на стояния в пробках. Дело не в скорости доставки, а в стабильности поставок запчастей сервисникам и наличия их onsite. И в оплаченном HP Care Pack конечно же.
            • 0
              В рабочее время лучше на метро)))). Быстрее и почти без пробок. У меня на такой случай всегда лежит чутка запчастей дома (обходится примерно как стоимость пресловутого HP Care Pack). Впрочем — холивар на эту тему страивать не стоит — каждый экономит свои нервы так, как им (нервам, в смысле) удобнее.
              • +2
                Ну в 1876 километрах от МКАД у нас метро конечно есть, но тут оно не поможет. Если Вы можете позволить себе хранить дома в качестве «чутка запчастей» кеш-BBU или, к прмеру, RAID контроллер стоимостью в $1к — то я охрененно рад за ваше финансовое благополучие
                • 0
                  1876 км от МКАД метро, пожалуй, не поможет.))) А пробки-то там откуда?))). В качестве «чутка» запчастей я храню то, что может вылететь и повлиять на работоспособность серверов. RAID стоимостью 1К в них не входит. Я такое на свои сервера вообще не ставлю. Старая привычка еще со времен возни с FreeBSD — в начале 2000-х подобные игрушки без вазелина на нее, как правило, не вставали.
                  Впрочем, если учесть разницу в стоимости самосбора и готового решения вендора — можно было бы, пожалуй, и хранить.
                  • 0
                    Пробки оттуда же, откуда в пределах МКАД :-) Автомобилей много.
                    У нас в Екате в пробке можно даже кино смотреть (что мы с коллегой как-то и проделали однажды)
    • 0
      Есть ребята которые этим профессионально занимаются
      www.percona.com/

      В особенности оптимизацией SQL
    • 0
      Я вот подумываю начать в эту сторону фрилансить, но один отрефактореный проект, пусть даже большой — это еще не портфолио :)
  • –2
    Прочитал заголовок как "… как способ выжить из ума..."
  • –5
    ничего не понял, но когда что-то сделано круто — это круто =))
  • 0
    Хорошая статья. Оптимизации зачастую совершенно не уделяют внимания, а уж конкретных цифр (как в рекламе средств для похудания) типа «до» и «после» и вовсе не дождешься.

    Единственно что как-то резануло, так это RDBMS. Ну мы же для рунета пишем, есть же хорошая аббревиатура РСУБД, вполне устоявщееся название :-/
  • +1
    Статья понравилась. За рекомендации по настройке MySQL — отдельный респект создателям tuning_primer.sh
  • +1
    Отличная статья! Особенное спасибо за mysqlsla, не знал о таком инструменте.
  • 0
    В статье в самом начале есть ссылка php_cache -> wiki:PHP_accelerator,

    так вот есть этот же разбор на русском + тесты: club.shelek.ru/viewart.php?id=300
    кому интересно…
  • 0
    Вопрос, что было бы дешевле: сервера и репликация с удобством суппорта взамен текущих затрат на оптимизацию и поддержку этого хозяйства на случай если чего потребуется изменить?
    • 0
      сколько потребуется серверов чтобы обслужитьва 400-500 запросов в секунду на php с 4-5 запросами к базе?
      • 0
        один?
      • 0
        Смотря какой один. :)
        Если двух ядерный Core2Duo E>6000, то хватит, Еще оперы 4 гига хватит. Я думаю

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