Реальный сетевой трафик Аксапты

[Seismic]

Доброго времени суток!
Хотел бы услышать отзывы зубров по Аксапте на такой вопрос.
Мы сейчас изучаем, точней знакомимся с сист. на примере демоверсии, т.к. хотелось бы узнать ее возм-ти перед принятием решения о ее приобретении.
Я провел некоторые эксперименты с ней в трехуровневой архитектуре и
вот, что поразило - сетевой трафик Аксапты между клиентом и сервером
приложения ( тонкий клиент) такой же как и для старой (образца 1995 г.) еще
досовской версии системы RS balance. В нашей компании существует сеть
филиалов и мы предполагали соединить их с центральным сервером для работы по
удаленке с использованием тонкого клиента, но получается , что система при
создании заказа в 10 поз. между клиентом и сервером приложения (!)
"прокачивает" около 1 Мб! Разве она может быть отнесена к
клиент-серверным. Получается, что приложение не выполняется на сервере
-AOS, а еще и задействует рабочую станцию на удаленном конце, вместо
использования ее только для отображения информации! В чем причина такого
трафика Аксапты?
Если судить об информации, которая имеется в инете - работа по удаленного
доступу по телефонному каналу по скорости не отличается от работы в
локальной сети, - такого быть не должно. В чем может быть дело? Или Аксапта
не совсем клиент-серверная система? А все сообщения о ней - рекламные
акции!? И именно поэтому все и советуют терминалку!?
Заранее благодарен.

[mazzy]

Цитата:

Изначально опубликовано Seismic
...система при создании заказа в 10 поз. между клиентом и сервером приложения (!) "прокачивает" около 1 Мб! Разве она может быть отнесена к
клиент-серверным.

Вы очень... хм... далеко идущие выводы делаете. Хотя пока только спрашиваете

Вы меряли трафик не только "при создании заказа".
Скорее всего, вы меряли трафик от начала работы Аксапты до ввода заказа.

Аксапта кеширует используемые объекты и прокачивает по сети куски aod-файла. Эти куски прокачиваются только в первый раз. Затем идут только данные.

Хорошо, что вы меряли трафик не в первый запуск тонкого клиента
Аксапта проверяет, есть ли на клиенте необходимые dll-ки и ocx-ы и закачивает еще и их. Если бы вы меряли трафик, при первом запуске, то там было бы гораздо больше мегабайта.

Насчет работы тонкого клиента по телефону - читайте на этом форуме. В двух словах, если ничего не настраивать, то сначала идет загрузка минут на 10. Потом работа идет более-менее нормально. Читайте и о рекомендуемой ширине канала. в доке говорится о 64Кбит на 10 пользователей. Подумайте над этой рекомендацией. Подумайте почему в рекомендации не указан канал на одного пользователя.

Читайте документацию. И думайте, пожалуйста.

[AKIS]

г-н Seismic, вам не попробовать Web client, заместо стандартного Аксаптового?

По моим представлениям и опыту, шуршать по сети должно гораздо скорее, да и софта на клиентскую машину ставить не нужно -> зело сэкономите на поддержке.

Возможно, это вам несколько дороже обойдется (увы, давно уже не знаю, какие сейчас цены на разные компоненты Аксапты, посему лишь могу предполагать на основании того, как было полтора года назад). Ну так ведь нельзя ж чтоб было и дешево, и качественно, и быстро

Наконец, как бы сделал я - поставил бы в каждом филиале по махонькому сервачку, и присоединил бы к нему местных клиентов. А связь между серверами "центр-периферия" сделал бы в виде репликации (стандартной MSSQL-ной) раз в день, ну можно раз в 3 часа если сильно надо. Вряд ли вашим филиалам так уж жизненно необходим реал тайм....

[mazzy]

не надо репликацию.
RecID поплывут и могут стать неуникальными.

web-разработка... там прогать много придется. Особенно для финансов.
Однако, если Enterprise Portal покрывает запросы, то его можно и нужно использовать.

[AKIS]

Цитата:

RecID поплывут и могут стать неуникальными.

А если их изначально - как-нибудь, не знаю как - разнести? У центра они начинаются с 0, у филиала 1 - с 10000000000000000000000, у филиала 2 - с 20000000000000000000000...

Согласен, идея глупая - но на одном моем проекте, правда не MS SQL-ном, работала без проблем.

[Pavel]

Цитата:

Изначально опубликовано AKIS
Наконец, как бы сделал я - поставил бы в каждом филиале по махонькому сервачку, и присоединил бы к нему местных клиентов. А связь между серверами "центр-периферия" сделал бы в виде репликации (стандартной MSSQL-ной) раз в день, ну можно раз в 3 часа если сильно надо. Вряд ли вашим филиалам так уж жизненно необходим реал тайм....

Такого в жизни аксапты не бывает, разве что только в обещаниях не очень опытных селйзменов (для "чайников").

Цитата:

Изначально опубликовано AKIS
А если их изначально - как-нибудь, не знаю как - разнести? У центра они начинаются с 0, у филиала 1 - с 10000000000000000000000, у филиала 2 - с 20000000000000000000000...

Формирование RecId для новых записей в таблицах, выделение диапазонов для номеров и принцип их использования – это изначально встроенный в систему механизм. Его нельзя модифицировать. Перезапись уже сформированных RecId создает риск серьезного сбоя в работе системы и потери данных.

[Vadik]

Цитата:

Формирование RecId для новых записей в таблицах, выделение диапазонов для номеров и принцип их использования – это изначально встроенный в систему механизм. Его нельзя модифицировать.

его можно не трогать

Цитата:

Перезапись уже сформированных RecId создает риск серьезного сбоя в работе системы и потери данных.

Сгенерированные RecId можно не перезаписывать. Зато можно аккуратно подкрутить вперед счетчик, который выдаст значения для новых записей, SystemSequences.NextVal и выделить в каждой базе свой диапазон. Граблей в пределах одной БД пока что не было, репликацию не настраивали, но попробовать можно

[Pavel]

Цитата:

Изначально опубликовано Vadik
Зато можно аккуратно подкрутить вперед счетчик, который выдаст значения для новых записей, SystemSequences.NextVal и выделить в каждой базе свой диапазон.

Счетчик RecId не всегда последовательно идет вперед с дискретным шагом - 48. Во многих таблицах записи могут быть удалены функциональностью или пользователями, поэтому движок анализирует наличие свободных диапазонов в номерах RecId и в какой-то момент автоматически переключается на их заполнение.
Предложение «подкрутить вперед счетчик» - означает прямое вмешательство в работу механизма. Система не предполагает такого рода вмешательств со стороны пользователей.

Цитата:

Изначально опубликовано Vadik
Граблей в пределах одной БД пока что не было, репликацию не настраивали, но попробовать можно

Может статься, что "все самое интересное в вашей жизни" еще впереди.

[Seismic]

Господа, всем кто принял участие в обсуждении проблемы, grand рахмат! В общем идея понятна.

[Vadik]

Цитата:

Во многих таблицах записи могут быть удалены функциональностью или пользователями, поэтому движок анализирует наличие свободных диапазонов в номерах RecId и в какой-то момент автоматически переключается на их заполнение.

странно, никогда ничего похожего в сиквельном профайлере не видел, правда, специально не искал

поиск свободного диапазона записей - не самая тривиальная задача, неужели движок сам ее периодически выполняет, если его никто об этом не просит?

в общем, поэкспериментируем..

[mazzy]

насколько я знаю, поиск свободного диапазона в RecID Аксапта не выполняет.

[Антон Солдатов]

100% не выполняет

[Pavel]

Цитата:

Изначально опубликовано Антон Солдатов
100% не выполняет

А каким образом вы пришли к этому выводу?

Кстати, писал про ядро 2.5, сейчас заглянул в трешку, там движок модифицирован, например, шага 48 уже нет, RecId идут иногда подряд, иногда с некоторым дискретным шагом, но и он не постоянный.
Помню, мы в какой-то дискуссии (вроде как о сохранении ссылок по RecId при экспорте/импорте записей из базы) поднимали вопрос по правилам формирования RecId и тогда специально проверял разные таблицы.