I am

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

Желающие что-то пообсуждать или там поставить мне коньяку - welcome

Comments

слушайте, переименуйте хайлоад в коллайдер! а то слово непривычно читать как-то...

Здравствуйте, Алексей.

Тоже был на Хайлоаде. Первый день, на докладе Антона Самохвалова сидел от Вас через проход... много смеялся :)

По поводу 10000 потоков (жесть, особенно UDP пакеты с зелеными потоками)... склоняюсь в сторону стейтмашины.. успел наступить на много грабель и постепенно подхожу к реализации схемы, с мультиплексингом на входе (потокам уже давно не доверяю, сейчас активно использую вариации на тему префорков). Вообще странно, перед этим докладом старшие озвучили идеальную, на их взгляд, архитектуру, в которой ввод/вывод осуществляется за счет мультиплексинга, а Антон гнул свое с кучей потоков. В общем позиция Яндекса не ясна, скорее всего смешали в кучу параллельные сервера и задачи связанные с вычислениями, из-за этого и непонятки. Игорь С. произвел положительное впечатление как человек и как специалист, старая школа, полностью поддерживаю :)

Первые 3 доклада очень порадовали, остальное полная лажа или смех сквозь слезы. Mail.ru отжег :)

Второй день совсем отстой (хотя про Сфинкс было очень даже ничего), зажег даже Яндекс с ассинхронной обработкой :) Надо было идти на DDOS, но кто же знал.

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

Мы это все пообсуждали в кулуарах с Анатоликсом и с Антоном тоже.
На мой взгляд, Антон сравнивал два таких случая
- "базовый поиск", который сам по себе http-сервер, многопоточный и т.п.
- его же (возможно в однопоточном варианте) плюс frontend

Понятно, что никакого zero copy в такой ситуации нет, оверхед в 5 процентов (если мы, скажем, гигабит насыщаем) - вполне вероятен (на пальцах, примерно столько и должно получиться).

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

В случае веб-сервера общего назначения, жизнь гораздо хуже - каналы медленные, плюс хочется держать keepalive. Пропагандируемый Антоном Apache2 (с сервером приложений, ну хоть mod_perl) в этом месте крякнет (т.к. будет держать под парами интерпретатор перла даже для keep-alive threads).
Я в кулуарах пофантазировал про идеальный тредовый сервер. Получилось как-то так
- пул threads для приема запросов (включая uploads)
- пул (с жестко регулируемым количеством) threads для сервера приложений
- пул для отдачи (сюда же отдача статики)
- пул threads для keep-alive (хватит и одной, там можно стейт-машину сделать :)

Но такого идеального http-сервера нет. И, я думаю, никогда не будет т.к. упаришься программировать. Ну если только Антон напишет. Ну а вообще - и смысла нет, ради избавления от лишнего копирования backend-frontend городить такой огород просто нет смысла.

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

Мне надо, так у меня есть собственный сервер приложений. Почти как описано - с пулом тредов под разные задачи (там не только HTTP), но с небольшой поправкой - все задачи реализованы в виде state machine (благо server side script тоже свой). Не state machine - только обращение к SQL (руки не дошли расковырять, как его сделать асинхронно).

Это был я :)

Написал длинное письмо, потом стер, сейчас его же напишу.

Apache 2.0 выпускали лет 5 или 7 и довольно большой толпой. mod_perl2 начали в 2002м, релиз выпустили в 2005-м.
Это все не такая маленькая задача, если мы делаем именно массовую вещь (на nginx посмотри :).

А тредовый сервер "общего применения" вещь вообще опасная т.к. в тамошнем сервере приложений будут работать приложения от разных криворуких программистов и ничего хорошего из этого не получится. Там реально много проблем, в числе прочего связанных с тем, что нужен не свой server-side скрипт, а PHP/perl/pyhon/Ruby далее везде. И основной рынок, который за 5% может и удавиться - хостеры - на отсутствие изоляции никогда не смогут пойти.

Остаются всякие крупные порталы, у которых сотни машин под однотипной задачей. Вычеркнем из них тех, у кого задача уперта в диск и 5% экономии на zero copy не вылечат. Останется очень очень мало. И у них, конечно, 5% экономии - это заметная величина - на каждой тысяче серверов можно поэкономить, скажем, 100 килобаксов т.е. вроде бы разработка окупается (для внутреннего применения то-се, казалось бы пара человеко-месяцев и все работает).
Но про альтернативные издержки тоже надо помнить, пул сотрудников, которые могут писать такое - очень маленький, брать новых негде, а значит лучше занять чем-то более полезным, что даст не 5% прироста, а 50.

(в сторону) Яндексовское Not invented here периодически потрясает.

Да я все это знаю.

Вопрос о том, чтобы сделат еще лучше массовый сервер не стоит - есть апач, данный нам свыше и куча модулей к нему. Если речь шла об улучшении массового продукта, тогда ой.

Но для проектов, разрабатываемых с нуля, мой подход отлично подходит. Не обязательно больших. По моим наблюдениям на среднем проекте отказ от требующего доработки опенсорса и переписывание сервера приложений (или чего-то еще) с нуля обходится дешевле, чем постоянное латание опенсорса. И бонус тут не в том, чтобы сэкономить килобак, поставив 1 сервер вместо двух :) в проекте, стоящем $50K, а в том, чтобы иметь максимально стабильное решение, дешевое в поддержке и развитии.

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

Ну я вот в вебе уже лет 12-13 примерно. Ну да, я видел несколько решений, когда web-сервер написали сами. Но это все не было предназначено для высовывания наружу (сюрприз, не меньше половины было поисками).

Но если бы речь шла о решении, которое exposed в дикий интернет и нет желания сделать проект делом всей жизни (смотрим на nginx) - категорически нет. Вот есть Игорь Сысоев, все грабли уже истоптал, мы с ним говорим на одном языке, ему нравится, вот и отлично.

У меня уже второй проект, в котором это "высунуто наружу". Первый правда издох быстро очень. А так - чисто внутрикорпоративный веб-интерфейс к колцентру и прочая лабуда (VoIP, SMS и т.д.)

Я бы не рискнул взять бабки за высовывание наружу апача с прочей опенсорсной обеской - надо тогда превращаться в профессионального админа и заниматься секьюрити этой балалайки. или брать человека на саппорт. А то поставил я как-то phroum на aboutphone.info .... апдейтить - забил, ну так через N лет его и похакали.

А со своим можно спать спокойно - какой бы кривизной он не был, но черные ящики так просто не ломаются.

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

А application layer - да, требует аккуратности, но это как раз повод отнести его в отдельный memory space и без всяких тредов.

Так нужно и то, и другое. И безопасно. И не превращаясь в профессионального апач-админа. И чтобы модули свои удобно было приписывать.

:)

И без хлеба.

Я ровно о том, что
а) писать свой HTTP-layer со всеми наворотами (keep-alive, pipelined, chunked, сжатие) - глупо. Протокол сложный, а простой вариант высовывать в сеть под хоть какую-то нагрузку не менее глупо.
б) application layer никто за тебя не напишет
в) разделить понятия ценой 5% производительности - выгодно.

a) Про gzip не скажу (не знаю, зачем он на практике нужен, мне кажется, что каналы нынче дешевле для владельца сервисов, чем ресурс CPU, хотя какие-то предупакованные файлы может и полезно выдавать), а остальное - это плюс-минус неделя-две девелопмента и тестинга. Если руки не кривые и код сервера свой.

в) мне все же выгодней обе уровня иметь свои :) Впрочем, у меня протоколы - это не только HTTP.

причем развитие http-сервера у меня - это крайне редкая эпизодическая деятельность.

Но у меня, кстати, не все свое - openssl юзаю. Думаю, как бы его заизолировать - смущает он меня.

Тоже стараюсь юзать поменьше чужого кода т.к. когда проимеются чужие бабки аргумент - "это либа Васи Пупкина" не прокатит :) Хочется отвечать только за себя и иметь возможность оперативно что-то поменять.

Антон, а операционная система тоже своя?

Нет, операционная система не своя, там дыры пускай латают специально обученные люди. А вот риски поиметь гемороя на прикладном уровне из-за того, что я в своей программе использую сомнительный чужой код на порядок выше (да и логика может быть посложнее). Ключевое слово - "своей", за свое ПО несу ответственность только я, за операционную систему те кто просят за нее деньги или те, кто принял решение заюзать на продакшене open source :)

Я сторонник open source но не будем кривить душой, множество проектов ведут криворукие программеры или куча народа по очереди исправляет друг за другом непонятные места и случайно искажают оригинальные идеи автора.

Я ни на что не претендую, поэтому ничего и не выкладываю.

В общем поддерживаю опасения Анатолия.

Давайте с точки зрения бизнеса на все это посмотрим.
* опенсорс с неясным количеством ошибок - это риски. Даже при очень большой разборчивости - ненулевые (libz, libpng, да тот же apache chunked - тому примеры)
* изобретение всех велосипедов с нуля - это и риски и альтернативные издержки. Компания рискует на рынке труда (найти внятных сотрудников вообще сложно, а с фильтром по lua - просто труба). Кроме того, если есть сотрудники, которые одной левой пишут http-cервер, то не лучше ли их занять чем-то полезным, по профилю компании.

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

Естественно, если компания этим программистам и принадлежит, то развлекаться за собственные деньги - есть их неотъемлемое право.

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

Никто тут свои операционки, web-сервера и мега-фреймворки не пишет, все занимаются своим делом, я пытаюсь сказать другое - если есть возможность (время и скилы) лучше не рисковать и написать самому (понятное дело openssl я не буду переписывать).

А что Вы имеете против lua? Это отличный клей.. маленький, быстрый, расширяемый, много на чем собирается с сями вяжется на ура. Конечно Java Script мне ближе по синтаксису, но пока, на мой взгляд, идеальна луа (питон совсем не перевариваю). И не надо изобретать свой скриптинг :)

Приходилось с сями вязать Perl, Java, Lua (питон сам не пробовал, но показывали) - интереснее всего показалась луа.

Правда после выхода v8 может многое измениться.

Я не имею ничего против lua - ничего про него не знаю и не собираюсь пока.

Но если ваш HR попробует найти lua-программиста, то будут проблемы.

В lua программистах нет необходимости, я ничего не имею против lua сообщества, но я осилил спецификацию языка и внутреннего API за 2 часа в горячей ванной :) Вторая часть для меня более интересна, а сам язык очень прост, серьезно можно не заморачиваться.

Давайте с точки зрения бизнеса на все это посмотрим.

Давай. Тем более, что я им и занимаюсь :)

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

Это не только риски поимать дыру, про которую будет знать весь мир, кроме нас :), это еще и некоторая сумма на развитие и сопровождение, если продукт не устраивает нас хоть чем-то. Плюс, возможно, какие-то лицензионные проблемы (привет, GPL).

* изобретение всех велосипедов с нуля - это и риски и альтернативные издержки.

Это ДРУГИЕ риски. Обеспечение безопасности черного ящика, экземпляр которого не доступен хакерам для изучения, намного проще, чем общеизвестного продукта.

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

Компания рискует на рынке труда (найти внятных сотрудников вообще сложно, а с фильтром по lua - просто труба).

Нет проблемы организовать обучение внутрифирменным инструментам (если найдены вменяемые работники). "Готовые специалисты по PHP/perl" актуальны, когда мы берем на работу невменяемых, не способных к обучению. Но тут свои проблемы - невменяемые часто работают очень плохо. Их хорошо использовать на аутсорсе, продавая их труд закачику за затраты времени (чем индусы успешно занимаются), и методы организации процесса при использовании "индусов" общеизвестны. Но при внутренней разработке, при которой за все платишь ты из своего кармана, а клиент платит за продукт независимо от затрат человекочасов, с это не так выгодно :)

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

А что больше "по профилю" для условного "яндекса", чем собственный сервер приложений и стек? Да и о чем базар? HTTP-сервер с кип-аливом, пайплайном и чанкед энкодингом - это примерно 130К исходников, включая до кучи простенького HTTP-клиента и проксю для фронтенда, использование openSSL и интерфейс со скриптом. Плюс еще килобайт 100 - инструменты (универсальный сокет-менеджер с шарингом тредов, кеш и т.д.).

Тут просто нет темы для базара - задача-то совсем небольшая.

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

Ну у меня всяко захватили :) Но не программисты - архитекторы. 50% "гаек" делаем сами. "универсальная платформа всего" имеется и продается.

Естественно, если компания этим программистам и принадлежит, то развлекаться за собственные деньги - есть их неотъемлемое право.

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

Про "захватили власть программисты" могу предложить простой тест, позволяющий отличить полный пиз##ц от благодати:

посмотри, кто платит деньги. Если те же программисты, что заххватили власть, о там либо благодать, либо лавка дохнет очень быстро. Если же программисты захватили власть распоряжаться чужими бабками - то да, чаще всего пи###ц

Все может быть гораздо хуже: у нормальной софтверной компании на начальном этапе все растет по экспоненте. Ну допустим, в два раза в год. Году на 4-5м может наступить полное видимое благолепие и запас устойчивости... на год-два. Или на 7-8-м году, видел такое.

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

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

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

Я лично "перепишем все" наблюдал на своем продукте, (ранее помянутом) для компании А. Так совпало, что рост компании с наймом новых людей совпал с очередным повышением моих расценок, и на волне возмущения меня решили заменить. Найденные через полгода орлы, количеством человека 3, вместе со старыми штатными работинкам решили сыграть в "перепишем все" (ведь было известно, что там примерно 9 месяцев моей работы на разработку - видимо начальству пообещали толпой за 3 месяца управиться). Через 3 месяца меня порадовали "мы переписали". Через год еще ничего не работало, вышла виста и у компании не оказалось продукта под нее. Еще через 9 месяцев выкатили сырой продукт и теряя репутацию доводили его до ума некоторое время. Слава богу, не умерла компания - обошлись без "общей шины".

Общая шина - это часто синдром третьей версии. Первая как-то работала, вторая - это куча патчей на первой, чтобы реально работать. В результате накопился опыт, денег достаточно (первые две версии - успешно продаются) и возникает желание сделать "по хорошему" - спроектировать все правильно, все предусмотреть и прочая.
Желание - вполне естественное, заметим.

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

Мне кажется хуже когда в компании застой, при этом все чувствуют что уже почти уперлись и пора, пока не поздно, отвлечься и подумать о будущем. Но на верху сверху сидит генератор идей, живущий в своем идеальном мире, у которого все отлично работает и есть 300% запас прочности. Из собственного негативного опыта делаются абсолютно неверные выводы. В итоге те кто внизу вязнут в болоте рутины... старый багаж все сильнее тянет назад. Никому и в голову не приходит приподнять голову и осмотреться что происходит вокруг (в т.ч. в плане организации и оплаты труда). И это при не кислых оборотах компании.

Как можно охарактеризовать такую ситуацию?

Ты правильно описал путь к пизде###у - "варез программируют в сторонке три года и потом пытаются перевести на него продукты"

На самом деле переписывать с нуля надо так, чтобы цикл переписывания занимал максимум полгода (лучше - месяц) и все приложения тестировать/адаптировать в процессе переписывания. Если все за такой срок не переписывается - надо переписывать куски. Моя "мегаплатформе" такие "перепишем" уже переживала. Переписывал куски, в которых архитектура "сделаем по-быстрому, а потом начнем латать походу" начала сильно раздражать.

Анатолий, я начну новую ветку, а то не влазит уже.

"Переписать кусками по полгода (месяцу)" - во многих случаях кажется (а иногда и является) просто неправильной идеей. Ну вот представь, что проекту - 10-15 лет, это значит что он стартовал в доисторические времена с совершенно другими требованиями и т.п. У него архитектура - просто может быть неподходящей к сегодняшнему дню и оставлять ее - означает оставлять старые ограничения и старые проблемы.

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

"Третья версия" - это не 15 лет, а где-то 3-5.

Вопрос о моральном старении продукта через 10 лет - это отдельная песня, и с ней все делается по-другому. А "третья версия" - это исправление ошибок изначального дизайна. Проблему можно решить как "мягко" (заодно заложив запас под будующее старение), так и через большой андронный коллайдер, угробив фирму.

Я обычно стараюсь проектировать продукт изначально нормально, если хоть как-то понимаю перспективые его развития. В итоге, например, аутпост вообще обошелся практически без переписываний (ну какие-то мелочи переписал, не слишком существенные), при том, что прожил в моих руках с 1999 до 2006 года, начиная с windows 95 original и до 2003 :), а почти весь содержательный функционал был написан до 2001 года. Рекордсмен - библиотека пользовательского интерфейса, рожденная мною в 90м, переписанная на 50% в 91м (не на третьей версии, а на второй) и далее просуществовавшая года до 2000 (в 2000 у меня еще были продукты с ней, а в 99 еще как-то развивал). Пережила добавление кривографического режима, переход на C++, переполз в 32 бита в DOS и потом в консоль Windows и все без переписываний. А текущий основной продукт систематически подвергается переписываниям, потому что начинался как не очень сложный автоответчик на нескольких модемах с одной стороны и софт для веб-камеры - с другой :) В итоге мигрировал до "универсальной платформы всего и вся", пройдя этап и быстрых затычек в старом коде, и полных или частичных переписываний кривых устаревших модулей.

Анатолий, а ты сам еще что-нибудь лабаешь?

50% своего рабочего времени :)

Опять куда-то атворизация потерялась.

Выше про "50% рабочего времени" был я :)

Да я понял :)

Можешь про себя сказать что жизнь удалась или все таки чего-то не хватает для полного счастья?
У каждого свое понимание счастья... семья, работа в удовольствие, самореализация, признание, путешествия и Range Rover. Мне для полного счастья, в рамках текущего уровня развития :) не хватает последнего и второе тоже что-то теперь не очень радует.
В тоже время меня очень порадовало то, что я наблюдал на HL... одна большая семья с заморочками как у меня, живущие в своих фантазиях и своими мечтами. Для меня это была отдушина, удалось на два для забыть о негативе, постоянно получаемом на работе. Удалось посмотреть чем живут окружающие... я прозрел :)

Для полного счастья всегда чего-то не хватает, но во всяком случае идиотов-начальников у меня нет уже 16 лет, и занимаюсь я тем что более-менее близко к моим интересам.

Классно... не страшно было от дяди уходить? :)

В 1992 году, учась на 4 курсе института? Не страшно. Тем более, что я сначала на полставки пошел саппортить издательство небольшое (тогда это было актуально), ну и мелкие заработки пошли :)

Блин, ты уникум.. я тоже начал трудовую карьеру на 4-м курсе, был раздолбаем, но после свадьбы решил становиться мужиком :) Нашел работу, на нормальные по тем временам бабки программером. На учебу забил и меня с 5-го курса выпи##ли, но зареспаунился с того же места и благополучно защитился. Потом всех программеров на работе разогнали, а я стал админом и остался до окончания учебы. Как закончил - сразу свалил из этой клоаки и нашел новую :). Собственно так там и работаю. Был у самых истоков, когда радовались каждой транзакции :) Сейчас это уже монстр на которого потратил молодость и весь свой энтузиазм. В результате, пока я работал за идею, продажники, с которыми все начиналось нереально поднялись на этом бизнесе, а я с остальным "обслуживающим персоналом" остался в ж##пе, хотя вроде и должность ничего и увожают и денег хватает на дорогое пиво... обидно, я вечно где-то не там, где надо :)

Я начал на первом :), причем после третьего курса от учебы был освобожден почти полностью по причине бесполезности института для меня (диплом тоже не пригодился). И время было такое - по-мелочи можно было халтурить вполне прилично, если башка варит.

Я начну ниже...

Только речь идет не о софтверной компании, софт только для себя. Нагрузка постоянно растет и уже видны первые ласточки пизде###а :)

Ну у меня нынешний основной продукт - это тоже не совсем "софтверная компания", т.е. мы его не продаем в коробке, а используем его как платформу для того, чтобы делать решения для клиентов, при этом постоянно переделываем платформу. Правда процент кода, разрабатываемого под клиента все понижается и понижается и образ "софтверной компании" все ближе и ближе :) В случае выпуска внутреннего продукта процесс был бы почти тот же, только повторного использования кода между проектами не было бы.

Несмотря на то, что продукт является классической демонстрацие неверного подхода к разработке (разрабатывали одно, а через N итераций получили совсем другое) пи###ц не наступает и не наступает. Делается это помодульным переписыванием с нуля (или близким к тому), как описано выше. Попробовал бы запустить полный процесс переписывания - убил бы гарантировано.

У меня одна штука (на нее вся нагрузка ложится, самое критичное место во всем комплексе) уже имеет 4-ю реализацию, правда внедрена только 2-я, т.к. "работает - не трогай". 3-я полностью совместима со 2-й, так что переход будет прозрачный.. как наступит момент когда совсем справляться не будет (как было несколько лет назад) - перейду на следующую версию. Каждая итерация - абсолютно новая концепция :)

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

Поэтому, в соответствии с этим принципом, она обычно чужая - не переписывается за разумное время под наши требования :)

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

Да google идет этим путем, только сегодня за обедом обсуждали с коллегами.

Но тут опять же вопрос что мы понимаем под своим дистрибутивом и чего хотим добиться.. Google активно патчит (правит) все подряд, а Ubuntu вроде вообще ничего не трогает, а просто дебы варит и скрипты лабает.

У себя мы максимум свой репозиторий внутренний развернули со своими пакетами, дальше не пойдем.

Когда-то я пытался с нуля свой "дистрибутив" делать, тянул себя за уши, делал сбрку всего сам. Убил кучу времени... оно корректно грузилось и выключалось, этим можно было пользоваться, но меньше остальных не стало. Для себя понял что если хочется поиграться, то берем генту, отличный компромисс..вроде полноценный дистрибутив и гемор есть, а если надоело все пересобирать, то можно бинарые пакеты с OpenOffice и Mozilla поставить :)
А если серьезно нормальный дистриб варить, то на основе дебиана (это мое мнение).

Анатолий, по предыдущим постам зачет :)

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

это уже начало пути к "напишем свою OS" :)

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

кстати, если мне не изменяет, то в какой-то момент у оракла был свой дистрибутив линакса для максимальной производительности сервера БД.

Почему-то логин не подставился. Anonymous, который "мы пообсуждали" - это я.

Встретились как-то 2 анонимуса ... :)

У меня префорки аля apache 1.3, но процессы делятся на три группы - приоритетные (гр.1), обычные (гр.2) и типа сборщика мусора что бы отшивать клиентов если в первых двух нет места. Процесс может переводить себя из группы в группу, скажем при открытии/закрытии соединения с БД или удаленным Web сервером. Также из группы 1 процесс автоматом переходит в группу 2 при отсутствии активности.
С одной стороны 24/7 молотят cgi`ники с бешеной частотой (постоянные реконнекты), с другой имеем щадящие кипэлайвы - все счастливы.

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

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

Еще до конфы начал думать о мультиплексинге, очередях и ограниченного набора процессов в пуле (воркеров).. теперь на 100% склоняюсь к этому... буду ваять.
Очень вкусно выглядят очереди с приоритетами и специализация воркеров.

В качестве server side script активно юзаю lua :) отлично вяжется с сями, только синтаксис немного убогий... в остальном очень доволен.
Замутил свой lua home pages с компиляцией, но коллеги-перловики смеются.. говорят что видимо все сишники в какой-то момент изобретают свой lhp (похожий проект уже есть - lsp) :)
Встраиваю везде где только можно, есть модули для 2-х апачей.

Коллеги, а на HL++ что-нибудь стоящее будет?
Странные они какие-то ребята, делать подряд два идентичных мероприятия .

Будет или нет - не знаю, но ребята не странные, а конкурирующие после развода.

Да, слышал эту историю, но для меня странно... типа у нас будет свой HL с блекджеком и шлюхами. Туда мой начальник собирается теперь собирается.

Я тоже люблю все сам, когда-то COM-объекты микрософтовские руками стряпал (свою либу писал).. дошел до автоматизации, но дальше уже не рискнул, смыла городить такое самому нет. Но для самообразования очень полезно. Боюсь лет через 10 никто уже и знать не будет как оно там работает.

Народ приходит на собеседование... за последний год только 2 человека внятно смогли рассказать как работает sizeof, что такое vtable, какие бывают сегменты памяти и назвали несколько подходов к построению параллельных серверов. Правда и они были зациклины на pthreads... как пользоваться разделяемой памятью и что там за semset`ы такие не в теме. Один ушел в Яндекс, второй в Суп... оба мимо.

В принципе выставить собственный web-сервер наружу я бы рискнул, но пока нет смысла, по крайней мере пока поток не начнем на 7-м уровне делить между апачем и самопиской в зависимости от типа запросов (лень из-за веба cgi, ssl и прочие радости реализовывать).

По поводу HTTP - на позопрошлой неделе на плюсах налабал реализацию с keep-alive, chunked encoding (в сторону клиента), digest авторизацией (правда для упрощения stateless вариант без контроля за значением nonce counter`а) и lua. На все про все ушло порядка 4-х дней. Для внутренних вопросов вполне достаточно, а тратить жизнь на полноценный сервак тоже желания нет, боюсь дальше пойдет рутина и негитавные отзывы избалованных пользователей :)

Хотел спросить, что вы думаете по поводу кашерности передачи файловых описателей между процессами с использованием локальных сокетов, sendmsg и SCM_RIGHTS? Недавно об этом узнал и немного удивился, на линуксе проверил, все ОК, на бсде тоже должно работать. Такое есть в винде в winsock2, юзал когда писал мультипроцессный сервер под нее.

В принципе можно обойтись без этого хака, но это единственноый способ, который я смог найти, для раелизации FSM на наскольких процессах без гонок. Интересно как поступил Сысоев в nginx, у него же можно поднять несколько воркеров. Не думаю что у него они все тупо ждут соединения на сокете а потом кто успел.

Ну есть такая штука. Я ее лет 10 назад обнаружил, потестировал и никогда более не использовал, ибо не могу придумать разумного применения.

А параллельные процессы на одном сокете - обычно делают висение на mutex, отчего accept происходит только в одном из процессов. Так сделано в apache, думаю что у Игоря - аналогично.

Если сервер многопоточный, то тут вопросов нет, а я говорю о многопроцессном.
Тут семафоры никак не получается приладить. В серверах на основе FSM
все вертится вокруг мультиплексинга ввода/вывода кучи файловых описателей (серверные сокеты, клиентские сокеты, пайпы с сигналами и т.д.). Т.е. сердце всего это системный вызов типа select, poll и epoll_wait, а там к сожалению нет лишнего параметра на тему семафоров. Все что мы можем совместить - операции ввода/вывода и сигналы. Семафоры остаются в стороне, придется придумывать что-то с управляющим процессом, но ничего внятного в голову не приходит. Ну либо тупо ждем события на сокете из нескольких процессов и надеемся что никто не догадается поставить сотню воркеров и выставить это чудо в интернет.

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

Интереснее вариант со звездой, основной процесс расфоркивается, потом ждет соединений и раскидывает их по очереди между потомками (ну и себя не забывает). Дальше все работает как FSM.
Получаем тупейшую схему как и на потоках только с изоляцией. Без проблем можно что-то придумать что бы при падении основного процесса его обязанности переходили к другому.

Насколько все это будет эффективным надо пробовать... может кто-то что-то подобное делал?

Почему не получается?
Можно atomic get/set на mmap-ed памяти, как nginx делает.
Можно заблокироваться на файловом дескрипторе, как apache делает.
Есть SYSV семафоры.

Вообще, вариантов синхронизации в современных ос скока хочешь.

:) для этой задачи я подходящего варианта не нахожу.

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

Вот только как быть если дочерний процесс у меня обслуживает больше одного клиента с использованием мультиплексинга? Вариант с семафором не работает. Если делать захват семафора после селекта - гонки. Если до, то надо с флагом IPC_NOWAIT, иначе живые клиенты всех процессов кроме одного встанут. Но в любом случае получится так, что серверный сокет захватит один процес, а о моменте его освобождения никто не узнает. Нужен механизм что бы их пнуть, при чем так что бы пробудились не все, а только один.

Боюсь что не понятно получается.

Я вижу два варианта
а) accept делают все (ну, точнее, в select или там в kqueue загоняем все сокеты). Проблема на самом деле минимальная - лишние wake up (по числу процессов) по приходу соединения.

б) если мы успеваем проверять семафор быстрее, чем заполняется backlog (нет долгих операций в FSM), то mutex отвечает не за accept, а за помещение хэндла в select/whatever

В первом варианте меня как раз и смущают лишние wake up, все предыдущие посты на эту тему.

По второму... mutex отвечает за помещение хэндла серверного сокета в select?
Если так, то как раз возникает ситуация что остальные не узнают когда хэндл освободится если не будут постоянно молотить опрашивая mutex. А молотить мы не будем т.к. большую часть времени мы спим в select`е.

Опрашивать mutex нужно чаще, чем время заполнения backlog, что на самом деле довольно редко.

Т.е. у нас всетаки получается опросная модель? Или предлагается из select`а раз в секунду (цифра с потолка) вываливаться и пробовать захватить mutex (в каждом процессе)?

Мне кажется это плохая затея, в таком случае лучше использовать сценарий А, а еще лучше SCM_RIGHTS.

В nginx trylock делается в каждом проходе по eventloop.
7 инструкций процессора (для типичной в наше время архитектуры)

Алексей, вы общаетесь с Игорем, поэтому должны знать, у него воркеры на потоках или процессах?

nginx is very well documented...

На процессах, по меньшей мере на FreeBSD

Блокировки - на mutex. Как именно лечится обсуждаемая проблема - не смотрел.

По поводу вчерашнего у Яндекса, Самохвалов 10000 потоков запустил?

Я учился по специальности (инженер-программист), но все что я знаю получил не там, в общем самоучка как и все. Диплом никто никогда не смотрел, он "важен" только в государственных учреждениях.
Насчет халтурить.. да, с другом пытались впаривать свою программу складского учета, но я на этом заработал всего 125$ :) Еще анализировал безопасность какой-то сети... хоть и был полным лохом, умудрился за ночь заработать на золотую печатку. Вообще тогда все находилось в зачатке, было где развернуться... У тех ребят прокся наружу торчала, сейчас бы копнул глубже.
Правда мои воспоминания о юнешестве гораздо позже твоих :) Первый модем у меня появился в 11-м классе, это был внутренний USR 14400 (про "Русский курьер" тоже слышал) :) Сначала были BBSки, помню была коммерческая с несколькими линиями White Bear.. потом был первый опыт общения с Интернетом. Первый пров был Сайтек, у них еще BBS тоже была... помню очередь в окошко. Потом был Ситилайн с безлимитным тарифом, ездили в какой-то игровой клуб "Орки" что бы бабки заплатить. Помню халявные эккаунты... тогда я с головой ушел в IRC... тусовки по выходным в Парке Горького. Это было время 3DFX (у меня был Diamond 3D Monster, пытался под него писать... glide) Тогда вышла Half Life 1, но я в нее уже не играл из-за интернет-зависимости, первый раз прошел ее в прошлом году :)
Было круто, не то что сейчас... хочешь PS3, хочешь 10000 потоков :)

Помню как классе в пятом перепрограммировал знакогенератор на спектруме, еще играли в Элиту. Спектрум был верхом мечтаний, у меня был БК 0010 (с фокальным блоком), а самый первый - Электроника РК-86, тогда я был, блин, совсем детём.. у него даже крышки не было верхней.

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

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

А ты на HL++ пошел?

Я живу в Питере.
Да и не интересны мне такие тусовки.

Не знал :)
А кроме фото чем-нить увлекаешься?
У меня телескоп есть.

Ну чем увлекаться озверевшему от компьютеров программисту? Если фото, то, конечно, еще и путешествия :)

чей-то мы Алексея оффтопиком завалили :)

Думаешь обидется? :)

Тогда по теме, наши вернулись с HL++, говорят в основном пиарили свои продуты, многие докладчики совсем не подготовились... Отличились ребята с ZFS.
CBOSS вроде ничего был, собрали какую-то свою бустовую штуковину разными компиляторами под разные ОС и посмотрели где быстрее, оказалась винда.
Разбираться почему не стали (еще бы.... в кишках буста кому охота копаться), винда так винда :)

Блин, путешествия это супер, я правда за пределы России не выезжал, но за последние 2 года весь Краснодарский край объездили с женой. Очень радуют горы и рафтинг. Теперь, после рождения ребенка, придется прерваться.

Вообще, действительно, устроили тут флуд. Щаз зобаню, тоже мне, чат на яндексе нашли (я помню и такое!)

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

Из недостатков - в кабаке не было Мартеля (в прошлый раз все выпили), а от Хенесси меня клонит в сон.

Алексей, прости.
Приятно поговорить с умными людьми :)

На предыдущем HL, как я уже писал, мне понравились 3 первых доклата в 1-м зале. Остальное бред или скукота.

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

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