Есть подозрение, что админ домена что-то намудрил, т.к. 1С у всех (примерно 50 юзеров) стала работать почти в 2 раза медленнее.
например делаю с клиентского компа запрос такой
ping -l 65000 ИмяСервера1С
выдает время доступа = 11 мс

это много или нормально ?

и как еще проверить можно ???
спасибо

а сколько шлюзов до сервера?
tracert сколько компов показывает?
---
не админ, но имхо все что больше 5 мс - зло

по моему на полном пакете 11 мс очень хорошо

ping 192.168.0.1
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
64 bytes from 192.168.0.1: icmp_seq=1 ttl=128 time=0.185 ms
64 bytes from 192.168.0.1: icmp_seq=2 ttl=128 time=0.208 ms
64 bytes from 192.168.0.1: icmp_seq=3 ttl=128 time=0.289 ms

если это скуль, то счетчик нетворкио

можно вот этим затестить http://www.infostart.ru/public/16681/

(0)нормально для 100

(1)ты на размер пакета глянь ...

либо жОско тупит сервак, либо флуд по сетке идет

(5) а, ну тогда
ping -s65000 192.168.0.1
PING 192.168.0.1 (192.168.0.1) 65000(65028) bytes of data.
65008 bytes from 192.168.0.1: icmp_seq=1 ttl=128 time=1.59 ms
65008 bytes from 192.168.0.1: icmp_seq=2 ttl=128 time=1.64 ms
65008 bytes from 192.168.0.1: icmp_seq=3 ttl=128 time=1.56 ms
65008 bytes from 192.168.0.1: icmp_seq=4 ttl=128 time=1.69 ms

(5) а я не знаю что это такое )))
проверил на своих - 1 мс

правда гигабитка

(3)по дефолту пакет всего 32 байт ...

(10) что есть «по дефолту»? написано же - 56 байт данных (84 всего)

(8)параметр -l задает размер дайтограммы ... по дефолту он равен всего 32 байтам ... здесь протаскивают 65000 байт

(12) => (7)

(1) еще 1 промежуточный

(9) со всех клиентских компов гигабитка ?

(12) да и внимательнее (11) читай

Ключ –l задает размер дейтаграммы без учета длины заголовка (28 байт), посылаемой в эхо-запросе. Допустимыми являются значения от 0 до 65.500, включительно. По умолчанию размер дейтаграммы составляет 32 байта. Манипулируя этим значением, можно выяснить зависимость: скорость доставки – размер дейтаграммы. Если размер дейтаграммы превысит некоторую критическую величину (определяемую каждым промежуточным узлом самостоятельно), дейтаграмма разрезается на несколько пакетов подходящего размера, каждый из которых добирается до конечной точки маршрута самостоятельно, а на узле назначения они вновь собираются в исходную дейтаграмму.

(16) и чО?
      -s packetsize
             Specifies the number of data bytes to be sent.  The default is 56, which translates into 64 ICMP data bytes when combined with
             the 8 bytes of ICMP header data.

все равно 1,5мс при 65028 байт

(14) не, тока на моем и между серваками )

(19) аааа! вот жук!
а с обычного клиента не глянешь ?

(17)внематочно прочитай (0) ... в стандартной винде и стандартном пинге параметр -s отвечает за другое

-l size        Send buffer size.
-s count       Timestamp for count hops (IPv4-only).

поэтому при ping -s65000 получаем
Value must be supplied for option -s65000.

ping -s 6500
Bad value for option -s, valid range is from 1 to 4.

(21) а кто тебе сказал, что у меня стандартная винда? я с линуксового хоста до скуль-сервера, на котором базы 1сные крутятся пинганул, у меня через 2 свича - за 1,5мс пролетает 65000 байт туда-сюда. значит, у (0) - либо с реакцией сервера, либо с временем прохода пакета по сети уже есть проблема.

(23)на время прохождения пакета влияет толщина канала и размер пакета... для канала толщиной в сотку пакет размером 65000 это допустимо...

А у нас стандартная win server 2003 64 бит SP2
сетка 100 мегабит

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

Pinging head.bps.com [192.168.1.3] with 32 bytes of data:

Reply from 192.168.1.3: bytes=32 time<1ms TTL=128
Reply from 192.168.1.3: bytes=32 time<1ms TTL=128
Reply from 192.168.1.3: bytes=32 time<1ms TTL=128
Reply from 192.168.1.3: bytes=32 time<1ms TTL=128

-----
Pinging head.bps.com [192.168.1.3] with 65000 bytes of data:

Reply from 192.168.1.3: bytes=65000 time=12ms TTL=128
Reply from 192.168.1.3: bytes=65000 time=12ms TTL=128
Reply from 192.168.1.3: bytes=65000 time=12ms TTL=128
Reply from 192.168.1.3: bytes=65000 time=12ms TTL=128

(25)значит проблема не в сети... а скорее всего на сервере

(27) т.е. 11-12 мс - это номально ?

(28) счас найду 100мбитку по удаленным сетям, гляну

(30)+ так навскидку - нигде нету уже

(28) процессор сервера приложений 1С загружен не более чем на 6-10%
SQL так же 6-10%

(32) дисковая?

(30) зачем в терминале гигабит? у вас сотни компов?

(33) а что и где посмотреть ?

(29)нормально

(29) у меня такой пакет проходит за 2ms, дефолтный - >1ms, правда на гигабите :)

(35) монитор производительности, добавляем счетчик "средняя длина очереди диска", можно добавить "на запись", "на чтение" и цифры сюда (под нагрузкой, конечно)

Прочел

"Как определить скорость СВЕТА до сервера 1С ?"

+38 ну и чисто из вежливости: конфиг обоих серверов, есть ли raid (тогда какой), объем баз(ы), число юзеров...

(39) :))

(0) как и все это делают:
1. пишешь в "Выполнить":
net send server hello world!
2. одновременно нажимаешь на кнопку секундомера и Enter на клавиатуре
3. Ломишься к северу
4. Как у видишь окошко "hello world!" останавливаешь секундомер

ps: сервис службы сообщений должен быть включен, а то я так неделю стоял у сервера с екундомером

(40) сервера НР
1C: 2.6 Ггц, 2 процессорный (по 4 ядра) память 4 Гб .....RAID есть, но какой не могу точно сказать
SQL: 3 Ггц, 2 процессорный (по 2 ядра) память 18 Гб

число юзеров (ок 60 чел)

в серверах ничего не менялось!!

(42) отличный вариант :)))
напомнило из реальности:
вызывают, просят разобраться с печатью документов (принтер обычный, без дуплекса, примитивный струйник)
показывают проблему:
- смотрите, вот я посылаю два листа, принтер печатает один (в этот момент подырвается из-за стола и бежит к принтеру) - видите? я еле успеваю добежать, а мне еще лист перевернуть надо!
- зачем?
- так мне на обеих сторонах надо напечатать, а я не успеваю перевернуть!!!
- <немая сцена>
через неделю буха уволили. просто она и учет так же вела. своеобразно т.е.
(44) вот raid какой - интересно таки, ну и дисковую очередь померяй - увидим, что там у вас.
кстати, а размер лога транзакций не является слишком большим? а то подобное уже было, люди дорастили (при живом штатном админе) лог до 20 гиг (база - 3) и жаловались на тормоза потом :)

(43) т.е. это не юмор?
звиздец...

(45) 3 боевые базы:
Основная 38 Гб (лог 37 Гб)
2я - 3 Гб (лог 0.5 Гб)
3я - 3 Гб (лог 0.7 Гб)
Базы на логическом диске Д, логи на Е

Почему-то тему ветки прочёл как "Как определить скорость света до сервера 1С "... Хм...

(47) ну база основная немаленькая...
давай мерять диски перфмоном, пока думаю на них.
сразу ошибки: если логический диск - виндовый - это смысла не имеет, а вот если LUN - т.е. логический диск, созднный средствами аппаратного raid-контроллера - тогда другое дело. т.е. разбивка д.б. на уровне контроллера, не винды.
давай показания и мы все увидим, вслепую не получится

(0) скачай iperf