|
|
In that case, why even bother with writing a ReplayingDecoder implementation for debugging/testing? Like I said, the extra logic needed for a FrameDecoder isn't really that hard...Originally Posted by iKilem
I guess it's a tradeoff between cleaner code and performance. But until I see actual numbers, I'm going to call this premature optimisation.
I really doubt that in a server with 2000 players the packet decoding would be the bottleneck.
this is why i avoid Java, so many design abstractions
obviously NIO, not much of a discussion.
blocking IO is faster than NIO by a bit, but it blocks...
you can block with NIO, which will give you better performance than IO, but you need a thread per client model
for best performance, just use NIO (no API), either blocking or non-blocking.
something you continued to miss until i pointed it out... which you can't really be doing while programming
EDIT: not here to argue... to answer your statement, no my implementation is not bad, i used the reactor pattern and also i would like to see someone try the blocking thread per client model with nio, haven't tried it myself
I wouldn't. Its counterproductive, and ultimately handicapping your server due to the overhead of the exorbitant number of threads needed. Speed is always good but scalability and practicality are more important in my opinion. To tell the truth, its unpractical to have a host with the physical capabilities of holding a large amount of connections using that design.
As a result, I don't think that anyone should waste their time following that model.
Originally Posted by blakeman8192
it's not handicapping your server..
i think you overestimate the overhead, and of course, speed is way more important then overhead in the case of an MMORPG (if it's practical, and in this case it is practical, 2000 threads? pfft, java can handle thousands more than that).
the trade off is simply: speed at the cost of more processing power, and there's nothing wrong with that
I don't know if I speak for myself only, but the average thread on windows takes roughly 2mb ram.
2 mb ram with 2000 connections is roughly 4 gigabytes ram. The ironic part is that the memory is dedicated to those specific connections only and can't be reused or utilized by the rest of your program.
As a result, I still think that it is inefficient, because my pockets are not lined with gold.
Also, man, I know your smart as hell, you don't have to prove that to me by posting stuff to prove the errors of my ways by saying that threads take less memory on linux.
Originally Posted by blakeman8192
that's a gross overstatement, i think you should double check how much memory a thread really takes, you can both specify stack size (default size 512kb??? i think not sure) and then rest of memory thread uses is shared memory between threads (-Xss and -Xmx on command line to specify thread stack size and max memory used).
i don't know if your computer has a defect or something, but you should be able to have 2000 threads A-ok.
at 2013 threads, program is using 116,340KB of memory (that's with all the threads waiting. with the threads looping at 600ms, the memory goes down to ~105,000KB) which is not alot, considering my laptop has 4GB and yeah, you don't want to hear this but, jagex doesn't host their servers on windows and neither should you (but it will suffice for an RSPS)
You sure about that?
By overhead, are you talking about memory overhead? (Surely you're not talking about speed overhead, because that wouldn't make any sense in your statement.) I'd say that keeping memory contention low is the priority, but that depends on the situation. Perhaps you're fine with with hosting on a 4GB dedi, but I'm sure many people would like to keep their costs low. By design, thread-per-client does not only introduce memory overhead, but speed overhead as well. Using "blocking NIO" is not going to be better. Why would it be? It's still blocking in the end.
What do you mean by "speed at the cost of more processing power"?
| « Are there any server's that's worth playing? | Old school server. » |
| Thread Information |
Users Browsing this ThreadThere are currently 1 users browsing this thread. (0 members and 1 guests) |
Graham
