Скорость обработки данных

Sovnarkom · 29.09.2010, 01:42

Вот есть тарифный калькулятор, который подсасывает данные из базы 1С, на 180'000 объектов. Делает, само собой, не особо шустро (паузы от 1 до 3 секунд).
Думаю переписать его на флеш со всякими красивостями и фичами, в связи с чем встает вопрос: рационально ли это? Не будет ли таких же задержек в обработке данных?

Насколько я знаю, напрямую с БД флеш работать не умеет, поэтому планируется разбить это огромную базу хотя бы частей на 100 и для каждой части сделать свой xml файл, который уже и парсить на предмет вводимых пользователем населенных пунктов.

Либо пойти какой-то другой дорогой? Буду благодарен любому совету.

gloomyBrain · 29.09.2010, 01:52

Может, проще сделать небольшой PHP скрипт, который бы делал выборку необходимой части данных, преобразовывал в JSON и отдавал флешке?
Формат JSON предлагаю по тому, что в пыхе он нативно поддерживается, а в AS3 под него есть удобный пакет в составе as3corelib
По поводу задержек - можете тем же скриптом отдавать в неком своем формате , который можно будет парсить по частям (или тот же JSON, только загруженный как несколько дискретных кусков данных). И парсить, например, одну часть за один кадр. Таким образом, можно сделать отображение процесса чтения данных. Соответственно, задержка будет выглядеть как плавный процесс.

Sovnarkom · 29.09.2010, 02:12

Хм. Ну как вариант.

Вообще дело в том, что базу 1С в хмл выгрузить, скажем, раз в сутки — не проблема. Так что можно и xml - обработать его флешем довольно просто.

Вопрос пока что в другом: будет ли XML/JSON файл на пару тысяч записей с параметрами достаточно быстро обрабатываться? Я понимаю, что можно сделать эту задержку красивой, чтоб пользователь не напрягался, но хотелось бы ее минимизировать по максимуму.

gloomyBrain · 29.09.2010, 03:55

Цитата:

будет ли XML/JSON файл на пару тысяч записей с параметрами достаточно быстро обрабатываться?

Вряд ли. Тем более, что на этой задаче программа, написанная не на AS3, подвисает на 3 секунды. Поэтому я и предложил грузить по кусочкам и парсить каждый кусочек отдельно для "размазывания" нагрузки по времени. В любом случае, что мешает попробовать и так и эдак? А уж как именно минимизировать нагрузку - тут решать только Вам =)

iillyyaa · 29.09.2010, 04:02

ты бы написал, что делает твой "тарифный калькулятор" в двух словах...
зачем ему все эти 180.000 записей ?

где и как он запускается..

Sovnarkom · 29.09.2010, 20:13

gloomyBrain: спасибо! ) Будем пробовать

iillyyaa: калькулятор расчитывает стоимость доставки грузов в зависимости от нескольких параметров: вес, расстояние, габариты и скорость доставки.
180'000 записей - это населененные пункты, каждый из которых относится либо к определенной зоне, либо имеет коэффициент для расчета стоимости доставки.
Запускается на главной странице сайта сразу же при входе.

incoob · 29.09.2010, 22:47

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

iillyyaa · 29.09.2010, 22:55

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

сделай к примеру выбор зоны, а там уже грузить надо будет не 180.000 а всего 10.000 записей а то и меньше...

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

сам фантазируй, но дели как то на части, что бы загрузить именно нужную часть

expl · 30.09.2010, 01:06

JSON - сильно грузить флеш при парсинге (при 180.000 записей парсер подохнет)
XML - легче для парсинга (вряд ли выдержит)
AMF - гораздо легче для парсинга на флеше (не проверял, но вдруг выдержит эти 180.000 записей?)
Отобразить тоже можно, 180.000 записей в экран все равно не влезут,
а отобразить 100 рендереров и переиспользовать их при скролллировании (меняя только данные) - вполне

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