Недавно мы обновились до Castor 1.2 с версии 0.9.5.3 и заметили резкое падение производительности при вызове демаршала в XML. Мы демаршалируем классы java, которые были сгенерированы castor в обоих случаях. Для сравнения, при использовании идентичного XML время для демаршалирования XML раньше занимало около 10-20 мсек, а теперь составляет около 2300 мсек. Есть ли что-то очевидное, что мне может не хватать в нашей новой реализации роликового ролика, может быть, в файле свойств, который я пропустил, или мне стоит начать возвращаться к старой версии? Может быть, в генерации файла java-класса было что-то, что убивает немаршальный вызов? Я мог бы также рассмотреть альтернативы Castor, если бы была веская причина отказаться от него в пользу чего-то другого. Мы используем java 1.5 на сервере веб-логики.
Проблемы с производительностью Castor
Ответы (4)
У нас были очень серьезные проблемы с производительностью при использовании castor 1.0.5 с файлом .castor.cdr (несколько секунд для демаршализации, тогда как раньше это занимало миллисекунды).
Оказалось, что сгенерированный файл .castor.cdr содержит старые / неправильные значения (несуществующие типы и дескриптор). После удаления инкриминируемых строк в этом файле все вернулось в норму.
Надеюсь, это поможет всем, у кого такая же проблема!
Мы вернулись к версии Castor 0.9.5.3, и производительность снова выросла после того, как мы регенерировали классы java из новых XSD. Я не уверен, почему именно такая большая разница между результирующим java, но классы 1.2 были примерно на 2 порядка медленнее при демаршалинге.
** РЕДАКТИРОВАТЬ: ** Похоже, что, создав файл сопоставления ClassDescriptorResolvers / и отключив проверку, мы могли бы также улучшить производительность, но поскольку мы создаем около 1000 объектов с помощью процесса генерации схемы, это не совсем жизнеспособно с точки зрения затрат.
У меня тоже есть эта проблема, при генерации базового набора клиентов / адресов XML требуется около 3 секунд для создания документа, включающего 74 клиента.
При возврате к 1.0.4 (для тестирования) возвращается к 1.4 с,
Но ручная перемотка XML показывает результат менее 40 мсек. Я знаю, что фреймворки добавляют некоторые накладные расходы, но должно быть что-то, вызывающее это.
Проводилось ли профилирование Castor?
Я пойду исследовать JiBX, как предложил Дэн.
