Как быстро скопировать 500 маленьких файлов

← →
lessard (2006-09-06 10:46) [0]

Есть 500-600 файлов по 5-6 Кбайт каждый. Как ОЧЕНЬ БЫСТРО скопировать эти файлы в другое место? PS: Место - в сети.... и занимает эта процедура 5-10 сек., надо меньше...

← →
Skyle © (2006-09-06 10:52) [1]

А сколько времени занимает их заархивировать?

← →
lessard (2006-09-06 10:59) [2]

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

← →
evvcom © (2006-09-06 11:06) [3]

> [2] lessard (06.09.06 10:59)

А в чем проблемы с программной архивацией?

← →
lessard (2006-09-06 11:09) [4]

2evvcom
предложения методики? стандартным средствам, простите, не обучен - rar архивировать зараза не хочет, zip-компонентами пользоваться я не умею. Ещё варианты?

← →
Skyle © (2006-09-06 11:10) [5]

> 4] lessard (06.09.06 11:09)
> 2evvcom
> предложения методики? стандартным средствам, простите, не
> обучен - rar архивировать зараза не хочет, zip-компонентами
> пользоваться я не умею. Ещё варианты?

что значит "не хочет"?

← →
PSPF2003 © (2006-09-06 11:12) [6]

> что значит "не хочет"?

Производная от не умею

← →
lessard (2006-09-06 11:13) [7]

Удалено модератором

← →
evvcom © (2006-09-06 11:13) [8]

> [4] lessard (06.09.06 11:09)

> простите, не обучен

← →
evvcom © (2006-09-06 11:14) [9]

> [8] evvcom © (06.09.06 11:13)

> Ещё варианты?

Обучиться.

← →
Плохиш © (2006-09-06 11:14) [10]

> и занимает эта процедура 5-10 сек., надо меньше

А что винчестеры уже мгновенно данные находят и отдают?
> lessard (06.09.06 11:09) [4]
> стандартным средствам, простите, не обучен

Ты забыл добавить, что сами вы не местные.

> rar архивировать зараза не хочет

Что, так и говорит "не хочу"?

PS. И для кого же конференцию "Начинающим" создали?

← →
lessard (2006-09-06 11:14) [11]

Удалено модератором

← →
PSPF2003 © (2006-09-06 11:18) [12]

Удалено модератором

← →
Плохиш © (2006-09-06 11:19) [13]

> lessard (06.09.06 11:14) [11]

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

← →
evvcom © (2006-09-06 11:23) [14]

> [7] lessard (06.09.06 11:13)

А... Вот почему не хочет! Так тебе ж по-русски пишет рар "Зарегистрируйтесь!" Или ты думаешь тебе сейчас здесь начнут объяснять, как надо рар сломать?

← →
Skyle © (2006-09-06 11:26) [15]

Опиши задачу.
Теперь получается, что нужно тянуть с сетевого диска, а не толкать в сеть, а это принципиально другое.

← →
Elen © (2006-09-06 11:28) [16]

> lessard

BlockRead,BlockWrite вроде самые быстрые. Но это еще от сети зависит

← →
StriderMan © (2006-09-06 11:36) [17]

> Elen © (06.09.06 11:28) [16]
> BlockRead,BlockWrite вроде самые быстрые. Но это еще от
> сети зависит

CopyFile самый быстрый. Быстрее ось не умеет по определению.

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

← →
lessard (2006-09-06 11:40) [18]

Всем:

Задача: readfrom LAN -> writeto LOCAL -> обработка/изменение/ -> writeto LAN -> readfrom LAN ...и так далее.

Blockread/blockwrite не превнесли особого ускорения. разница в 0,1283 секунды по сравнению с просто copyfile. Тут непонятно - 1,55 гб файл скопировался за 16 секунд...

← →
Skyle © (2006-09-06 11:49) [19]

> Blockread/blockwrite не превнесли особого ускорения

А какой размер блока?

← →
lessard (2006-09-06 11:53) [20]

10, 20 и 50 кбайт в зависимости от формата файла

← →
Skyle © (2006-09-06 12:10) [21]

А я бы попробовал по 4 кб или кратно.

сколько времени занимает скопировать это локально?

← →
lessard (2006-09-06 12:13) [22]

локально - 10-12 секунд, если пользоваться виндовыми методами
а я и говорю что кратно файлы там есть сйечас от 4 до 200 кбайт, так большие быстрее копируются...

← →
StriderMan © (2006-09-06 12:16) [23]

> Задача: readfrom LAN -> writeto LOCAL -> обработка/изменение/
> -> writeto LAN -> readfrom LAN ...и так далее.

мне кажется тут так и напрашивается поместить твою прогу на ту машину где файлики лежат.

← →
DiamondShark © (2006-09-06 12:16) [24]

> так большие быстрее копируются...

не быстрее.
у них просто отношение (накладные расходы)/(копирование тела) меньше.
Что естественно, т.к. для открытия сетевого файла надо надо довольно много подёргаться.

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

← →
Skyle © (2006-09-06 12:16) [25]

Логично, что большие копируются быстрее.
Теперь нужно либо распараллелить копирование, либо сделать из них один файл.. Других вариантов как-то нету.

← →
dwar © (2006-09-06 12:16) [26]

> Есть 500-600 файлов по 5-6 Кбайт каждый

Примерно 3 гига информации 5-10 секунд помоему неплохой результат

← →
Плохиш © (2006-09-06 12:18) [27]

> lessard (06.09.06 12:13) [22]

> так большие быстрее копируются

Ну об этом в любой книжке по компьютерам в разделе о работе дисков написано. Головкам не нужно постоянно искать на всём диске требуемое место, да ещё на таблицу раделов/файлов скакать.

← →
lessard (2006-09-06 12:19) [28]

StriderMan, клиент-бд стоит у 50 человек в зале. не катит. в новой версии сделаю TCP-обмен. думаю будет лучше.

Skyle, распаралелить в смысле? А сделать файл... была такая идея, даже пробовал ZLib, да не сложилась. Есть ещё варинты?

← →
dwar © (2006-09-06 12:20) [29]

> Теперь нужно либо распараллелить копирование, либо сделать
> из них один файл..

не думаю что слив в один файл а потом разбор его на 600 мелких +сохранение займет менше времени, та же лошадь только в порфиль

← →
DiamondShark © (2006-09-06 12:22) [30]

> Головкам не нужно

Это не в ту степь.
Самый тормозной винт на порядки быстрее самой быстрой сети.

← →
Skyle © (2006-09-06 12:26) [31]

Качественный скачок даст качественно иное решение ;-)
1. как уже сказали, исключить из процесса сеть
2. разнести копирование и обработку по времени (пусть копируется и обрабатывается не пачкой, а непрерывно)
3. купить EVA-3000 и FiberChannel и поиметь гигабит и общий диск :)

← →
lessard (2006-09-06 12:28) [32]

DiamondShark, угу.

Стоит ли рассматривать как вариант TCP-транспорт такого типа:

>connect 192.168.0.1 3928
+OK Login, please
>user root
+OK Enter password
>pass password
+OK Logged in, welcome

и потом:

>query dblist.dxf id 1
+OK Transferring started...
sdQ3H50E9HDSKJ3LJBRTELRFB23[RIJEWOFZKLERGBN <-- типа ReadStream

>write dblist.dxf id 1
+OK Enter data for write...
sdjkhljkw345whlferptf23jkr5hlfzelfgdgjdflg23rlsjrdljfkd
+OK Save success

>exit
+OK Bye

← →
lessard (2006-09-06 12:29) [33]

В смысле, будет ли это быстрее?

← →
lessard (2006-09-06 12:30) [34]

Skyle, сеть не получится. Как я тебе буду обрабатывать запросы от кучи пользователей?

← →
Skyle © (2006-09-06 12:36) [35]

Тогда ещё вариант:
ставишь везде NTFS, на той машине, с которой данные надо забирать всё собираешь в один многопоточный файл, потом этот файл копируешь, на своей машине читаешь прямо из потоков, также копируешь обратно, разбираешь :)

← →
Skyle © (2006-09-06 12:37) [36]

> [34] lessard (06.09.06 12:30)
> Skyle, сеть не получится. Как я тебе буду обрабатывать запросы
> от кучи пользователей?

А эту обработку на машине пользователя сделать никак нельзя?
Для обработки тоже требуются данные такого же уровня срочности?

← →
StriderMan © (2006-09-06 12:41) [37]

> DiamondShark © (06.09.06 12:22) [30]
> Самый тормозной винт на порядки быстрее самой быстрой сети.

вот это сомнительно

гигабитный LAN прокачивает за секунду 128 мегабайт. далеко не всякий винт на такое способен.

← →
lessard (2006-09-06 12:43) [38]

Skyle, не в том дело
файлы физически должны лежать в одном месте, а то получится, что один предприятие изменил, сохранить не успел, а другой изменил и сохранил...

← →
Skyle © (2006-09-06 12:46) [39]

> Как ОЧЕНЬ БЫСТРО скопировать эти файлы в другое место

> файлы физически должны лежать в одном месте

Как-то не коррелируется :(

← →
Плохиш © (2006-09-06 12:48) [40]

> DiamondShark © (06.09.06 12:22) [30]
>
> > Головкам не нужно
>
> Это не в ту степь.

В [21] и [22] про сети ничего не говориться, а уточняется как раз другое. Так что сами Вы степью ошиблись.

← →
lessard (2006-09-06 12:49) [41]

Объяснял же... у меня при запуске СУБД создаётся локальная копия профиля пользователя (т.к. если рабоают в базе все, тормоза дикие). А при изменении/нажатии "сохранить" это переписывается обратно, сверяясь с текущими изменениями оригинальных файлов. Я вот только не подумал - может не копировать те файлы, которые не были изменены? Или же получение exist/date/time тоже существенно замедлит работу?

← →
lessard (2006-09-06 12:51) [42]

Плохиш, DiamondShark, ребят, мы тут тему обсуждаем... не про скорость работы, явно...

← →
Skyle © (2006-09-06 12:55) [43]

Уменьшение количества файлов явно пойдёт на пользу.
Получение времени файла, Exists и прочее явно будет не медленнее его копирования.

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

А ты уменьшением времени копирования пытаешься изобразить транзакцию, я правильно понимаю?

← →
lessard (2006-09-06 12:57) [44]

Корче получается так: когда юзер загружает базу, файлы формата *.job и *.dxf (двоичные для заданий/записей о выполнении) копируются в папку %APPATH%\cache\*.job и *.dxf соответственно. Когда юзер нажимает сохранить, файлы *.job едут обратно, *.dxf копируются только после завершения сеанса, т.к. всё равно ещё будут изменяться. Я не имею опыта работы с БД, к сожалению...

← →
Skyle © (2006-09-06 13:03) [45]

> не имею опыта работы с БД, к сожалению...

Я с такой тоже уже не имею

Как там по скорости получилась идея с выборочным копированием?

← →
lessard (2006-09-06 13:04) [46]

Я вот правда подумывал как бы сделать из всех job"ов один файл, но запутался с заголовками - они все разного размера и непонятно, как писать и куда писать...как вариант было сделать ещё файл jobs.idx в котором эти индексы и записывать, но почему-то Database.Seek(10, 0) не даёт нужного рез-та, пишется в конец файла после последней записи...

> lessard (06.09.06 12:51) [42]
> Плохиш, DiamondShark, ребят, мы тут тему обсуждаем... не
> про скорость работы, явно

Странная ветка, однако, говорят про одно, а обсуждают другое.

> lessard (06.09.06 12:57) [44]
> Корче получается так

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

← →
lessard (2006-09-06 13:05) [48]

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

Выборочное копирование по 4 байта за раз получилось на 0,239 сек. меньше, чем полное...

← →
lessard (2006-09-06 13:06) [49]

Плохиш, это не обсуждается в плане невозможности технического осуществления да и не нужно оно нам, пока менеджеров 50 человек...

> [48] lessard (06.09.06 13:05)
> Skyle а это и не биде. это грубая поделка одного из наших
> прогаммеров-экстремалов, плоды чьего творчества я сейчас
> пожинаю - это была его идея.

Сочуствую.

> Выборочное копирование по 4 байта за раз получилось на 0,239
> сек. меньше, чем полное...

Именно байта? Не Кб?

← →
lessard (2006-09-06 13:13) [51]

фу
Кбайта
заописался уже :(

Ну похоже что тупо упираемся в сеть.

А намного меньше стало файлов копироваться?

← →
lessard (2006-09-06 13:40) [53]

Skyle, да, сеть тут попа настоящая :(
52-100 файлов за раз получается. пока не проверял особо, манагеры халявничают.

Нет, а самый тупой вариант не работает чтоли?

"собрать у клиента все изменения в каком-то своём формате", дать клиенту работать дальше, как-нибудь перекинуть эти изменения на сервер, применить, вернуть ответ.

Собственная такая вот реализация транзакций ;-)

← →
lessard (2006-09-06 13:42) [55]

В ответ на ваш последний пост, коллэга, хочю добаветь, што...
а по русски можно? я программист начинающий, неопытный, с сетями дела не имел... :-[

Это не сети, это базы.

Я предлагал отправлять не все файлы на сервер и даже не изменённые файлы, а непосредственно сами изменения. То есть грубо изменённые строки или даже поля.

Правда в зависимости от конкретных реалий эта задача может (и скорее всего должна) стать неподъёмной.

← →
lessard (2006-09-06 14:05) [57]

Дело в том, что в данном случе используется packed record и я как вариант вижу только отправку на сервер обработки куска файла с данными именно этой записи, последующей обработки и тд... но по сути это то же что есть сейчас - просто использую seek...

А поставить на сервер какой-нибудь сервер терминалов и свести задачу к локальному копированию не получится? ;-)

Хотя 50 юзеров этот сервер разорвут....

← →
lessard (2006-09-06 14:12) [59]

Как понять к локальному копированию? М.. извиняюсь за тупость:)

Да я просто предложил перевести менеджеров на работу в терминале (который удалённый рабочий стол).
Тогда фактически они все будут работать на том самом компьютере который сервер. И эти самые кэши будут работать точно также, только вот для их копирования не требуется передача по сети, потому что всё в рамках одного компа...

← →
lessard (2006-09-06 14:26) [61]

А, ты об этом... знаешь, была идея с rdp (если ты про ето)....как-то не срослось... да и в техническом плане это кажись дешевле...

Ага, именно rdp... Citrix не предлагаю, дорого.

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

← →
lessard (2006-09-06 14:32) [63]

да собственно по этой теме я сюда и обращался...
хотя... может быть если ты посмотришь код, ты сможешь предложить что-то ещё? :-[

> [63] lessard (06.09.06 14:32)
> да собственно по этой теме я сюда и обращался...
> хотя... может быть если ты посмотришь код, ты сможешь предложить
> что-то ещё? :-[

Можно попробовать.

← →
lessard (2006-09-06 14:39) [65]

стукни в асю 269379191

Как быстро скопировать 500 маленьких файлов Найти похожие ветки