[for ALL] Valentina Server 1.x // And they say OpenBase isgood?

[Frank Bitterlich]

Ruslan Zasukhin wrote:
> 
> on 2/10/03 9:51 PM, Frank Bitterlich at bitterlich at gsco.de wrote:
> :-) and pay them tons of bucks for "support"?

Well, maybe *they* need funds to develop the next version of Openbase?
;-) LOL..

No, seriously, I think they'd give you a bit of "getting started"
support for free - but then again, they might not. Who knows :)

> 1) I believe this was VERY simple test. Just one table with all numeric
> fields. What here can be tuned. I do not see in prefs option for cache
> size...In any case it must go best from the start.

I don't know what can be tuned; as I wrote, I didn't get that far with
OB. But I know that sometimes even simple things can be improved if you
know how - it might not always be obvious.

> 2) Frank, you probably have not note that right now we here totally rewrite
> Valentina kernel from scratch.

I have; and I'm very interested in the results. :)

... 
> And I many times have repeat here, "single user DB" and "multi-user db" do
> not differ significantly...Well, may be only Oracle has crazy complex file
> format...and I am not sure they are right...
My DB engine knowledge is not deep enough to tell anything about that;
however, I do know that there are (or rather, were) databases around
that look pretty decent whe under single-user or light multi-user acces,
but their performance sucks when more than a few concurrent accesses
occur. So I was assuming that managing multi-user access was much more
difficult. But again, that was just an assumtion.
 
> 3) Frank, note, that increasing of cache as you describe, IS NOT
> optimization. This is just usage of more fast device.
> But be careful. This means that as only your db size become bigger of size
> of RAM, you again immediately jump to 20 seconds speed...Actually even
> worse, because again, as shown on my benchmark pages, speed of regular RDBMS
> DO NOT grow linear to the number of records. IT is much worse, when size of
> db is much more of RAM.

... which is exactly my situation here. In which case, fine-tuning the
DB (controlling WHICH tables are being cached, and how) can be a very
important factor. And this is what I complain about with the existing
multi-user DMBS systems (except Valentina): It's difficult to get the
maximum performance out of the product without either support from the
vendor or much trial-and-error. No such problems with Valentina: Set up
a cache size and you're ready to go.

> 4) When you test db on OS X or Windows, virtual system can give surprises.
> You can even quite app, start it again, but next query will be much faster,
> because in RAM still present pages of db file. In fact OS work here as
> secondary cache...
>     So it is really hard to test it on cool system.
> So you could see this effect, and think that you see speed up thanks to
> cache size. You see?

I know that, and that's one more point on the list of reasons why it is
hard to do a valid benchmark on an abstract basis with modern DBMS and
OS. The point is: If you want to know which product can solve _your_
specific task faster, you have to actually try it on that task, with all
tweaks, tricks, and optimizations you're able to do. While putting more
RAM into my machine to improve speed is not really an optimization: if
it helps, who cares. I don't care if I buy a database for $1000 and RAM
for $1000, or a database for $2000 which requires no additional RAM. I
just want it FAST. You know, that "need for speed" thing ;)

And to make my point clear: Valentina has never disappointed me in this regard.

> 5) And to warm up you :-)

... which I desperately need, because of all the cold Russian air that
is currently flowing into the central-European region... :)
 
> We here already have Valentina Server working on Windows for now.
> As backend Igor use 1.x kernel (!)
> In other words we already have done:
>     -- threading model
>     -- sockets,
>     -- network protocol
> 
> We can send all SQL commands of Valentina 1.x
> And read/write data...

No transactions - does that mean no record locking? Or is locking
available already? If so, I can only suggest to release it. You've heard
how many people are waiting for it :)

Like someone once said (on the RB NUG?): Release early, release often...

Cheers,
   Frank+++

--
Günter Schmidt & Co. oHG         
Frank Bitterlich             eMail: bitterlich at gsco.de
Schlosserstr. 4              WWW:   http://www.gsco.de/gsco
D-60322 Frankfurt            Tel.:  069 / 156809-29
GERMANY                      Fax:   069 / 156809-28