Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister
 
PerlMonks  

Re^4: Do I need to use Coro instead of threads/forks

by mohan2monks (Beadle)
on Sep 29, 2014 at 13:27 UTC ( [id://1102354]=note: print w/replies, xml ) Need Help??


in reply to Re^3: Do I need to use Coro instead of threads/forks
in thread Do I need to use Coro instead of threads/forks

Yes BrowserUK your understanding is correct.
What i meant with main program must wait was exactly in the sense that i must aggregate content and hence cannot detach threads. (i never thought of queuing thinking it will be hard to manage)
Or can i try one of your excellent suggestion here Re: Why Coro?. using OS threads for each vendor and then use coros inside them to fulfill new requirement.
May be that should give me best of both.
Please correct me if i am wrong.

Replies are listed 'Best First'.
Re^5: Do I need to use Coro instead of threads/forks
by BrowserUk (Patriarch) on Sep 29, 2014 at 13:41 UTC
    Or can i try one of your excellent suggestion here Re: Why Coro?. using OS threads for each vendor and then use coros inside them to fulfill new requirement.

    For just 10 threads, mixing Coro/threads would be overkill. (It has also never been confirmed to me that Coro is thread safe.) Personally, I'd stick to the known simplicity of threads. Also, if you go the mixed architecture route, you may find yourself out in the cold as far as support is concerned. I'm pretty sure that the Coro author doesn't do threads; and I don't do Coro; so you'd be on your own if things go tits-up.

    Also, unless your vendors are unusually tolerant; if you going hitting their websites with multiple concurrent requests, you are likely to get your accounts suspended. You may even find that hitting them with large numbers of requests serially with be frowned upon unless you put some delays between each request.

    My advice is: stick to one thread per vendor and a simple serial loop over the request to each vendor. Once you have that working, you can benchmark and look for opportunities to improve performance if it proves necessary.


    With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.

      Thanks for your support.
      I have tried both approaches with OS threads and Coro.
      As above started one OS thread per vendor (used limited functionality for 3 vendors) and serial loop for inside calls per thread.
      With Coro started 3 threads and each doing inside calls asynchronously.
      Even though Coro seems to fetch all results in parallel overall response time for Coro is much higher.
      Is this because Coro is running in a single process while OS threads has 4.
      I thought as my scripts waits for IO for larger amount of time compared to actually process the received data Coro should win.

      I have logged request and response times for SOAP calls for both as below.

      Using OS threads total time 13 seconds Start time Tue Sep 30 15:29:00 2014 Request 859 sent time Tue Sep 30 15:29:01 2014 #thread 1 Request 532 sent time Tue Sep 30 15:29:01 2014 #thread2 Request 906 sent time Tue Sep 30 15:29:02 2014 #thread3 Response 859 receive time Tue Sep 30 15:29:03 2014 #thread 1 respon +se Request 155 sent time Tue Sep 30 15:29:03 2014 Response 532 receive time Tue Sep 30 15:29:03 2014 #thread 2 respon +se Request 232 sent time Tue Sep 30 15:29:04 2014 Response 906 receive time Tue Sep 30 15:29:04 2014 #thread 3 respon +se Request 870 sent time Tue Sep 30 15:29:04 2014 Response 870 receive time Tue Sep 30 15:29:06 2014 Request 570 sent time Tue Sep 30 15:29:06 2014 Response 232 receive time Tue Sep 30 15:29:07 2014 Response 155 receive time Tue Sep 30 15:29:07 2014 Request 461 sent time Tue Sep 30 15:29:07 2014 Response 570 receive time Tue Sep 30 15:29:09 2014 Request 585 sent time Tue Sep 30 15:29:09 2014 Response 585 receive time Tue Sep 30 15:29:10 2014 Response 461 receive time Tue Sep 30 15:29:10 2014 Request 479 sent time Tue Sep 30 15:29:10 2014 Response 479 receive time Tue Sep 30 15:29:13 2014 Using Coro's total time 31 sec Coros Start time Tue Sep 30 16:03:53 2014 Request 812 sent time Tue Sep 30 16:03:53 2014 #thread1 Request 923 sent time Tue Sep 30 16:03:54 2014 #thread2 Request 942 sent time Tue Sep 30 16:03:57 2014 #thread3 Response 812 receive time Tue Sep 30 16:03:59 2014 #thread1 respons +e Response 923 receive time Tue Sep 30 16:04:00 2014 #thread2 respons +e Response 942 receive time Tue Sep 30 16:04:01 2014 #thread3 respons +e # individual threads starting sub threads async Request 312 sent time Tue Sep 30 16:04:01 2014 Request 607 sent time Tue Sep 30 16:04:02 2014 Request 578 sent time Tue Sep 30 16:04:03 2014 Request 675 sent time Tue Sep 30 16:04:04 2014 Request 310 sent time Tue Sep 30 16:04:05 2014 Request 720 sent time Tue Sep 30 16:04:06 2014 Request 502 sent time Tue Sep 30 16:04:07 2014 Request 867 sent time Tue Sep 30 16:04:08 2014 Response 312 receive time Tue Sep 30 16:04:11 2014 Response 607 receive time Tue Sep 30 16:04:13 2014 Response 578 receive time Tue Sep 30 16:04:16 2014 Response 675 receive time Tue Sep 30 16:04:18 2014 Response 310 receive time Tue Sep 30 16:04:21 2014 Response 720 receive time Tue Sep 30 16:04:22 2014 Response 502 receive time Tue Sep 30 16:04:24 2014 Response 867 receive time Tue Sep 30 16:04:26 2014

      May be i am better of with BrowserUK suggested approach or have not understood Coro correctly.
      please suggest.

        First I'd say that without you publish the code behind those two run traces, you'll not get anyone very exited about the comparison. It could well be that you've some fundamental error in your coding of one or both solutions.

        That said. I doubt the comparison will come as any great surprise to anyone who has though about it.

        Think of it like a small supermarket that has 4 checkouts. On one day, there are also 4 checkout operators. On another day, all 4 checkouts are operating but only one operator flitting between the tills on demand.

        Using cooperative multitasking (alone*) on a machine with multiple cores will always leave 75% of your potential throughput untapped.


        With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://1102354]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others imbibing at the Monastery: (4)
As of 2024-03-28 16:43 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found