Мне часто помогает ObjectExplorer. Я решил расширить его возможности для работы с GemStone.

Начнем наше исследование с объекта, который является “точкой входа”.

shops – представляет собой список цехов, typeEquipments – список типов оборудования и т.д.

nil переменные выделены серым цветом

stub -ы выделены зеленым цветом.

Попробуем нажать на переменную shops :

Stub shops “вытащился” из базы и теперь является обычным объектом – переменная shops стала черного цвета. Число 358 на стрелочке обозначает время “вытаскивания” stub -а в миллисекундах. Посмотрим что-же произошло за эти 358 миллисекунд: Для этого добавим статистику(правой кнопкой мыши на стрелочке – add statistics):

Попробуем разобраться в этих страшных названиях:

primTraverse 1 - обозначает что была одна передача по сети.

traversedObjects 67 – говорит что по c ети было передано 67 объектов.

atOop : putClient : и atClient : putDelegate : требует некоторых пояснений.

GemStone на клиенте ведет два словаря.

Один :

OOP объекта в базе –> объект на клиенте,

а второй:

Объект на клиенте -> OOP объекта в базе.

atOop : putClient : 53 говорит что в первый словарь было добавлено 53 записи, а atClient : putDelegate : 53 тоже самое только для второго словаря.

Часто возникает вопрос: “Объекты каких классов были вытянуты из базы”.

Здесь – правой кнопкой мышки на atOop : putClient : и выбираем more .

Теперь пройдемся по тем объектам, которые уже получены на клиента(черные названия переменных):

Как видно shops имеет черный цвет, т.е. содержится на клиенте, а возле него все равно стоит надпись stub .

Подписи stub , min 2, forwarder получаються из replicationSpec , поэтому даже после “разименования” stub -а мы видим что указано в replicationSpec . Это очень удобно когда необходимо выяснить почему же так много объектов “вытащилось” на клиент.

Например из этого рисунка

можно сделать вывод, что “вытягивание” закончилось на переменной owners , потому как переменная owners определена в replicationSpec как stub .

Рассмотрим один интересный случай:

Здесь метод OgeRegistrar >> sortedEvents вызывается два раза. Первый раз по сети было передано 9348 объектов ( traverseObjects 9348 ) все объекты кроме одного(9347) были получены на клиент впервые поэтому были занесены в два словаря atClient : putDelegate : 9347 и atOop : putClient : 9347 . Во второй раз по сети были переданы те же объекты ( traverseObjects 9348 ), но все они кроме одного уже были в словарях. Этот один новый объект есть результат запроса – OrderedCollection .

Для сбора статистика у GemBuilder есть специальный класс, который записывает статистику в файл. Причем статистика не суммарная, как на диаграмме, а просто лог. Записывается такой лог долго. И разобраться в нем мне было не просто. Потому я написал свой сборщик, подменяя стандартный сборщик своим только на время сбора статистики. Оба сборщика имеют независимое включение/отключение.

Сбор статистики увеличивает времени выполнении запроса. Приведенный выше пример (11 секунд выполнения) без сбора статистики выполняется около 2,9 секунд.

Далее интересней