2010-09-02 2 views

ответ

9

Это мой список из опыта. Он не является полным, но должен охватывать наиболее распространенные проблемные области:

  • Запланируйте конфигурацию распределенного управления сеансом (т. Е. Вы будете использовать реплику памяти для памяти или базы данных). Обратите внимание, что если вы все еще на 32-битной платформе, из-за нехватки ресурсов из кластеризации могут возникнуть проблемы с нестабильностью, если ваше приложение использует уже много памяти.
  • Убедитесь, что все, что вы помещаете в пользовательские сессии, можно сериализовать с помощью сериализатора по умолчанию (реализует Serializable). В противном случае вы могли бы столкнуться с проблемами распределенных сеансов.
  • То же самое касается всего, что вы вкладываете в DynaCache. Убедитесь, что все правильно сериализовано.
  • Укажите и убедитесь, что все определения ресурсов (поставщики JDBC и т. Д.) Будут внесены в правильную область. Обычно я рекомендую использовать фактическую область кластера для всего, что ваши приложения устанавливают для использования кластером. Это гарантирует, что функции тестирования работают должным образом из надлежащих точек и что вы не делаете противоречивых определений.
  • Убедитесь, что ваше приложение использует относительные пути для ресурсов в веб-интерфейсах. Как только вы начнете балансировку нагрузки и прочее, вы можете столкнуться с серьезными проблемами, если у вас есть множество вещей.
  • Если у вас были какие-то таймеры, убедитесь, что они хорошо работают с кластерами. С помощью Quartz это означает, что вы должны использовать хранилище JDBC для задач таймера. С помощью EJB Timers убедитесь, что вы регистрируете таймеры только один раз (возможно повреждение базы данных таймера WAS, если у вас есть несколько узлов, пытающихся зарегистрировать то же самое время) и убедитесь, что вы устанавливаете их в область кластера.
  • Убедитесь, что вы используете предоставленные WAS механизмы SSO. Если у вас есть пользовательская реализация, убедитесь, что она хорошо переносит пользователя между серверами в кластере.
+0

+1 для 'Убедитесь, что ваше приложение использует относительные пути для ресурсов в веб-интерфейсах. Как только вы начнете балансировку нагрузки и прочее, вы можете столкнуться с серьезными проблемами, если у вас есть много вещей. IBM WebSphere Commerce 7 – TheBlackBenzKid

0

Также рекомендуется получить PMR для поддержки IBM перед любыми крупными изменениями, такими как эта или обновление до новых версий и т. Д. Поднимите его как «Вопрос об использовании программного обеспечения», и они могут предоставить вам обратная связь с их базой знаний, основанная на других клиентах. То же самое относится к любому типу продукта, с которым у вас есть соглашение о поддержке, - обратитесь за поддержкой до возникновения проблем.

2

Храните его простым, в зависимости от ваших требований, попробуйте настроить балансировщик нагрузки для использования липких сеансов и не сохранять состояние в сеансе HTTP. Таким образом, вам не нужно использовать ресурс, голодный в репликации сеанса памяти.

Single Sign On не является проблемой для одного кластера, так как ваши HTTP-клиенты не будут перемещаться с одного и того же http://server.acme.com/ ... имени домена хоста.

Большая часть вашего тестирования должна быть сосредоточена на конфликте базы данных. Если у вас очень транзакционное приложение (т. Е. Многие записи в одну и ту же таблицу), убедитесь, что вы смотрите на уровни изоляции базы данных, чтобы блокировки не выполнялись должным образом. То же самое касается демаркации транзакций. Держите транзакции как можно более краткими. Если у вас нет навыков работы с базой данных, убедитесь, что вы получаете аналитика базы данных, чтобы помочь вам контролировать базу данных во время тестирования.