Re[2]: [Haskell-cafe] Optimizing a high-traffic network architecture
Hello Simon, Thursday, December 15, 2005, 4:53:27 PM, you wrote: SM> The 3k threads are still GC'd, but they are not actually *copied* during SM> GC. SM> It'll increase the memory overhead per thread from 2k (1k * 2 for SM> copying) to 4k (4k block, no overhead for copying). Simon, why not to include this in the "base package"? either change something so that a 1k-threads will be not copied during GC, or at least increment default stack size? this will improve performance of other hyper-threaded programs. memory expenses seems not so great -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[2]: [Haskell-cafe] Optimizing a high-traffic network architecture
Bulat, On Dec 14, 2005, at 9:00 PM, Bulat Ziganshin wrote: TZ> You don't have to check "every few seconds". You can determine TZ> exactly how much you have to sleep - just check the timeout/ event with TZ> the lowest ClockTime. this scenario don't count that we can receive new request while sleeping and if this thread services different waiting periods, the new message may require more earlier answer The scenario above does account for the situation that you are describing. We will always retrieve the minimum key and will fire the timer as long as it has expired. My timers don't need to be precise so this works for me. checkTimers :: IO () checkTimers = do t <- readMVar timers -- takes it and puts it back case M.size t of -- no timers 0 -> threadDelay timeout -- some timers _ -> do let (key@(Timer time _), io) = M.findMin t TOD now _ <- getClockTime if (time <= now) then do stopTimer key try $ io -- don't think we care return () else threadDelay timeout checkTimers i repeat my thought - if you have one or several fixed waiting periods (say, 1 sec, 3 sec and 1 minute), then you don't need even to sort requests - just use one waking thread for each waiting period and requests will be arrive already sorted. in this way, you can really sleep as Tomasz suggests I do not have several fixed waiting periods, they are determined by the user. Joel -- http://wagerlabs.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Optimizing a high-traffic network architecture
Hello Tomasz, Wednesday, December 14, 2005, 10:48:43 PM, you wrote: TZ> You don't have to check "every few seconds". You can determine TZ> exactly how much you have to sleep - just check the timeout/event with TZ> the lowest ClockTime. this scenario don't count that we can receive new request while sleeping and if this thread services different waiting periods, the new message may require more earlier answer TZ> On Wed, Dec 14, 2005 at 07:11:15PM +, Joel Reymont wrote: >> I figure I can have a single timer thread and a timer map keyed on >> ClockTime. I would try to get the min. key from the map every few >> seconds, compare it to clock time, fire of the event as needed, >> remove the timer and repeat. i repeat my thought - if you have one or several fixed waiting periods (say, 1 sec, 3 sec and 1 minute), then you don't need even to sort requests - just use one waking thread for each waiting period and requests will be arrive already sorted. in this way, you can really sleep as Tomasz suggests Wednesday, December 14, 2005, 11:04:38 PM, you wrote: JR> Right, thanks for the tip! I would need to way a predefined amount of JR> time when the map is empty, though. no. you just read next message from the Chan (but don't use MVar here! ;) -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Optimizing a high-traffic network architecture
Hello Joel, Thursday, December 15, 2005, 5:13:17 PM, you wrote: >>> The statistics are phys/VM, CPU usage in % and #packets/transfer >>> speed >>> >>> Total: 1345, Lobby: 1326, Failed: 0, 102/184, 50%, 90/8kb >>> Total: 1395, Lobby: 1367, Failed: 2 >>> Total: 1421, Lobby: 1394, Failed: 4 >>> Total: 1490, Lobby: 1463, Failed: 4, 108/194, 50%, 110/11Kb >>> Total: 1574, Lobby: 1546, Failed: 4, 113/202, 50%, 116/11kb >> >> Hmm, your machine is spending 50% of its time doing nothing, and the >> network traffic is very low. I wouldn't expect 2k connections to pose >> any problem at all, so further investigation is definitely required. JR> That's CPU utilization by the program. My laptop is actually running JR> a lot of other stuff as well, although the other stuff is not JR> consuming much CPU. if your program has something to do, but cpu usage is less that 100%, this means (at least in windows), that your program is just works in some system calls, which waits for hardware. for example, read from disk. your program may wait for network i/o, logging i/o. try to disable using these code parts and see how cpu utilization will change -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
