Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Re: [dev] [commits] Horde branch master updated. 26bc04dcbb9b9261863531ad7be1385a8c96a031

2 views
Skip to first unread message

Jan Schneider

unread,
May 7, 2013, 5:40:41 AM5/7/13
to

Zitat von Michael M Slusarz <slu...@horde.org>:

> Quoting Michael M Slusarz <slu...@horde.org>:
>
>> Quoting Jan Schneider <j...@horde.org>:
>>
>>> commit 8f9d271fb37cbe951c5698aa37425a1657990060
>>> Author: Jan Schneider <j...@horde.org>
>>> Date: Mon May 6 23:17:52 2013 +0200
>>>
>>> MongoDB is sloooow. Extend expiry time by a magnitude.
>>>
>>> framework/Lock/test/Horde/Lock/Storage/TestBase.php | 6 +++---
>>> 1 files changed, 3 insertions(+), 3 deletions(-)
>>>
>>> http://git.horde.org/horde-git/-/commit/8f9d271fb37cbe951c5698aa37425a1657990060
>>
>> MongoDB for me is at *least* an order of magnitude faster for me
>> than the SQL backends (Postgres). And I'm running SQL natively on
>> the same machine while running MongoDB in an entirely separate
>> virtual machine with minimal resources (512 MB total for the VM).
>
> For the record: some of this gain may be due to the smaller/simpler
> code being run on the Horde side. So this super unofficial
> benchmark is solely me looking at a PHP process (or a portion of it)
> and eyeballing the differences when swapping between the two
> drivers. And this was with the Horde_Imap_Client cache driver,
> which uses multiple tables, so the JOIN queries in the SQL DB are
> not necessarily tuned all that well.

Not sure what the issue is, but the adding and reading a record, then
adding another one inside this unit test took more than 10 seconds.
Thus the test failures. Probably some issue with my local MongoDB
installation.
--
Jan Schneider
The Horde Project
http://www.horde.org/

--
dev mailing list
Frequently Asked Questions: http://wiki.horde.org/FAQ
To unsubscribe, mail: dev-uns...@lists.horde.org

Michael M Slusarz

unread,
May 7, 2013, 12:37:11 PM5/7/13
to
Oh... I think I know why. For unit tests, we currently destroy the
entire MongoDB database after every test (via setUp; not once per test
file i.e. with setUpBeforeClass). Creating a new MongoDB database is
an expensive operation. Maybe not 10 seconds expensive normally, but
possibly a second or so.

This could be optimized a bit to simply drop all *collections* in
setUp and only build the DB once per test file. Although I don't see
anywhere near this kind of slowness so I don't have a heck of a lot of
motivation to do this.

michael

___________________________________
Michael Slusarz [slu...@horde.org]
0 new messages