Я никогда не стремился что-то осуждать. Поэтому в голове не откладываются неприятные моменты, оставляя место лишь best practice. Которое потом применяя находишь вновь и вновь причины делать именно так.
Задача: вывести example.com/best-feature/ в best-feature.example.com
Правильное решение задачи: использование мультисайтовости (множества доменов на одной копии ядра). Будет на доп. домене промо-страница с фоточками, но все равно так как основная редакция «Бизнес» то и доп. лицензию надо докупать «Бизнес» — 17000 рублей. Дальше создаем новый сайт, привязываем к папке /best-feature/ и все готово.
Как решено на практике:
<?php $_SERVER["DOCUMENT_ROOT"] = '/valid/path/of/example.com/';
require($_SERVER["DOCUMENT_ROOT"]."/bitrix/modules/main/include/prolog_before.php");
// it worked!
+ конфиг nginx, у которого root стоит /valid/path/of/example.com/best-feature
Проблема не серьезная, просто неприятная с организационной и правовой точки зрения.
Другая задача: организовать показ баннеров со счетчиком
Проблема: битрикс открывает сессию для каждого гостя со всеми вытекающими последствиями
Решение: считать не битриксом
Задача: корректное обновление html-/композитного кеша
Проблема: кеш-тайм, установленный, пусть даже для стандартного компонента — работает так, как задан кеш-тайм. То есть, полугодовая новость, у которой тоже время жизни кеша 3600 секунд (например) — будет обновляться при входе в нее. Работает эта фишка посредством отдачи html-кеша + javascript-запрос с ?bxrand={timestamp}. Далее какими-то дебрями включается работа Cache Dependies, при котором происходит детектирование наличия измененных данных, чтобы кеш обновился по факту изменения данных ранее тайм-аута в 3600 секунд. И здесь начинается самое интересное — на 2-3 миллиона новостей, с разным cache time от 100 до 3600 секунд сколько уйдет ресурсов на проверку наличия изменений (я не говорю об истечении ttl даже). Отвечу сам — с онлайном в 10к юзеров будет идти порядка 20-30 запросов на наличие изменений.
Решение: заблокировать к черту запросы с ?bxrand= и научить «срочные» компоненты, изменения в которых критично отобразить сразу — чистить за собой по изменению. cron_events раз в 1/5/30/60 минут могут предложить одни из более глубоко копавшихся в битриксе. Разумеется добавив свой скрипт апдейт_чекера. Увы, работает эта тема нестабильно. С одной стороны разобравшись с вылетом CEvent:Util() not found по запуску в cli режиме получаем потенциальную возможность работы более 1/5… а дальше не важно скольких минут. Запуститься дубликатом, сожрать все процессы php5-fpm (достаточно одного в каждом форке, чтобы они не завершались и висели в ожидании пришествия). Или обратная ситуация — когда его излишняя работа вызовет массовое перегенерирование того, что истекло по обычному ttl.
Задача: быстро принять и обработать более 100 запросов в секунду с гарантированным 1-3 запросом в базу (чтение, чтение, запись).
Проблема: банальнейшая — при общей нагрузке черта с два любой типовой компонент битрикса справится с этим.
Решение: а нужен ли битрикс? Пусть наш скрипт работает без него. Читать данные мы будем один раз, сохранив далее их в memcache, проверим (потратим процессорное время) и при успешной проверке запишем все в… монгу. И когда момент приема запросов пройдет (длится фиксированный период времени) — спокойно вторым скриптом все разберем и разложим по полочкам в битриксе. Да, можно и скрптом на основе битрикса юзать мемкеш, но эта архитектура мне кажется чем-то убийственным. Highload-инфоблоки не предлагать. Как иначе сделать это на битриксе я не знаю.
Все постепенно приходит к тому, чтобы использовать битрикс в режиме асинхронного хранилища контента, занимаясь кешированием и выборкой самостоятельно (своими средствами). Когда настанет момент, что есть лучшее хранилище самого разного контента и его выборки лучше чем битрикс (с точки зрения контент-менеджера прежде всего). Тогда мы сможем от него отказаться. А пока платим за две бизнес-лицензии, используя лишь админку и api.
Зачем что? Свои компоненты? Они нужны тогда, когда требуется функционал совершенно специфический. Например, панель работы дежурного/диджея для отображения текущего трека (кратко: играет лайв микс из Traktor, метаданные треков в силу миксования между панелями могут высылаться любые из активных — поэтому эта панель должна отображать все из активного). Или другой пример, раздел полуновостей музыки. Они могут интегрироваться с новостями, всплывающими виджетами, содержаться во множестве (артисты, альбомы, треки — как угодно могут связываться друг с другом) — стандартным компонентом это можно реализовать, но с большими доработками. А свой компонент суть — контроллер, который подготавливает данные из базы (модели), шаблон компонента — уже представление для страницы раздела, попапа или какого-то виджета. Да даже для банальной задачи страницы со списком новостей и детальная страница новости — свой компонент. Почему? Потому что в этой новости кроме самой новости могут быть различные виджеты, попап-галереи, аудиотреки и тетрис. И при этом совершенно не нужен функционал хлебной дорожки, постраничной навигации, эрмитаж тем более, фильтров и остального прочего. Эта как раз та ситуация, при которой типовая задача требует в себе бОльшей гибкости (ага, шаблон представления этого компонента работает в режиме десктопной версии, версии для WebView, версии json) при этом, даже само наличие доп. возможностей может сделать выстрел в ногу.
Так что свои компоненты — единственный правильный выбор при разработке любых нетиповых хотелок заказчика/руководства именно потому, что код максимально минифицирован и в нем нет того, что не работает. Так или иначе — доработка стандартных компонентов под хотелку — максимальная скорость (не всегда) для выполнения задачи. И превращается после адекватного периода использования и доработок это все в ад, который надо полностью стирать и переписывать с нуля. И хорошо, если этот ад независим от остального — так нет же! Сколько фриланс задач я не смотрел — всегда в каком-то шаблоне представления компонента идет прямой вызов апи и по результату выдачи апи в foreach'е вызывается еще какой-то из любимых стандартных (+ доработанных) компонентов, далее это все загружается по ajax (да, jQuery Ajax, а не чем-то с HistoryAPI) и надо чтобы корректно работала кнопка «назад» в браузере. И ссылка была постоянной на результат этого бреда. Ну и композитный кеш там внедрите, а то тормозит как-то…
Наверное, ваш комментарий это то, что было сложно сказать и признать самому себе. Что сам профи битрикса и что битрикс все же ужас, а не ты ущерб — не умеешь его готовить.
Единственное, что может подкрепить этот вывод — использование в текущем высоконагруженном битрикс проекте из него только API. Все остальное — самостоятельные компоненты, тщательно поддерживаемые кешами (можно насчитать их как минимум трех уровней — статики на поддомене, хтмл-кеш, мемкеш из общего). И все это надо всегда контролировать и держать на пульсе, ибо вылет одной системы в нагрузку убивает все остальное. И да, я умею готовить битрикс, раз все это все еще работает.
Пока совершенно непонятно почему этого человека называют хакером. Человек рассылал спам и использовал инструменты анализа (по статье). Однако, нет никаких упоминаний про взлом, проникновение, кражу, использование чего-то чужого и другого, что можно было бы квалифицировать как хакерство.
Вероятно, речь идет о какой-то системе сохранения взлетной площадки? Очевидно, она тогда должна быть на борту, но почему-то из головы не выходит мысль о каком-то подрыве основной ракеты с земли второй ракетой) Наверное то еще зрелище -)
Не взирая ни на какие предположения о причинах почему-то переживаю такие видео так, как будто сам принимал участие в создании этого аппарата. На душе очень грустно, печально и даже после падения хочется продолжать считать секунды полета, надеяться получить хоть какую-то телеметрию. Эхх…
(с последними изменениями поясов у нас сейчас 11? я запутался с нашим правительством)
Оставшиеся 13 часов: террористы, Америка (шпионы внутри страны), Тихий океан. И ведь как возразить? Это часовая география обвинений американцев: русские, террористы, шпионы)
Бог с ней с русификацией. Доставляют именно «рабочие часы». То есть наши хакеры трудятся как любой полноправный гражданин 8 часов в дневное время суток с перерывом на обед и перекурами?) Самое забавное на этом фоне — фильмы, где хакеры всегда представляются в работе ночью)
Есть какой-то сервис, в котором можно хотя бы картинку Земли получать в каком-то онлайн режиме? Пусть с задержкой, пусть с обновлением хоть 1 картинка в 5 минут, но онлайн? Смотрел бы часто (что уж говорить про онлайн Землю, если даже нравится на птичью кормушку заглядывать).
Привет коллеги по радио -). Вы молодцы! Но в комментариях к подобной статье просто не могу не упомянуть про Liquidsoap. Очень мощная штука. С ее помощью можно создать архитектуру сложного радио (переходы, рекламные моменты с dtmf-метками, войсоверы, джинглы, динамичное управление плейлистами, таймингом, битрейтом, работой с метаданными, гибкое сохранение истории, мониторинг уровня сигнала в децибелах или тишины с последующим вызовом внешних скриптов-оповещалок, идеальное кодирование на лету в кучу разных форматов и битрейтов, кучи разных инпутов, выходов лайвов, автопроговаривания). Описанное — лишь малый список того, что есть «при первом взгляде». Определенную часть из описанного мы используем, с радостью поделюсь опытом (а опыт в 133 потоков разных радио разных форматов и битрейтов + icecast, стабильно держащий avg 4 Гб/с) поднятия и настройки этого чуда). Тема феерично интересная, завораживает и заставляет гордиться)
Хорошее уточнение. Однако, потенциально скомпрометированная отправляющая сторона все таки не повод безответственно относиться к приему. Это если рассматривать с точки зрения передачи данных. С точки зрения хранения, очевидно, что лучше использовать свое (при этом грамотно отнесясь к безопасности к взлому). Это избавит от потенциальной возможности читать важные данные самими службами яндекса, мейла, гугла, например. Также, нельзя не подумать о внутреннем документообороте. Наверняка в своем постоянстве где-то используется: — Вероника, отправь мне базу должников за первый квартал в почту! — Не вопрос, лови! (при этом два соседних ПК передали информацию через сторонний почтовый сервер где-то далеко — в другом городе, стране или континенте).
Печальная. Но не на столько, чтобы расстроиться. Как по мне — ничего удивительного не произошло. Все ожидаемо. Было бы наоборот радостно, если бы ваша статистика была бы приближенной к реальности дел. Тогда за 50% собственных серверов структур я бы удивился и порадовался. Причем порадовался стремлению к собственным серверам, но никак не потенциально возросшей безопасности. С одного конца — приватность данных относительно своего сервера и стороннего понятна, с другого конца — устойчивость ко взлому всяко выше у яндекса, мейла, гугла, чем у старшего лейтенанта Почтовика Ивана Сергеевича или отдела безопасности из двух человек и собаки где-то в далеком малоразвитом регионе.
Взял для примера МВД Волгоградской области. Домен 34.mvd.ru. По DNS MX Check выдаются mx.yandex.ru, чтд.
По моему мнению, вариант использовать почту для доменов — очень высок. Использование своих собственных почтовых серверов будет только тогда, когда об этом специально попросят и средства на поддержку веделят. И самый простой способ убрать публичные окончания mail.ru, yandex.ru — использовать почту для домена. Делов-то, одну-две строчки скопировать-вставить.
Задача: вывести example.com/best-feature/ в best-feature.example.com
Правильное решение задачи: использование мультисайтовости (множества доменов на одной копии ядра). Будет на доп. домене промо-страница с фоточками, но все равно так как основная редакция «Бизнес» то и доп. лицензию надо докупать «Бизнес» — 17000 рублей. Дальше создаем новый сайт, привязываем к папке /best-feature/ и все готово.
Как решено на практике:
+ конфиг nginx, у которого root стоит /valid/path/of/example.com/best-feature
Проблема не серьезная, просто неприятная с организационной и правовой точки зрения.
Другая задача: организовать показ баннеров со счетчиком
Проблема: битрикс открывает сессию для каждого гостя со всеми вытекающими последствиями
Решение: считать не битриксом
Задача: корректное обновление html-/композитного кеша
Проблема: кеш-тайм, установленный, пусть даже для стандартного компонента — работает так, как задан кеш-тайм. То есть, полугодовая новость, у которой тоже время жизни кеша 3600 секунд (например) — будет обновляться при входе в нее. Работает эта фишка посредством отдачи html-кеша + javascript-запрос с ?bxrand={timestamp}. Далее какими-то дебрями включается работа Cache Dependies, при котором происходит детектирование наличия измененных данных, чтобы кеш обновился по факту изменения данных ранее тайм-аута в 3600 секунд. И здесь начинается самое интересное — на 2-3 миллиона новостей, с разным cache time от 100 до 3600 секунд сколько уйдет ресурсов на проверку наличия изменений (я не говорю об истечении ttl даже). Отвечу сам — с онлайном в 10к юзеров будет идти порядка 20-30 запросов на наличие изменений.
Решение: заблокировать к черту запросы с ?bxrand= и научить «срочные» компоненты, изменения в которых критично отобразить сразу — чистить за собой по изменению. cron_events раз в 1/5/30/60 минут могут предложить одни из более глубоко копавшихся в битриксе. Разумеется добавив свой скрипт апдейт_чекера. Увы, работает эта тема нестабильно. С одной стороны разобравшись с вылетом CEvent:Util() not found по запуску в cli режиме получаем потенциальную возможность работы более 1/5… а дальше не важно скольких минут. Запуститься дубликатом, сожрать все процессы php5-fpm (достаточно одного в каждом форке, чтобы они не завершались и висели в ожидании пришествия). Или обратная ситуация — когда его излишняя работа вызовет массовое перегенерирование того, что истекло по обычному ttl.
Задача: быстро принять и обработать более 100 запросов в секунду с гарантированным 1-3 запросом в базу (чтение, чтение, запись).
Проблема: банальнейшая — при общей нагрузке черта с два любой типовой компонент битрикса справится с этим.
Решение: а нужен ли битрикс? Пусть наш скрипт работает без него. Читать данные мы будем один раз, сохранив далее их в memcache, проверим (потратим процессорное время) и при успешной проверке запишем все в… монгу. И когда момент приема запросов пройдет (длится фиксированный период времени) — спокойно вторым скриптом все разберем и разложим по полочкам в битриксе. Да, можно и скрптом на основе битрикса юзать мемкеш, но эта архитектура мне кажется чем-то убийственным. Highload-инфоблоки не предлагать. Как иначе сделать это на битриксе я не знаю.
Все постепенно приходит к тому, чтобы использовать битрикс в режиме асинхронного хранилища контента, занимаясь кешированием и выборкой самостоятельно (своими средствами). Когда настанет момент, что есть лучшее хранилище самого разного контента и его выборки лучше чем битрикс (с точки зрения контент-менеджера прежде всего). Тогда мы сможем от него отказаться. А пока платим за две бизнес-лицензии, используя лишь админку и api.
Так что свои компоненты — единственный правильный выбор при разработке любых нетиповых хотелок заказчика/руководства именно потому, что код максимально минифицирован и в нем нет того, что не работает. Так или иначе — доработка стандартных компонентов под хотелку — максимальная скорость (не всегда) для выполнения задачи. И превращается после адекватного периода использования и доработок это все в ад, который надо полностью стирать и переписывать с нуля. И хорошо, если этот ад независим от остального — так нет же! Сколько фриланс задач я не смотрел — всегда в каком-то шаблоне представления компонента идет прямой вызов апи и по результату выдачи апи в foreach'е вызывается еще какой-то из любимых стандартных (+ доработанных) компонентов, далее это все загружается по ajax (да, jQuery Ajax, а не чем-то с HistoryAPI) и надо чтобы корректно работала кнопка «назад» в браузере. И ссылка была постоянной на результат этого бреда. Ну и композитный кеш там внедрите, а то тормозит как-то…
Единственное, что может подкрепить этот вывод — использование в текущем высоконагруженном битрикс проекте из него только API. Все остальное — самостоятельные компоненты, тщательно поддерживаемые кешами (можно насчитать их как минимум трех уровней — статики на поддомене, хтмл-кеш, мемкеш из общего). И все это надо всегда контролировать и держать на пульсе, ибо вылет одной системы в нагрузку убивает все остальное. И да, я умею готовить битрикс, раз все это все еще работает.
+ подчеркнуть названия пунктиром?
Оставшиеся 13 часов: террористы, Америка (шпионы внутри страны), Тихий океан. И ведь как возразить? Это часовая география обвинений американцев: русские, террористы, шпионы)
UPD: извиняюсь, нашел
По моему мнению, вариант использовать почту для доменов — очень высок. Использование своих собственных почтовых серверов будет только тогда, когда об этом специально попросят
и средства на поддержку веделят. И самый простой способ убрать публичные окончания mail.ru, yandex.ru — использовать почту для домена. Делов-то, одну-две строчки скопировать-вставить.