Point noted brother.

On Wed, Nov 30, 2011 at 9:21 AM, kevin karanja <kevinkarash@gmail.com> wrote:
is it a vb6 app :-).... i remember that most vb apps where never coded
to use network resources efficiently i.e maintaining an active
connection to the db as long as the app was running, instead of just
when data transfer was needed. .net's data access methods alleviate
this issue coz ado.net is desgined to open/close db connections
automatically.... however, in some scenarios, that may become
problematic if ur not careful.....i remember helping a pal improve an
app he had. it wld update 10,000 records in just under an hour (on a
dev laptop) because each single update per record wld make ado.net
open a connection to the db, update that single record, then close the
connection. opening/closing connections is expensively time consumig
ng, and we slashed thd processing time fo just under a minute by
batching up the updates, so only one db-connection would be used go
update all the records.....

.... in short, i'd bet on the app being the culprit, esp if reporg
processing is done on the client-end.

On 11/29/11, Mr. Lawi <mail2lawi@gmail.com> wrote:
> On Tue, Nov 29, 2011 at 1:48 PM, muskiv <kulebak@gmail.com> wrote:
>
>> Mr. Lawi
>>
>> On Tue, Nov 29, 2011 at 11:45 AM, Mr. Lawi <mail2lawi@gmail.com> wrote:
>>
>>> Is the problem replicated at the hq/head office?
>>>
>>
>> NO
>>
>>
> This points to network issues. You should explore Aki's options (and other
> network suggestions provided).
>
>
>> Because if its still slow there then the bandwidth issue may not be the
>>> concern.
>>>
>>> Then, on report generation, where is the reporting done?
>>>
>>
>> As in location or device?.....If device reporting done from Main DB
>> server.
>>
> This fine.
>
> Maybe you can also do a few checks using SQL Profiler - check the time it
> takes to service a request
>
>>
>>
>>> Are u using stored procedures?
>>>
>>
>> Yes...Most likely the SQL logic  is in Stored procedures
>>
>>
> Good
>
>> Though unlikely, it could be that the logic is in the vb app as opposed to
>>> it running on the SQL server.
>>>
>>> My advice, as has been noted by other listers:
>>> a) Check your queries. For shared db some reports dont have to be
>>> regenerated for every user
>>>
>>
>> OK
>>
>>
>>> b) Check your network. If the reports are generated fast enough, then its
>>> the serving thats the problem
>>>
>>
>> Did U mean server?
>>
>
> I meant the database server may be fast in accepting and processing the
> requests but serving the same to the end user takes time - coz of network.
>
>
>>  c) Maybe the application/platform itself
>>>
>>> Thx
>>
>>>
>>> On Tue, Nov 29, 2011 at 10:12 AM, muskiv <kulebak@gmail.com> wrote:
>>>
>>>> Aki
>>>>
>>>> On Tue, Nov 29, 2011 at 11:05 AM, aki <aki275@gmail.com> wrote:
>>>>
>>>>> @muskiv, imo, your problem is purely on the network layer. You need to
>>>>> see the number of db sessions open in tcp to understand the overhead
>>>>> demanded by the client-server wan-wan application.
>>>>>
>>>>
>>>> Sorry how do I do this in WIN2K3?
>>>>
>>>>
>>>>> You way eventually have to install wan application and optimization
>>>>> accelerators since increasing the bandwidth on the remote sites would
>>>>> not
>>>>> justify costs.
>>>>>
>>>>
>>>> Same question as above. (Sorry I know I can google :)
>>>>
>>>>
>>>>> Have you also done local LAN tests on the seutp to determine
>>>>> the nbottlenecks at DB or hardware level?
>>>>>
>>>>
>>>> A number of LAN tests have been done. I've noted a few that I think need
>>>> resolution...work is in Progress. Just didn't want to miss anything
>>>>
>>>>
>>>> Thx
>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Skunkworks mailing list
>>>>> Skunkworks@lists.my.co.ke
>>>>> ------------
>>>>> List info, subscribe/unsubscribe
>>>>> http://lists.my.co.ke/cgi-bin/mailman/listinfo/skunkworks
>>>>> ------------
>>>>>
>>>>> Skunkworks Rules
>>>>> http://my.co.ke/phpbb/viewtopic.php?f=24&t=94
>>>>> ------------
>>>>> Other services @ http://my.co.ke
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Skunkworks mailing list
>>>> Skunkworks@lists.my.co.ke
>>>> ------------
>>>> List info, subscribe/unsubscribe
>>>> http://lists.my.co.ke/cgi-bin/mailman/listinfo/skunkworks
>>>> ------------
>>>>
>>>> Skunkworks Rules
>>>> http://my.co.ke/phpbb/viewtopic.php?f=24&t=94
>>>> ------------
>>>> Other services @ http://my.co.ke
>>>>
>>>
>>>
>>> _______________________________________________
>>> Skunkworks mailing list
>>> Skunkworks@lists.my.co.ke
>>> ------------
>>> List info, subscribe/unsubscribe
>>> http://lists.my.co.ke/cgi-bin/mailman/listinfo/skunkworks
>>> ------------
>>>
>>> Skunkworks Rules
>>> http://my.co.ke/phpbb/viewtopic.php?f=24&t=94
>>> ------------
>>> Other services @ http://my.co.ke
>>>
>>
>>
>> _______________________________________________
>> Skunkworks mailing list
>> Skunkworks@lists.my.co.ke
>> ------------
>> List info, subscribe/unsubscribe
>> http://lists.my.co.ke/cgi-bin/mailman/listinfo/skunkworks
>> ------------
>>
>> Skunkworks Rules
>> http://my.co.ke/phpbb/viewtopic.php?f=24&t=94
>> ------------
>> Other services @ http://my.co.ke
>>
>
_______________________________________________
Skunkworks mailing list
Skunkworks@lists.my.co.ke
------------
List info, subscribe/unsubscribe
http://lists.my.co.ke/cgi-bin/mailman/listinfo/skunkworks
------------

Skunkworks Rules
http://my.co.ke/phpbb/viewtopic.php?f=24&t=94
------------
Other services @ http://my.co.ke