 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / .NET Framework / Performance / October 2004Serious Performance, can .NET handle it?
I want to write a HTTP proxy with C#, but I am unsure if it will scale; I need to handle at least 5000 simultaneous users per server. The servers can be MP with 2GB ram, that isn?t the issue. I will be filtering the http streams for keywords, so there is a processing load there. Well - only one way to find out - try writing one and throw the tester at it  SignatureSriram Krishnan http://www.dotnetjunkies.com/weblog/sriram >I want to write a HTTP proxy with C#, but I am unsure if it will scale; > [quoted text clipped - 3 lines] > filtering the http streams for keywords, so there is a processing load > there. in a way you are absolutelly right.... but the "test" environment is an ISP client base of thousands of paying customers. No room for mistakes. > Well - only one way to find out - try writing one and throw the tester at it > [quoted text clipped - 5 lines] > > filtering the http streams for keywords, so there is a processing load > > there. Naively programmed, .NET is not going to scale. There are many mistakes you can make in this process. Honestly, any language would suffer the same demise. As long as you know what you are doing, and stick to stream management operations you should be fine. Because you are going to be doing stream management, the BCL classes are not going to help you much. You can't, for instance, arbitrarily start pulling strings out of a stream (aka using encodings) because you are going to quickly run into GC problems. SignatureJustin Rogers DigiTec Web Consultants, LLC. Blog: http://weblogs.asp.net/justin_rogers > in a way you are absolutelly right.... but the "test" environment is an ISP > client base of thousands of paying customers. No room for mistakes. [quoted text clipped - 9 lines] >> > filtering the http streams for keywords, so there is a processing load >> > there. Can I therefore assume the encoding classes aren?t memory efficient? > Naively programmed, .NET is not going to scale. There are many mistakes you > can make in this process. Honestly, any language would suffer the same demise. [quoted text clipped - 18 lines] > >> > filtering the http streams for keywords, so there is a processing load > >> > there. > Can I therefore assume the encoding classes aren?t memory efficient? No, they are fine, but you must take care. > Can I therefore assume the encoding classes aren?t memory efficient? oops, The encoding classes are fine, but you must be careful. This method char[] GetChars(byte[]); Allocates a new char[] for each call. In a high-performance application, it should be avoided. Instead use this one: int GetChars(byte[], int, int, char[], int); Which requires you to supply your own char[], which you can reuse over and over. That's the kind of thing to keep in mind when asking wether .NET can handle the performance. Exactly the same issues occur with Java and C++. For high-performance applications you have to know when you are allocating new memory. All these languages make it easy to allocate memory without knowing it, and so you just need to take care. David Also, there are NO routines for examining a character array, only a string. So even if you use the memory efficient character scanning methods you'll need to write all of your character and pattern matching from scratch. That is more of where I was heading with encodings, since most users will want the pattern matching available on either the string or regular expression classes. SignatureJustin Rogers DigiTec Web Consultants, LLC. Blog: http://weblogs.asp.net/justin_rogers >> Can I therefore assume the encoding classes aren?t memory efficient? >> [quoted text clipped - 23 lines] > > David > Also, there are NO routines for examining a character array, only a > string. So even if you use the memory efficient character scanning [quoted text clipped - 4 lines] > will want the pattern matching available on either the string or regular > expression classes. That's a good point. And the problem with writing your own pattern matching is that array access in safe code is slow. David > in a way you are absolutelly right.... but the "test" environment is an ISP > client base of thousands of paying customers. No room for mistakes. If you were really thinking of deploying *anything* without testing it in a less risky fashion, I think you're playing with fire. Throwing the tester at something should *not* mean deploying it in a live production environment. I believe what Sriram was saying was that you should build it (or at least a prototype) then rig up a test system (which should almost certainly consists of many different machines) to stress test the app. SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet If replying to the group, please do not mail me too Exactly.You don't want to deploy something unless knowing for certain that it can scale to 5000 users SignatureSriram Krishnan http://www.dotnetjunkies.com/weblog/sriram >> in a way you are absolutelly right.... but the "test" environment is an >> ISP [quoted text clipped - 9 lines] > least a prototype) then rig up a test system (which should almost > certainly consists of many different machines) to stress test the app. Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.