The last slow performance is my fault, I was calling
FailoverManager::execute() for every pending message.

Now I have improved my program so it can do as much as 5000 messages per
second, but it's still slower than I would have expected. So I wrote a
test program deriving from the replay_sender test example, to test the
performance of c++ client using FailoverManager, the code is pasted
below.
The result is not much different from my real application, the maximum
update rate is about 5000-6000 messages per second. Can anyone please
have a look at my test and point out if any reason could be the course
of slow performance. If JMS can do as much as 100K, I would expect the
c++ can achieve similar rate.


#include <qpid/client/FailoverManager.h>
#include <qpid/client/Session.h>
#include <qpid/client/AsyncSession.h>
#include <qpid/client/Message.h>
#include <qpid/client/MessageReplayTracker.h>
#include <qpid/Exception.h>
#include <iostream>
#include <sstream>

using namespace qpid;
using namespace qpid::client;
using namespace qpid::framing;

using namespace std;

class Sender : public FailoverManager::Command
{
  public:
    Sender(const std::string& queue, uint count);
    void execute(AsyncSession& session, bool isRetry);
    uint getSent();
        uint getCount() const { return count; }
  private:
    MessageReplayTracker sender;
    const uint count;
    uint sent;
    Message message;
    
};

Sender::Sender(const std::string& queue, uint count_) : sender(10),
count(count_), sent(0) 
{
    message.getDeliveryProperties().setRoutingKey(queue);
}

void Sender::execute(AsyncSession& session, bool isRetry)
{
    if (isRetry) sender.replay(session);
    else sender.init(session);
    time_t start = time(NULL);
    while (sent < count) {
        stringstream message_data;
        message_data << "<Hi, i'm a big fat useless message being sent
to mess up your queue,i'm a big fat useless message being sent to mess
up your queue,i'm a big fat useless message being sent to mess up your
queue,i'm a big fat useless message being sent to mess up your queue,i'm
a big fat useless message being sent to mess up your queue,i'm a big fat
useless message being sent to mess up your queue,i'm a big fat useless
message being sent to mess up your queue,i'm a big fat useless message
being sent to mess up your queue, over> - ";
        message_data << ++sent;
        message.setData(message_data.str());
        message.getHeaders().setInt("sn", sent);
        sender.send(message);
        if (count > 1000 && !(sent % 1000)) {
            std::cout << "sent " << sent << " of " << count <<
std::endl;
        }
    }
    time_t end = time(NULL);
    std::cout << "time spent: " << end-start << " seconds"<< std::endl;
    Sleep(10000);
}

uint Sender::getSent()
{
    return sent;
}

int main(int argc, char ** argv) 
{
    ConnectionSettings settings;

    std::string url = "amqp:tcp:myhost:5672";
    std::vector<Url> urlVect;
    urlVect.push_back(Url(url));
    
    FailoverManager connection(settings);
    connection.connect(urlVect);
    Sender sender("message_queue", 50001);
    try {
        connection.execute(sender);

        std::cout << "Sent " << sender.getSent() << " messages."
<std::endl;
        connection.close();
        return 0;  
    } catch(const std::exception& error) {
        std::cout << "Failed: " << error.what() << std::endl;
    }
    return 1;
}





-----Original Message-----
From: Carl Trieloff [mailto:[email protected]] 
Sent: 09 June 2009 18:16
To: [email protected]
Subject: Re: do we know what's the highest update rate qpid can achieve?


Depends on disk, whether using Async etc... should easily be able to do 
close to 100k/s before
you get into big disk configurations.

What client are you using?  i.e. JMS is sync by default. quick testing 
can be done with perftest and
using the durable options on perftest.

based on the numbers I expect you are running sync.. also are you using 
txns?

Carl.

Shan Wang wrote:
> I've just done a simple test, c++ client and server, message size is
500
> bytes, deliveryProperity set to PERSISTENT, the queue is durable,
using
> default exchange, cluster and client are running in the same domain
but
> different hosts. The update rate achieved is about 100 message/second,
> which is a bit lower than I expected. Have we done any comprehensive
> tests about the update rate qpid can support? Is there any
configuration
> I can play with to increase the update rate?
>
>  
>
> Thanks,
>
> Shan
>
> The information contained in this email is strictly confidential and
for the use of the addressee only, unless otherwise indicated. If you
are not the intended recipient, please do not read, copy, use or
disclose to others this message or any attachment. Please also notify
the sender by replying to this email or by telephone (+44 (0)20 7896
0011) and then delete the email and any copies of it. Opinions,
conclusions (etc.) that do not relate to the official business of this
company shall be understood as neither given nor endorsed by it. IG
Index plc is a company registered in England and Wales under number
01190902. VAT registration number 761 2978 07. Registered Office: Friars
House, 157-168 Blackfriars Road, London SE1 8EZ. Authorised and
regulated by the Financial Services Authority. FSA Register number
114059.
>
>   


---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:[email protected]

The information contained in this email is strictly confidential and for the 
use of the addressee only, unless otherwise indicated. If you are not the 
intended recipient, please do not read, copy, use or disclose to others this 
message or any attachment. Please also notify the sender by replying to this 
email or by telephone (+44 (0)20 7896 0011) and then delete the email and any 
copies of it. Opinions, conclusions (etc.) that do not relate to the official 
business of this company shall be understood as neither given nor endorsed by 
it. IG Index plc is a company registered in England and Wales under number 
01190902. VAT registration number 761 2978 07. Registered Office: Friars House, 
157-168 Blackfriars Road, London SE1 8EZ. Authorised and regulated by the 
Financial Services Authority. FSA Register number 114059.

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:[email protected]

Reply via email to