Данная идея не является той же что здесь уже есть!
Предлагаю реализовать поддержку данного сервиса внутри БУС (+ Б24). Вопрос оптимизации поиска стоит довольно остро и хотелось бы иметь возможность реально ускорить в несколько раз систему. Плюс самое интересное - это подойдет не только для поиска, но и для вывода например каких-то других данных.
Среди крупных сайтов, использующих Elasticsearch, отмечаются Wikimedia, StumbleUpon, Quora, Foursquare, SoundCloud, GitHub, Netflix. Amazon, IBM, Qbox и компания Elastic предлагают подписчикам Elasticsearch в качестве управляемого сервиса
1. После добавления документа в индекс поиск по этому документу доступен уже менее чем через 1 секунду. 2. Структура хранения данных в Еlasticsearch произвольная, что позволяет хранить документы в удобном, подготовленном виде. 3. Мы используем Еlasticsearch еще и для хранения серверных логов. А выводим их в Kibana. 4. Ну и конечно, Еlasticsearch очень быстр! Запрос для одного раздела обрабатывается за 0,03 секунды.
На странице "Проекты" (Задачи и Проекты) в список проектов попадают все рабочие группы, не зависимо от того, включен ли функционал задач в группе. Из-за этого страница может долго загружаться, если в группе много участников, т.к. на каждого участника в базу отправляется запрос.
В нашем случае на портале имеется группа "Общение" на 14500+ человек (для связи интранет/экстранет пользователей), из-за которой страница "Проекты" грузится в среднем 130 секунд:
Идея: предлагаю фильтровать проекты в зависимости от включенного функционала задач в группах.
Здравствуйте! Сайты24 получают низкие оценки по поисковой оптимизации в части скорости загрузки. Сайт на мобильном телефоне грузить около минуты. Поисковики его будут понижать в рейтинге. Предлагаю: 1. Включить компрессию текстовых ответов: gzip, deflate, brotli 2. Оптимизировать CSS: Более 1.5 МБ стилей - загружаются очень долго 3. Убрать не используемые для отображения первого экрана лендинга стили и скрипты в подвал. шапке они блокируют загрузку. 4. Добавить в редактор изображений функции по оптимизации изображений: сжатие, переименование, изменение формата на JPEG 2000, JPEG XR и WebP. 5. Сделать режим Lazyloading для изображений 6. Включить использование локального кэша браузера и првильно управлять им
На сегодня форма заказа в админке выглядит очень тяжело с большим объемом информации - не всем нужной с недостаточной возможностью кастомизации. По опыту из другой CMS наши менеджеры видят информацию по заказу почти из одного окна без скроллинга - это позволяет быстро и безошибочно обработать заказ, параллельно набирая по телефону клиента. Пока идут гудки - менеджер уже часто владеет всей необходимой информацией с минимум затрат времени и нагрузки на его мозг, что бережет ему силы и внимательность. Ниже расписаны предложения по оптимизации. https://www.screencast.com/t/9LlPUoRt 1 - Кнопку изменить можно добавить во второй блок, который можно зафиксировать, сделав плавающим. 2 - Данная информация не всем нужно, ее можно скрывать, сворачивать или сделать весь данный блок в 2 столбика. 3 - Пример технической информации модуля доставки. Данные, не вводились покупателем, а получены извне по API службы доставки и нужны только для интеграции с модулем доставки в системе учета 1С Бухгалтерия. Менеджеру по продажам они вообще не полезны. 4 - Введенная покупателем информация в 2-3 полях попала в 1 строку, для которых не сработал тег переноса строки и все слилось. Дать базовые возможности форматирования. 5 - Информация о свойствах товара дублируется и удлиняет опять форму заказа.. 6 - Не все строки нужны. Самая необходимая информация была выведена уже в самый первый блок заказа, а тут много того ,что не все нужно. Опционально этот блок можно сворачивать или выводить в 2 столбца. Конечно возможны и другие альтернативные решения сделать форму более компактной и легкой к восприятию, например, не всем нравятся большие табуляции между строками.
Канбан для бизнес процессов был бы отличным решением. Если предприятие ставит цель автоматизировать какой то процесс, скорее всего у них этих процессов очень много (по крайней мере в трех организациях где я внедрял автоматизацию, картина выглядела именно таким образом). А когда много бизнес процессов, необходимо понимать где застревают больше всего процессов, т.е. так называемые "узкие горлышки", чтобы данные горлышки потом оптимизировать. Ведь одна из главных целей автоматизации это и есть оптимизация временных издержек.
Бизнес-процессы - это средство автоматизации чего-то. Сами по себе они не существуют в нашей жизни.У вас есть поток лидов или сделок, к примеру, и переход между стадиями как раз можно регулировать автоматикой.
Если в построении URL используется #SECTION_CODE_PATH#, то компонент bitrix:catalog.section.list начинает генерировать ОЧЕНЬ большое количество запросов.
например, при выводе списка из 40 разделов, генерируется 176 запросов.
Если разделов много, то может быть и 1000 запросов.
Необходимо сделать кеширование URL к разделу (по примеру фасетного индекса для умного фильтра) и брать закешированные данные.
Наличие любого параметра (?blablabla) у ссылки на подключаемый файл заставляет любое клиентское приложение (браузер, прокси-сервер, мобильное приложение и т.д.) обязательно обратиться за файлом на сервер. Это RFC. Сервер, в лучшем случае ответит "304 Not Modified" (но при этом всё равно дёрнет файл с диска/памяти, чтобы проверить) или же полноценный 200 с полной передачей файла. Ответ сервера в некоторых кешах сохранится, в некоторых (н-р, AppCache) нет.
Соответственно, время модификации, хеш от него или любой другой праметр для cache busting должен быть в имени или пути файла (...template_283cd0022d3edc763e34cc00a91e7e1b/template_283cd0022d3edc763e34cc00a91e7e1b-142712022549372.js), а не в параметре (...template_283cd0022d3edc763e34cc00a91e7e1b/template_283cd0022d3edc763e34cc00a91e7e1b.js?142712022549372).
Проверить очень просто: при повторном открытии страницы сайта на сервер должен идти только 1 запрос - на саму страницу, а все остальные файлы должны браться из кеша браузера.
UPDATE 2015-04-01
Теоретическое обоснование и рекомендации от известных разработчиков:
Never access cached files by using traditional GET parameters (like other-cached-page.html?parameterName=value). This will make the browser bypass the cache and attempt to get it from network.
Стандартная оптимизация хороша, но есть идеи как можно сделать еще лучше, для этого необходимо событие (после объединения CSS в один файл) в этом файле: /bitrix/modules/main/lib/page/asset.php После 2001 строки:
foreach (GetModuleEvents("iblock", "OnAfterCssUnion", true) as $arEvent)
ExecuteModuleEventEx($arEvent, array(&$tmpStr));
Моя идея оптимизации CSS заключается в минификации CSS и замене маленьких картинок на base64. Но имея такое событие другие разработчики могли бы реализовать и свои идеи.
Посмотрите Канбан в CRM и Роботов там же.