similar to: IMAP stress testing tool

Hi. Does anyone know of a good imap stress testing tool? And one which supports SEARCH commands? I have to compare Courier and Dovecot. I already did some tests using a modified postal/rabid package. I would be thankfully for any hints. Best regards. Erny Yaco Sistemas Spain

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I need some user grade windows-based IMAP stress tool. I have a situation with a lot of "disconnect" error on the user side (outlook, thunderbird and outlook express) but no sign of error on the Dovecot server. Between clients and server there are a LAN of dubious performance and a ZyWALL. I have already removed every kind of packet

I spent the last 5 hours or so updating my imaptest tool. It's beginning to become almost like a real IMAP client. http://dovecot.org/tools/imaptest10.c contains a version that compiles against Dovecot v1.0 (instead of against CVS HEAD). imaptest is this tool that I've been using for a few years to do stress testing. It can create a lot of dummy IMAP client connections which execute some

I've tried to stress test dovecot 1.1.4 with imaptest for days without any assertion failure or crash. Just some "got too little data" messages. So far it's the most stable 1.1.x version. Today a user got this imap segfault with vanilla 1.1.4 (I don't know if it's something you have already fixed in current tree). The user didn't complain of anything, I've just

Some new features in CVS HEAD are: - v1.0 saves most of the data to dovecot.index.cache only when the client is FETCHing the messages. With mboxes the message headers are saved while parsing the mbox, which is almost the same thing. With CVS HEAD the dovecot.index.cache file is updated already when the new messages are being saved (with deliver or IMAP APPEND). This avoids reading the message

Now that I have a working kvm setup, I thought I'd finally try how Zimbra works. This is mainly some microbenchmarking, so it may not have much to do with actual performance in real life. Setup: - 1GB memory given to kvm (from host's 2GB) - Intel Core 2 6600 (kvm uses only one CPU) - CentOS 5 - 15GB qcow2 image on XFS filesystem - Zimbra 5.0 RC2 RHEL5 x86_64 - Dovecot latest hg,

Hello all. May be not in right list but... I have a email system based on: Exim-4.69 + Dovecot-1.1.11 on FreeBSD-7.1 I need to make a stress test on it. Something like a 1000 concurrent conection to IMAP and SMTP. What tool can help me? -- Best regards, Proskurin Kirill

I've finally added support for "normal" command/reply tests for my imaptest program (http://imapwiki.org/ImapTest). My plan is that imaptest will include some generic IMAP compliancy tests and Dovecot will include some more strict Dovecot-specific checks. "make dist" will run all these tests before building a tarball, so in future I shouldn't be able to release

On 23 May 2017, at 12.10, aduprat <aduprat at linagora.com> wrote: > > Hi, > > I'm an Apache James committer and we are curious to use imaptest in order to validate our IMAP protocol implementation. > I'm using the nightlybuild : imaptest-20170506 > > > I follow the examples given in the /T/ /est IMAP server compliancy/ examples

Hey guys, Has anybody ever used imaptest to benchmark *ONLY* reads? I'm trying to run a battery of tests in my new cluster and apparently no combination of parameters works, because fetch instruction doesn't run. Below is the command I'm using and its partial output imaptest/src/imaptest host=$SERVER_IP port=143 user=teste%d at example%d.com pass=$TEST_PASS users=10 domains=10

I thought I'd try benchmarking with dbmail (v2.2.4) to see how much slower a SQL backend could actually be. Skip to bottom for the conclusions. Originally I ran the tests with the databases being in XFS filesystem. MySQL's performance was horrible. It went 3-7x faster with ext3. MySQL 5.0.30 backend (innodb): ./imaptest clients=1 - append=100 seed=1 secs=30 msgs=1000000 logout=0

I cleaned up the lib-storage code a bit so that it's easier to write support for new mailbox formats. It could still use a bit of cleaning up. Anyway, I thought I'd try how easy it would be to implement Cyrus-like mail store which would consist of only Dovecot's index files and "<uid>." message files. Flags and everything else is kept only in Dovecot's index files

Hello list, we continue our tests using Dovecot on a RHEL 6.1 Cluster Backend with GFS2, also we are using dovecot as a Director for user node persistence, everything was ok until we started stress testing the solution with imaptest, we had many deadlocks, cluster filesystems corruptions and hangs, specially in index filesystem, we have configured the backend as if they were on a NFS like setup

http://dovecot.org/tools/imaptest.c now keeps track of messages' metadata and complains if they change. It relies on Message-ID: header being unique in the source mailbox, otherwise it'll give bogus errors. I might fix that some day. I changed the code from using simple line-based parsing to Dovecot's imap-parser code. Unfortunately it looks like it's pretty slow. At least I'm

> > I'm in the "testing and proof" stage of converting from Windows NT 4 to > Linux/SAMBA and I'm very interested in any "stress testing" that you (or > anyone else) could point me to. If you get your DOS Program working, > would you mind sharing it? > > The other thing that interests me in your post is the corruption of a > Paradox database.

> On 18 Sep 2019, at 0.29, Marc Roos via dovecot <dovecot at dovecot.org> wrote: > > I am also testing rbox plugin ;) So I would like just the imaptest tool > to work. No one else ever run into this? I saw something similar on the > mailing list a long time ago. Yes I saw this in my rbox testing long time ago. I thought that rbox was just not mature enough back then. But

http://dovecot.org/releases/dovecot-1.0.rc13.tar.gz http://dovecot.org/releases/dovecot-1.0.rc13.tar.gz.sig I'll just keep on making new releases now whenever something important is fixed. Hopefully there shouldn't be many left anymore. Most of the bugs fixed in this release were found by stress testing with my imaptest tool (http://dovecot.org/tools/imaptest.c). If you're interested

http://dovecot.org/releases/dovecot-1.0.rc13.tar.gz http://dovecot.org/releases/dovecot-1.0.rc13.tar.gz.sig I'll just keep on making new releases now whenever something important is fixed. Hopefully there shouldn't be many left anymore. Most of the bugs fixed in this release were found by stress testing with my imaptest tool (http://dovecot.org/tools/imaptest.c). If you're interested

Hi, How can I stress test an asterisk IVR? I am looking for some kind of sip phone which can be "programmed" to send out digits after specified time to simulate users pressing menu items. If it can originate large number of calls simultaneously then it's great! Does any one have any recommendations ? Any other method to stress test an IVR call flow? with regards, raj

Dear Folks, Using head of imaptest with dovecot 2.1, I am attempting to put a heavy load on the server, with insufficient success. I made 15000 user accounts, put them in to a file, one per line. Then I ran imaptest with ./imaptest userfile=../../imap-test-userlist-15001.txt clients=15001 pass=SECRETPASSWORD But CPU load is only reaching 20. I put an mbox containing 67 messages into