Битрикс. Редакция “Кривое говно”.
May. 4th, 2012 10:31 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
ermouthСайт Формозы работает на Битриксе. В весьма дорогой комплектации, имхо правильное название которой – Кривое Говно.
Битрикс глючит – пользователи жаловались, что в магазине Битрикса (штатный функционал) пропадают разделы и товары. Глючит модуль, загружающий прайсы из 1С.
Впервые мы заметили эту проблему в декабре. Повторно она вылезла в марте. Мы сначала решили, что дело в нас. Потом – что в менеджерах офлайного магазина, заносящих товары. Потом, всё перебрав и написав контрольный скрипт, выяснили, что Битрикс глючит – причём глючит как и любое такое говно, по-тихому. Записывая в логи “Всё ок”. Это выяснилось окончательно в апреле – и мы написали в саппорт.
Криворукие из саппорта Битрикса две недели трахали нам мозги, регулярно присылая нам обновления скрипта, создавая видимость работы, отвечая на тикеты… Скрипт всё равно глючит, разделы и товары пропадают. Они даже не подобрались за эти две недели к причине проблемы.
После звонка и разговора на повышенных тонах проблеме присвоили типа какой-то там важный статус. Отправили из саппорта разработчикам. Я думал, волшебный пендель поможет. Я был дурак и недооценил степень застойности болота.
Разработчики, почесав репу один день и палец о палец не ударив для решения собственной криворукости, посоветовали нам перенастроить сервер и, по сути, самостоятельно реализовать функционал запуска по таймеру авторизованного php-скрипта.
Дело, на минуточку, происходит в Винде, никакого cron’a там нет, а назначенные задачи по ряду причин не подходят.
Проблема происходит потому, что кривой компонент Битрикса не успевает отработать 15000+ строк в csv-файле за 10 отведённых минут (занимает примерно 15 минут). А кривой Битрикс-агент убивает “зависший” скрипт и запускает новый.
Вообще, это надо было ещё ухитриться написать такое говно, которое на многоголовом жирном Intel Xeon разбирает по 15 строк в секунду. Отличная скорость разбора и записи простых текcтовых данных – примерно 300 килобайт в минуту. Это 40kbps – скорость работы дешевого модема в конце 90-х годов. Я не могу себе даже представить степень криворукости и непрофессионализма говнокодера, родившего такое. Скрипт, как мне показалось по беглому осмотру, типичный пример сложности O(n^2), а достаточно O(n).
Потом надо было ещё ухитриться написать агенты, не учитывающие состояния запущенного скрипта.
А потом надо было ухитриться, протрахав клиенту, заплатившему несколько тысяч долларов за лицензию, мозги две недели, свалить решение проблемы на него.
Одарённые из Битрикса, с кем я имел дело, поимённо:
- Иван Лузин – робот из партнёрского отдела Битрикса, который ухитрился проговорив со мной несколько минут гнусавым шёпотом, несколько раз повысить на меня голос, поучить меня жизни и не ответить ни на один заданный вопрос.
- Денис Шаромов – который пообещал поставить проблему на контроль, результатом которого явилась просто констатация проблемы. “Да, мы обосрались – но решать вам”.
Гореть им в аду.
А вам, дорогие читатели, как только предлагают сделать магазин на Битриксе – сразу бейте в лицо.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2012-05-04 06:43 pm (UTC)no subject
Date: 2012-05-04 07:13 pm (UTC)no subject
Date: 2012-05-05 03:26 pm (UTC)no subject
Date: 2012-05-04 07:14 pm (UTC)no subject
Date: 2012-05-05 07:37 am (UTC)no subject
Date: 2012-05-05 06:20 am (UTC)no subject
Date: 2012-05-05 07:37 am (UTC)no subject
Date: 2012-05-05 08:51 am (UTC)no subject
Date: 2012-05-05 05:14 pm (UTC)no subject
Date: 2012-05-05 01:36 pm (UTC)Ну давайте сначала по существу.
Я Денис Шаромов, руководитель отдела поддержки компании Битрикс. К вашей проблеме относились очень внимательно. Но ясности с ней не было полной. Я лично разговаривал с вами по телефону пытался вникнуть в проблему и найти какое-то решение. Бывает, что ты пытаешься помогать решить проблему, а со стороны клиента занимают такую позицию, что как говорится "сквозь зубы", и не помощи в локализации и сам еще дурак, что позвонил. Так было и с вами, к сожалению.
Разговор с вами не помог локализовать проблему, но некоторые эксперименты помогли выяснить причину проблемы.
Вы делаете тяжелую операцию импорта, длительностью более 10 минут, на хитах 4 раза в день.
1. Изначально озадачило нас, почему 10 минут. 15 000 товаров не так много, должно было бы быть быстрее.
2. Ну и делать это на хитах совсем неправильно, для таких долгих процедур есть возможность вынести агенты на внешний планировщик.
Что в итоге выяснилось.
1. Проблема медленного импорта.
Импорт работает медленно потому что в файле импорта нет XML_ID, в итоге поиск существующих разделов идет по названию, что очень долго.
Банально, XML_ID с индексом, строка без. Ероме того, в XML файле с вашими данными есть лишние данные, которые парсятся, но не импортируются.
Проблема бы решилась, если бы вы выгружали символьный идентификатор, настроив для него соответствие в профиле импорта.
В случае такого изменения импорт бы работал быстро. Не за секунду, конечно, 15000 товаров в XML надо разобрать и проверить, но все же было бы быстро. Но и в этом варианты мы рекомендуем выносить на агентов такие процедуры.
2. Проблема импорта на хитах.
На вашем проекте было выявлено, что два агента запускались одновременно и с отставанием в 10 минут делали импорт в тот же инфоблок.
Мои сотрудники начали пытаться получить положительный результат при работе с агентами. А не нужно было это делать.
Надо было сразу переводить выполнение на задания и планировщик.
А теперь не по существу.
Можно ли было быстрее решить вашу проблему? Да, я думаю можно было быстрее.
Могли ли вы внимательнее относиться к разработке своего проекта? Да, как программист вы должны понимать физику процесса, а не занимать поверхностную позицию.
no subject
Date: 2012-05-05 02:24 pm (UTC)Или предупреждайте честно, что ваша поделка непригодна для "больших" (15000 строк как я понял невыносимая нагрузка для софта за несколько килобаксов) наборов данных. А вы -- как и полагается неумехам -- валите всё на клиента и его данные.
По поводу хмл-ид. Начнем с того, что это не xml, а csv. XML-ID есть в каждой строке -- вы поленились даже файл открыть. Ну, куда там. Отписки то проще писать.
И не надо про то, что было бы быстрее -- у меня написан скрипт, который разбирает тот же csv и пишет экселевский прайс. Он отрабатывает за 5 секунд. Я потестировал с проверкой и укладкой в MySQL-базу -- 30 секунд, это при том, что у меня там говнокод и очень слабая виртуальная машина. Видите ли, в базу можно укладывать не построчно, а сразу по несколько строк -- это, вы не поверите, круто быстрее.
Чуваки, 15 минут -- это запредельно, без всяких оправданий. Остальное -- тоже. И я вижу, что вы даже не почешетесь.
Ну ничего, Гугл помнит всё, и я вам торжественно обещаю, что это не конец истории. Потому что вы украли у нас кучу времени, продали нам говно с ограничениями, про которые не удосужились нас уведомить, и до сих пор считаете, что в этой ситуации мы неправы и делали что то не так.
Вместо того чтобы напрячься и решить проблему.
no subject
Date: 2012-05-05 02:39 pm (UTC)no subject
Date: 2012-05-18 09:18 am (UTC)no subject
Date: 2012-05-18 05:10 pm (UTC)no subject
Date: 2012-05-18 05:16 pm (UTC)Срач начался с фразы:
Битрикс изнутри напоминает unix — набор простых и неубиваемых концепций, никаких извращенных десятиэтажных объектных конструкций, доступным избранным умам. Поэтому простой или сложный проект делается на Битриксе — неважно, куда не ткни, система раскладывается на простые кубики, покрытые изнутри инструментами профилирования и отладки.
Это вынесло мне мозг просто :)
no subject
Date: 2012-05-18 05:36 pm (UTC)Да даже чисто внешне -- явно пузыри с win xp срисовывали. ну и деревья эти виндовые, и layout как в mmc.
no subject
Date: 2012-05-21 08:22 am (UTC)no subject
Date: 2012-05-18 08:06 am (UTC)Импорт работает медленно потому что в файле импорта нет XML_ID, в итоге поиск существующих разделов идет по названию, что очень долго.
Тут цитата вот эта отлично подходит:
— Так у нас проблемы с производительностью, надо добавить кэширование, вертикальное партиционирование и NoSQL DB для логинов.
— Парни — я тут посмотрел EXPLAIN — у Вас fullscan запрос на 4,000 строк, я попробовал создать индекс — все ускорилось в 26 раз
no subject
Date: 2012-05-07 08:01 pm (UTC)no subject
Date: 2012-05-18 05:11 pm (UTC)no subject
Date: 2012-05-21 02:14 pm (UTC)Напишите сюда сколько теперь времени уходит на импорт 15K строчного файла.
no subject
Date: 2012-05-21 03:55 pm (UTC)no subject
Date: 2012-06-08 06:15 pm (UTC)Вначале мы подозревали, что прошлая команда разработчиков была уровня "студент", но как оказалось - это сам битрикс, в принципе, обязывает разработчика говнокодить.
Процесс разработки выглядит примерно так:
1 неделя: геморой и порождение костылей (не переписывать же проект с нуля).
2 неделя: покрывание матом и создание кукол вуду команды битрикса.
3 неделя: задумываемся сделать rm -rf проекта, выпить бутылку виски за упокой и собрать все на Yii framework.
Они ведь это называют продуктом corporate уровня. Битрикс, вы оху*ли?
P.S. - Извините, слив эмоций, предел терпения.
Bitrix - Кривое говно, трехэтажный пиздец и тупая хуйня!
Date: 2012-09-19 07:25 am (UTC)no subject
Date: 2012-11-08 01:03 pm (UTC)no subject
Date: 2013-06-28 05:51 pm (UTC)no subject
Date: 2013-07-11 08:13 pm (UTC)no subject
Date: 2013-07-11 08:50 pm (UTC)Тут вся суть именно в том, чтобы все нужные данные дернуть одним запросом. Ну или несколько запросов - но больших.
P.S.: кроме того, остается еще резервный вариант - соответствия между кодом товара и id можно сохранять в файл/спец.таблицу и пользоваться им для работы - так не придется дергать api битрикса для получения каких-то первоначальных данных, а просто собрать список id товаров на обновление и уже по этим id их и запросить. А не дергать все данные из всей базы товаров. Вообщем, даже 10-15 минут на работу алгоритма - это не так и много. Я тут встречал сайты где по два-три часа данные грузят. И без транзакций, по несколько запросов к базе на каждый товар :)
no subject
Date: 2013-07-11 09:08 pm (UTC)Про "10-15 минут – не так и много" – это всё хорошо, пока у вас есть крон. А там была винда.
Смысл поста был в том, что у продукта за $3К+ модуль импорта писал какой-то криворукий дебил, а другие криворукие дебилы вместо того, чтобы устранить проблему, кормили нас говном больше полумесяца.
Как бы не ждёшь, выполнив все техтребования и заплатив кучу денег, что тебя будут настолько бессовестно сливать, когда ты просишь устранить криворучие.
no subject
Date: 2013-07-11 09:14 pm (UTC)Проблема в том, что особых альтернатив нет. Другие cms - еще хуже.
no subject
Date: 2013-07-11 11:07 pm (UTC)Битрикс действительно гэ. Просто архитектура не позволяет – сочинить на php что-то по-хорошему расширяемое, не дырявое и производительное достаточно сложно. Ну и конечно наблюдается в полный рост в php-системах вот это явление http://en.wikipedia.org/wiki/Greenspun's_tenth_rule. Причём добавление чисто функциональных фич (замыкания, карринг, функции как аргументы) в 5.3 ничего в комьюнити не поменяло – люди, пишущие на бейсике, обречены всю жись писать на бейсике. Да и перелопатить codebase предыдущих версий php-шных cms для изъятия велосипедиков довольно нетривиальная задача.
Но это не проблема – я ни разу не встречал ситуации, в которой нужен был бы весь функционал Битрикса хотя бы близко, поэтому мы ситуационно используем разные решения, не универсальные, которые уделывают битрикс по всем без исключения параметрам конкретной задачи.
Битрикс только по запросу клиента, с предупреждением обо всех прелестях.
no subject
Date: 2013-07-12 12:07 am (UTC)Битрикс действительно гэ. Просто архитектура не позволяет – сочинить на php что-то по-хорошему расширяемое, не дырявое и производительное достаточно сложно. Ну и конечно наблюдается в полный рост в php-системах вот это явление http://en.wikipedia.org/wiki/Greenspun's_tenth_rule. Причём добавление чисто функциональных фич (замыкания, карринг, функции как аргументы) в 5.3 ничего в комьюнити не поменяло – люди, пишущие на бейсике, обречены всю жись писать на бейсике. Да и перелопатить codebase предыдущих версий php-шных cms для изъятия велосипедиков довольно нетривиальная задача.
Но это не проблема – я ни разу не встречал ситуации, в которой нужен был бы весь функционал Битрикса хотя бы близко, поэтому мы ситуационно используем разные решения, не универсальные, которые уделывают битрикс по всем без исключения параметрам конкретной задачи.
Битрикс только по запросу клиента, с предупреждением обо всех прелестях.