про работу.
Присказка
Я давно тружусь "прикладным программистом для системы 1С:Предприятие". С точки зрения маркетинга и своевременности на рынке очень удачная система и, что характерно, в целом старается оставаться. С технической/технологической - не безупречно, но глядя на остальные какашки отечественного рынка, просто гордость за 1С берёт.
Хорошая система, универсальная, да вот есть и у неё области для которых она не пригодна. Использовать её в этих областях можно, но это будет дорого и ненадёжно. Вот возьмём, например, высоконагруженные системы: биллинг, он-лайн трейдинг на бирже, системы с большим количеством пользователей и операций пользователей. Ситуация чем-то напоминает "культ карго". Вроде и СУБД приличные, кросс-платформенность, что аж обзавидоваться, объектная модель относительно стройная (кто не согласен - могу аргументированно посравнивать с Аксессом тем же), диаграмки бизнес-процессов появились, внедренцы нынче не в трамвае в футболке приезжают, а на иномарках в пинжачках. Красота. А вот уй. Не предназначена. Программисты-разработчики её не писали для такого, и уши этих решений будут постоянно торчать.
Вот тут обычно из слушателей-собеседников выкристаллизовываются 2 большие группы. Одни скажут: "Вот ведь говнецо ваша 1С, там даже язык программирования на русском", другие: "Да кто ты такой так осквернять святыню. На 1С можно написать искусственный разум, и это уже сделал Сергей Нуралиев, но пока не пришло время явить Его миру". Вот с этими группами я прямо здесь могу распрощаться. Первые уходят искать достойного конкурента 1С, вторые идут искать информацию о том как 1С в оперативной памяти числа хранит, и сравнивают с другими реализациями. А я отмечу лишь несколько моментов, что мне мешает в создании высоконагруженных систем в 1С. Перечислю далеко не всё, скорее то, обо что реально спотыкаемся. Есть куча мелких проблем, но они скорее жужжат, но не кусают. Типа таких: неполное использование возможностей СУБД (простите, кросплатформенность), прожорливость по ресурсам (покупайте железку, на лицензиях сэкономили), медленный интерпретатор (куда торопиться - один фиг на выборке из БД всё просадится), куча блокировок при работе с БД, невозможность создавать произвольные индексы и еще куча обглоданных и сто раз описанных проблем. К тому же это и не проблемы, а так - чтобы жизнь интереснее была.
сказка
Глюк первый. При нормальной работе пользователй сервер приложения вдруг отправляется в мир иной, оставив клиентские сессии сиротинушками, а незафиксированные транзакции откатывает, служба рестартует. После второго "Ой" от сервера я настроил технологический журнал на сервере и уже на третий за день инцидент выяснилось, что падает при получении списка активных польователей (а надо сказать, что это действие у нас происходило ОЧЕНЬ часто). Ну что, к вечеру 11.01 с кучей матов был создан костыль, который максимально исключал получение этого списка. 12.01 вечером выяснилось, что этого недостаточно. 13.01 были убраны все получения списка программные и всем, кто имел доступ к получению списка интерактивно было устно запрещено его получать. В пятницу я подготовил скриптец, который получает этот список в цикле, но не смог его тестировать даже на разработческих серверах (уж очень весело всё падало). Дожили до выходных. Начали гонять тесты (на тестовых и боевой системе), выяснили:
Но это была разминка. Сама ошибка достаточно легко локализовалась, данные целы, выявляется и исправляется проблема быстро (все падают, переподключаются и всё). А вот вторая проблемка до сих пор не факт что решена (хоть и не происходила уже 2 дня). Проблема такая: иногда, без видимых причин один из клиентов (опять же обычно служебных, мать их, пользователей) говорит: 3902! "Тhe COMMIT TRANSACTION request has no corresponding BEGIN TRANSACTION." Дело осложняется следующими нюансами: программист 1С не напрямую работает с СУБД и такую ошибку вызвать не может (платформа ему сама насчитает коммиты и выдаст своё сообщение, которое хотя бы отловить в коде не проблема), сеанс клиента тупо висит с модальным диалоговым окном об ошибке и эту ошибку не отловить в коде (учитывая, что это периодически запускаемое задание - крайне обидно и сложно отловить). Но и это не самое печальное. Печально то, что в технологическом журнале сервера и клиента 1С (это грубо говоря полный лог действий системы) нет очевидных причин и одинаковых ситуаций для падения. И самое противное, что Менделеев всё-таки был прав. Ежели где-то коммитов излишки, то, блин где-то их будет недостача. И эта недостача была в одном из соседних коннектов.
С точки зрения целостности данных ситуация ужасная:
Выяснилось, что проблема возникает так: при большом количестве коротких транзакций иногда бывает что одно соединение с БД из пула выдаётся двум клиентским соединениям. Одно уже к этому времени сделало BEGIN TRAN, а второе только запрашивает соединение. При этом у первому соединению отдаётся новое соединение. Порог при котором это всё начинает себя так вести - около 1000 транзакций в секунду с одного соединения.
У нас такое количество транзакций происходит при чтении изменений из плана обмена "ВыборкаИзменений = УзелПланаОбмена.ВыбратьИзменения();" и потом "Объект = ВыборкаИзменений.Получить();" в цикле. При этом каждое ВыборкаИзменений.Получить() является отдельной транзакцией. Ну плюс на самом деле мы там несколько небольших прикладных ошибок нашли, но факт остаётся. Залечили достаточно просто: каждые N ВыборкаИзменений.Получить() и операций выгрузки данных делаются в единой транзакции, так что количество транзакций резко снизилось (фактически в 2*N раз). Уже несколько дней я не получаю (тьфу-тьфу) страшную СМС. Потихоньку отслеживаем все корявые места в коде, где может быть много транзакций и пытаемся это дело оптимизировать. На выходных попробую репру для 8.2 сделать. Если будет валить 8.2 - пошлю в 1С. Если не будет (первую багу, кста, исправили или уменьшили вероятность до ненаблюдаемой) - придётся смириться, потому что на 8.2 мы раньше июне не мигрируем.
Мораль басни
Помню, как-то раз я удивился, правильно ответив (не угадав!) Денису Анатоличу (Анатолич, привет!) на пост типа "угадайте где бага". Прочитал пост в сортире с телефона, ответил с телефона. С++ (о котором был вопрос), конечно, немного знаю, но не зубр (хотя небольшие внешние компоненты и не проблема написать). Потом на самом деле оглянулся, что ему в чем-то проще. У него хотя бы исходный текст его мамонта под рукой есть (ну или был на тот момент). У меня только ибучая интуиция - где же программисты платформы чаще всего ошибки совершают. Люди вообще и программисты в частности делают очень много ошибок. Иногда мне кажется, что программисты вообще делают только ошибки, а работающий код - результат какого-то нематериального процесса, в котором программисты лишь выступают мутагенным фактором. Так вот этой мутагенности в программистах платформы явно выше в тех областях, которые качаются больших нагрузок. Поэтому если будете делать высоконагруженную систему на 1С - скорректируйте бюджет на пару зарплат таких решателей проблем как я (не-не-не, не почасовка, оклад, и не одного как я, а двоих), не забывая, что эта зарплата будет на некоторый процент выше большинства остальных разработчиков. Прибавьте риски (простой системы и потеря данных). Что? Многовато? Ну это по сравнению с чем. Если у вас есть готовый движок для биллинговых систем, то да, а если вы думаете, что ваши программисты могут написать лучше, чем 1С, то сомневаюсь (если конечно у вас нет хотя бы пары десятков упомянутых Анатоличей, но, как гововил товарищ Сухов: "Это вряд ли"), а если думаете, что лучше да еще и дешевле, то срочно бросайте те наркотики, которые употребляете.
Я давно тружусь "прикладным программистом для системы 1С:Предприятие". С точки зрения маркетинга и своевременности на рынке очень удачная система и, что характерно, в целом старается оставаться. С технической/технологической - не безупречно, но глядя на остальные какашки отечественного рынка, просто гордость за 1С берёт.
Хорошая система, универсальная, да вот есть и у неё области для которых она не пригодна. Использовать её в этих областях можно, но это будет дорого и ненадёжно. Вот возьмём, например, высоконагруженные системы: биллинг, он-лайн трейдинг на бирже, системы с большим количеством пользователей и операций пользователей. Ситуация чем-то напоминает "культ карго". Вроде и СУБД приличные, кросс-платформенность, что аж обзавидоваться, объектная модель относительно стройная (кто не согласен - могу аргументированно посравнивать с Аксессом тем же), диаграмки бизнес-процессов появились, внедренцы нынче не в трамвае в футболке приезжают, а на иномарках в пинжачках. Красота. А вот уй. Не предназначена. Программисты-разработчики её не писали для такого, и уши этих решений будут постоянно торчать.
Вот тут обычно из слушателей-собеседников выкристаллизовываются 2 большие группы. Одни скажут: "Вот ведь говнецо ваша 1С, там даже язык программирования на русском", другие: "Да кто ты такой так осквернять святыню. На 1С можно написать искусственный разум, и это уже сделал Сергей Нуралиев, но пока не пришло время явить Его миру". Вот с этими группами я прямо здесь могу распрощаться. Первые уходят искать достойного конкурента 1С, вторые идут искать информацию о том как 1С в оперативной памяти числа хранит, и сравнивают с другими реализациями. А я отмечу лишь несколько моментов, что мне мешает в создании высоконагруженных систем в 1С. Перечислю далеко не всё, скорее то, обо что реально спотыкаемся. Есть куча мелких проблем, но они скорее жужжат, но не кусают. Типа таких: неполное использование возможностей СУБД (простите, кросплатформенность), прожорливость по ресурсам (покупайте железку, на лицензиях сэкономили), медленный интерпретатор (куда торопиться - один фиг на выборке из БД всё просадится), куча блокировок при работе с БД, невозможность создавать произвольные индексы и еще куча обглоданных и сто раз описанных проблем. К тому же это и не проблемы, а так - чтобы жизнь интереснее была.
- Реально выбивает отсутствие типа времени, точнее, чем секунда. Не зря 1С - 1 с. Для бухгалтерской программы в большинстве случаев откровенно пофигу на доли секунд, но если у вас больше 100000 событий в день, то их даже нельзя раскидать на оси времени в достоверной последовательности не прибегая к костылям. Что делать если система должна хранить информацию о более чем миллионе событий (документов) в день, да еще и не раскиданные равномерно по суткам - решительно не понятно.
- Очень напрягает медленная работа с БД на изменение. По сути update'ов и insert'ов работающих с множеством записей вообще нет, а delete только для очень частного случая (и то - кто из программистов 1С не сносил регистр сведений целиком из-за этого случая? :)). Скорость вставки, если не прибегать к мегаизвратам для записей в 100-200 байт не выходит за 500-1000 записей в секунду из одного клиентского соединения. Для большинства типовых загрузок это вообще 1-50 документов в секунду. Те же данные банальным bulk insert вставляются 10000-30000 записей/сек на той же железке.
- Бедный язык запросов. Он похож на обычный SQL, но в нём нет нескольких важных особенностей. Нет windowed аггрегатных функций, нет рекурсивных запросов, нет подзапросов для выборки одиночных значений в части между SELECT и FROM (как нет и OUTER APPLY, которым это можно заменить), нет банального EXISTS.
- Самое важное. 1С писали не для этого. Продеменстрирую на паре примеров.
сказка
Глюк первый. При нормальной работе пользователй сервер приложения вдруг отправляется в мир иной, оставив клиентские сессии сиротинушками, а незафиксированные транзакции откатывает, служба рестартует. После второго "Ой" от сервера я настроил технологический журнал на сервере и уже на третий за день инцидент выяснилось, что падает при получении списка активных польователей (а надо сказать, что это действие у нас происходило ОЧЕНЬ часто). Ну что, к вечеру 11.01 с кучей матов был создан костыль, который максимально исключал получение этого списка. 12.01 вечером выяснилось, что этого недостаточно. 13.01 были убраны все получения списка программные и всем, кто имел доступ к получению списка интерактивно было устно запрещено его получать. В пятницу я подготовил скриптец, который получает этот список в цикле, но не смог его тестировать даже на разработческих серверах (уж очень весело всё падало). Дожили до выходных. Начали гонять тесты (на тестовых и боевой системе), выяснили:
- Падает на активной работе служебных пользователей (которые часто подключаются/отключаются)
- Падает на основном сервере и на разработческом сервере, но не падает на старом разработческом сервере. На серверах подготовки отчетов проверить было нельзя, поэтому там не проверяли.
Но это была разминка. Сама ошибка достаточно легко локализовалась, данные целы, выявляется и исправляется проблема быстро (все падают, переподключаются и всё). А вот вторая проблемка до сих пор не факт что решена (хоть и не происходила уже 2 дня). Проблема такая: иногда, без видимых причин один из клиентов (опять же обычно служебных, мать их, пользователей) говорит: 3902! "Тhe COMMIT TRANSACTION request has no corresponding BEGIN TRANSACTION." Дело осложняется следующими нюансами: программист 1С не напрямую работает с СУБД и такую ошибку вызвать не может (платформа ему сама насчитает коммиты и выдаст своё сообщение, которое хотя бы отловить в коде не проблема), сеанс клиента тупо висит с модальным диалоговым окном об ошибке и эту ошибку не отловить в коде (учитывая, что это периодически запускаемое задание - крайне обидно и сложно отловить). Но и это не самое печальное. Печально то, что в технологическом журнале сервера и клиента 1С (это грубо говоря полный лог действий системы) нет очевидных причин и одинаковых ситуаций для падения. И самое противное, что Менделеев всё-таки был прав. Ежели где-то коммитов излишки, то, блин где-то их будет недостача. И эта недостача была в одном из соседних коннектов.
С точки зрения целостности данных ситуация ужасная:
- В том соединении где была ошибка - фиг знает были ли команды DML (изменения данных), которые должны быть в транзакции одиночными. Или хотя бы все ли они были вне транзакции и выполнены.
- Во стором соединении данные откатываются. Это бы не было страшным, если бы система не считала эту транзакцию закоммиченной! Пользователь (или робот) честно думал, что транзакция зафиксирована и послал, например, уведомление в другую систему о загрузке данных. А потом его труды пропадают.
- Пока второе соединение висит "без коммита" у него открыта транзакцияи скапливается дикое количество блокировок.
Выяснилось, что проблема возникает так: при большом количестве коротких транзакций иногда бывает что одно соединение с БД из пула выдаётся двум клиентским соединениям. Одно уже к этому времени сделало BEGIN TRAN, а второе только запрашивает соединение. При этом у первому соединению отдаётся новое соединение. Порог при котором это всё начинает себя так вести - около 1000 транзакций в секунду с одного соединения.
У нас такое количество транзакций происходит при чтении изменений из плана обмена "ВыборкаИзменений = УзелПланаОбмена.ВыбратьИзменения();" и потом "Объект = ВыборкаИзменений.Получить();" в цикле. При этом каждое ВыборкаИзменений.Получить() является отдельной транзакцией. Ну плюс на самом деле мы там несколько небольших прикладных ошибок нашли, но факт остаётся. Залечили достаточно просто: каждые N ВыборкаИзменений.Получить() и операций выгрузки данных делаются в единой транзакции, так что количество транзакций резко снизилось (фактически в 2*N раз). Уже несколько дней я не получаю (тьфу-тьфу) страшную СМС. Потихоньку отслеживаем все корявые места в коде, где может быть много транзакций и пытаемся это дело оптимизировать. На выходных попробую репру для 8.2 сделать. Если будет валить 8.2 - пошлю в 1С. Если не будет (первую багу, кста, исправили или уменьшили вероятность до ненаблюдаемой) - придётся смириться, потому что на 8.2 мы раньше июне не мигрируем.
Мораль басни
Помню, как-то раз я удивился, правильно ответив (не угадав!) Денису Анатоличу (Анатолич, привет!) на пост типа "угадайте где бага". Прочитал пост в сортире с телефона, ответил с телефона. С++ (о котором был вопрос), конечно, немного знаю, но не зубр (хотя небольшие внешние компоненты и не проблема написать). Потом на самом деле оглянулся, что ему в чем-то проще. У него хотя бы исходный текст его мамонта под рукой есть (ну или был на тот момент). У меня только ибучая интуиция - где же программисты платформы чаще всего ошибки совершают. Люди вообще и программисты в частности делают очень много ошибок. Иногда мне кажется, что программисты вообще делают только ошибки, а работающий код - результат какого-то нематериального процесса, в котором программисты лишь выступают мутагенным фактором. Так вот этой мутагенности в программистах платформы явно выше в тех областях, которые качаются больших нагрузок. Поэтому если будете делать высоконагруженную систему на 1С - скорректируйте бюджет на пару зарплат таких решателей проблем как я (не-не-не, не почасовка, оклад, и не одного как я, а двоих), не забывая, что эта зарплата будет на некоторый процент выше большинства остальных разработчиков. Прибавьте риски (простой системы и потеря данных). Что? Многовато? Ну это по сравнению с чем. Если у вас есть готовый движок для биллинговых систем, то да, а если вы думаете, что ваши программисты могут написать лучше, чем 1С, то сомневаюсь (если конечно у вас нет хотя бы пары десятков упомянутых Анатоличей, но, как гововил товарищ Сухов: "Это вряд ли"), а если думаете, что лучше да еще и дешевле, то срочно бросайте те наркотики, которые употребляете.