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

--
Sriram Krishnan

http://www.dotnetjunkies.com/weblog/sriram


"Cablito" <cablito (AT) dontspam (DOT) com> wrote

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.


"Sriram Krishnan" <ksriram (AT) NOSPAMgmx (DOT) net> escreveu na mensagem
news:%23QI%23qwUsEHA.3268 (AT) TK2MSFTNGP09 (DOT) phx.gbl...

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.

--
Justin Rogers
DigiTec Web Consultants, LLC.
Blog: http://weblogs.asp.net/justin_rogers

"Cablito" <cablito (AT) dontspam (DOT) com> wrote

Cablito <cablito (AT) dontspam (DOT) com> wrote:
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.

--
Jon Skeet - <skeet (AT) pobox (DOT) com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Can I therefore assume the encoding classes aren´t memory efficient?


"Justin Rogers" <Justin (AT) games4dotnet (DOT) com> escreveu na mensagem
news:eHc9uIrsEHA.3320 (AT) TK2MSFTNGP15 (DOT) phx.gbl...

"Cablito" <cablito (AT) dontspam (DOT) com> wrote

"Cablito" <cablito (AT) dontspam (DOT) com> wrote


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.


--
Justin Rogers
DigiTec Web Consultants, LLC.
Blog: http://weblogs.asp.net/justin_rogers

"David Browne" <davidbaxterbrowne no potted meat (AT) hotmail (DOT) com> wrote

"Justin Rogers" <Justin (AT) games4dotnet (DOT) com> wrote

That's a good point. And the problem with writing your own pattern matching
is that array access in safe code is slow.
David