|
|
|
Время обработки данных по сети
|
|||
|---|---|---|---|
|
#18+
Есть приложение, которое производит определенный расчет. Если оно установлено локально - расчет занимает примерно 1 минуту, но если запускать по сети, то может считать и до часа. Код для расчета содержит replace-ы, scan-ы, select-ы. Может кто то может объяснить механику работы выше описанных команд в сетевом режиме, почему так долго считает? Возможно, например, сетевой запрос при scan или replace делается для каждой записи? (а не буферизирует таблицу и работает уже с ней. Отсюда и задержки). Это чисто предположение, объясните, если кто в теме. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.03.2018, 11:46 |
|
||
|
Время обработки данных по сети
|
|||
|---|---|---|---|
|
#18+
faustgreen, перелопачивание данных, лежащих в сети, всегда медленнее, чем на локальном диске. Ибо сеть медленнее дисков. И не надо придумывать про сетевые запросы для каждой записи и прочую чушь. Используйте для временных таблиц/курсоров папочку на локальном диске и должно резко полегчать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.03.2018, 11:50 |
|
||
|
Время обработки данных по сети
|
|||
|---|---|---|---|
|
#18+
Sergey SizovИбо сеть медленнее дисков. Сеть разная бывает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.03.2018, 11:55 |
|
||
|
Время обработки данных по сети
|
|||
|---|---|---|---|
|
#18+
Alibek B.Sergey SizovИбо сеть медленнее дисков. Сеть разная бывает.Спасибо за открытие мне глаз. И как я раньше этого не знал?! Осталось выяснить какое практическое отношение это имеет к изначальному вопросу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.03.2018, 11:58 |
|
||
|
Время обработки данных по сети
|
|||
|---|---|---|---|
|
#18+
faustgreenЕсть приложение, которое производит определенный расчет. Если оно установлено локально - расчет занимает примерно 1 минуту, но если запускать по сети, то может считать и до часа. Код для расчета содержит replace-ы, scan-ы, select-ы. Может кто то может объяснить механику работы выше описанных команд в сетевом режиме, почему так долго считает? Возможно, например, сетевой запрос при scan или replace делается для каждой записи? (а не буферизирует таблицу и работает уже с ней. Отсюда и задержки). Это чисто предположение, объясните, если кто в теме. Сеть это тормоз: если несколько прог открыли один и тот же файл, то при каждом обращении происходит чтение по сети. Причем скорость в разы ниже чем макс.пропускная способность сети. Если не путаю 100 Мбитная сеть отдает данные со скоростью 1-2 Мбайта в секунду. В случае когда данные на локальном диске, то они дополнительно кэшируются в памяти, а это скорость доступа до 1-2 Гбайт/сек. Так что тормоз в 60 раз это еще хорошо. Советы для оптимизации выше дали 21267238 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.03.2018, 13:54 |
|
||
|
Время обработки данных по сети
|
|||
|---|---|---|---|
|
#18+
Dima TЕсли не путаю 100 Мбитная сеть отдает данные со скоростью 1-2 Мбайта в секунду. Это какие-то странные фантазии. Сеть это просто транспорт, ничего специально она не замедляет. Для TCP есть определенные нюансы, связанные с фрагментацией пакетов и подтверждением доставки, но при правильном использовании и TCP может утилизовать 90-95% емкости интерфейса. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.03.2018, 15:02 |
|
||
|
Время обработки данных по сети
|
|||
|---|---|---|---|
|
#18+
Alibek B.Dima TЕсли не путаю 100 Мбитная сеть отдает данные со скоростью 1-2 Мбайта в секунду. Это какие-то странные фантазии. Сеть это просто транспорт, ничего специально она не замедляет. Для TCP есть определенные нюансы, связанные с фрагментацией пакетов и подтверждением доставки, но при правильном использовании и TCP может утилизовать 90-95% емкости интерфейса. Речь не о TCP, оно почти 11 Мб/сек дает в сети 100 Мбит, близкая скорость при монопольном доступе по сети. Речь об организации виндой расшаренного доступа к файлу, когда несколько процессов вместе файл используют. Проверяется элементарно, замерить время: Код: sql 1. где BigTable на другом компе и фокс на клиенте дважды запустить, во второй копии достаточно просто открытой таблицу держать Код: sql 1. PS Я давненько тестил, на XP у меня замедление было почти в 10 раз. Может на более свежих виндовсах по-другому. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.03.2018, 15:14 |
|
||
|
Время обработки данных по сети
|
|||
|---|---|---|---|
|
#18+
Alibek B.Сеть это просто транспорт, ничего специально она не замедляет.Разумеется. Просто она сама медленно работает.Для TCP есть определенные нюансы, связанные с фрагментацией пакетов и подтверждением доставки, но при правильном использовании и TCP может утилизовать 90-95% емкости интерфейса.И при чем тут TCP? То есть самый верхний уровень транспорта. Если речь о скорости работы физического канала по технологии Ethernet, то есть самого нижнего уровня транспорта? На котором вся пропускная способность делится на всех пользователей, а не дается каждому те же 100 Мбит. Вы в курсе, что Ethernet сам по себе НЕ гарантирует СКОРОСТЬ передачи? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.03.2018, 15:40 |
|
||
|
Время обработки данных по сети
|
|||
|---|---|---|---|
|
#18+
[quot Sergey Sizov]Просто она сама медленно работает.[quot] Сочувствую. У меня быстро. Sergey SizovИ при чем тут TCP? Я написал, при чем. В TCP есть особенности, ограничивающую верхнюю границу пропускной способности (которая зависит от размера пакетов и времени отклика), но при правильном использовании это почти не мешает. Sergey Sizovто есть самого нижнего уровня транспорта? TCP это четвертый уровень. Под ним есть еще три. Ethernet это тоже не нижний уровень, а второй. Sergey SizovНа котором вся пропускная способность делится на всех пользователей, а не дается каждому те же 100 Мбит. Сочувствую. В остальном мире концентраторы (хабы) не используют уже лет 10, каждый пользователь подключается в отдельный порт коммутатора . А современный коммутатор, в свою очередь, способен коммутировать пакеты на wirespeed (причем речь не о дорогих устройствах, а вполне себе офисных мыльницах). Ну и нужно постараться, чтобы последние года три в офисной сети увидеть коммутатор на 100 Мбит/с, а не гигабитный. Sergey SizovВы в курсе, что Ethernet сам по себе НЕ гарантирует СКОРОСТЬ передачи? А это к чему? Шина SATA гарантирует, что-ли? Объяснить, что значит «шина»? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.03.2018, 16:07 |
|
||
|
Время обработки данных по сети
|
|||
|---|---|---|---|
|
#18+
Dima TPS Я давненько тестил, на XP у меня замедление было почти в 10 раз. Может на более свежих виндовсах по-другому. Затестил, оба компа Win10, на сервере гигабитный порт, клиент 100 Мбит. Сеть не загружена. Код теста Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Тест 1. BigTable.dbf никем не открыт. Результат Код: plaintext 1. Тест 2. Запускаем еще один фокс, и там следующий код Код: sql 1. 2. Результат: Код: plaintext 1. Просадка скорости втрое только потому что файл открыт несколькими процессами. PS Размер файла 64 Мб, скорость 64 / 5.8 = 11 Мб/сек. т.е. максимум для 100 Мбит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.03.2018, 16:40 |
|
||
|
Время обработки данных по сети
|
|||
|---|---|---|---|
|
#18+
AFAIK Скорость мерится как минимум двумя параметрами: throunginput - пропускная способность и latency - задержка при получении ответа на запрос (round-trip) Если throunginput "на бумаге" у современных сетей уже даже превышает througinput жестких дисков. То с latency у Ethernet все достаточно плохо. Разница latency доступа к кэшу в оперативной памяти и latency доступа по сети - может отличаться на ПОРЯДКИ (сотни, тысячи, десятки тысяч раз). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.03.2018, 15:06 |
|
||
|
Время обработки данных по сети
|
|||
|---|---|---|---|
|
#18+
Leonid KudryavtsevТо с latency у Ethernet все достаточно плохо. Если ничего не делать, то плохо. Но есть jumbo-frame, есть коммутаторы cut-through со сверхнизкой задержкой. Так что правильный iSCSI мало чем уступает FC или SAS. Вот только в FC или SAS верхняя граница 12-16 Гбит/с, а для сети 40 Гбит/с уже вполне доступно для среднего бизнеса. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.03.2018, 15:13 |
|
||
|
Время обработки данных по сети
|
|||
|---|---|---|---|
|
#18+
Чем jumbo-frame поможет latency? Jumbo-frame как раз повысит througthinput, больше данных в одном пакете, но на latency не скажется На коммутаторы тоже пофиг. Сетевой карты с "interrupt moderated" (не помню как точно опция в настройках карты называется) и планировщика потоков Windows вполне достаточно ))) Если приложение так написано, что сверх чувствительно к задержкам, то никакой коммутатор и настройка сети не спасет. Ну в 2-3 раза latency может снизить и удастся (и то не факт), но это будет "мертвому припарка". Только менять алгоритм или какие-то другие софтверные решения. Но об этом уже во втором сообщение и сказали. Можно конечно заменить Ethernet на Melanox InfiniBand, где намного больше возможностей поиграться с латенси, или прямое соединение машин через PCI-E коммутатор (на данном форуме предлагали, на форуме разработчики есть).... но мне кажется, автора топика такое предложение вряд ли обрадует ))) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.03.2018, 17:32 |
|
||
|
Время обработки данных по сети
|
|||
|---|---|---|---|
|
#18+
Alibek B.Так что правильный iSCSI мало чем уступает FC или SAS. Вот только в FC или SAS верхняя граница 12-16 Гбит/с, а для сети 40 Гбит/с уже вполне доступно для среднего бизнеса. Ну и подозреваю, что автор под словами "запускать по сети" имел в виду не iSCSI, а обычный file sharing. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.03.2018, 17:34 |
|
||
|
Время обработки данных по сети
|
|||
|---|---|---|---|
|
#18+
faustgreen...Может кто то может объяснить ... Может быть Вам просто надо решить проблему - сократить время ожидания Ваших клиентов? В таком случе Вам надо просто изменть подход - удалённый доступ на компьютер, где локально будут производится вычисления, web services или вообще всё перевести на MS SQL Server или Oracle... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2018, 10:16 |
|
||
|
|
start [/forum/topic.php?fid=41&fpage=11&tid=1581809]: |
0ms |
get settings: |
12ms |
get forum list: |
16ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
28ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
57ms |
get tp. blocked users: |
2ms |
| others: | 277ms |
| total: | 416ms |
| 0 / 0 |
