Автор |
Тема  |
|
verus
Почетен Член
12 Пораки |
Posted - 26/10/2006 : 08:35:29
|
Здраво,
Имам ситуација каде еднаш месечно на некој event треба да се креираат ~40000 објекти кои пак во себе содржат подобјекти и истите да се обработат. Тоа трае и трае ... :) Како идеа во моментов го имам следното: наместо објектите да се креираат on the fly, да врти едно сервисче во позадина и да ги сериализира објектите и снима на диск. Проблемот со синхронизација на објектите да не го земаме в предвид. На event-от, сите објекти наместо да се креираат од база, да ги десериализирам само од дискот.
Дали мислите дека со ова ќе добијам на перформанси? Друго, секако, било какви други идеи се добродојдени.
Фала, Иво
|
|
boban
Почетен Член
Macedonia
11 Пораки |
Испратено - 06/11/2006 : 12:32:27
|
Здраво Иво,
Дали би сакал да го опишеш проблемот малку повеќе. Има неколку работи кои не ми се јасни во твојот проблем, како потребата од серијализација и десеријализација, локација на обработката на објектите, ... . Мислам дека е многу побрзо да ги полниш објектите рачно со вредности прочитани од база отколку да ги десеријализираш од фајл. Може да има милион причини зошто обработката е спора, и затоа не ќје биде лошо да покажеш и дел од кодот за полнење и обработка на објектите.
Поздрав, boban.s |
 |
|
verus
Почетен Член
12 Пораки |
Испратено - 11/11/2006 : 17:42:05
|
Здраво Бобан,
>Мислам дека е многу побрзо да ги полниш објектите рачно со вредности >прочитани од база отколку да ги десеријализираш од фајл. >Може да има милион причини зошто обработката е спора, и затоа не ќје >биде лошо да покажеш и дел од кодот за полнење и обработка на >објектите.
Логиката за обработка е доста сложена и не е сместена во една процедура, така што не би можел да ти ја прикажам. Меѓутоа главен проблем со перформасите е полнењето на објектите со податоци извлечени од база, како и запишувањето на резултатите назад во база (bulk insert). За снимањето ќе пробам да ја искористам BULK INSERT наредбата. Вчера правев некои тестови на пробни табели, и запишување на 40000 записи во база траеше 1 сек. наместо 28 сек. ако 40000 пати се изврши наредбата INSERT INTO за секој запис поединечно.
Поздрав, Иво |
 |
|
boban
Почетен Член
Macedonia
11 Пораки |
Испратено - 13/11/2006 : 11:34:26
|
28 секунди за толку податоци и не е многу чекање. А зошто обработката на податоци не ти е на серверот? Читањето на толку многу податоци, па потоа сложена обработка на клиентска страна, и на крај повторно запишување во база не може да биде многу брзо. Плус дека ова треба да се заврши еднаш месечно, ми личи на Sql Server Job schedule-иран да се изврши еднаш месечно, а тој ќе изврши една сторирана процедура за обработка.
boban.s |
 |
|
verus
Почетен Член
12 Пораки |
Испратено - 13/11/2006 : 13:54:56
|
>28 секунди за толку податоци и не е многу чекање.
28 секунди на пробни табели со по 2-3 колони.
>А зошто обработката на податоци не ти е на серверот? Читањето на толку многу податоци, па потоа сложена обработка на клиентска страна, и на крај повторно запишување во база не може да биде многу брзо.
Се е на сервер.
>Плус дека ова треба да се заврши еднаш месечно, ми личи на Sql Server Job schedule-иран да се изврши еднаш месечно, а тој ќе изврши една сторирана процедура за обработка.
ОК е тоа, само логиката е многу комлицирана и е веќе направена во бизнис логиката на апликацијата, па спуштање на целата логика во база ќе земе многу време ако воопшто може да се направи.
Сепак фала на одговорите.
Поздрав, Иво
|
 |
|
boban
Почетен Член
Macedonia
11 Пораки |
Испратено - 13/11/2006 : 16:01:24
|
Кога кажав сервер не мислам на компјутер туку на SQL Server а под клиент мислам на апликација. Ако логиката ти е во .NET можеш да ја користиш директно во SQL Server 2005 без да ја конвертираш во Transact SQL бидејќи можеш да користиш .NET библиотеки директно во SQL 2005, се разбира само доколку конверзијата е навистина тешка или имаш потреба на истата логика и во апликацијата за други работи. Инаку најдобро и најбрзо е да користиш сторирана процедура за обработка.
Поздрав, boban.s |
Едитирано од - boban on 14/11/2006 00:33:28 |
 |
|
|
Тема  |
|