Comments 184
UFO just landed and posted this here
То что доктор прописал!
клева :) А блог появился сегодня? :) Примерно год назад абсолютно аналогичным образом зародился и блог «Клиентская оптимизация»
Столько вкусного! Спасибо!
Спасибо за статью. Очень интересно.
Может вы сталкивались с такой проблемой в munin. При временном подскоке нагрузки на сервер, munin не обновляет инфу, в итоге график за последние сутки выглядит вот так.
Может вы сталкивались с такой проблемой в munin. При временном подскоке нагрузки на сервер, munin не обновляет инфу, в итоге график за последние сутки выглядит вот так.
Автар ты мозг! Как долго я мечтал о подобной информации! Спасибо за статью! Очень интересно!
Мммм… сколько вкусностей. Автору респект!
Глупо. Когда не хватит памяти, перейдете на memcached, придется переписывать PHP. Когда упретесь в серверную часть на C++ — придется переписывать. Основная задача при highload нагрузках это проектирование с возможностью спокойного роста, не хватает мощностей — купили сервер под memcached, и опять летаем.
Вот для вас и написан комментарий серым =) APC всё равно будет быстрее, так что часть особо часто используемой инфы лучше убрать в него благо 128 метров ему отдать не жалко, то чего в нём не найдём будем искать в memcached.
По умному это вроде называется en.wikipedia.org/wiki/Chain-of-responsibility_pattern
А цепь выглядит как Глобальные_переменные_php-APC-memcached-SQL
Но до этого чувствуется ещё далеко.
По умному это вроде называется en.wikipedia.org/wiki/Chain-of-responsibility_pattern
А цепь выглядит как Глобальные_переменные_php-APC-memcached-SQL
Но до этого чувствуется ещё далеко.
Вы как-то неправильно используете кэширование. К примеру социальный портал в 10к активных пользователей кушает около 4гигов memcached. Есть разноуровневое кэширование, как данных из таблицы, так и сгенеренного html куска кода — или к примеру в вашем случае относительно RSS — всего RSS потока, и отдача его nginx`om без PHP вообще.
PS: APC между прочем тормоз
PS: APC между прочем тормоз
В место APC какой op-code кешер предлагаете
И, если не секрет, какой template engine используете?
И, если не секрет, какой template engine используете?
APC хорош для кеширование опкода, он плох для хранения данных в нем. Хорош тем что войдет в PHP 6. В ядро, и будет дефолтным — значит и поддержка будет соответствующая.
plain php, кусок HTML кода подгружается с ob_start, обрабатывается в контроллере, потом ob_get_clean отдается и кешируется в memcached. От templater`ов отказались за производительностью. nginx получает html код из memcached. PHP запускается редко в fastcgi. плюс в этой схеме это возможность горизонтального роста, до любого колл серверов. никоим образом не уменьшая скорость работы, хоть при 10к и 1 сервере, хоть при 1кк и 10 серверами. скорость будет одинаковой.
plain php, кусок HTML кода подгружается с ob_start, обрабатывается в контроллере, потом ob_get_clean отдается и кешируется в memcached. От templater`ов отказались за производительностью. nginx получает html код из memcached. PHP запускается редко в fastcgi. плюс в этой схеме это возможность горизонтального роста, до любого колл серверов. никоим образом не уменьшая скорость работы, хоть при 10к и 1 сервере, хоть при 1кк и 10 серверами. скорость будет одинаковой.
UFO just landed and posted this here
UFO just landed and posted this here
Мы как раз и пробовали через loopback, проблема была не в пропускной способности, а в времени выборки(latency).
Нам важно получить данные из кеша как можно быстрее, чтобы сразу же отдать их пользователю. У APC, по нашим тестам, это получалось куда лучше. Но через сокет мы не пробовали, учтём на будущее. Спасибо.
Нам важно получить данные из кеша как можно быстрее, чтобы сразу же отдать их пользователю. У APC, по нашим тестам, это получалось куда лучше. Но через сокет мы не пробовали, учтём на будущее. Спасибо.
UFO just landed and posted this here
меньше, суть в росте. APC вы на второй сервер никак не перенесёте.
Надо будет потестить скорость чтения из APC и memcached(пусть даже работающего через сокет)
Чувствуется скорость чтения на небольшой базе будет у APC больше
(Мы в apc храним сессии и по мелочи фигню. В итоге набирается не более 10к записей, так что скорость выборки O(1) тут мало на что влияет, а вот скорость соединения весьма критична)
В любом случае если дойдут руки, протестирую, выложу в этом блоге.
Чувствуется скорость чтения на небольшой базе будет у APC больше
(Мы в apc храним сессии и по мелочи фигню. В итоге набирается не более 10к записей, так что скорость выборки O(1) тут мало на что влияет, а вот скорость соединения весьма критична)
В любом случае если дойдут руки, протестирую, выложу в этом блоге.
UFO just landed and posted this here
Ещё можно добавить eaccelerator, xcache, mysql query cache и простые файлы.
Для memcache и mysql можно ещё добавить вариант с pconnect.
Для memcache и mysql можно ещё добавить вариант с pconnect.
O(1) говорит о постоянном времени работы алгоритма, независимо от входных данных. Любые две программы будут работать с большей вероятностью с разным O(1), чем с одинаковым. В случае FastCGI + APC, как я понимаю, при каждом коннекте доступ к shared memory APC уже имеется, поэтому коннектится не надо, в отличие от мемкеша. Это первый момент, не столь критичен (loopback, socket, etc.). Мне видится, разность скорости в самой идее добычи информации — что memcached, что APC в любом случае используют всяко-разные O(1) хэш-функции для поиска данных, поэтому принцип поиска один и тот же, но в случае с APC мы имеем доступ к разделяемой памяти между процессами — они ее видят, как свою собственную память и лочат только при записи, а в случае мемкеша мы гоняем данные по транспорту, дергаем определенное количество раз mem_cpy, что занимает время. Поэтому shared memory намного быстрее, но ее не поюзаешь в распределенной системе, если это не shared memory в каком-нибудь специально спроектированном супер-кластере со своим аппаратным чудо-супер-пупер-контроллером. ИМХО.
UFO just landed and posted this here
> Не умеете — не беритесь.
Так вот они как раз и не берутся :)
Какой смысл в memcached, если все на одной машине? При разнесении частей кэшер поменять совсем не сложно.
Так вот они как раз и не берутся :)
Какой смысл в memcached, если все на одной машине? При разнесении частей кэшер поменять совсем не сложно.
Спасибо, очень познавательно
Отличная статья. Поскольку изучаю вопрос с нуля, то уже опробовал многие методы. Сейчас один сервер стоит на Apache+Nginx, второй только на Nginx, пока тестовый, планирую окончательно на него перебраться в скором времени :)
Надеюсь, блог серверная оптимизация будет полезным, сам постараюсь туда писать результаты экспириенса :_)
Надеюсь, блог серверная оптимизация будет полезным, сам постараюсь туда писать результаты экспириенса :_)
избави меня бог от таких админов…
Вы сначала разберитесь в отличиях ОС, потом постарайтесь разобраться как устроены разные fs, научитесь настраивать, к примеру, кеши дисковой подсистемы линуха их тайминги объемы (вы наверное не видели как система захлебывается от слишком большоко количества свободной памяти — которую она радостно забирает под write cache и при снижении нагрузки — все занятые 10-16 гигов начинает таки писать на диск (кстати этим страдает стандартная конфигерация Gutsy).
В общем вопрос надо не изучать — а проводить стресс тесты и манипулируя параметрами базы, апача, нгинкса и ядра системы учиться на практике.
Вы сначала разберитесь в отличиях ОС, потом постарайтесь разобраться как устроены разные fs, научитесь настраивать, к примеру, кеши дисковой подсистемы линуха их тайминги объемы (вы наверное не видели как система захлебывается от слишком большоко количества свободной памяти — которую она радостно забирает под write cache и при снижении нагрузки — все занятые 10-16 гигов начинает таки писать на диск (кстати этим страдает стандартная конфигерация Gutsy).
В общем вопрос надо не изучать — а проводить стресс тесты и манипулируя параметрами базы, апача, нгинкса и ядра системы учиться на практике.
научитесь настраивать, к примеру, кеши дисковой подсистемы линуха их тайминги объемы (вы наверное не видели как система захлебывается от слишком большоко количества свободной памяти — которую она радостно забирает под write cache и при снижении нагрузки — все занятые 10-16 гигов начинает таки писать на диск
Если у вас система захлебывается от такого типичного паттерна и закидывает в память 10-16 гиг данных, то у вас явно что-то не так. К примеру СУБД не тюнилась вообще и работает с настройками по умолчанию. Хотя вот в указанном вами случае желательно выделить памяти побольше.
Абсолютно не спорю и не оспариваю свое дилетантство :) Вопросом и экспериментами пришлось, как и многим в приниципе, заняться не от хорошей жизни. А поскольку занимаюсь некоммерческими сайтами, с не очень большой посещаемостью, то от моих действий никто серьезно пострадать не может. Производительность серверов потихоньку наращиваю за счет оптимизации MySQL, изучения Nginx, всего, что может помочь.
Как раз именно поэтому недавно и понял, что без тестового сервера, который можно мучать до беспамятства — никуда :) Благо slicehost очень демократичные цены на VPS имеет.
Спасибо за предостережения и рекоммендации :) Кстати, то что Убунта не совсем правильное решение для сервера, это уже понял на опыте.
Как раз именно поэтому недавно и понял, что без тестового сервера, который можно мучать до беспамятства — никуда :) Благо slicehost очень демократичные цены на VPS имеет.
Спасибо за предостережения и рекоммендации :) Кстати, то что Убунта не совсем правильное решение для сервера, это уже понял на опыте.
и мы идем примерно по такому пути, но
— memcached таки более подходит для кеширования результатов запросов (если в будущем планируется добавлять сервера) :)
— трекер писали с нуля на C++ (свой код и оптимизировать и искать ошибки в нем как-то проще)
— сейчас с PHP переходим на Java, т.к. работает в разы быстрее первого + много других плюсов
— memcached таки более подходит для кеширования результатов запросов (если в будущем планируется добавлять сервера) :)
— трекер писали с нуля на C++ (свой код и оптимизировать и искать ошибки в нем как-то проще)
— сейчас с PHP переходим на Java, т.к. работает в разы быстрее первого + много других плюсов
как я понимаю у нас разница в масштабах. у вас офис, штатные программеры, возможность свой трекер с нуля писать, у нас же всё в исключительно свободное время, поэтому выбор идёт в первую очередь — что меньше времени потребует. над переводом морды на JForum думали изначально, но столько времени просто нет
ну небольшая разница есть, но весь программинг делался исключительно мной до недавнего времени, а у вас вон сколько программеров ;)
на JForum мы тоже смотрели вначале, но как-то он нам не приглянулся. сейчас на своем фреймфорке практически всю морду уже сделали… вот баги ловим и будем в продакшн запускать :)
на JForum мы тоже смотрели вначале, но как-то он нам не приглянулся. сейчас на своем фреймфорке практически всю морду уже сделали… вот баги ловим и будем в продакшн запускать :)
Это регрессивные технологии. Однако очень популярные по одной простой причине:
все хотят крутить баннеры, дрочить на рейтинг и банить юзеров.
Прогрессивные технологии в p2p это DC++. Verlihub написан на C++ и действительно много держит и обходится без всей псевдополезной мишуры вебфорума.
все хотят крутить баннеры, дрочить на рейтинг и банить юзеров.
Прогрессивные технологии в p2p это DC++. Verlihub написан на C++ и действительно много держит и обходится без всей псевдополезной мишуры вебфорума.
Дададаа!!! Как я ждал этого первого человека который начнёт Hollywar Torrent vs DC++
Хотите напишите пост про оптимизацию Verlihub на примере RusDC 1.2.x вас никто не останавливает. Ну или создайте опрос про предпочитаемые p2p сети в специальном блоге, зачем тролить-то?
Хотите напишите пост про оптимизацию Verlihub на примере RusDC 1.2.x вас никто не останавливает. Ну или создайте опрос про предпочитаемые p2p сети в специальном блоге, зачем тролить-то?
А вдруг кто-то не понимает чем вы На Самом Деле вы занимаетесь? :)
Так что это даже не холивар.
Так что это даже не холивар.
Меня торренты подбешивают тем, что нельзя взять тупо и скачать — я не жадный ни на контент (слава Богу, в России живу), ни на трафик (он бесплатный, ибо), но то, что выкладываю я, народ не особо качает (битлы с пинк флойдом — видимо уже не модно), посему рейтинг у меня моментально падает и приходится идти на другой трекер. А в остальном, вполне себе крутая вещь!
на самом деле ситуация с торрентами в россии и в мире принципиально отличается. в мире есть огромные полностью свободные трекеры и индексы типа пиратской бухты или мининовы. там не надо регистрироваться, берёшь и тупо качаешь. закрытые (приватные) трекеры есть, но они менее популярны. Россия же как всегда идёт своим путём, самый популярный трекер рунета — закрытый, с учётом трафика, регистрацией и т.п. несколько открытых трекеров есть, но о них мало кто знает.
о, как! не знал — спасибо за информацию)
менталитет у нас, что ли такой — скачал — свалил, потому на открытых трекерах раздачи умирают практически моментально
Вот только качество контента благодаря модерации на этом закрытом форуме поддерживается в разы лучше, чем на так называемых открытых.
Пиратская бухта и мининова — просто две большие помойки по сравнению с торрентс.ру. А еще есть, например, what.cd, закрытый трекер. Там за шаг влево, шаг вправо — пожизненный бан. Зато качество на высоте!
Пиратская бухта и мининова — просто две большие помойки по сравнению с торрентс.ру. А еще есть, например, what.cd, закрытый трекер. Там за шаг влево, шаг вправо — пожизненный бан. Зато качество на высоте!
кто мешает сидировать популярные раздачи для подъема рейтинга?
Раз уж трафик «бесплатный ибо»?
Приносите пользу сообществу и не будет проблем с ним. :)
Раз уж трафик «бесплатный ибо»?
Приносите пользу сообществу и не будет проблем с ним. :)
Чтобы что-то раздать — это что-то надо сначала скачать :)
Можно, пока есть рейтинг, качать текущие главные раздачи, даже если они тебе не нужны и потом их сидировать ради подъема рейтинга.
Я например таким образом на torrents.ru держу у себя рейтинг примерно 1:10 в пользу трекера. себе качаю то что мне интересно, а чтобы качать то что мне интересно — сидирую все подряд. :)
Я например таким образом на torrents.ru держу у себя рейтинг примерно 1:10 в пользу трекера. себе качаю то что мне интересно, а чтобы качать то что мне интересно — сидирую все подряд. :)
на многих закрытых трекерах есть «золотые раздачи»
Не согласен — торрент чем удобен: ты знаешь, что ты качаешь, это регламентируется правилами самого торрент-трекера. В отличие от, через DC++ ты не знаешь, что ты качаешь, в результате люди просто решили выбрать лучшую вещь, вот и всё
Так создайте сайт, выкладывайте скрины и magnet-ссылки, сделайте возможность комментировать.
Ах, вы не сможете снять раздачу? Некого забанить? Ой, какая жалость!
Ах, вы не сможете снять раздачу? Некого забанить? Ой, какая жалость!
Ну напишу я сайт. Это разве заставит ВСЕХ приходящих на DC хаб делать описание к каждому выложенному файлу? Torrent-трекеры хороши уже тем, что при при использовании этой p2p технологии гораздо проще создать такую ситуацию, при которой у всех выложенных в раздачу файлов будет подробное описание со скринами и т.п… Мне DC все же представляется распределенной FTP-файлопомойкой.
Простите, а зачем пытаться создавать какую-то ситуацию? Вы рассуждаете как владелец трекера с рейтингом.
Хорошие файлы попадут на сайт, рано или поздно. Не очень хорошие — все равно найдутся свободным поиском.
В любом случае это лучше красненьких огоньков и вечной надписи tracker timeout.
Хорошие файлы попадут на сайт, рано или поздно. Не очень хорошие — все равно найдутся свободным поиском.
В любом случае это лучше красненьких огоньков и вечной надписи tracker timeout.
Для того чтобы рассуждать как владелец трекера с рейтингом, нужно сначала стать владельцем трекера с рейтингом. Я пока таковым не стал и в каком-то обозримом будущем этого делать не планирую. Но как пользователя, меня привлекает именно концепция трекеров (причем, почему обязательно с рейтингом? посмотрите тот же TPB: там тоже есть описания, не смотря на отсутствие рейтинговой системы), но никак не DC-сетей.
Раньше я тоже думал что DC лучше, я, правда, пользовался ed2k. Ну, вроде не надо париться со сбором торрент-файлов выкладыванием их на трекер, держать рейтинг.
Но часто найти что-то дельное там нереально, потому что даже при поиске по маске получаешь кучу абсолютно левых результатов, которые, причём, никак не описаны. И даже если вдруг нашёл что искал, нет никакой гарантии что там нужный язык или качество. Мало того просто огромное количество раз закачка вдруг останавливается и всё — жди, не жди, уже не докачать.
Но последней каплей стало то, что скачав несколько клипов с совершенно определёнными названиями, обнаружил в них банальные порноролики.
Больше я ed2k не пользуюсь.
Не спорю, DC и ed2k имеют право на жизнь, идея, сама по себе, замечательная, но это проканает только в полностью сознательном высокоморальном обществе. Получается, что на планете Земля это не возможно (ну разве что скандинавы могут попробовать).
Но часто найти что-то дельное там нереально, потому что даже при поиске по маске получаешь кучу абсолютно левых результатов, которые, причём, никак не описаны. И даже если вдруг нашёл что искал, нет никакой гарантии что там нужный язык или качество. Мало того просто огромное количество раз закачка вдруг останавливается и всё — жди, не жди, уже не докачать.
Но последней каплей стало то, что скачав несколько клипов с совершенно определёнными названиями, обнаружил в них банальные порноролики.
Больше я ed2k не пользуюсь.
Не спорю, DC и ed2k имеют право на жизнь, идея, сама по себе, замечательная, но это проканает только в полностью сознательном высокоморальном обществе. Получается, что на планете Земля это не возможно (ну разве что скандинавы могут попробовать).
А что вы так зацыклились на банах. В Дц тоже можно банить. Но, как было сказанно выше (или ниже), дц — это помойка. Что там банить то? А закрытый тракер, это культурное общество — со ввоими правилами. Не ты тнужен тракеру, а тракер нужен тебе. Это как привилегия. Была недавн остатья про what.cd — чтоб туда пость, надо пройти собеседование. Вам нравится анархия? Ну тогда DC для вас. Я предпочитаю торренты, где банят быдло, удаляю неправельные раздачи, оставляя только качественные.
Не понимаю ваши доводы в пользу дц — рано или поздно появится. Мне не надо поздно, мне надо рано, надо 0day.
Вобщем IMHO вы не правы. Может вас обидел кто на тракере? Забанили… теперь всех грязью поливаете.
Не понимаю ваши доводы в пользу дц — рано или поздно появится. Мне не надо поздно, мне надо рано, надо 0day.
Вобщем IMHO вы не правы. Может вас обидел кто на тракере? Забанили… теперь всех грязью поливаете.
DC это, прежде всего, технологическое превосходство: оптимизированный софт, продуманный протокол и отсутствие костылей на php, о преодолении которых написали целую героическую статью. Просто есть другой путь для масштабирования с гораздо меньшими трудностями.
Ну а то, что исторически в DC отсутствуют Закрытые Каталоги со спасибками, повышениями, модераторами и банами, так это просто означает, что люди не хотят там сидеть. В торентах выбора нет.
Впрочем, после того как докажут вину и пособничество владельцев трекера в преступлениях, остальные задумаются и над DC. Все там будем.
Ну а то, что исторически в DC отсутствуют Закрытые Каталоги со спасибками, повышениями, модераторами и банами, так это просто означает, что люди не хотят там сидеть. В торентах выбора нет.
Впрочем, после того как докажут вину и пособничество владельцев трекера в преступлениях, остальные задумаются и над DC. Все там будем.
НЕ обязательно наличие костылей. НЕ обязательно применение именно пхп. Тут просто кому как удобнее. Хочу — могу коллекцию *.torrent файлов просто выложить к себе на FTP, хочу — активурую встроенный в uTorrent трекер. И тогда помимо самой программы-трекера каких-то веб-морд на пхп (и каком либо другом языке программирования) не понадобится. Это то же самое, как если бы я нашел реализацию DC-хаба на пхп и опираясь на это начал пытаться гнобить саму идею DC-сетей.
По поводу каталогов спасибок и повышений — попросите гугл, он покажет кучу трекеров, где такого не существует. Forum-based хранилище *.torrent файлов — это еще не все что существует в природе, поверьте. Модераторы же и баны существуют и в DC, не находите? Ну точнее не из коробки, а если установить соответствующие скрипты. Но. Соответственно, и в том же торрентс.ру теоретически сам движок позволяет поснимать со всех модераторские полномочия, снять все баны и удалить учетки администраторов, запретить комментировать созданные раздачи. Станет так же как и вы пытаетесь представить в этом абзаце дц сеть. Удобны ли будут такие изменения? Мне — нет.
По поводу каталогов спасибок и повышений — попросите гугл, он покажет кучу трекеров, где такого не существует. Forum-based хранилище *.torrent файлов — это еще не все что существует в природе, поверьте. Модераторы же и баны существуют и в DC, не находите? Ну точнее не из коробки, а если установить соответствующие скрипты. Но. Соответственно, и в том же торрентс.ру теоретически сам движок позволяет поснимать со всех модераторские полномочия, снять все баны и удалить учетки администраторов, запретить комментировать созданные раздачи. Станет так же как и вы пытаетесь представить в этом абзаце дц сеть. Удобны ли будут такие изменения? Мне — нет.
И где же эти все не костыли? Вы читали о чем статья? О марафонском беге на костылях.
Да, в чистом виде DC-клиент не так уж удобен. Поэтому нужно к хабу создавать сайт-каталог. И не обязательно один. И не обязательно привязанный к хабу. Даже с лычками и спасибками можно, если уж на то пошло. Будет удобно.
Да, в чистом виде DC-клиент не так уж удобен. Поэтому нужно к хабу создавать сайт-каталог. И не обязательно один. И не обязательно привязанный к хабу. Даже с лычками и спасибками можно, если уж на то пошло. Будет удобно.
Пф. Да, читал я о чем статья. Вам процитировать ваш первый комментарий к ней или сами вспомните и поймете что говорили о технологии в целом а не об описанном в этой статье?
По поводу сайтов уже высказался. Мне куда удобнее торренты. пусть с подсчетом рейтинга, но удобнее. Впрочем я того что этот подсчет ведется даже не замечаю, т.к. строго придерживаюсь правила «скачал сам — дай скачать другим».
По поводу сайтов уже высказался. Мне куда удобнее торренты. пусть с подсчетом рейтинга, но удобнее. Впрочем я того что этот подсчет ведется даже не замечаю, т.к. строго придерживаюсь правила «скачал сам — дай скачать другим».
И в итоге вы придёте к системе торрентов.
И в итоге вы придёте к системе торрентов.
И в итоге вы придёте к системе торрентов.
Cпасибо разсмешили в воскрестное утро. Direct Connect прогресивное? Ахахахах. Как появились торренты он просто умер. УМЕР. У меня он даже не установлен.
Псевдополезной мишуры? Ахаха. Я вижу описание торрента, в каком качестве фильм, САМ или DVDRip. Могу скрины посмотреть. А в вашем дц помнится все фильмы почти были фильм.avi, сиди и гадай что там.
Следить за новинками навернео тоже очень удобно в dc, правда? Как дебил каждую минуту сидеть и тырчиться в поиске. А тут тебе по рсс пришлют, что закачали фильм, всё как у людей.
Псевдополезной мишуры? Ахаха. Я вижу описание торрента, в каком качестве фильм, САМ или DVDRip. Могу скрины посмотреть. А в вашем дц помнится все фильмы почти были фильм.avi, сиди и гадай что там.
Следить за новинками навернео тоже очень удобно в dc, правда? Как дебил каждую минуту сидеть и тырчиться в поиске. А тут тебе по рсс пришлют, что закачали фильм, всё как у людей.
Чувак, выучи хотя бы мат-часть перед тем, как делать подобные клоунские заявления.
DC++ — клиент под винду.
DirectConnect — p2p-протокол.
Разные вещи, да?
DC++ — клиент под винду.
DirectConnect — p2p-протокол.
Разные вещи, да?
о так как проэктом занимаемся...
Все же через Е пишется:) 7 раз правильно написали и один раз ошиблись:)
Ps Не занудства ради, а красоты для.
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'а.
Не поделитесь? :) У нас конечно машинка тащит, но такое хотели делать сами, но пока отложено до лучших времен.
Тут выложено под GPL
torrentpier.info/viewtopic.php?p=18182#p18182
torrentpier.info/viewtopic.php?p=18182#p18182
на что уменьшает нагрузку worker vs forker (preforked i mean)? на цпу/память?
Не подскажите на каких версия апача и пхп оно сейчас стабильно работает с worker?
2.2.x и 5.2.6. Учтите что перед использованием такой связки надо проверить необходимые вам расширения на threadsafe если они не threadsafe то все же прийдется использовать forker, но при этом кеш байткода будет болтаться в памяти, что все же скажется положительно на производительности.
На больших нагрузках глохнет намертво. Подозреваю что из-за отсутствия количества свободных слотов. При этом если увеличить количество воркеров еще, то тачка с 4Гб на пиках залазит в своп.
Есть мнение, что проблема скорее в тредовом php чем в апаче, но сути это не меняет, связка так-себе.
Может, конечно, я не умею готовить эту связку, но пока что в продакшене и у других тоже не видел.
Есть мнение, что проблема скорее в тредовом php чем в апаче, но сути это не меняет, связка так-себе.
Может, конечно, я не умею готовить эту связку, но пока что в продакшене и у других тоже не видел.
А теперь расскажи, как используя mod_php можно обеспечить безопасность сервера, если на нём более одного сайта.
А теперь расскажи, как используя mod_php можно обеспечить безопасность сервера, если на нём более одного сайта.
См. выше. Читать не умеем да?
Извиняюсь, это глюк хабра, который вроде бы потерял моё первое сообщение.
Посмотрел на тесты mpm_itk, но двухкратное падение на динамике и 10 кратное падение на статике уж очень некрасиво.
Посмотрел на тесты mpm_itk, но двухкратное падение на динамике и 10 кратное падение на статике уж очень некрасиво.
А подругому у вас не получится. Даже при замене на php-fpm fork на клиента никто не отменял. К тому же в этом случае теряется совместимость с .htaccess и приложения приходится серьезно пилить. Apache лучше всего использовать в связке с nginx где apache отвечает за динамику а nginx за статику и работу с медленными клиентами. В этом случае у вас нет проблемы 10 кратного падения на статике, а двухкратное падение на динамике это увы то за что приходится расплачиваться безопасностью.
Сейчас использую mod_fcgid (fastcgi), падения по сравнению с mod_php нет.
Из минусов — все существующие кешэры под php создают свой пул под каждого потомка.
Удивительно, но ни в одном из них программисты никак не сделают общий shared кэш для всех процессов. APC уже год собирается.
.htaccess при этом работает.
Из минусов — все существующие кешэры под php создают свой пул под каждого потомка.
Удивительно, но ни в одном из них программисты никак не сделают общий shared кэш для всех процессов. APC уже год собирается.
.htaccess при этом работает.
+500 Неоднократно проверено nginx + apache(worker)/mod_php лутче чем nginx + forked php. Правда меня за ето заминусовали бешеные фанатки толи Сисоева, толи php-fpm. Кто гонит на apache — просто не умеют его готовить.
Очередная статья на тему: «Как Охуенно Вася и Коля разогнали свой гробик». Нудно уже ИМХО.
Очередная статья на тему: «Как Охуенно Вася и Коля разогнали свой гробик». Нудно уже ИМХО.
Отличная работа и описание, вот только непонятно, изначально стояла задача запустить все на таком железе? По моему это боршь переписывать трекер на си++ именно для запуска на Pentium 4 HT / 512Mb RAM, в данный момент проще обновить конфигурацию железа, т.к. по стоимости и времени это гораздо выгоднее.
Сами столкнулись с проблемой высокой нагрузки городского торрент-трекера, но одно объявление на форуме и благодаря пользователям теперь работаем на 2*XeonE5410 + 8Gb RAM
Сами столкнулись с проблемой высокой нагрузки городского торрент-трекера, но одно объявление на форуме и благодаря пользователям теперь работаем на 2*XeonE5410 + 8Gb RAM
изначально железо было хуже, был 2006 год, когда только начался появляться массовый широкополосный инет в крупных городах, наплыв народа на все трекеры был огромный, и на торрентс.ру который тоже не справлялся с нагрузкой и постоянно падал. рекламы первое на трекер на ставили, так что баблос на железо был ограничен. и как только выпадёт свободных пара дней — подкручивали что-то по мелочи, вроде легчало
Как правило оптимизация ПО требует меньшего количества телодвижений чем установка мощной машины.
прямо сейчас, кстати, наблюдаю обратную ситуацию — люди вместо оптимизации берут второй сервер — но у них типа рост и оптимизацией заниматься особо некогда, наращивают функциональность :)
Зависит от проекта. Если при при его создании была заложена масштабируемость то почему бы и нет :)
проект звучит слишком гордо, не было никакого «проекта», заложенной масштабируемости и прочих модных слов, зато есть load average под 40 и полное непонимание чего там где и как жрёт ресурсы… ну и деньги на второй сервер, да и на 3ий думаю найдут :)
Как правило месячная зарплата 3-4 програмеров больше стоимости даже «взрослого» сервера. И часто намного дешевле смасштабироваться горизонтально еще на один сервер, чем пару месяцев «рефакторить» код трех, а то и пятилетней давности
Как правило это зависит есть ли у вас программеры эти или нет. Если есть то тут начинаются варианты.
PS За МКАД месячная зарплата 3-4 программеров меньше стоимости взрослого сервера :)
PS За МКАД месячная зарплата 3-4 программеров меньше стоимости взрослого сервера :)
Средний HP DL360G5 в конфиге 2 x Quad Xeon 5420, 2x72GB SAS 10k, 4GB RAM, P400i стоит около $5к.
Зарплата программера большего вебпроекта даже за МКАД будем считать не меньше 35 т.р. Это пусть 5 программеро-месячных окладов.
Но вы представьте себе теперь «рефакторинг» кода пятилетней давности на проекте с посещаемостью под 100к уников в сутки. Это займет у этих пяти программеров от пары месяцев до полугода в лучшем случае. Конечно зависит от объема кода. Но его много… (вообще я это смотрю на коллег из такого проекта и со 100% понимаю — что им проще втыкать машину, правда оптимизируют они постепенно свои наработки тоже, но это не самоцель)
Зарплата программера большего вебпроекта даже за МКАД будем считать не меньше 35 т.р. Это пусть 5 программеро-месячных окладов.
Но вы представьте себе теперь «рефакторинг» кода пятилетней давности на проекте с посещаемостью под 100к уников в сутки. Это займет у этих пяти программеров от пары месяцев до полугода в лучшем случае. Конечно зависит от объема кода. Но его много… (вообще я это смотрю на коллег из такого проекта и со 100% понимаю — что им проще втыкать машину, правда оптимизируют они постепенно свои наработки тоже, но это не самоцель)
Это пять!
UFO just landed and posted this here
для их проекта — да. Но если бы оптимизацию проводил знающие люди за пару дней — то это бы обошлось явно меньше покупки нового сервера и его обслуживания.
С клиентской оптимизацией ситуация еще хуже — тут серверами особо делу не поможешь.
С клиентской оптимизацией ситуация еще хуже — тут серверами особо делу не поможешь.
c10k никто не отменял — с течением времени проект либо дохнет, либо развивается, а вместе с развитием растет и нагрузка — нельзя вечно железом отстреливаться, не помогает ;)
Чем раньше решишь проблему с оптимизацией, тем меньше потратишь времени в будущем. Время программиста конечно подороже, чем железо (хотя наш новый сервер с двумя 4-х-ядерными ксеонами и 16-ю гигами мозгов стоит больше, чем я получаю денег… причем, в несколько раз), но время пользователей еще дороже — чем меньше время отклика, тем меньше вероятность, что пользователь уйдет с сайта и не узнает, что можно отправить волшебную смс, получить за это виртуальную ерунду, к примеру и озолотить тем самым на копеечку компанию-владельца ресурса, а вместе с ней и ее программистов. Упущенная выгода — смертный грех любого бизнеса, имхо +)
Да и потом, неужели неинтересно решать задачи по оптимизации? Можно вывить кучу багов, начиная с какого-нибудь алгоритма, заканчивая архитектурой самого проекта — это куда интереснее, чем железки крутить, имхо))
Впрочем, лично я и от закручивания винтиков кайф ловлю, а наблюдение за компиляцией системы меня просто в транс вводит — особенно, когда gcc ни одного писка не выдает при -Wall, как в случае с nginx'ом ;))
Чем раньше решишь проблему с оптимизацией, тем меньше потратишь времени в будущем. Время программиста конечно подороже, чем железо (хотя наш новый сервер с двумя 4-х-ядерными ксеонами и 16-ю гигами мозгов стоит больше, чем я получаю денег… причем, в несколько раз), но время пользователей еще дороже — чем меньше время отклика, тем меньше вероятность, что пользователь уйдет с сайта и не узнает, что можно отправить волшебную смс, получить за это виртуальную ерунду, к примеру и озолотить тем самым на копеечку компанию-владельца ресурса, а вместе с ней и ее программистов. Упущенная выгода — смертный грех любого бизнеса, имхо +)
Да и потом, неужели неинтересно решать задачи по оптимизации? Можно вывить кучу багов, начиная с какого-нибудь алгоритма, заканчивая архитектурой самого проекта — это куда интереснее, чем железки крутить, имхо))
Впрочем, лично я и от закручивания винтиков кайф ловлю, а наблюдение за компиляцией системы меня просто в транс вводит — особенно, когда gcc ни одного писка не выдает при -Wall, как в случае с nginx'ом ;))
Боюсь, что приведенная выше оптимизация стоит дешевле :)
а потом ещё надо умножить на количество работающих таких трекеров.
однажды сделанная оптимизация и клонирование её на сотню инсталяций окажется дешевле апгрейда сотни машин.
однажды сделанная оптимизация и клонирование её на сотню инсталяций окажется дешевле апгрейда сотни машин.
Что на картинке?
tuning-primer.sh — очень хорош, везде его использую, а также дополнительно еще вот это:
wiki.mysqltuner.com/MySQLTuner
wiki.mysqltuner.com/MySQLTuner
спасибо, прочитал с удовольствием!
Если кому интересно, то вот тут уже есть трекер который был написан специально для xbtt. xbtit.com/
это уже скорее оффтоп, но пару лет назад я искал — оказалось что XBTT прикрутили практически ко всем популярным php-трекерам. не все бесплатные, сейчас вроде даже к phpBB3 прикрутили но баблос хотят. сам автор XBT, Olaf van der Spek, писал морду к… IPB по-моему, так что выбор «морд» к XBTT широкий, на любой вкус есть.
Спасибо за статью, достаточно интересно.
Солидарен с автором по подходу к оптимизации :-)
В том чтоби поставить парк серверов вместо одного теряется искусство расработчика :-)
В том чтоби поставить парк серверов вместо одного теряется искусство расработчика :-)
> супер-мега-удобный rss со встроеным поиском
Это как? Не очень понятно, как в rss может быть поиск.
P.S.: отличнейшая статья!
Это как? Не очень понятно, как в rss может быть поиск.
P.S.: отличнейшая статья!
UFO just landed and posted this here
В избранное не медля :)
Использую аналогичную связку nginx+ memcached + php + apc. Хочу немножко добавить, для отладки очень удобно использовать xdebug с включенным profile и скармливать полученные данные kcachegrind. Сразу видно кто и где тормозит.
молодцы!
очень красиво показали, как много можно выйграть, когда кодеры заодно с админами.
очень красиво показали, как много можно выйграть, когда кодеры заодно с админами.
расскажите, пожалуйста, подробнее о запросе, в котором вы оказались умнее оптимизатора (с помощью FORCE INDEX)
есть мод к phpBB который показывает несколько последних тем. там запрос с проверкой прав доступа и т.п. и заканчивается на ORDER BY id-последнего-поста LIMIT 5; поле, естественно, проиндексировано, но в WHERE стоят условия и на другие поля, видимо поэтому мускул использовал другие индексы, после чего делал дисковую сортировку результата и отбирал 5 первых строк. добиться от него, чтобы он выбирал по индексу последние посты, пока не наберётся нужный LIMIT тупым переписыванием запроса сходу не получилось, хинт с явным указанием имени индекса помог. есть подозрение, что мускул предпочитает индексы, поля которых фигурируют в WHERE, а не в ORDER BY, но глубоко на эту тему не гуглили и не экспериментировали. надеюсь понятно написал, если надо — могу сам запрос привести.
до этого что-то подобное было в RSS где тоже надо было отобрать несколько последних сообщений с ещё большим числом условий, но подробностей сейчас не помню и по-моему хватило хинта STRAIGHT_JOIN
покажите условие и show create table, если не сложно :-)
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
почему было не сделать составной индекс 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»
ps: всегда думал, что NOT IN, равно как != не используют индексы при выборке
«A B-tree index can be used for column comparisons in expressions that use the =, >, >=, <, <=, or BETWEEN operators»
(topic_last_post_id,forum_id) можно было бы попробовать, но оно и сейчас отлично работает, поэтому трогать не хочется, вдруг не поможет. конкретно этот запрос можно вообще по p.post_id делать, а индекс topic_last_post_id выкинуть. но замену на ORDER BY p.post_id мы пробовали — не помогло без хинтов.
>> (topic_last_post_id,forum_id) можно было бы попробовать
отсутствие смысла в этом составном индексе вам покажет переписывание запроса в явную форму с INNER JOIN… ON…
>> вдруг не поможет
не поможет. потому что см. выше.
>> но замену на ORDER BY p.post_id мы пробовали — не помогло без хинтов.
мде…
свой совет я дал. ваше дело — прислушаться к нему или нет.
моё видение проблемы: вместо использования очевидного решения и создания составного индекса на используемые в выборке по ОСНОВНОЙ ТАБЛИЦЕ вы посчитали, что вы умнее оптимизатора mysql и построили костыль-полумеру, которая, и вполне логично, работает немного лучше оригинала.
отсутствие смысла в этом составном индексе вам покажет переписывание запроса в явную форму с INNER JOIN… ON…
>> вдруг не поможет
не поможет. потому что см. выше.
>> но замену на ORDER BY p.post_id мы пробовали — не помогло без хинтов.
мде…
свой совет я дал. ваше дело — прислушаться к нему или нет.
моё видение проблемы: вместо использования очевидного решения и создания составного индекса на используемые в выборке по ОСНОВНОЙ ТАБЛИЦЕ вы посчитали, что вы умнее оптимизатора mysql и построили костыль-полумеру, которая, и вполне логично, работает немного лучше оригинала.
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 по первичному ключу, проверка условий, пока не наберётся нужный лимит. без хинтов такого плана добиться тоже не удаётся.
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 по первичному ключу, проверка условий, пока не наберётся нужный лимит. без хинтов такого плана добиться тоже не удаётся.
>> 3) какое поле будет первым в составном индексе принципиально. оптимальный план выполнения данного запроса — частичный обход индекса на topic_last_post_id пока не найдётся 6 подходящих строк, в большинстве случаев ими будут самые первые 6.
да что вы говорите? он будет использоваться в части объединения. у вас же проблемы в другом месте.
>> 4) явная форма JOIN тут роли не играет. оптимально обходить строки phpbb_topics по индексу topic_last_post_id в обратном порядке, выбирать строку таблицы и проверять условия, если ОК — выбрать соотв. строку из phpbb_posts по первичному ключу. т.е. JOIN должен быть самым последним.
явная форма JOIN покажет вам несостоятельность вашей идеи. вы глазками своими увидите, что тот индекс не пришей кобыле хвост.
>> 5) если Вы предлагаете составной индекс, где первым полем будет forum_id — будет такой полный JOIN с последующей дисковой сортировкой, ибо обход будет не по сортируемому полю до лимита.
индекс, который я предлагал, абсолютно никак на объединение не влияет
да что вы говорите? он будет использоваться в части объединения. у вас же проблемы в другом месте.
>> 4) явная форма JOIN тут роли не играет. оптимально обходить строки phpbb_topics по индексу topic_last_post_id в обратном порядке, выбирать строку таблицы и проверять условия, если ОК — выбрать соотв. строку из phpbb_posts по первичному ключу. т.е. JOIN должен быть самым последним.
явная форма JOIN покажет вам несостоятельность вашей идеи. вы глазками своими увидите, что тот индекс не пришей кобыле хвост.
>> 5) если Вы предлагаете составной индекс, где первым полем будет forum_id — будет такой полный JOIN с последующей дисковой сортировкой, ибо обход будет не по сортируемому полю до лимита.
индекс, который я предлагал, абсолютно никак на объединение не влияет
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) опишите подробно план исполнения запроса с ипользованием предложенного Вами индекса.
2) есть 2 способа выполнения запроса. либо мы сначала собираем все данные (join+where), сортируем, и потом возвращаем первые 6 строк. либо мы начинаем обходить данные в порядке необходимой сортировки, т.е. от максимального topic_last_post_id к минимальному, и как только набрали указанное в LIMIT число строк — остановить обход.
3) обходить в нужном порядке можно по индексу, где первым полем стоит либо t.topic_last_post_id, либо p.post_id. предложенный Вами индекс этого не позволяет.
4) в каком месте, по вашему, у нас проблемы?
5) опишите подробно план исполнения запроса с ипользованием предложенного Вами индекса.
>> 4) в каком месте, по вашему, у нас проблемы?
в предложении этого: "(topic_last_post_id,forum_id) можно было бы попробовать"
5. WHERE + ORDER BY будут использовать один и тот же индекс, соответственно как для выборки, так и для сортировки. опять же — потому как в индексе данные хранятся отсортированные, то никаких дополнительных действий mysql выполнять не будет, а остановится после получения 6 записей. INNER JOIN, который будет выполняться по составному индексу p.topic_id + p.post_id на этот процесс никак влиять не будет.
в предложении этого: "(topic_last_post_id,forum_id) можно было бы попробовать"
5. WHERE + ORDER BY будут использовать один и тот же индекс, соответственно как для выборки, так и для сортировки. опять же — потому как в индексе данные хранятся отсортированные, то никаких дополнительных действий mysql выполнять не будет, а остановится после получения 6 записей. INNER JOIN, который будет выполняться по составному индексу p.topic_id + p.post_id на этот процесс никак влиять не будет.
1) что-то я не понял. то Вы пишете «отсутствие смысла в этом составном индексе вам покажет...», то, наоборот, настаиваете на подобном индексе?
2) составной индекс отсортирован только по одному полю — первому. если есть несколько строк с одинаковым значением этого поля — они сортируются по второму, если есть совпадающие — по третьему и т.д. поэтому если поле в составном индексе не на 1 месте — потребуется отдельная сортировка результатов.
3) данных в индексе недостаточно. например, там нет поля topic_title. поэтому дополнительные действия мускул выполнять будет — построчно читать данные из самой таблицы.
при этом оптимизатор сначала оценивает, какую долю записей позволяет отбросить индекс. ибо построчное обращение к таблицы намного медленее чем её полное сканирование подряд без индекса. поскольку условие NOT IN, я не исключаю что оптимизатор решит вообще индексов не использовать, а сделать FULL TABLE SCAN. с хинтом он заведомо будет использовать указанный индекс, потому я и написал «попробовать».
4) никакого составного индекса «p.topic_id + p.post_id» не существует.
2) составной индекс отсортирован только по одному полю — первому. если есть несколько строк с одинаковым значением этого поля — они сортируются по второму, если есть совпадающие — по третьему и т.д. поэтому если поле в составном индексе не на 1 месте — потребуется отдельная сортировка результатов.
3) данных в индексе недостаточно. например, там нет поля topic_title. поэтому дополнительные действия мускул выполнять будет — построчно читать данные из самой таблицы.
при этом оптимизатор сначала оценивает, какую долю записей позволяет отбросить индекс. ибо построчное обращение к таблицы намного медленее чем её полное сканирование подряд без индекса. поскольку условие NOT IN, я не исключаю что оптимизатор решит вообще индексов не использовать, а сделать FULL TABLE SCAN. с хинтом он заведомо будет использовать указанный индекс, потому я и написал «попробовать».
4) никакого составного индекса «p.topic_id + p.post_id» не существует.
>Мы остановились на последнем, из-за хорошей скорости и возможности хранить в нём пользовательские данные
eAccelerator с этим тоже прекрасно справляется, более того может выступать как session handler, заменив стандартный файловый.
eAccelerator с этим тоже прекрасно справляется, более того может выступать как session handler, заменив стандартный файловый.
А что вам такую красивую картинку нарисовало с графиком загруженности?
И какова же итоговая разница, между голым LAMP'ом и всей этой оптимизацией — было бы интересно знать.
Несоизмеримо. Дефолтный LAMP умирал на 150 посетителях на форуме и пиров не больше 600-750 мог держать. Сейчас теоретический максимум гдето в районе 8-8.5 Миллионов пиров и 2500 одновременных посетителей форума.
замечу что разница не только количественная, но и в качестве предоставляемых «услуг».
обмен данными торрент-клиентов с трекером происходит каждые 5 минут, на других — до 50 минут, поэтому новые пиры быстрее находят друг друга. поддерживается scrape, на многих php-движках он вообще отключен.
многие трекеры вообще отключили поиск в тексте сообщений форума, оставив только по названиям тем. мы не только оставили, но отдаём даже по RSS.
качество поиска выше. поищите «s.t.a.l.k.e.r» например. у многих слова короче 2-3 букв не индексируются вообще.
обмен данными торрент-клиентов с трекером происходит каждые 5 минут, на других — до 50 минут, поэтому новые пиры быстрее находят друг друга. поддерживается scrape, на многих php-движках он вообще отключен.
многие трекеры вообще отключили поиск в тексте сообщений форума, оставив только по названиям тем. мы не только оставили, но отдаём даже по RSS.
качество поиска выше. поищите «s.t.a.l.k.e.r» например. у многих слова короче 2-3 букв не индексируются вообще.
>«Темболее пока у нас всё отлично крутится на одном сервере и нам распределённое хранилище не так уж и нужно.»
«Забавно, но когда программист разрабатывает какой-либо продукт, он редко задумывается над вопросом масштабированности. А зря. Оказывается надо.»
«Забавно, но когда программист разрабатывает какой-либо продукт, он редко задумывается над вопросом масштабированности. А зря. Оказывается надо.»
Спасибо, очень интересно.
Вопрос — есть ли на рынке фрилансеры / компании, оказывающие подобные услуги? Если нет, то почему (вряд ли из-за отсутсвия спроса, хотя он и невелик, но есть и его легко увеличить просветительскими статьями, дающими людям понять, что вместо покупки новых серверов за 4-10 тысяч долларов каждый, можно просто нанять человека для проведения оптимизации). Если небольшой объём работ позволяет сэкономить тысячи долларов, это может стать выгодным бизнесом, близким по марже кторговле кокаином текущему бизу по восстановлению данных (самая высокая цена клика в Директе и общие цены по 50 долларов за востановленный гигабайт) и в отличае от него не требующий специального железного оборудования типа стендов.
Просто когда неделю назад пытался найти админа для LAMP-вебсервера, с платного размещения на weblancer.net, форума админов и объявы на своих проектах с посещаемостью 7 тыс. хостов в сутки, не получил ни одного отклика, хо тя стоимость в вакансии указана не была и можно было бы хоть для интереса узнать «а сколько платите?».
Вопрос — есть ли на рынке фрилансеры / компании, оказывающие подобные услуги? Если нет, то почему (вряд ли из-за отсутсвия спроса, хотя он и невелик, но есть и его легко увеличить просветительскими статьями, дающими людям понять, что вместо покупки новых серверов за 4-10 тысяч долларов каждый, можно просто нанять человека для проведения оптимизации). Если небольшой объём работ позволяет сэкономить тысячи долларов, это может стать выгодным бизнесом, близким по марже к
Просто когда неделю назад пытался найти админа для LAMP-вебсервера, с платного размещения на weblancer.net, форума админов и объявы на своих проектах с посещаемостью 7 тыс. хостов в сутки, не получил ни одного отклика, хо тя стоимость в вакансии указана не была и можно было бы хоть для интереса узнать «а сколько платите?».
Спрос на действительно качественные услуги невысок, потому что больших проектов, которые бы имели существенную стоимость владения пока сильно меньше прочих. Многие люди очень сильно удивляются, когда слышат, что стоимость владения железками в большом проекте в разы больше фонда зп. Но и на фриланс многие такое отдавать не решаются. Оптимизация инфраструктуры — это не просто разово гайки покрутить по объявлению — обычно это целый комплекс процедур, начиная с отстраивания грамотных процедур мониторинга, заканчивая регулярным анализом «здоровья», участия в проектировании, админских делах и т.д. поскольку грамотный тюнинг экономит сотни тысяч долларов в год и выше (чем крупнее проект — тем выше значимость этих услуг) — в крупных компаниях уже есть отдельные performance-группы — как правило «кросс-функциональные» — то есть разбирающихся и в администрировании и программировании проекта. Если нужен совет где таких людей искать — пишите личку.
А зачем покупать сервера за 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 дней на изучение материала, в данном случае, себя окупит.
А на новом сервере провести оптимизацию и тонкий тюнинг софта.
P.S. Для людей, считающих, что сервер может быть собран только вендором, отвечающим за его качество, можно прикинуть добавочную стоимость от вендора (порядка 200%) и попробовать пересчитать ее на классические гарантии при сборке из запчастей (3 года — платформа=хорошей гарантии вендора, + 1 год — винты (суммарно не более 10% стоимости сервера) — если они будут лететь регулярно на следующий день после окончания гарантии — даст удорожание сборки на 20% — соответственно от прибыли вендора остается 180%), + 1 год — процессоры (20% стоимости сервера — если будут ломаться как винты, от прибыли вендора останется 140%), ну и память (как правило с пожизненной гарантией).
Конечно, собрать сервер — дело несколько более сложное, чем тачку домой, но, мне кажется, трата 2 — 3 дней на изучение материала, в данном случае, себя окупит.
А на новом сервере провести оптимизацию и тонкий тюнинг софта.
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-систем, максимум могу мускул ребутнуть когда подвиснет) и какой результат хотя бы примерно принесёт. А там уж смотреть, что выгоднее.
Платформа 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-систем, максимум могу мускул ребутнуть когда подвиснет) и какой результат хотя бы примерно принесёт. А там уж смотреть, что выгоднее.
Бренды рулят и это неоспариваемо.
P.S. После вылета памяти в кеше контроллера, державшего 6-ти терабайтную полку в почтовом сервере на 250к юзеров и замены ее в течение ТРЕХ часов НОЧЬЮ (с 1 до 4:30 включая дозвон до московского супорта, отзвон местного инженера и ночные гонки до склада) я обоснованно могу сказать — ни одна супермикра ни за какие деньги не сможет такой гарантии обеспечить (это было HP если что)
P.S. После вылета памяти в кеше контроллера, державшего 6-ти терабайтную полку в почтовом сервере на 250к юзеров и замены ее в течение ТРЕХ часов НОЧЬЮ (с 1 до 4:30 включая дозвон до московского супорта, отзвон местного инженера и ночные гонки до склада) я обоснованно могу сказать — ни одна супермикра ни за какие деньги не сможет такой гарантии обеспечить (это было HP если что)
супермикра, говорят, вообще скоро не сможет гарантии обеспечить.
Экстрим)))). У нас, в этом плане ситуация чуть проще — наш провайдер держит дата-центр в закрытом институте, и доступ к серверам в нерабочее время мягко говоря затруднен (конечно, я слышал, бывает и по-другому, но на московском рынке, к сожалению, ситуация типичная). Ну а в рабочее… дайте подумать… наверное, на замену памяти ушло бы часа полтора (включая дорогу до провайдера).
В рабочее время полтора часа ушло бы на стояния в пробках. Дело не в скорости доставки, а в стабильности поставок запчастей сервисникам и наличия их onsite. И в оплаченном HP Care Pack конечно же.
В рабочее время лучше на метро)))). Быстрее и почти без пробок. У меня на такой случай всегда лежит чутка запчастей дома (обходится примерно как стоимость пресловутого HP Care Pack). Впрочем — холивар на эту тему страивать не стоит — каждый экономит свои нервы так, как им (нервам, в смысле) удобнее.
Ну в 1876 километрах от МКАД у нас метро конечно есть, но тут оно не поможет. Если Вы можете позволить себе хранить дома в качестве «чутка запчастей» кеш-BBU или, к прмеру, RAID контроллер стоимостью в $1к — то я охрененно рад за ваше финансовое благополучие
1876 км от МКАД метро, пожалуй, не поможет.))) А пробки-то там откуда?))). В качестве «чутка» запчастей я храню то, что может вылететь и повлиять на работоспособность серверов. RAID стоимостью 1К в них не входит. Я такое на свои сервера вообще не ставлю. Старая привычка еще со времен возни с FreeBSD — в начале 2000-х подобные игрушки без вазелина на нее, как правило, не вставали.
Впрочем, если учесть разницу в стоимости самосбора и готового решения вендора — можно было бы, пожалуй, и хранить.
Впрочем, если учесть разницу в стоимости самосбора и готового решения вендора — можно было бы, пожалуй, и хранить.
UFO just landed and posted this here
Прочитал заголовок как "… как способ выжить из ума..."
ничего не понял, но когда что-то сделано круто — это круто =))
Хорошая статья. Оптимизации зачастую совершенно не уделяют внимания, а уж конкретных цифр (как в рекламе средств для похудания) типа «до» и «после» и вовсе не дождешься.
Единственно что как-то резануло, так это RDBMS. Ну мы же для рунета пишем, есть же хорошая аббревиатура РСУБД, вполне устоявщееся название :-/
Единственно что как-то резануло, так это RDBMS. Ну мы же для рунета пишем, есть же хорошая аббревиатура РСУБД, вполне устоявщееся название :-/
Статья понравилась. За рекомендации по настройке MySQL — отдельный респект создателям tuning_primer.sh
Отличная статья! Особенное спасибо за mysqlsla, не знал о таком инструменте.
В статье в самом начале есть ссылка php_cache -> wiki:PHP_accelerator,
так вот есть этот же разбор на русском + тесты: club.shelek.ru/viewart.php?id=300
кому интересно…
так вот есть этот же разбор на русском + тесты: club.shelek.ru/viewart.php?id=300
кому интересно…
Вопрос, что было бы дешевле: сервера и репликация с удобством суппорта взамен текущих затрат на оптимизацию и поддержку этого хозяйства на случай если чего потребуется изменить?
Sign up to leave a comment.
Прогрессивные технологии, как способ выжать из сервера максимум