Re: [Phpgroupware-developers] SQL garbage in contacts backend

[Markus Kaemmerer]

Alex Borges <address@hidden> wrote:,

>> >> is there a switch or something like this we can set if we get our data
>> >> trough IPC and XML-RPC?
>> >
>> >Yes. Upon instantiation of sql_contacts you can tell it not to prefetch
>> >the catalogs. 
>> 
>> How do I do this?
>> 
>Send false to contacts_sql upon instantiation. Youll need to look at
>read_sessiondat() method to look at what we are doing there.

i found this and disabled this for my performance tests some days ago.
Disableing the cache results in a small performance improvement.

>Still, if youre thinking you can get away with only one query joining to
>catalogs for fetching of contact communication data, notes data or
>addresses, you best look into the design further. There is NO way to
>accomplish this in a generic way.

I see no big perfomance problem in doing one little query more or
less. If this query is supported by an index, this should be quite
fast, as I found in my performance tests today. 

>Yes, we carried this from 14's vcard implementation. The standard is not
>limiting in that way, this limitation can be removed. If anyone has
>anything to say about this, speak now, or forever hold your peace.

Noone asked for this feature untiil now, so you can reomve it now :)

>> My be it would be much better to use shared memory to cache things
>> like acl and little tables than sessions. This would help in really
>> big installations a lot more than caching in session variables.
>
>This is a great idea! Yes, this has been in my mind for some time. But
>im not shure of how to go on implementing it.... i havent looked into
>it. 
>But hey, shure, a class to set_shm_var($name,$data) get_shm_var($name)
>would really be cool (there is a lot of data fetched from the database
>that is fetched for all users all the time).

This should be simple, because every functionallity for this is
included in PHP already. Caching things in shared memory is can lead
to a great performance increase. Even more, if there are more users on
one machine. 

>> You now your database at best, so you should decide which field needs
>> and index. Adding more index to fields that are not used only slow
>> down things. 
>> 
>
>If i knew it best, and needed no help, the indexes would already be
>there now wouldnt they? If you achieved 30% performance increase by
>adding indexes, then we best as hell know which indexes where those. 

I added a line to class.db.inc that all queries are made where logged
to the php error_log (see end of the other mail). Here you see, which
queries can be faster if they are backed by an index. I found some,
see attached patch (other mail).

>I want to take this oportunity to state that we all are very interested
>in seeing sync come to life in the most perfect way possible. I want to
>check out what we can do with the xml-rpc in the phpgroupware side.

Almost all code is in Savannah HEAD already.

>As ive said, it may have performance problems, but 300 contact == 30
>minutes (or 15 minutes, or 10 or 5) is not acceptable for anyone. If you
>can import a vcard list of 600 in less than a minute, then the
>bottleneck is  nowhere near the core of the contacts backend.

As with newer testing today I saw, that most of the time is wasted
while initalization of all API functions and so on. For my little page
which only displays two lines, 80% where done for initialization and
20% for createing the header and the rest of all HTML.

Markus

--
Markus Kämmerer         Team Software Solutions
pro|business AG, EXPO Plaza 1, 30539 Hannover
E-Mail: address@hidden,  Phone.: 0511/60066-0
WWW: http://www.probusiness.de/,    Mobile: 0177/5990932

**********************************************
           address@hidden 2004

*       Halle 1, Stand 3k4 (Magirus Deutschland GmbH)
*       Halle 1, Stand 7f2 (EMC Deutschland GmbH)
*       Halle 6, Stand D46 (Land Niedersachsen)
**********************************************