COM-RPCServer - New Version
in [Visual Basic]
|
From: Schmidt on 14 Apr 2007 09:56 Hi, just finished a general overhaul of all of my free COM-tools. The "flagship" of them is the RPCServer (now in Version 2.1), wich makes use / integrates many of my other free COMponents (e.g. the dhSQLite-Wrapper or DirectCOM). Many of you will ask, "What the heck should I use it for - never needed COM+ or DCOM or some of this Enterprise- Level stuff" - well, what about an XCopy-deployable DB- Server then, with outstanding Performance in the LAN? Just wrote a small serverside COM-Dll with (let me count) 50 lines of Code, implementing a small, but fully functional (in Read/Write-Direction) DB-Layer around dhSQLite. This performes so well, that it outperformes e.g. a .NET- Webservice by ca. factor 9 in a disconnected Recordset- scenario. Simply check this out - the Package contains three folders: The RPCServer, a COM-Demo-Client and a DB-Demo- Client. All three folders can be moved and used inside your LAN without leaving any traces in your registries - all is working completely registryless. www.datenhaus.de/Downloads/dhRPCServer2.1.zip The Connect-Textfields are predefined to 'localhost' tough, so that you can test this out on your local Developer-PC first. Here comes a Screenshot (made yesterday), on what you can expect inside the Demo: www.datenhaus.de/Downloads/Linux-RPC-Hosting.png This is the RPC-Server running on Linux, currently stressed bei two DB-Clients - one of them running on the same Linux-Host, the other one on XP. Performance in Version 2.1 is greatly improved - Version 2.0 reached ca. 4000 small COM-Requests per second - the new Version now can serve 10000 (tested on a Dual-Athlon 2GHz). DB-Performance: - e.g. "Select * from Customers" was running with ca. 500 Responses/sec, stresstested from different Clients in parallel (using disconnected SQLite-Recordsets). The new release has passed a complete test-suite and runs solid and rockstable (even on Linux/Wine without any memory-leaks). So, have fun with it - maybe it helps, to convert some of you into "three-layer-guys" somehow. ;-) Olaf P.S. VB6-Sources for the Demo-Clients follow shortly.
From: RB Smissaert on 14 Apr 2007 11:14 Hi Olaf, This sounds good and I wonder if it were possible to do the following: We are dealing with an Interbase 5.6 (don't ask why) clinical database. This is a server-client setup with up to maybe some 100 users. The server is Windows 2000. Average size of all the .gdb files is maybe some 5 Gb, but could be up to may 20 Gb. There are some 200 tables, the majority small ones, but there are a few large ones with up to say 20 million rows. The front-end is a C++ application, which connects to the database with the Interbase API, through it's own API. In the majority of cases the connection will be through a LAN, but it also will have to connect via a Terminal Server setup. Performance is not good and my question is if you reckon it were possible to convert this to a setup based on SQLite and your RPCServer. The next bit is not really to do with the above question, but it might give you a better idea what is going on. The majority of user interactions are reads or writes dealing with a single patient, but there are also queries (reports) that deal with all patients in the database. This is the bit where I have written replacement software for (an Excel .xla add-in) and I am in the process of converting this to a SQLite based app. This is already a lot faster than the provided reports software written in C++, but obviously if the database was held in SQLite it would be a lot faster as I wouldn't have to connect with ODBC and move the data from Interbase to SQLite. Thanks for any insight/advice. RBS "Schmidt" <sss(a)online.de> wrote in message news:e9JKqzpfHHA.208(a)TK2MSFTNGP05.phx.gbl... > Hi, > > just finished a general overhaul of all of my free COM-tools. > > The "flagship" of them is the RPCServer (now in Version 2.1), > wich makes use / integrates many of my other free COMponents > (e.g. the dhSQLite-Wrapper or DirectCOM). > > Many of you will ask, "What the heck should I use it for - > never needed COM+ or DCOM or some of this Enterprise- > Level stuff" - well, what about an XCopy-deployable DB- > Server then, with outstanding Performance in the LAN? > > Just wrote a small serverside COM-Dll with (let me count) > 50 lines of Code, implementing a small, but fully functional > (in Read/Write-Direction) DB-Layer around dhSQLite. > This performes so well, that it outperformes e.g. a .NET- > Webservice by ca. factor 9 in a disconnected Recordset- > scenario. > > Simply check this out - the Package contains three folders: > The RPCServer, a COM-Demo-Client and a DB-Demo- > Client. All three folders can be moved and used inside your > LAN without leaving any traces in your registries - all > is working completely registryless. > www.datenhaus.de/Downloads/dhRPCServer2.1.zip > The Connect-Textfields are predefined to 'localhost' > tough, so that you can test this out on your local > Developer-PC first. > > Here comes a Screenshot (made yesterday), on what you > can expect inside the Demo: > www.datenhaus.de/Downloads/Linux-RPC-Hosting.png > This is the RPC-Server running on Linux, currently stressed > bei two DB-Clients - one of them running on the same > Linux-Host, the other one on XP. > > Performance in Version 2.1 is greatly improved - > Version 2.0 reached ca. 4000 small COM-Requests > per second - the new Version now can serve 10000 > (tested on a Dual-Athlon 2GHz). > > DB-Performance: - e.g. "Select * from Customers" > was running with ca. 500 Responses/sec, stresstested > from different Clients in parallel (using disconnected > SQLite-Recordsets). > > The new release has passed a complete test-suite and > runs solid and rockstable (even on Linux/Wine without > any memory-leaks). > > So, have fun with it - maybe it helps, to convert some > of you into "three-layer-guys" somehow. ;-) > > Olaf > > P.S. VB6-Sources for the Demo-Clients follow shortly. > >
From: Schmidt on 14 Apr 2007 11:51 "RB Smissaert" <bartsmissaert(a)blueyonder.co.uk> schrieb im Newsbeitrag news:eqWW3eqfHHA.4804(a)TK2MSFTNGP06.phx.gbl... > We are dealing with an Interbase 5.6 (don't ask why) clinical > database.This is a server-client setup with up to maybe some > 100 users. The server is Windows 2000. > Average size of all the .gdb files is maybe some 5 Gb, but could > be up to may 20 Gb. The sqlite-docs say, that the maximum-db-size is 2^41 bytes (2,199,023,255,552). The largest DB I've tested so far was a conversion from a 2.4GByte MS-SQL-DB (containing e.g. tables of ca. 130,000 Rows on 130 Columns and one Table of 1.3 Mio Rows on 3 (Index-)Columns. This DB had many very complex View-Defs in it, wich I've converted successfully to SQLite-Views. The performance was better compared with the SQL-Server on all direct Table-Requests (including complex where-clauses) and also on all direct Table-Joining-Requests. The complex views were running faster too - only on deep nested Views (Views using Views using Views ;-) the performance was slower by a small factor of ca. 1.5. I don't know, what this may worth regarding interbase, but I would assume, that the "normal" interbase-performance is somewhat below that of an MS-SQL-Server - but I've not made a direct Interbase-comparison so far - you'd have to check this out yourself. If you can manage, to get the Interbase-Resultsets over an ADO-Connection somehow, then my converter-class should "eat them" fine - this way you could import and then compare the sqlite-performance (after setting all Indexes correctly) testing especially your larger Interbase-Tables. The RPCServer as a DB-layer sitting in front of SQLite should be able, to serve your 100 Users very well (its limit for concurrent "Keep-alive"-socket-connections is 1024). I'd say, simply create a SQLite-pendant at least for your "worst-case"-tables and the currently slowest performing Select (or View) from your Interbase-Setup and write a test-case (a small VB6-App) for it (using the Code of the DB-Demo as an "How-To"). The RPCServer has XCopy-deployment, so you should have no stress, putting the appropriate RPCServer-Directory to your Windows2000-Host and perform a small (stress-) test over the LAN with your VB-TestClient. Olaf
From: RB Smissaert on 14 Apr 2007 12:24 Thanks, it sounds then this could be doable. Converting the C++ frontend would be beyond me, but maybe it is an option for my reporting software to run this on a regularly updated SQLite file that sits on the server. The main problem I can see is the effect that running queries on this SQLite file would have on the performance of Interbase. > If you can manage, to get the Interbase-Resultsets over an > ADO-Connection That is no problem and I can convert this fine already to the SQLite file. In fact I have a custom dll for this that does this without ADO, directly from Interbase to SQLite. This is faster than doing it via ADO. Actually, I have a dll that does the same for MS SQL Server >> SQLite. > my converter-class Where was this class again? > I'd say, simply create a SQLite-pendant at least for your > "worst-case"-tables and the currently slowest performing > Select ... Will have a go at that and thanks again for the help. RBS "Schmidt" <sss(a)online.de> wrote in message news:eMnwG0qfHHA.4064(a)TK2MSFTNGP03.phx.gbl... > > "RB Smissaert" <bartsmissaert(a)blueyonder.co.uk> schrieb im Newsbeitrag > news:eqWW3eqfHHA.4804(a)TK2MSFTNGP06.phx.gbl... > >> We are dealing with an Interbase 5.6 (don't ask why) clinical >> database.This is a server-client setup with up to maybe some >> 100 users. The server is Windows 2000. >> Average size of all the .gdb files is maybe some 5 Gb, but could >> be up to may 20 Gb. > The sqlite-docs say, that the maximum-db-size is 2^41 bytes > (2,199,023,255,552). > The largest DB I've tested so far was a conversion from a > 2.4GByte MS-SQL-DB (containing e.g. tables of ca. 130,000 > Rows on 130 Columns and one Table of 1.3 Mio Rows on > 3 (Index-)Columns. > This DB had many very complex View-Defs in it, wich I've > converted successfully to SQLite-Views. > The performance was better compared with the SQL-Server > on all direct Table-Requests (including complex where-clauses) > and also on all direct Table-Joining-Requests. The complex views > were running faster too - only on deep nested Views (Views using > Views using Views ;-) the performance was slower by a small > factor of ca. 1.5. > I don't know, what this may worth regarding interbase, but I > would assume, that the "normal" interbase-performance is > somewhat below that of an MS-SQL-Server - but I've not > made a direct Interbase-comparison so far - you'd have to > check this out yourself. > If you can manage, to get the Interbase-Resultsets over an > ADO-Connection somehow, then my converter-class should > "eat them" fine - this way you could import and then compare > the sqlite-performance (after setting all Indexes correctly) > testing especially your larger Interbase-Tables. > > The RPCServer as a DB-layer sitting in front of SQLite should > be able, to serve your 100 Users very well (its limit for > concurrent "Keep-alive"-socket-connections is 1024). > > I'd say, simply create a SQLite-pendant at least for your > "worst-case"-tables and the currently slowest performing > Select (or View) from your Interbase-Setup and write a > test-case (a small VB6-App) for it (using the Code of the > DB-Demo as an "How-To"). > The RPCServer has XCopy-deployment, so you should have > no stress, putting the appropriate RPCServer-Directory to > your Windows2000-Host and perform a small (stress-) test > over the LAN with your VB-TestClient. > > Olaf > >
From: Schmidt on 14 Apr 2007 13:25
"RB Smissaert" <bartsmissaert(a)blueyonder.co.uk> schrieb im Newsbeitrag news:Oqob5FrfHHA.2640(a)TK2MSFTNGP06.phx.gbl... > ... The main problem I can see is the effect that running queries > on this SQLite file would have on the performance of Interbase. You mean, regarding the additional "Server-Load", running time-consuming queries in parallel to the Interbase-Engine? Think, you should look at the current load of your W2K-machine when the Interbase-Server has its "rush-hour" - if there are 50% left over (many DBMS don't use the full CPU-Power whilst running complex queries, because they have to wait for the Disk-IOs to complete), then there are good chances IMO, especially, if you can place the SQLite-DB-File on a different HardDisk. > > my converter-class > > Where was this class again? Inside the original SQLite-Demo-Zip. > > I'd say, simply create a SQLite-pendant at least for your > > "worst-case"-tables and the currently slowest performing > > Select ... > > Will have a go at that and thanks again for the help. Let me know your results, or when you need help, putting it behind the RPC-Server. Olaf |