Re: Sql ce server process
- From: Brandon <Brandon@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Mon, 18 Feb 2008 12:54:00 -0800
Thanks for the reply.
These are all things we are considering before we will go to these lengths.
Pretty much when you boot, you have about 13M - 17M of VM per process to use,
minus any native dll's that each process uses outside of what's loaded for
the OS + drivers(sqlmobile, libraries required to support the barcode
scanner, speech engine, etc). The process in question uses sqlmobile and the
barcode scanner, along with a few pInvokes, etc, has about 13 threads running
and has a robust multi-screen UI (implemented as full-screen user controls
that take up the whole form - and there is only one form). In total there is
about 4M - 5M of VM eaten up by native dll's that the process has a reference
to. Almost 2M of that is sqlmobile, so the thought is that if these dll's
are no longer referenced in this process, that's 2M that can be allocated for
other things, plus whatever VM is used to support the open connection at
runtime, and all of the extra JIT'd code at the bottom of the slot.
We have about 20M - 30M of free physical memory, so this does not seem to be
our limitation. The only dll's that the sql engine would reference would be
those required by the framework, anything required for the tcp interface, and
sqlmobile, so it should have a solid 10M - 14M of VM to work with solely for
interfacing with sql, not having to share any of that with an interface or
anything else, and with only two or three other simple threads running.
"Jesse Houwing" wrote:
Hello brandon,.
I posted this on the compact framework board, as the reasoning behind
the direction described here is compact framework - related, but I
though there might be an expert over here on this board that might be
more familiar with possible past attempts in this direction....
We are running out of VM in our main application, and among other
things, I am considering how we might break functionalities across
groups of native dll's that have to load for those functionalities.
An obvious break line involves sqlmobile (3.x). I threw together a
quick proof of concept for basically creating a database engine
process that would perform all sqlmobile access, with a TCP interface
for issuing commands and getting results wrapped in XML (we already do
something similar in a process that performs all of our replication -
conceivably, this process would grow up to be a sqlmobile engine that
handles both queries and replication). I know that there may be
something we can do that will be more efficient than XML, but our
result sets are generally small - probably the biggest one is 18 rows
by about 30 columns. Hopefully an added benefit would be that we
might even be able to put together an algorithm for caching a few
query plans...we have been unable to do this for some time, due to VM
constraints.
I can't imagine that this is as avenue that has not been explored, and
am just wondering if anyone has any comments on the approach - is this
a bad idea? It seems like if this were a viable option, that it would
already exist out there somewhere, probably even provided by
Microsoft. Maybe they were just afraid people would try to use it in
a more robust way than it was intended...?
SQL Server CE has a pretty small footprint for all the features it provides.
What is it that makes you run out of VM space? Doe the devices have a very
limited amount of memory? Are you leaking memory somewhere? Is you application
very memory consuming? Can you optimize some of your algorithms or UI parts
to free up some of the memory in use?
Only after exhausting all these questions I'd start thinking of writing my
own storage engine. No matter how simple, efficient en robust you can make
it. The main reason for that is that if one of the issues mentioned above
isyour actual problem, chances are that your new storage engine will only
add to that.
--
Jesse Houwing
jesse.houwing at sogeti.nl
- References:
- Re: Sql ce server process
- From: Jesse Houwing
- Re: Sql ce server process
- Prev by Date: Re: Sql ce server process
- Next by Date: Re: Sql ce server process
- Previous by thread: Re: Sql ce server process
- Next by thread: Re: Sql ce server process
- Index(es):
Relevant Pages
|
Loading