phpwiki-talk

[Phpwiki-talk] Phpwiki and Mysql slowness

[Manuel V. <man...@gm...>]

Hello all,

I noticed than, sometimes, mysql based phpwikis become slow when there
are several concurrent access.

I guess it's due to table locking for update operation (phpwiki locks
whole table).

I'm wondering if it could be a good idea to use innodb table type when
available and replace table locks by transactions as other ACID
complient engines (pgsql, ...) do ?

What do you think ?

-- Manuel

Re: [Phpwiki-talk] Phpwiki and Mysql slowness

[Reini U. <ru...@x-...>]

2007/1/8, Manuel Vacelet <man...@gm...>:
> Hello all,
>
> I noticed than, sometimes, mysql based phpwikis become slow when there
> are several concurrent access.
>
> I guess it's due to table locking for update operation (phpwiki locks
> whole table).
>
> I'm wondering if it could be a good idea to use innodb table type when
> available and replace table locks by transactions as other ACID
> complient engines (pgsql, ...) do ?

postgresql, oracle or innodb are much better than myisam on crowded
servers, yes.

BTW: can I expect an updated french translation for the new 1.3.13 features?

> What do you think ?
-- 
Reini Urban
http://phpwiki.org/              http://murbreak.at/
http://spacemovie.mur.at/   http://helsinki.at/

Re: [Phpwiki-talk] Phpwiki and Mysql slowness

[Manuel V. <man...@gm...>]

2007/1/9, Reini Urban <ru...@x-...>:
> 2007/1/8, Manuel Vacelet <man...@gm...>:
> > Hello all,
> >
> > I noticed than, sometimes, mysql based phpwikis become slow when there
> > are several concurrent access.
> >
> > I guess it's due to table locking for update operation (phpwiki locks
> > whole table).
> >
> > I'm wondering if it could be a good idea to use innodb table type when
> > available and replace table locks by transactions as other ACID
> > complient engines (pgsql, ...) do ?
>
> postgresql, oracle or innodb are much better than myisam on crowded
> servers, yes.

Ok, we will have look on this approach.
Obviously, we will keep the list informed.

> BTW: can I expect an updated french translation for the new 1.3.13 features?

I think Sabri (who's working with me on the subject) already gave to
you the small work he did on the subject.

-- Manuel

Re: [Phpwiki-talk] Phpwiki and Mysql slowness

[Reini U. <ru...@x-...>]

2007/1/12, Manuel Vacelet <man...@gm...>:
> 2007/1/9, Reini Urban <ru...@x-...>:
> > 2007/1/8, Manuel Vacelet <man...@gm...>:
> > > I noticed than, sometimes, mysql based phpwikis become slow when there
> > > are several concurrent access.
> > >
> > > I guess it's due to table locking for update operation (phpwiki locks
> > > whole table).
> > >
> > > I'm wondering if it could be a good idea to use innodb table type when
> > > available and replace table locks by transactions as other ACID
> > > complient engines (pgsql, ...) do ?
> >
> > postgresql, oracle or innodb are much better than myisam on crowded
> > servers, yes.
>
> Ok, we will have look on this approach.
> Obviously, we will keep the list informed.

The fastest connect by far has berkeley ("dba - db3 or db4"), but time sorting
(e.g. RecentChanges) and other advanced queries are very slow.
I recommend dba on small wikis < 500 pages, and then postgresql.
Both, ADODB and PearDB behave fine now. PDO is not that well tested.
dba has serious locking issues with sessions.
>From time to time you'll have to delete the session.db(3,4) file when
it is OS locked. But still better than with gdbm.

For the next release I will work for sql db's on extracting the standard
page and version data properties from serialized blobs into real
table columns.
This will require more sql schema updates, but I hope action=upgrade
will be good enough to do that automatically.

> > BTW: can I expect an updated french translation for the new 1.3.13 features?
>
> I think Sabri (who's working with me on the subject) already gave to
> you the small work he did on the subject.

Thanks.
I checked it in and will do the 1.3.13 release after the remaining
php-5.2.0 checks hopefully tommorrow.

The new 5.2 constructor strictness or the new __toString method can be
the culprit.

Next week I'll be offline in Koeln for some days.
-- 
Reini Urban
http://phpwiki.org/              http://murbreak.at/
http://spacemovie.mur.at/   http://helsinki.at/

Re: [Phpwiki-talk] Phpwiki and Mysql slowness

[Manuel V. <man...@gm...>]

2007/1/13, Reini Urban <ru...@x-...>:
> 2007/1/12, Manuel Vacelet <man...@gm...>:
> > 2007/1/9, Reini Urban <ru...@x-...>:
> > > 2007/1/8, Manuel Vacelet <man...@gm...>:
> > > > I noticed than, sometimes, mysql based phpwikis become slow when there
> > > > are several concurrent access.
> > > >
> > > > I guess it's due to table locking for update operation (phpwiki locks
> > > > whole table).
> > > >
> > > > I'm wondering if it could be a good idea to use innodb table type when
> > > > available and replace table locks by transactions as other ACID
> > > > complient engines (pgsql, ...) do ?
> > >
> > > postgresql, oracle or innodb are much better than myisam on crowded
> > > servers, yes.
> >
> > Ok, we will have look on this approach.
> > Obviously, we will keep the list informed.
>
> The fastest connect by far has berkeley ("dba - db3 or db4"), but time sorting
> (e.g. RecentChanges) and other advanced queries are very slow.
> I recommend dba on small wikis < 500 pages, and then postgresql.

FYI, today there is 29000+ pages in our wiki_page table (even if most
of them are automaticatly created from pgsrc).

> For the next release I will work for sql db's on extracting the standard
> page and version data properties from serialized blobs into real
> table columns.
> This will require more sql schema updates, but I hope action=upgrade
> will be good enough to do that automatically.

This is very intresting, do you exepect any performances enhancement
with this upgrade ?
It could be an opportunity for us to contribute our patch to allow
several wiki instances to be stored in one table.

> > > BTW: can I expect an updated french translation for the new 1.3.13 features?
> >
> > I think Sabri (who's working with me on the subject) already gave to
> > you the small work he did on the subject.
>
> Thanks.
> I checked it in and will do the 1.3.13 release after the remaining
> php-5.2.0 checks hopefully tommorrow.
>
> The new 5.2 constructor strictness or the new __toString method can be
> the culprit.
>
> Next week I'll be offline in Koeln for some days.

Have a nice trip !

-- Manuel

Re: [Phpwiki-talk] Phpwiki and Mysql slowness

[Reini U. <ru...@x-...>]

2007/1/17, Manuel Vacelet <man...@gm...>:
> FYI, today there is 29000+ pages in our wiki_page table (even if most
> of them are automaticatly created from pgsrc).
>
> > For the next release I will work for sql db's on extracting the standard
> > page and version data properties from serialized blobs into real
> > table columns.
> > This will require more sql schema updates, but I hope action=upgrade
> > will be good enough to do that automatically.
>
> This is very intresting, do you exepect any performances enhancement
> with this upgrade ?
> It could be an opportunity for us to contribute our patch to allow
> several wiki instances to be stored in one table.

It will be a trade-off of the SQL-relation access against a php serialize.
serialize with objects is very slow. Here with the pages and versions
we have only hashes.
I wonder also if it will be worth the trouble.

-- 
Reini Urban
http://phpwiki.org/              http://murbreak.at/
http://spacemovie.mur.at/   http://helsinki.at/