 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
VB Forum / COM / April 2007COM-RPCServer - New Version
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. 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 > Hi, > [quoted text clipped - 53 lines] > > P.S. VB6-Sources for the Demo-Clients follow shortly. > 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 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 >> 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 [quoted text clipped - 41 lines] > > Olaf > ... 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 > You mean, regarding the additional > "Server-Load", running time-consuming queries > in parallel to the Interbase-Engine? Yes, that is the one I was worried about. Will let you know when I have some results. RBS >> ... The main problem I can see is the effect that running queries >> on this SQLite file would have on the performance of Interbase. [quoted text clipped - 23 lines] > > Olaf Ok, here come the commented Client-Sources - once for the DB-Demo- and for the COM-Demo-Client too. www.datenhaus.de/Downloads/RPCSourceDemoClients.zip The COM-Demo is going more into detail, covering (more or less) all of the features of this "DCOM-Replacement" - mainly thought for those, who want to "dive into deep" ;-) The DB-Demo covers only the needed parts of the RPC- mechanisms and is probably the better recommendation for a quick overwiew. Both demos (please read: '_Before you start.txt' first) allow a client-side RoundTrip-Debugging using the normal "VB-F8-Mode", as long as the DebugMode-Switch is set to true, and if the project was loaded prior as a VB- ProjectGroup (containing the appropriate Server-Dll-Project). The Code inside the Modules is not too voluminous (ca. 40-50 lines on average) - think, if you invest ca. half an hour into the DB-Demo-Source, then you already got a very good overwiew and understanding about the whole RPC-thing. Olaf |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.