При потреблении пусть даже 3х кубов в месяц, этими потерями можно принебречь.
Даже без учета того что часть отводимого Вы приносите с работы\из магазина.
Уж коли пошла такая вечеринка — обращусь сюда.
Я сам бОльшую часть своего рабочего времени занимаюсь оптимизацией производительности баз 1С, не смотря на то что сертификата Эксперт у меня нет, потому что руки не доходят.
Что хотелось бы и не понятно почему в 1С разработчики это упорно игнорируют, хотя те же преподаватели на курсах говорят что было бы здорово если бы это было:
1) Конструктор Индексов объектов баз данных.
Поясню — не я проектирую справочники\ документы с 20-80 реквизитами и не я автор РЛС на несколько реквизитов в одной таблице. Эту проблему можно было бы достаточно малой кровью, но сейчас 3 пути решения, которые озвучиваются на том же обучении:
N1 Ничего не делать.
N2 Реализовать через вспомогательные объекты (как правило Регистры сведений), но делать 10-15 регистров сведений к тому же справочнику номенклатуры не очень здорово + требуется большая переработка существующего функционала. Да это работает, но иногда чудовищные затраты по времени.
N3 Нарушить лицензионное соглашение и добавить индексы на уровне БД и поосле реструктуризации следить за ними, потому что платформа скидывает индексы в по дефолту. Так себе решение, мало кто может это позволить, ибо решение N2 дорого сейчас, а решение N3 дорого всегда.
А бОльший пул проблем можно часто решить просто добавлением 1-2 соответствующих индексов.
2) Нет человеческого инструмента анализа логов.
Объясню: ЦУП — долго, не качественно. На том же обучении — из 5ти попыток только одна смогла проанализировать логи. Для софта за 100 000 с намеком на энтерпрайз по моему плохо.
— Скрипты на perl — неплохое решение, из рекомендуемого gitBash — чтение идет в 1 поток и скорость неудовлетворительна. У одного заказчика установка любого софта запрещена, и я еле еле вынес логи на флешке для анализа, тот же GitBash мне не поставили.
— Самописки. Каждый ваяет как может. Я написал нормализатор на Python и загружаю в SQL.
— Кто то ипользует ELK.
Но есть ситуации когда заказчик ультимативно требует только инструменты Вендора.
Не понятно почему нельзя выпустить инструмент и продавать его за деньги, если он будет лишен недостатков ЦУП — спрос будет, я сам куплю его на свои в первый же день выхода. Тем более для держателей формата тех журнала и тех кто знает основные проблемы это задача не несподъемная.
Просто по своему опыту — 30 гб логов ТЖ нормализуются в CSV на достаточно посредственной машине с HDD диском за 5-15 минут, все зависит от загруженности диска другими задачами.
Тот же Сергей Старых aka TormozIT сделал очень неплохой и достаточно быстрый анализатор логов ТЖ на 1С в инструментах разработчика, но том из — за того что данные после разбора хранятся на форме — не получится анализировать что то большое.
Большое спасибо за внимание.
Даже без учета того что часть отводимого Вы приносите с работы\из магазина.
Я сам бОльшую часть своего рабочего времени занимаюсь оптимизацией производительности баз 1С, не смотря на то что сертификата Эксперт у меня нет, потому что руки не доходят.
Что хотелось бы и не понятно почему в 1С разработчики это упорно игнорируют, хотя те же преподаватели на курсах говорят что было бы здорово если бы это было:
1) Конструктор Индексов объектов баз данных.
Поясню — не я проектирую справочники\ документы с 20-80 реквизитами и не я автор РЛС на несколько реквизитов в одной таблице. Эту проблему можно было бы достаточно малой кровью, но сейчас 3 пути решения, которые озвучиваются на том же обучении:
N1 Ничего не делать.
N2 Реализовать через вспомогательные объекты (как правило Регистры сведений), но делать 10-15 регистров сведений к тому же справочнику номенклатуры не очень здорово + требуется большая переработка существующего функционала. Да это работает, но иногда чудовищные затраты по времени.
N3 Нарушить лицензионное соглашение и добавить индексы на уровне БД и поосле реструктуризации следить за ними, потому что платформа скидывает индексы в по дефолту. Так себе решение, мало кто может это позволить, ибо решение N2 дорого сейчас, а решение N3 дорого всегда.
А бОльший пул проблем можно часто решить просто добавлением 1-2 соответствующих индексов.
2) Нет человеческого инструмента анализа логов.
Объясню: ЦУП — долго, не качественно. На том же обучении — из 5ти попыток только одна смогла проанализировать логи. Для софта за 100 000 с намеком на энтерпрайз по моему плохо.
— Скрипты на perl — неплохое решение, из рекомендуемого gitBash — чтение идет в 1 поток и скорость неудовлетворительна. У одного заказчика установка любого софта запрещена, и я еле еле вынес логи на флешке для анализа, тот же GitBash мне не поставили.
— Самописки. Каждый ваяет как может. Я написал нормализатор на Python и загружаю в SQL.
— Кто то ипользует ELK.
Но есть ситуации когда заказчик ультимативно требует только инструменты Вендора.
Не понятно почему нельзя выпустить инструмент и продавать его за деньги, если он будет лишен недостатков ЦУП — спрос будет, я сам куплю его на свои в первый же день выхода. Тем более для держателей формата тех журнала и тех кто знает основные проблемы это задача не несподъемная.
Просто по своему опыту — 30 гб логов ТЖ нормализуются в CSV на достаточно посредственной машине с HDD диском за 5-15 минут, все зависит от загруженности диска другими задачами.
Тот же Сергей Старых aka TormozIT сделал очень неплохой и достаточно быстрый анализатор логов ТЖ на 1С в инструментах разработчика, но том из — за того что данные после разбора хранятся на форме — не получится анализировать что то большое.
Большое спасибо за внимание.