Re: DHCP Server Socket receive performance

Discussion in 'Java' started by Katie Wright, Aug 27, 2003.

  1. Katie Wright

    Katie Wright Guest

    Thanks for responding so quickly.

    Personally, I don't have any problems but architect says that the
    prototype server is not returning enough ACKs (ie. responding to
    requests), fast enough and to try to make it run faster.

    I would insert my timings and speed here but getting different results
    on different JVMs which is interesting. I am currently looking into
    this and doing more testing.

    I do a profile and it says that 92% of CPU processing is being taken
    up by the DatagramSocket.receive() and every other line is only taking
    up 0.33% each.

    Maybe it is like Star Trek and Captain Kirk asking Scotty to make the
    Enterprise run faster and I should say "Capt'n, she cannot run any
    faster, or she's gonna blow."

    Right now, the server is only a skeleton of the implementation of the
    JDHCP API that satistifies the DHCP standard for require communication
    and all of the values (IP, lease, etc) are hardcoded. So once the
    values are not hardcoded, that will degrade the speed ... hopefully
    only slightly.

    Yes, I realized that it is a blocking call which is why I tried the
    DatagramChannel.receive but don't receive any major performance
    improvement.

    Katie Wright

    "Steve Horsley" <_SPAM.net> wrote in message news:<_SPAM.net>...
    > On Tue, 26 Aug 2003 05:44:02 -0700, Katie Wright wrote:
    >
    > > Hello,
    > >
    > > I am currently writing a DHCP Server prototype in Java using the JDHCP
    > > API.
    > >
    > > The server is running as expected but it is not running fast enough.
    > > By profiling, I discovered that the bottleneck is the use the JDHCP
    > > DHCPSocket.receive() which basically is a wrapper for
    > > DatagramSocket.receive().
    > >
    > > I am currently playing around with still implementing the JDHCP API
    > > but bypassing the receive() method for a faster implementation if
    > > possible. I tried DatagramChannels but got a slight performance
    > > downgrade.
    > >
    > > I am playing with different implementations but still have not found
    > > anything faster than DHCPSocket.receive() and was wondering if anyone
    > > could offer me any ideas?
    > > Thanks,
    > >
    > > Katie Wright
    > >

    >
    >
    > Can you explain why you think it's not fast enough? What problems do you
    > have?
    >
    > I am suspicious of the idea that DHCPSocket.receive() might be the
    > problem. Although I am not familiar with the DHCP API, I am familiar with
    > the DatagramSocket.receive(), and don't think it has any performance
    > issues. Remember that it is a blocking call, so the profiler will show a
    > long time spent there while it awaits tne next incoming datagram.
    >
    > Steve
    Katie Wright, Aug 27, 2003
    #1
    1. Advertising

  2. Katie Wright

    Katie Wright Guest

    Hi,

    The thought is that by not responding to enough to client REQUESTs per
    second, the server is not running fast enough.

    I am using a dummy load tester client and I managed to improve its
    performance which in turn improved the server's number because it
    would then wait less for the client to respond.

    However, I am still only hitting around 500 ACKs per second in my most
    common configuration. Numbers vary depending on configuration but
    never hit 1000 mark.

    Architects have talked to a guy who wrote his own DHCP in C++ who
    claims that his can handle 7500 per second and wondering why I am
    having problems matching their numbers in Java.

    Does the setDatagramSocketImplFactory() method on DatagramSocket allow
    me to create my own receive() implementation that I could possibly
    write one that is faster? I am going to do more testing but this is
    what I am going to look into today.

    Yes, I have realized too that there is some network overhead which is
    why I am testing with different configuration including the
    configuration that the server and client are on the same box.

    I don't intend to read a database. I will be reading a configuration
    file. At this point, I did some testing and found that multithreading
    was making the program slower since I am not doing much of anything
    except sending and receiving YET.

    Ideally, I think that architects were hoping to match the 7500 number
    they got from the other DHCP implementation but for now I think they
    are hoping to get 1000 per second.

    Thanks,

    Katie

    "Steve Horsley" <_SPAM.net> wrote in message news:<_SPAM.net>...
    > On Wed, 27 Aug 2003 05:38:37 -0700, Katie Wright wrote:
    >
    > > Thanks for responding so quickly.
    > >
    > > Personally, I don't have any problems but architect says that the
    > > prototype server is not returning enough ACKs (ie. responding to
    > > requests), fast enough and to try to make it run faster.

    >
    > I don't understand what you mean there. Make what run faster? What's not
    > fast enough?
    >
    > > I would insert my timings and speed here but getting different results
    > > on different JVMs which is interesting. I am currently looking into
    > > this and doing more testing.
    > >
    > > I do a profile and it says that 92% of CPU processing is being taken up
    > > by the DatagramSocket.receive() and every other line is only taking up
    > > 0.33% each.

    >
    > That suggests to me that the server is spending maybe 90% of its time
    > waiting for the next packet to arrive.
    >
    > > Maybe it is like Star Trek and Captain Kirk asking Scotty to make the
    > > Enterprise run faster and I should say "Capt'n, she cannot run any
    > > faster, or she's gonna blow."

    >
    > Well, you canna change the laws of pyhsics!
    >
    > > Right now, the server is only a skeleton of the implementation of the
    > > JDHCP API that satistifies the DHCP standard for require communication
    > > and all of the values (IP, lease, etc) are hardcoded. So once the
    > > values are not hardcoded, that will degrade the speed ... hopefully only
    > > slightly.
    > >
    > > Yes, I realized that it is a blocking call which is why I tried the
    > > DatagramChannel.receive but don't receive any major performance
    > > improvement.

    >
    > The architect is not the other end of a WAN link is he? Could this be an
    > issue with the transit time over the WAN making the server appear slow?
    >
    > If you are going to read the database from disk eventually, you might
    > improve performance by multithreading and thereby reducing the amount of
    > time you spend in blocking disk I/O. I guess that's irrelevant if you
    > cache the database in RAM.
    >
    > I'm very surprised that the performance of a DHCP server could become an
    > issue. How many transactions per second are you looking for? Serving an
    > entire class B with 65000 hosts each issuing a request once a minute
    > (unlikely, I think) would only generate a thousand requests a second.
    >
    > Steve
    Katie Wright, Aug 28, 2003
    #2
    1. Advertising

  3. On Thu, 28 Aug 2003 04:45:03 -0700, Katie Wright wrote:

    > Hi,
    >
    > The thought is that by not responding to enough to client REQUESTs per
    > second, the server is not running fast enough.
    >
    > I am using a dummy load tester client and I managed to improve its
    > performance which in turn improved the server's number because it would
    > then wait less for the client to respond.


    You mean the servers is dropping/losing requests?

    Or is the tester single-threaded - wait for a reply before sending the
    next request? If so, try running two or more testers simultaneously to the
    server, to reduce the amount of time that the server spends waiting for
    the next request. If the server really is spending 90% of its time waiting
    for a request, you should be able to support 10 testers concurrently,
    giving nearer 5,000 requests/sec.

    Pay attantion to the way you decode and encode messages too. This may
    become the main factor once you get the waiting time down.


    <snip>


    > I don't intend to read a database. I will be reading a configuration
    > file. At this point, I did some testing and found that multithreading
    > was making the program slower since I am not doing much of anything
    > except sending and receiving YET.


    Make sure you cache it in memory.

    Steve
    Steve Horsley, Aug 28, 2003
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. GHUM
    Replies:
    0
    Views:
    423
  2. yannifan

    DHCP and RAW socket and C

    yannifan, Apr 22, 2007, in forum: C Programming
    Replies:
    1
    Views:
    828
    Walter Roberson
    Apr 22, 2007
  3. Aldric Giacomoni

    Ruby and DHCP (Net::DHCP maybe)

    Aldric Giacomoni, Dec 5, 2008, in forum: Ruby
    Replies:
    1
    Views:
    299
    Eustáquio Rangel
    Dec 5, 2008
  4. Chris Henderson

    detect rogue DHCP server

    Chris Henderson, Mar 17, 2009, in forum: Ruby
    Replies:
    4
    Views:
    176
    Joel VanderWerf
    Mar 17, 2009
  5. Andy Rabagliati

    DHCP server

    Andy Rabagliati, Dec 24, 2006, in forum: Perl Misc
    Replies:
    1
    Views:
    101
    Martijn Lievaart
    Dec 25, 2006
Loading...

Share This Page