Вопрос - будет ли БИОС видеть такой диск как полноценный SSD? Для таких кейсов как развернуть на нее ОС со всеми данными и ходить с одним окружением от станции к станции
По сути сейчас использую Элемент как расширение имеющихся возможностей платформы в части мобилок удобных и красивых, в части ЛК, веб-сервисов для реализации микросервисной архитектуры. Есть пара проектов полностью автономных для задач чисто учета (то же самое что и на платформе, только в вебе и быстрее, а еще дешевле по лицензиям), ну и какие то сложные сценарии интеграции, где веб сервис на Элементе выступает в качестве брокера или просто для вебхуков.
Можно, конечно, и полноценную CRM сделать, но тут наверное какую-то специфическую надо реализовывать, так как сложно тягаться с общими решениями типа амо, битрикса, ритейла. Хотя за Элементом преимущество в части открытого исходного кода и возможности кастомизировать решение под себя, тут взято лучшее от самой платформы.
Попробуйте 1С:Элемент и его язык. Он похож на язык платформы 1С, но имеет ряд изменений и улучшений, в частности статическая типизация, большое количество фич из коробки (те же регулярки), облачная IDE на базе Teya, схема упрощения синтаксиса как в питоне. А еще все элементы и формы проекта в yaml файлах с возможностью прямого редактирования их кроме визуального конструктора свойств. Я лично год пишу на Элементе и тащусь от него, особенно когда приходится возвращаться обратно на платформу 1С.
Да, и работа с классами в целом тоже имеется в виде структур, только пока без наследования и полиморфизма, но хотя бы методы и поля имеются с управлением видимостью методов. Для задач сериализации например из JSON текста в объектную модель на ходу идеально заходит.
Соглашусь с предыдущим оратором. Для меня как для CEO материал крайне важен с точки зрения самодиагностики и подтверждения что мои проблемы не уникальные. Но читал я статью 4 дня урывками, поскольку текущая работа крайне редко дает возможность сесть и погрузиться полностью в текст. Аналогично и с книгой, я ее читаю маленькими порциями при появлении времени и возможности, но приходится постоянно перечитывать текст, потому что контекст со временем исчезает и за исходной мыслью надо возвращаться.
Потому лонгриды - это хорошо, но надо понимать что его и читать будут долго, неделями и месяцами. Просто принять как факт и не расстраиваться.
Аналогичное письмо получил на днях от своего: Информируем Вас о том, что 24.01.2025 с 10.30 до 17.00 в связи с плановыми работами будут недоступны услуги связи по адресу: Россия, Санкт-Петербург,...
Ожидается отключение до 5 часов. Приносим извинения за временные неудобства.
Еще вопрос - вы предварительную оптимизацию делали для СУБД Postgresql? Или взяли стоковую сборку от 1С и на ней запускали тесты? Поскольку по умолчанию postgresql настроен на минимальное потребление ресурсов, в отличие от MS SQL, который тюниися под систему прямо при установке.
По моим наблюдениям за последние пару лет, разница может достигать 30% до и после настройки параметров.
Кроме этого важна версия СУБД, 12 от 17 отличаются достаточно сильно, а кроме того крайне важна версия платформы. 8.3.24 и 8.3.25 отличаются между собой по производительности на 10-15% в пользу 8.3.25, при этом очень много пользователей работают под 8.3.24, об этом также важно помнить.
Что ж вы тесты Гилева не до конца проводите для AMD Epyc? Почему нет теста многопоточности, при том что для Intel вы его провели? Кроме этого, результаты Гилева надо брать средние от 3-5 запусков, так как первый тест ВСЕГДА выдает прирост производительности на 10-15% поскольку сама база пустая и индексы не мешают для операций. Смотреть надо не только однопоточные операции (они важны, но только для спортивного интереса и для сравнительной оценки), но и многопоточные, так как системы рассчитаны на многопользовательскую работу в первую очередь. А так что Intel Xeon что AMD Epyc крайне слабы для синтетических однопоточных тестов даже по сравнению с Intel 8400 (48 баллов Гилева) или AMD Ryzen 7700X (77 баллов Гилева). Но это ж не значит что надо брать десктоп камни для 100+ пользователей.
Обычно не оставляю комментарии на Хабре, но тут не могу сдержаться. Каким образом подключение к кластеру сервера 1С по сетевому порту 1541 связано с открытием ФАЙЛОВОЙ базы через указание пути к файлу 1CD? Полная бредятина написана с точки зрения реальной эксплуатации продуктов и решений от 1С.
Вопрос - будет ли БИОС видеть такой диск как полноценный SSD? Для таких кейсов как развернуть на нее ОС со всеми данными и ходить с одним окружением от станции к станции
По сути сейчас использую Элемент как расширение имеющихся возможностей платформы в части мобилок удобных и красивых, в части ЛК, веб-сервисов для реализации микросервисной архитектуры. Есть пара проектов полностью автономных для задач чисто учета (то же самое что и на платформе, только в вебе и быстрее, а еще дешевле по лицензиям), ну и какие то сложные сценарии интеграции, где веб сервис на Элементе выступает в качестве брокера или просто для вебхуков.
Можно, конечно, и полноценную CRM сделать, но тут наверное какую-то специфическую надо реализовывать, так как сложно тягаться с общими решениями типа амо, битрикса, ритейла. Хотя за Элементом преимущество в части открытого исходного кода и возможности кастомизировать решение под себя, тут взято лучшее от самой платформы.
Попробуйте 1С:Элемент и его язык. Он похож на язык платформы 1С, но имеет ряд изменений и улучшений, в частности статическая типизация, большое количество фич из коробки (те же регулярки), облачная IDE на базе Teya, схема упрощения синтаксиса как в питоне. А еще все элементы и формы проекта в yaml файлах с возможностью прямого редактирования их кроме визуального конструктора свойств. Я лично год пишу на Элементе и тащусь от него, особенно когда приходится возвращаться обратно на платформу 1С.
Да, и работа с классами в целом тоже имеется в виде структур, только пока без наследования и полиморфизма, но хотя бы методы и поля имеются с управлением видимостью методов. Для задач сериализации например из JSON текста в объектную модель на ходу идеально заходит.
Соглашусь с предыдущим оратором. Для меня как для CEO материал крайне важен с точки зрения самодиагностики и подтверждения что мои проблемы не уникальные. Но читал я статью 4 дня урывками, поскольку текущая работа крайне редко дает возможность сесть и погрузиться полностью в текст. Аналогично и с книгой, я ее читаю маленькими порциями при появлении времени и возможности, но приходится постоянно перечитывать текст, потому что контекст со временем исчезает и за исходной мыслью надо возвращаться.
Потому лонгриды - это хорошо, но надо понимать что его и читать будут долго, неделями и месяцами. Просто принять как факт и не расстраиваться.
Спасибо за ссылку. Прочитал в один присест. И стало страшно...
Аналогичное письмо получил на днях от своего:
Информируем Вас о том, что 24.01.2025 с 10.30 до 17.00 в связи с плановыми работами будут недоступны услуги связи по адресу: Россия, Санкт-Петербург,...
Ожидается отключение до 5 часов.
Приносим извинения за временные неудобства.
Еще вопрос - вы предварительную оптимизацию делали для СУБД Postgresql? Или взяли стоковую сборку от 1С и на ней запускали тесты? Поскольку по умолчанию postgresql настроен на минимальное потребление ресурсов, в отличие от MS SQL, который тюниися под систему прямо при установке.
По моим наблюдениям за последние пару лет, разница может достигать 30% до и после настройки параметров.
Кроме этого важна версия СУБД, 12 от 17 отличаются достаточно сильно, а кроме того крайне важна версия платформы. 8.3.24 и 8.3.25 отличаются между собой по производительности на 10-15% в пользу 8.3.25, при этом очень много пользователей работают под 8.3.24, об этом также важно помнить.
Что ж вы тесты Гилева не до конца проводите для AMD Epyc? Почему нет теста многопоточности, при том что для Intel вы его провели?
Кроме этого, результаты Гилева надо брать средние от 3-5 запусков, так как первый тест ВСЕГДА выдает прирост производительности на 10-15% поскольку сама база пустая и индексы не мешают для операций.
Смотреть надо не только однопоточные операции (они важны, но только для спортивного интереса и для сравнительной оценки), но и многопоточные, так как системы рассчитаны на многопользовательскую работу в первую очередь.
А так что Intel Xeon что AMD Epyc крайне слабы для синтетических однопоточных тестов даже по сравнению с Intel 8400 (48 баллов Гилева) или AMD Ryzen 7700X (77 баллов Гилева). Но это ж не значит что надо брать десктоп камни для 100+ пользователей.
Хорошая статья. Считай готовый план для составления вакансии и проведения собеседования: от основания до верхушки.
Обычно не оставляю комментарии на Хабре, но тут не могу сдержаться. Каким образом подключение к кластеру сервера 1С по сетевому порту 1541 связано с открытием ФАЙЛОВОЙ базы через указание пути к файлу 1CD? Полная бредятина написана с точки зрения реальной эксплуатации продуктов и решений от 1С.