>>> That seems a bit weird to me. What resolver backend are you using
for
>>> example?

> >In the case of libCURL multi interface, its epoll. In the case of
> >libCURL easy interface with 10 threads, its poll method.

>I meant which resolver backend your libcurl build is using.

>libcurl can be built to use several different resolver backends, and on
*nix the default resolver is using synchronous name resolving and in
such environments a threaded application using libcurl will of course be
faster than a multi interface using one

Yes, it's using default name resolving scheme as I did not make any
changes to libCURL (development configuration) settings meaning, I am
using library as it is with default settings.
I modified my multi interface sample code to launch 10 threads. Still
easy interface threaded application is having better performance than
multi interface threaded application.
Now, if this is the case (threaded EASY interface application with
default name resolving scheme is faster than multi interface
application), is it good to use my existing easy interface threaded
application instead of moving to multi interface? Or is there something
that can be done to multi interface to make it faster. Basically, my
goal is to improve data transfer rate.

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html