Как нам обустроить козла Фрэнка
В верхнее тематическое оглавление
Тематическое оглавление (Блогосфера)
Как известно, недавно козел Фрэнк опять обожрался проводами, из-за чего у ЖЖ был кровавый понос, а обитатели бложиков начали активно обсуждать, не сдохнет ли наконец это тупое животное.
Для объяснения причины происходящего специально выделенные люди вместе с примкнувшими к ним поведшимися блоггерами стали пользоваться аналогиями, что компьютерные кластеры - это города, блоги - это их жители, и тут вдруг, неведомо откуда (ВНЕЗАПНО) начались проблемы. Откуда - неизвестно, наверно, кровавая гэбня песок в буксу подсыпала, но они стараются все быстро исправить для нашей пользы и удовольствия. Нет, некоторые моменты в объяснении очень даже правдоподобны: в городе все рушится, а администрация занимается перекраской заборов.
Точно описать происходящее для меня, конечно, невозможно хотя бы потому, что СУП о происходящем и о своих действиях молчит, как пленный глухонемой партизан Герасим под пытками. Что с ним не делают, а он в ответ только одно муму повторяет. Однако изложить что-то менее относящееся к делу, как пресловутые города, все равно не удастся.
Итак, как известно, проблемы в IT можно решать программно, аппаратно и организационно. В том, что касается Интернет-проектов, можно два первых пункта разделить на проблемы на стороне клиента и на стороне сервера. Итак:
1. Проблемы ЖЖ со стороны клиента, то есть нас
С точки зрения того кода, который интерпретируется браузером компьютера, за которым вы это читаете, и вываливается на экран, ЖЖ предоставляет своим пользователям крайне урезанный функционал. Или, говоря проще, сайт, который представляет собой страница пользователя ЖЖ, удивительно убог. Это - текст с урезанными тегами форматирования с вставкой изображений и некоторых внешних объектов типа флэшь-роликов. Никакой интерактивности и адаптивности в результате нет и в помине. Возможности вставки ява-скриптов, не говоря о чем-то более интересном, отсутствуют. Даже при чтении голого текста нет таких элементарных возможностей, как изменение размера шрифта. И уж тем более нет возможности создать и сохранить несколько профилей с настройками, чтобы выбирать режим работы. В результате и при чтении ЖЖ с экрана телефона, и при работе со стационарного компьютера с большим монитором предлагается одна и та же разметка. А с появлением «читалок» с выходом в Интернет жизненно необходимо иметь по крайней мере три варианта настроек: под большие экраны, под крохотные экраны смартфонов и под черно-белые экраны средних размеров.
Из-за простоты и нефункциональности, казалось бы, и код страниц должен быть простым. А теперь, уважаемые читатели, сделайте пожалуйста, следующее. Щелкните правой кнопкой мышки в то, что Вы сейчас читаете, и выберите команду типа «посмотреть код страницы».
Ну как, впечатлились? Если перекинуть код страницы поста на страничку в Word, то там будет уже не одна страница, а сотня. А ведь все эти бесчисленные ссылки на библиотеки стилей и ява-скрипты с выполнением чего-то, лежащего где-то - лишь вызовы программ, лежащих на каких-то других ресурсах.
Когда бывают подобные безумные программы с непонятной логикой? Только тогда, когда над программным кодом последовательно работает куча кодеров (чаще всего - типа студентов 3 курса), которые что-то там приделывают, каждый свое, к уже работающей программе, в которую они даже не врубаются. В результате получается клубок с запутанной логикой, избыточными проверками и переходами, в значительном количестве - мертвыми. Начали делать, не понравилось, отключили, но «хвосты» в коде остались.
При этом подавляющая часть программного кода и не относится к показу контента автора поста и его скромным потребностям типа зафрендить/расфрендить. Это - многочисленные дублирующие друг друга системы сбора статистики, а также показа всяких… эээ… совершенно необходимой для всех нас рекламы СУПа.
Поэтому первый способ улучшения работы ЖЖ - это перепрограммирование клиентской части движка, но не прикручивание очередной хренотени к уже имеющимся, а наоборот, выкидывание всего умершего и малонужного. Тогда и код будет короче, и трафик меньше, и требования к железу снизится, и устойчивость возрастет.
2. Проблемы со стороны сервера
Наиболее простой способ увеличения надежности работы системы, работающей в режиме реального времени - это дублирование и резервирование мощностей на случай сбоев. Грубо говоря, если у вас время от времени отказывает аппарат ИВЛ и вы не хотите убивать пациентов - поставьте два аппарата рядом и при сбое переключайтесь на резервный. Если и два иногда сбоят вместе - поставьте третий.
ЖЖ в силу своей концепции хранения архивов и постоянного добавления требует все возрастающих аппаратных возможностей. Никаких неразрешимых проблем нет - возможности вычислительной техники развиваются очень быстро. Еще 10 лет назад винчестер в полгигабайта считался большим.
Конечно, оснащение техникой требует некоторых дополнительных затрат, но…
Сейчас у СУПа, насколько они дают объяснения, для обслуживания ЖЖ порядка 15 кластеров, то есть систем из нескольких связанных друг с другом серверов. Стоимость сервера порядка месячной зарплаты креативного бухгалтера… (уточнение читателя - при необходимой мощности - менее годовой зарплаты ). «Ну, ты понял»…
Есть также некоторые дефекты принятой изначально архитектуры, связанные с выбором языков программирования. Если чуть-чуть огрубить, то языки программирования (точнее, их реализации) делятся на интерпретируемые и компилируемые. В интерпретирующем варианте команды выполняются по одной. В компилирующем варианте вначале программа на языке высокого уровня целиком компилируется, то есть переводится в программу на машинном коде (в командах процессора), а уже потом запускается на выполнение.
В интерпретирующих системах проще писать. Там очень удобно отлаживать программу - видно, в какой команде ошибка. Можно отлаживать даже недописанные программы. Интерпретатор проще написать, чем компилятор (хотя хорошие системы сейчас поддерживают оба варианта - интерпретация для отладки и компиляция для счета). Языки программирования под Интернет изначально разрабатывались как только интерпретирующие, так как еще недавно скорость соединения по каналам Интернет была много меньше, чем вычислительные возможности компьютера, так что на скорость обработки браузером кода страницы можно было не обращать внимания. Соответственно для небольших проектов не только клиентская, но и серверная часть писалась на языках типа Perl, которые работают БЕЗУМНО МЕДЛЕННО.
По просачивающимся сообщениям программисты ЖЖ часть исходного кода переписывают на С++. Однако если прикинуть сложность и объем работ и их стоимость, то, как мне кажется, намного проще и дешевле усиливать аппаратную часть, докупая сервера, чем ковыряться в исходном ядре. Но вот что точно делать не надо - это продолжать навешивать никому, кроме СУП-дизайнеров, не нужных свистелок и перделок.
Но самое сложная и самая провальная часть проекта - это организационная, о чем я напишу позже, если этот аккаунт еще не засуспендят.