Дело не в политическом решении, я повторяю, это исключительно проблема структурная: Фейсбуку проще на всех покласть и сделать своими силами под себя. Ну и у нас никогда не было своего JIT, а это очень ресурсоёмкий проект — так что почему мы не сделали JIT — ну потому что очевидно это очень непростая задача, это человеко-годы, это может позволить себе компания размером в тысячу человек и больше. Насчёт платы и благодарности: ну мы-то отдаём до чёрта всего, см. http://github.com/badoo. Но open source проекты неэффективны c точки зрения бизнеса. Если Вы вдруг не знаете, мы пушили в апстрим php-fpm, это был просто сторонний патч когда-то, Андрея Нигматулина, нашего программиста. Мы запилили проект по исправлению косяка со вложенными локами в MySQL, его года три назад делал лид Тарантула Костя Осипов, так на исправление ушла пара недель, а на проталкиваение в апстрим ораклу, перконе и марии — несколько лет. Так что мы готовы тратить время, не вопрос, но мы не готовы убиваться, потому что мы — маленькие.
а я не говорил, что "TCP мог бы вообще когда-нибудь работать быстрее, чем unix socket". я говорил, что теоретически могло быть наоборот на старых ядрах, unix сокеты могли быть быстрее tcp, ну и я тоже что-то когда-то слышал про скрижали, которые это говорили, но вроде давно уже без разницы. твой эксперимент это лишь подтверждает. выпей порто :)
Потому что "сделать для себя" и "продвинуть в апстрим" — примерно равные по ресурсоёмкости задачи. Грубо, если один год девелопили, другой год будете двигать в апстрим. Мы это на своей шкуре несколько раз почувствовали и для не таких больших проектов. А почему не сделали сами — мы всё-таки слишком маленькие, чтобы такими задачами системно заниматься.
о, это очень старая история, но она от семёрки вообще не зависит
в PHP принята абсолютно не побоюсь этого слова гениальная stateless модель fcgi, с полным очищением памяти после завершения выполнения запроса, практически гарантирующая отсутствие "распухание" по памяти и прочую радость в продакшене
ну и отдельно скажу что для share nothing архитектур состояние в приложении — зло
Ну судя по отзывам коллег, которые это мероприятие посетили недавно (ко мне приходили с вопросами, а не работал ли этот чел у нас в Badoo — уж больно похожие озвучивает идеи) — думаю, может быть интересным. Все идеи так или иначе общие для индустрии разработки массовых сервисов, есть конечно особняком стоящие проекты типа поиска или реал-тайм веба, но в целом принципы и подходы примерно одинаковы.
А причем тут модель? В модели нет ничего о соединении, соединение — это физический уровень. А модель описывает логический уровень разделения ответственности между паблишерами и подписчиками, и не более. Можете делать длинное соединение и гет, можете длинное и пуш, в случае сильно распределенных сред можете получать UDP-уведомления, можете короткое и гет, вариантов море. А модель вообще ни при чём. Вы не правы, потому что пытаетесь притянуть очереди (то есть архитектурный концепт) к проблеме на физическом уровне (рестарт без потери открытых соединений).
У нас есть стандарт для внутренних апи — это google protobuf, документация генерится автоматом. Но это не покрывает 100% логики приложения, естественно. Лапши из вызовов нет. Автоматическое тестирование авторизации не нужно (перед деплоем selenium ну и в проде меряем просто число авторизаций). Резервное копирование делаем через xtrabackup вроде (надо DBA плдключать). Вопросы про облако я не очень понял, если можно — сформулируйте его поконкретнее, пожалуйста.
Это хороший вопрос, но я не смогу на него ответить в рамках комментария — слишком много всего надо уточнять. Если Вы окажетесь на Хайлоаде — найдите меня, обсудим.
очень много вопросов, кратко:
— «переписать с нуля» — это нереально, к тому же мы проектировали всё после опыта мамбы, где мы наступили на кучу граблей, в результате сделали всё достаточно грамотно и у нас ядреные компоненты не меняются уже 8 лет, при росте с 0 до более 200 миллионов юзеров
— писателей нет
— относимся хорошо, стараемся не отставать и мигрировать, но не чаще n раз в год (для базы — 1 раз в пару-тройку лет, для php и nginx — может и 5 раз в год, статистики под рукой нет).
— про тест уже отвечал — см. ссылки
— нагрузочное тестирование отвечал, считаю, что это миф, какие-то базовые вещи можно проверить в кластере на коленке (натравить бота в кучу потоков), остальное лучше смотреть в продакшене
Почти везде транспорт скрайб с продакшн-нод, а дальше свои обработчики — где-то в базу со своей системой анализа поверх, где-то в splunk, а аналитика, пользовательские действия в hadoop. Там несколько миллиардов событий в сутки, грепать — это будет сильно :)
Мне кажетчя, что у Вас в кучу смешано несколько вещей, и я не смогу ответить сразу на всё. Фейсбучный патч ядра для кеша на SSD вообще нужен для операций записи, это не про статику. Со статикой надо определиться, какая у неё природа, это UGC или нет? Ну и влезает она в память или нет? Если влезает — там нет дисковой нагрузки и вопрос просто снят. Если не влезает — либо сделать так, чтобы влезало, либо делать слой кешей с проксированием, всё остальное вокруг дисков без кеш-проксей не будет толком работать в промысленных масштабах.
в PHP принята абсолютно не побоюсь этого слова гениальная stateless модель fcgi, с полным очищением памяти после завершения выполнения запроса, практически гарантирующая отсутствие "распухание" по памяти и прочую радость в продакшене
ну и отдельно скажу что для share nothing архитектур состояние в приложении — зло
— «переписать с нуля» — это нереально, к тому же мы проектировали всё после опыта мамбы, где мы наступили на кучу граблей, в результате сделали всё достаточно грамотно и у нас ядреные компоненты не меняются уже 8 лет, при росте с 0 до более 200 миллионов юзеров
— писателей нет
— относимся хорошо, стараемся не отставать и мигрировать, но не чаще n раз в год (для базы — 1 раз в пару-тройку лет, для php и nginx — может и 5 раз в год, статистики под рукой нет).
— про тест уже отвечал — см. ссылки
— нагрузочное тестирование отвечал, считаю, что это миф, какие-то базовые вещи можно проверить в кластере на коленке (натравить бота в кучу потоков), остальное лучше смотреть в продакшене