Re: RE: Re: [ADMIN] v7.1b4 bad performance

At 09:40 AM 22-02-2001 -0500, Vadim Mikheev wrote:
>> It may be that WAL has changed the rollback
>> time-characteristics to worse than pre-wal ?
>
>Nothing changed ... yet. And in future rollbacks
>of read-only transactions will be as fast as now,
>anyway.

The rollbacks are ok for me at least - even the 6.5.3 rollbacks are ok.

>> > So my guess is that the 7.1 updates (with default
>> > fsync) are significantly slower than 7.0.3 fsync=off
>> > now.
>
>Do you update tables with foreign keys?
>Did you run tests in multi-user or single-user
>environment?

No foreign keys. Multiuser- I had apachebench do a concurrency of two.
e.g.
ab -n 100 -c 2 "<url>"

7.1beta4 snapshot was giving about 22 hits per sec max. 7.0.3 was doing
about 60 hits per sec max. That's a significant difference in speed to me.

Thing is, it was only updating _one_ row in a table with only one row (and
committing). Everything else was selects.

The typical sequence was:

rollback;
begin;
select (session where supplied id and cookie matches and not timed out)
update session and set lastactive to 'now'
commit;
begin;
select (bunch of stuff);
.. (selects but no updates or inserts )
select (bunch of stuff);
rollback;

Any reason for the gradual slow down in both 7.0.3 (e.g. 60 hits/sec to 30)
and 7.1beta4 (e.g. 22 hits/sec to 15)? The session table expands due to the
concurrency? 

Should I switch to "select session .... for update"? Would that reduce the
gradual slowdown? 

The reason why I do so many rollbacks is because that appears to be the
recommended way to begin a new transaction using perl DBI - not supposed to
issue an explicit BEGIN. 

I do the first rollback/begin so I don't get stale transaction timestamps
from the previous  "last rollback".

I do the last rollback/begin in order to free up any locks, before waiting
for an undeterminable time for the next connection.

Cheerio,
Link.