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