Re: what is going on with gtk.php.net?

This time I understand more what you are saying. I agree with you that 1000 connections open is an overhead ( i don't actually know how much). In my scenario, if the user doesn't use the connection for a while it will time out. Next time they try to use it, it's gone stale and a new connection is established. That way only the users currently using the app will have a connection open. Your idea to cache the original 1000 dataset in a tcp server is a good one if performace were to become a problem. I still think that if I want to look up bob smith a query to 'select firstname, surname from wherever where surname like s%' would do the job. Then another query to bring back the details. If there are 1000 people in the company each looking up 10 names a day thats 20,000 queries a day. I would not worry about that on any reasonably spec'd db server. Anyway I can see the merits in your solution and I'm sure we could debate the pro's and cons for ever. More than one way to skin a cat etc tony On Thu, 2004-07-22 at 19:50, Richard Thomas wrote: > What happens if you have 1000 users all connected to the database at the > exact same time, I wasn't talking the overhead really of the database in > general but instead the connections to the database itself. > > In my address book example, Say you have an address book with every > employee at the company, Typical format for an address book is to list > names and allow you to scroll through those names, then click for more > detailed, Its that original list of names that I was referring to in my > example. Do you do 1000 querys to pull the same exact list or can you > cache that list so the result is only a single query. > > The database handles all the updates so theres no problem there, If a > change does come in you would have to have your tcp server clear the > cache, the next request for the address book would query the db, and > recreate the cache. > > As to memory usage, If you think in terms of your computer there are a > number of diffrent types of caching going on in your computer at any one > time, The idea of caching is not to store everything but to store > frequently accessed data. Caching the list of people in the address book > would make sense since any use of the address book would require this > basic list, Caching every person in the address book however does not > make sense. > > Tony Leake wrote: > > On Thu, 2004-07-22 at 17:43, Richard Thomas wrote: > > > > > >>Such a "hack" doesn't seem like it would scale very well at all. It > >>seems to me you would be better off with a diffrent form of > >>communication between the applications, like possibly a tcp connection. > > > > > > I can't agree that this is a hack and it scales very well. I use this > > methds in an application that dispatches goods from a warehouse. It is > > used by 30 - 40 simultainous users spread over 4 georaphic locations. It > > handles 30,000 transactions a day and since it went live has handeled > > close to 3 million transactions. > > > > Our database servers average 15,000 queries a second and do not even > > flinch so a couple of extra queries to make sure that the databsae > > handle is still alive is a tiny overhead. > > > > > >>A good example.. Large company address book, employees work 9-5, so a > >>majority of your "initial" activity would occur between 8:55-9:00. 1000 > >>employees connecting to the db and performing a query to load there > >>address books for the data, then every time the address book changes > >>each one has to reperform the query. > >> > > > > It sounds to me like your saying you load the whole address book into > > memory? In real life you perform one query to connect to the database > > when you start the database and another when you want to look up an > > address, then another when you want another address, not a big issue for > > any database. > > > > > > > >>Instead using some tcp setup it would happen more streamlined. > >>1. People connect, First person that makes request causes query, Final > >>dataset built, cached and then sent. > > > > > > I also use a tcp server in the same application,but there are times you > > need real-time which is far more suitable for a database. > > > > > >>2. Everyone else pulls a simple dataset out of the tcp server memory, > >>low overhead. > > > > > > Then when someone updates an address, everyones local copy has to be > > updated. What happens if 2 people try to update the same record at the > > same time. Lots of code to handle that, or your database will do it all > > for you. > > > > > >>3. Ability to send "broadcasts" over the tcp connection letting people > >>know there are updates to the address book. Instead of everyone pooling > >>the server now you have told everyone there is a update, Next time they > >>open there address book it will pull it. > > > > > > so if you have 50,000 records in the datasset thats quite a lot of ram > > used just to hold the data that you may never use. > > > > > > Tony > > > > > >>tony@php.net wrote: > >> > >>>On Thu, 2004-07-22 at 09:11, Anders K. Madsen wrote: > >>> > >>> > >>>>On Thu, 22 Jul 2004 12:57:46 +0700 (SE Asia Standard Time) > >>>>xaviero1412@yahoo.com.au (Xaviero) wrote: > >>>> > >>>> > >>>> > >>>>>so, tony, could u write some article bout php-gtk that explain how to > >>>>>build > >>>>>an application such like address book that connect to mysql server ? > >>> > >>> > >>>I'm working on one at the moment :) > >>> > >>> > >>> > >>>>Well, PHP-GTK is just an extension of PHP, so any PHP/MySQL tutorial > >>>>would do in your case. > >>> > >>> > >>>Almost, however you need to be aware that a gtk app is likely to be open > >>>on someones desktop all day, and may only be used for a few minutes at a > >>>time. When you come back to it your db handle has gone stale. I always > >>>extend my basic db class with a gtk specific one that checks the > >>>connection is alive before I use it. > >>> > >>>tony > >>> > >> > >> > >>-- > >>Richard Thomas > >>Cyberlot Technologies Group Inc. > >>507.398.4124 - Voice >