Господа, что-то я совсем запарился в поисках возможности с эмулировать работу сети на 1 локальном ПК. Нужна возможность настройки этой "сети" по по пропускной способности. Очень желательно без доп. затрат на железо (типа "купи 2 сетевые карточки...").

2 mahoune
>Если тебя нагрузка на сеть беспокоит

Не нагрузка меня беспокоит, а выявление "узких" мест при работе клиента в сети.
Просто, когда разработка ведется на локале все летает, время выполнения какие-то милисекунды, у клиента на действующей сети - уже на пару порядков больше. Проверять и отлаживать на "клиенте" нет возможности .
Вот и хотелось поставить у себя нечто, ограничивающее обмен данными с "сервером" n Мб в секунду. И посмотреть как будет вести себя "клиент" при 1 при 2 при 3 при... Мб в секунду. Прекрасно понимаю, что любое решение не дасть 100% эмуляции сети со всеми ее примбабасами, затырками и глюками, но все же приятно знать,например, за сколько секунд/долей секунуд заполниться какой-нить журнал при разной пропускной способностью. И исходя из полученных цифири можно делать вывод о целесообразности дальнейшей оптимизации различных объектов.
К тому же появиться возможность испытать прогу при одновременном доступе к "серверу" n-го кол-ва пользователей для выявления возможных проблем.

>Все расчетами постигается. Говорю - посмотри, сколько и каких данных уходит с клиента на сервер, а главное обратно. Прикинь сколько пользователей будет.


Я не зря слово "сервер" в кавычки взял. Например, mdb+mde. Какие тут могут быть "сколько и каких данных уходит с клиента на сервер" - ответ будет - всё.
А как заценить потуги Акеса на прорисовку формы из нескольких десятков полей со списками+ подчиненая форма+...+...
Элементарный просмотр счетчиков в конкретном примере дает при числе записей в главной таблице 10 штук трафик на открытие формы в 5 мб. Делаем вывод, что при работе в сети 100Мб и ее реальной пропускной способностью 4-6Мб в секунды, форма откроется за 1 - 1,1 сенукды. Хрен она в реальной жизни так откроется. 2-3-4 секнуды, а то и более.

Самый оптимальный вариант: найти способ на локальном ПК эмулировать сеть, а еще лучше что бы была возможность эмулирования работы на разном железе.

2 Лоху Позорному и judge
>эмуляция сетки - флоповод :)
Ну или зип какой-нибудь...
>ну и кэш отрубить

Пробовал я уже с флопиком. Правда кэш не вырубал, но впечатление удручающее.
Нашел в анализируемой форме существенные тормоза на полях со списками у которых Автоподстановка=True. Поставил в False - все залетало - вместо 30 секунд открытия формы- 2 секунды. О как я был счястлив, радостно отправил исправленную версию заказчика и ... облом. НИ ХРЕНА НИ ЧЕГО НЕ ИЗМЕНИЛОСЬ . Как все медленно открывалось так и осталось. Я был морально(и скажу честно, и материально) разбит :(
ZIP - слишком дорого и боюсь повторения с флопиком
Единственное, если конечно не будет варианта с какой-либо прогой, установка двух дешевых сетевух, только как заставить Акес и ВиндосХП работаь через них я не еще не знаю.
А может через USB1.1? Два порта есть, найти шнурок, правда скорость слишком большая. Через COM? Но он у меня 1.

>А если флопповод - слишком мало и медленно, то RAID на 127 USB-флопповодах :)
Шутишь всё, а мне уже тошно.

Да я уже склоняюсь к этому.\r
Тут Циничный Кот в параллельном топике присоветовал (/topic/30414)\r
Но, блин, не уж то никто ничего не предумал для эмуляции.

А как быть с MS SQL?
Он сможет на старом ПК хранить базу и журнал?

Тут провел "мозновой штурм". Сам с собой.
Родилась идея.
Поставить Apache. Выделить директория по некий адрес www.SuperSet.ru
Поставить прогу типа BSB (Band Speed Balancer - ограничивает скорость Инета)
И подсоеденить базу по пути http://www.SuperSet.ru/db1.mdb. (а вообще такое возможно?). Или поставить IIS?
Благодаря BSB можно ограничить скорость, кол-во соединений.

Как такое? Прокатит? Если да, будем писать автору bsb.

p.s.
Все к тому же бесплатно.

Да нет. MS SQL будет жить на хорошем ПК. Дабы я с ума не сошел отожидания пока откроется QA или EM.
А базы и журналы только хранить на 486. Прокатит?

>Сковородой по яйцам? Оригинально-с
Ничего оригинально.
Сервер может хранить свои файлы где угодно. 2000, в т.ч. на неотформатированных разделах.

2 Лоху

>минутку .... какой такой сервер?

Что-то тебе сегодня колбасит.
Я же писал "2000, в т.ч. на неотформатированных разделах."
2000 это MS SQL2000, а ты про что?


>Здесь же форум для веб-дизайнеров.
Ну ты не прав, мы же теперь разбираемся, почему 256 цветов надо использовать и как

2 Лоху

А по теме поста у тебе что-нибудь есть или и дальше сам с собой будешь разговаривать?

До жив до своих лет, я понял одно - бывает все.

А проблемы (тут как-то был мой топик) с 1-ой формой с кучей полей со списками и прочей мутотенью. В чем причина я так и не понял (то ли акес глючит, то ли я, то ли у меня и у заказчика стоит та самая заплатка от микрософта, которая делает работу некоторых приложений раз в 10 медленее, то ли из-за защиты, то ли .... Решил (временно, пока не найду причину) просто всегда держать эту форму открытой (скрытой), тогда скрость ее появления нормальная (около 1-2 сек)

>Во время запроса Accessa скорость передачи ~100-200 кбайт/с

Ага и может либо падать до 0 либо взлетать до 3-3Мб. Не предсказуемо.


Меня чистый Акес при работе в сети ЗАДОЛБАЛ .

Поверте мне, я испробовал все способы оптимизации, описанные в хелпе, в MSDN (настройки Jet), книгах (Гетц и другие)
И спрашивать про дефрагментацию как и сжатие/восстановление для меня обидно. :(

2 Лоху Позорному

>Вспомнил, был топик. У тебя там кажется какие-то хитрые (большие) join'ы были?

Точно, только не джоины на запросе, а просто таблица связана с десятком других. Сам запрос ничего не джоинит.

>1. Запрос должен быть достаточно сложным, чтобы у аксеса съехала крыша.

Он у меня простой Select Поля From ОднаТаблица Where ID=Чему-то

>2. Таблицы должны быть прилинкованы через сеть. Подключение через сеть к себе же (через шару) - все нормально, летает.

Да, через сеть: //Server/Data/data.mdb

>3. (!!!) Запрос должнен быть хотя бы один раз сохранен в режиме SQL. Звучит полным бредом, но факт. Если запрос от момента рождения до момента смерти сохранялся в режиме конструктора - все летает. Запросы, создаваемые на лету - тормозят как сохраненные в SQL.

Одни авторы (вроде Гетц, но не уверен) предлагают открыть в режиме SQL добавить проблел, сохранить. И более его не трогать. Таким образом Jet перестроит план выполнения. Тогда получается, что лгут? Буду пробовать.

>4. В запросах используются ограничения на индексированные поля. Вернее, они-то как раз и не используются при выполнении запроса к связанным через сеть таблицам в случае сохранения в виде SQL

Надо будет посмотреть, как раз и индексов полно.

>и действительно, для сохраненных в SQL и в конструкторе планы отличаются.
Оху$ть, буду пороверять

> Для показа плана выполнения запроса надо в реестр какой-то ключ добавить, точно не помню но могу найти.

Да у меня это есть, Гетц подробно описывает, но не описывает как эту абракадабру расшифрововать, хотя Table scan виден как и Index
Надо будет пробовать

Спасибо за толчок в нужном(о, как я надеюсь на это!) направлении.

2 Владимир Смирнов

А настройки по пропускной способности там есть?

2 Лоху Позорному

Кол-во записей не проблема для анализа. Я недавно внес тестовые данные в прогу по 800 000 - 1 000 000 записей в таблицы. Прикольно - все шевелиться, на них и буду смотреть план.

2 alexkov

> Если правильно приложение слелано и не тормозит при одном подключении то не будет тормозить и при 5, 10, 30, и т.д.

Речь идет о файл-сервере (mdb+mdb). И ему по хрену, что ты в условии отобрал 1 запись из 100 000.Все равно притащит себе все 100 000 и тогда уж отберет 1.
Так что, чем больше записей тем тормазнутей становиться прога.
А сделать правильней можно только перейдя на клиент-серверную технологию, что в данном случае не обсуждается.

>Вот тебе и все тестирование.
Ну тогда наладь мне такое тестирование у меня дома (за твой счет, разумеется). Согласен на 3 ПК, 1 свитч, и кабель 5-ой категории.

2 Лоху

А ты попробуй выбрать из 100 000 записей 1 по PrimaryKey и посмотри, сколько Акес тебе через сеть тянет. 1 индекс несколько мегабайт весить не может