You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Konstantin Preißer <kp...@apache.org> on 2013/09/28 19:40:38 UTC
RE: Possible IIS SPDY Redirector for Tomcat
Hi all,
about a year ago, I wrote about an IIS SPDY/3 Redirector written in C# that could be used to redirect requests from IIS to Tomcat, Jetty, or other servers with SPDY/3 support; as an alternative to the ISAPI redirector that uses AJP - see [1]. It uses the new managed module pipeline that is available since IIS 7.0. However, currently it is simply a request forwarder that forwards every request over a SPDY. It does not have load-balancing or similar features.
At that time, I could test the redirector with Jetty, but not with Tomcat as it only had support for SPDY/2. However, I don't know what the current state of the SPDY/3 implementation in Tomcat is (I saw E-Mails from Costin that he wanted to update Tomcat for SPDY/3, but I don't know if it is finished). Maybe someone has information about that?
In my initial mail, I wrote about how to test the redirector with Google's web server. That required an Java NPN tunnel do to this.
However, there is a simpler way to test the Redirector e.g. with IIS 8.0 Express (so you don't need a Server OS; just a normal client Windows) and Jetty (using a non-SSL SPDY connector). That way you can test the redirector just like if it would forward the requests to Tomcat. Below is a guide how to set up IIS 8.0 express and Jetty to test the SPDY redirector.
I think that when comparing an SPDY redirector (C#) to the existing ISAPI redirector (C), there are advantages and disadvantages:
Pro:
- Because the code is using managed C# instead of native C(++), just like with Java it is easier to use advanced features like threading etc., and it should be easier to maintain. E.g. you can program the same way that you would with a Servlet for reading requests and writing responses. Also e.g. if an error occurs, you will get an exception instead of a crash.
- It is easier to install in IIS: You don't need to add a virtual directory (and don't forget to set execute permissions for the DLL file etc) - you just add a reference in the web.config file.
- SPDY should allow for forwarding WebSocket connections (available with IIS 8.0+), which AJP doesn't. However, I do not yet have looked how to use WebSockets with IIS 8 and over SPDY.
- IIS (7+) seems to enable buffering of response bodies when using the ISAPI redirector. This means, if you produce 100 MB of data in your servlet, then IIS will cache as much data as possible before it starts the response. This can be a problem if you need the response to be immediately started, e.g. for a IP camera which uses MJPEG streaming. It is however possible to change this behavior in IIS. The SPDY redirector is configured to flush each data packet so that the response body is sent immediately to the client.
Contra:
- Worse performance than the native ISAPI redirector. I made a test by a Servlet that produces 700 MB of random data, and on a separate machine I used a program to make a HTTP request and read the data. The average transfer speed was ~ 98 MByte/s, and the IIS worker process had around 50% CPU usage, whereas Jetty had only 12 %.
Now, to test the SPDY redirector, you can use IIS 8.0 Express that can be installed on any current Windows OS like Win8, Win7 and WinVista. Alternatively, if you have Visual Studio 2012 you can also create an empty ASP.Net Web Application and test it with the integrated IIS 8.0 Express.
The following is an updated guide for how to build the SPDY redirector, install IIS 8.0 Express and Jetty and configure the IIS web application to use the SPDY redirector on Windows (it uses Windows 7 64-bit as example).
TOC:
A) Build the SPDY Redirector with MSBuild tool
B) Install IIS 8.0 Express and create a Web Application having the SPDY Redirector
C) Install Jetty 8 and configure it for SPDY/3
D) Test if Jetty and the SPDY redirector is working
A) Build the SPDY Redirector with MSBuild tool
The sources of the SPDY Redirector are available at this SVN repository: https://kinderbasar-luhe.de:8543/svn/PreisserNormaleProjekte/SpdyConnector/
1) Install the .Net Framework 4.5 SDK which is included in the Windows 8 SDK. You can get it here: http://msdn.microsoft.com/en-us/windows/hardware/hh852363.aspx
When selecting the features to install, the only one you need to select is ".Net Framework 4.5 Software Development Kit".
2) After checking out the sources, run the MSBuild tool. To do this, open the command prompt and change to the directory of the checked out sources where the file "SPDY_Redirector.csproj" is located (SVN location: https://kinderbasar-luhe.de:8543/svn/PreisserNormaleProjekte/SpdyConnector/.Net/SPDY-Redirector/SPDY_Redirector/ ).
Then, run MSBuild by typing "%windir%\Microsoft.NET\Framework\v4.0.30319\msbuild.exe". The result of the build (SpdyRedirector.dll) will be in "bin\Debug" folder.
B) Install IIS 8.0 Express and create a Web Application having the SPDY Redirector
1) Install IIS 8.0 Express. You can get it here: http://www.microsoft.com/en-us/download/details.aspx?id=34679
2) Create a directory for the ASP.Net web application - e.g. "C:\MyIisApp1". Copy SpdyRedirector.dll to "C:\MyIisApp1\bin\SpdyRedirector.dll", and copy the web.config file located at https://kinderbasar-luhe.de:8543/svn/PreisserNormaleProjekte/SpdyConnector/.Net/web.config to "C:\MyIisApp1\web.config". This web.config file is an XML file that specifies that the SPDY Redirector module to be added for this Web Application.
3) Run IIS 8.0 Express by calling:
"%ProgramFiles%\IIS Express\iisexpress" /port:8081 /path:"C:\MyIisApp1"
This will bind to localhost:8081. If you open http://localhost:8081/ with a browser, you should see the following error message:
HTTP 503
The request could not be served because the remote server was not available.
This one is generated from the SPDY Redirector because the SPDY server (Tomcat/Jetty) is not yet available.
C) Install Jetty 8 and configure it for SPDY/3
1) Download Jetty 8.1.13 from http://eclipse.org/downloads/download.php?file=/jetty/stable-8/dist/jetty-distribution-8.1.13.v20130916.zip&r=1 and extract it. In the following steps, the Jetty directory will be called <jetty>.
2) Download http://repo2.maven.org/maven2/org/mortbay/jetty/npn/npn-boot/1.1.6.v20130911/npn-boot-1.1.6.v20130911.jar and copy it into <jetty>.
3) Edit <jetty>/etc/jetty-spdy.xml and replace the two existing <Call> elements by this one:
<Call name="addConnector">
<Arg>
<New class="org.eclipse.jetty.spdy.http.HTTPSPDYServerConnector">
<Set name="Port">8444</Set>
<Set name="defaultAsyncConnectionFactory">
<Call name="getAsyncConnectionFactory">
<Arg>spdy/3</Arg>
</Call>
</Set>
</New>
</Arg>
</Call>
This will create an non-SSL SPDY/3-Connector at Port 8444.
4) Edit <jetty>/start.ini, and add "spdy" to the OPTIONS list, so that it looks like this:
OPTIONS=Server,jsp,jmx,resources,websocket,ext,plus,annotations,spdy
5) Start jetty by using the following command, assuming that <jetty> is the current working directory:
java -Xbootclasspath/p:npn-boot-1.1.6.v20130911.jar -jar start.jar etc/jetty-spdy.xml
D) Test if Jetty and the SPDY redirector is working
1) Open http://localhost:8081/ with your browser. You should now see the "Welcome to Jetty 8" page. To test other Servlet 3.0 webapps, you can place them in <jetty>/webapps.
2) By default, the SPDY redirector creates a Logfile in C:\SpdyLog\Testlog1.txt. It should now look like the following:
2013-09-28 16:42:35.580Z: [DEBUG] [IIS Module] Redirecting request: GET http://localhost:8081/ HTTP/1.1
2013-09-28 16:42:35.580Z: [DEBUG] [IIS Module] Creating new HttpSpdyProcessor.
2013-09-28 16:42:35.611Z: [DEBUG] [SpdyConnector] Connecting to 127.0.0.1:8444 ...
2013-09-28 16:42:36.640Z: [DEBUG] [SpdyConnector] S: Stream 1: SYN_STREAM sent (FLAG_FIN: True; FLAG_UNIDIRECTIONAL: False).
2013-09-28 16:42:36.640Z: [DEBUG] [SpdyConnector] System.Net.Sockets.SocketException (0x80004005): Es konnte keine Verbindung hergestellt werden, da der Zielcomputer die Verbindung verweigerte 127.0.0.1:8444
bei System.Net.Sockets.TcpClient.Connect(String hostname, Int32 port)
bei Preisser.Spdy.SpdyRedirector.Connector.SpdyConnector.Start()
2013-09-28 16:42:36.640Z: [DEBUG] [SpdyConnector] TCP Connection aborted.
2013-09-28 16:42:36.640Z: [DEBUG] [SpdyConnector] R: Stream 1: Stream aborted (by remote side). streamNotCreated: False
2013-09-28 16:42:36.640Z: [DEBUG] [IIS Module] Status Code:
2013-09-28 16:42:36.640Z: [DEBUG] [IIS Module] Starting the response.
2013-09-28 16:45:53.695Z: [DEBUG] [IIS Module] Redirecting request: GET http://localhost:8081/ HTTP/1.1
2013-09-28 16:45:53.695Z: [DEBUG] [IIS Module] Creating new HttpSpdyProcessor.
2013-09-28 16:45:53.695Z: [DEBUG] [SpdyConnector] Connecting to 127.0.0.1:8444 ...
2013-09-28 16:45:53.695Z: [DEBUG] [SpdyConnector] TCP Connection established.
2013-09-28 16:45:53.711Z: [DEBUG] [SpdyConnector] S: Stream 1: SYN_STREAM sent (FLAG_FIN: True; FLAG_UNIDIRECTIONAL: False).
2013-09-28 16:45:53.945Z: [DEBUG] [SpdyConnector] R: Stream 1: SYN_REPLY received (FLAG_FIN: False).
2013-09-28 16:45:53.960Z: [DEBUG] [SpdyConnector] R: Stream 1: Data Frame received (Length: 2239; FLAG_FIN: True).
2013-09-28 16:45:53.976Z: [DEBUG] [IIS Module] Status Code: 200
2013-09-28 16:45:53.976Z: [DEBUG] [IIS Module] Starting the response.
2013-09-28 16:45:53.991Z: [DEBUG] [IIS Module] Redirecting request: GET http://localhost:8081/jetty_banner.gif HTTP/1.1
2013-09-28 16:45:53.991Z: [DEBUG] [SpdyConnector] S: Stream 3: SYN_STREAM sent (FLAG_FIN: True; FLAG_UNIDIRECTIONAL: False).
2013-09-28 16:45:53.991Z: [DEBUG] [SpdyConnector] R: Stream 3: SYN_REPLY received (FLAG_FIN: False).
2013-09-28 16:45:53.991Z: [DEBUG] [SpdyConnector] R: Stream 3: Data Frame received (Length: 65536; FLAG_FIN: False).
2013-09-28 16:45:53.991Z: [DEBUG] [IIS Module] Status Code: 200
2013-09-28 16:45:53.991Z: [DEBUG] [IIS Module] Starting the response.
2013-09-28 16:45:53.991Z: [DEBUG] [SpdyConnector] S: Stream 3: WINDOW_UPDATE sent (Delta: 65536).
2013-09-28 16:45:53.991Z: [DEBUG] [SpdyConnector] R: Stream 3: Data Frame received (Length: 6726; FLAG_FIN: True).
2013-09-28 16:45:54.023Z: [DEBUG] [IIS Module] Redirecting request: GET http://localhost:8081/favicon.ico HTTP/1.1
2013-09-28 16:45:54.023Z: [DEBUG] [SpdyConnector] S: Stream 5: SYN_STREAM sent (FLAG_FIN: True; FLAG_UNIDIRECTIONAL: False).
2013-09-28 16:45:54.023Z: [DEBUG] [SpdyConnector] R: Stream 5: SYN_REPLY received (FLAG_FIN: False).
2013-09-28 16:45:54.038Z: [DEBUG] [SpdyConnector] R: Stream 5: Data Frame received (Length: 1150; FLAG_FIN: True).
2013-09-28 16:45:54.038Z: [DEBUG] [IIS Module] Status Code: 200
2013-09-28 16:45:54.038Z: [DEBUG] [IIS Module] Starting the response.
It would be great to hear some feedback about the IIS SPDY redirector.
Thanks!
Regards,
Konstantin Preißer
[1] http://markmail.org/message/zhtmu73ixvstzipy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
RE: Possible IIS SPDY Redirector for Tomcat
Posted by Konstantin Preißer <kp...@apache.org>.
Hi all,
I would like to let you know some updates on this:
1) Results of performance measurement with various configurations and the SPDY-Redirector
2) Switching to Async I/O for the implementation of the IIS module
1) Performance
> -----Original Message-----
> From: Christopher Schultz [mailto:chris@christopherschultz.net]
> Sent: Monday, September 30, 2013 8:53 PM
> To: Tomcat Developers List
> Subject: Re: Possible IIS SPDY Redirector for Tomcat
>
> Konstantin,
>
> > So it seems that the main performance problem is IIS when using
> > managed code/ASP.Net to write to the response, but I need to do
> > additional testing.
>
> Wow. Are you sure the thread burning the CPU is the one running the
> above code? Seems ... unfortunate.
I have now done additional testing with various configurations and I think my previous statement was wrong - IIS is not the culprit here. I guess it's the multiplexing that the SPDY Redirector is doing (multiplexing multiple HTTP requests on a single TCP connection) that causes the CPU usage. However, I don't think that there is a real problem here comparing the performance/CPU usage to Jetty.
To measure performance (speed and CPU usage), I set up a 2-CPU VM with IIS 8.5 (Windows Server 2012 R2 x64), Tomcat 7.0.42 (for ISAPI Redirector) and Jetty 8.1.13 (for SPDY Redirector). For IIS, I created one web application using the SPDY Redirector (connecting to Jetty) and one web application using the ISAPI Redirector (connecting to Tomcat).
I then created a Servlet 3.0 webapp with a Servlet that produces ~ 700 MB of random data, sending it in 32 KB chunks to the client, using the following code:
protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
response.setContentType("text/plain");
response.setCharacterEncoding("UTF-8");
response.addHeader("Content-Disposition", "attachment; filename=\"myTextfile.txt\"");
byte[] bytes = new byte[32768];
for (int i = 0; i < bytes.length; i++) {
bytes[i] = (byte)'a';
}
long bytesWritten = 0;
long lastDisplay = 0;
try (OutputStream out = response.getOutputStream()) {
while (true) {
out.write(bytes);
bytesWritten += bytes.length;
if (bytesWritten - lastDisplay > 500 * 1024) {
lastDisplay = bytesWritten + 500 * 1024;
System.out.println(bytesWritten + " Bytes written (completely).");
}
if (bytesWritten > 700 * 1024 * 1024)
break;
}
}
}
Then, I created a C# application that creates a TCP connection and sending the following raw request:
GET /TestSpdyServer/BigFileProducerServlet HTTP/1.1
Host: localhost
Connection: close
and reads from the TCP connection until it is closed, counting the bytes and milliseconds to calculate the average speed.
I then tested the speed when 1) connecting directly to Jetty (HTTP), 2) connecting directly to Tomcat (HTTP), 3)+4) connecting to IIS with SPDY-Redirector, 5) connecting to IIS with ISAPI redirector, 6) connecting to IIS using a ASP.Net handler producing 700 MB of random data, equally to the Servlet above.
This is what I got:
1) JettyHttp-Direct: 260 MB/s (Jetty: 47% CPU)
2) TomcatHttpBio-Direct: 275 MB/s (Tomcat: 45% CPU)
3) Iis-SpdyRedirector(Async)-JettySpdy (64 KB initial window size): 170 MB/s (Jetty: 35% CPU, IIS: 43% CPU)
4) Iis-SpdyRedirector(Async)-JettySpdy (128 KB initial window size): 205 MB/s (Jetty: 40% CPU, IIS: 50% CPU)
5) Iis-IsapiRedirector-TomcatAjpBio: 190 MB/s (Tomcat: 10% CPU, IIS: 20% CPU)
6) Iis-Asp.Net-Handler-Direct: 400 MB/s, 50% CPU
As you can see, with the SPDY redirector, both Jetty and IIS have a high amount of CPU usage (probably the costs of multiplexing) whereas the ISAPI redirector had a low CPU usage. However, I'm pretty happy with the current performance of the SPDY redirector.
2) Switching the implementation of the IIS module to Async I/O - see [1]: "Scalable Apps with Asynchronous Programming in ASP.NET"
.Net 4.5 introduces new "async" and "await" keywords for C# that allow you to easily create asynchronous code. E.g. you can write code just as you would with synchronous operations, and the compiler will create the Async State Machine for you.
As the previous implementation of the SPDY Redirector used blocking/synchronous IO for the IIS module, it meant that 1 thread was used per request. Now imagine you have 200 clients that simultaneously do requests to a resource that produces the response body very slowly, it would mean that IIS had to create 200 threads for serving the requests. This can be a problem also e.g. for long-polling comet applications (where it may take some time until the HTTP response is sent) or Websocket connections (however WebSockets with IIS 8 can only be used with async IO so I had to do the switch to Async anyway for being able to support Websocket).
For example, with Servlet 3.1 you can use non-blocking I/O so that you don't need to acquire a thread for the complete duration of a request.
Therefore, I now switched the IIS module implementation of the SPDY redirector to async IO (with the "async" and "await" keywords this was rather simple). The result is that if a request takes a long time to complete, IIS does not need to acquire a thread for the complete duration of the request - instead it uses a thread from its Threadpool only if there is new data to be forwarded. (The underlying SPDY connector still uses blocking I/O for the SPDY connection, but since one SPDY connection is intended to multiplex a huge amount of HTTP requests, atm there is no need for the SPDY connector to use async I/O for the SPDY TCP connection).
For example, the ISAPI redirector seems to use blocking I/O when forwarding HTTP requests to Tomcat. I tested this by creating a servlet that writes 100 lines of text and waiting 10 seconds after writing each line. Then, I made a C# application creating 170 TCP connections and simultaneously sending a request on each connection.
Then I monitored the number of threads of the IIS worker processes (w3wp.exe) before and after sending the requests:
IIS with SPDY Redirector: 29 Threads -> 35 Threads
IIS with ISAPI Redirector: 26 Threads -> 195 Threads (the additional threads are also created very slowly - I saw 1 thread per second - which means there is additional waiting time for the clients)
As you can see, with the async implementation of the IIS module of the SPDY redirector the number of threads did not significantly increase when doing 170 concurrent requests (initially I wanted to try more, but Jetty does not allow this - after about 180 requests are created on the SPDY connection, Jetty simply sends a GOAWAY frame and closes the TCP connection, effectively aborting all running HTTP requests).
Also, as AJP needs one TCP connection for each request, doing 170 concurrent requests means the ISAPI redirector has to establish 170 separate TCP connections to Tomcat, whereas the SPDY redirector only needs a single TCP connection where it can multiplex the concurrent requests.
The SPDY Redirector does not yet support redirecting WebSocket connections, but I think I will look into the "WebSocket Layering over SPDY/3" [1] document (and the Websocket protocol spec) to implement redirecting Websocket connections (Jetty 8.1 seem to support Websockets while it is only Servlet 3.0, whereas Jetty 9.1 should support Servlet 3.1 but I was not yet able to create a non-SSL SPDY/3 connector with it).
If you would like to test the SPDY redirector with a downloadable version of IIS 8 (that runs also on client Windows editions), you can find the instructions for setting it up at [2]. I would appreciate if someone could test the SPDY redirector for some feedback.
What do you think?
Thanks!
Regards,
Konstantin Preißer
[1] http://msdn.microsoft.com/en-us/magazine/cc163463.aspx
[2] http://markmail.org/message/atwky5b4qpm52qq3
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Possible IIS SPDY Redirector for Tomcat
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Konstantin,
On 9/30/13 11:32 AM, Konstantin Preißer wrote:
> Hi Chris,
>
>> -----Original Message-----
>> From: Christopher Schultz [mailto:chris@christopherschultz.net]
>> Sent: Monday, September 30, 2013 5:19 PM
>> To: Tomcat Developers List
>> Subject: Re: Possible IIS SPDY Redirector for Tomcat
>>
>> Konstantin,
>>
>> On 9/28/13 1:40 PM, Konstantin Preißer wrote:
>>> Contra:
>>> - Worse performance than the native ISAPI redirector. I made a test by a
>> Servlet that produces 700 MB of random data, and on a separate machine I
>> used a program to make a HTTP request and read the data. The average
>> transfer speed was ~ 98 MByte/s, and the IIS worker process had around
>> 50% CPU usage, whereas Jetty had only 12 %.
>>
>> How good of a C# programmer are you? Perhaps you could have someone
>> else
>> look at it to make sure you aren't doing something that has obvious
>> performance drawbacks (e.g. using an un-buffered stream often results in
>> a kernel call for each byte of data to be transferred).
>
> Thanks for your reply. Yes, that redirector is only a draft and could have some performance issues.
>
> However, I have done a Test with IIS 8.0 and a simple ASP.Net Handler (.ashx) that just writes ~625 MB of random data by writing a 327680 bytes array 2000 times to the response:
>
> public class Handler1 : IHttpHandler {
>
> public void ProcessRequest(HttpContext context) {
> HttpResponse response = context.Response;
> response.ContentType = "text/plain";
> response.AddHeader("Content-Disposition", "attachment; filename=abc.txt");
>
> byte[] bytes = new byte[327680];
> for (int i = 0; i < bytes.Length; i++) {
> bytes[i] = (byte)((i * 12345 + 98237) % 255);
> }
>
> using (Stream sout = response.OutputStream) {
> for (int i = 0; i < 2000; i++) {
> sout.Write(bytes, 0, bytes.Length);
> response.Flush();
> }
> }
> }
>
> public bool IsReusable {
> get { return true; }
> }
> }
>
> And I still get ~ 50% CPU usage by the IIS worker process (w3wp.exe)
> while the transfer speed is about 100 MByte/s.
>
> So it seems that the main performance problem is IIS when using
> managed code/ASP.Net to write to the response, but I need to do
> additional testing.
Wow. Are you sure the thread burning the CPU is the one running the
above code? Seems ... unfortunate.
-chris
RE: Possible IIS SPDY Redirector for Tomcat
Posted by Konstantin Preißer <kp...@apache.org>.
Hi Chris,
> -----Original Message-----
> From: Christopher Schultz [mailto:chris@christopherschultz.net]
> Sent: Monday, September 30, 2013 5:19 PM
> To: Tomcat Developers List
> Subject: Re: Possible IIS SPDY Redirector for Tomcat
>
> Konstantin,
>
> On 9/28/13 1:40 PM, Konstantin Preißer wrote:
> > Contra:
> > - Worse performance than the native ISAPI redirector. I made a test by a
> Servlet that produces 700 MB of random data, and on a separate machine I
> used a program to make a HTTP request and read the data. The average
> transfer speed was ~ 98 MByte/s, and the IIS worker process had around
> 50% CPU usage, whereas Jetty had only 12 %.
>
> How good of a C# programmer are you? Perhaps you could have someone
> else
> look at it to make sure you aren't doing something that has obvious
> performance drawbacks (e.g. using an un-buffered stream often results in
> a kernel call for each byte of data to be transferred).
Thanks for your reply. Yes, that redirector is only a draft and could have some performance issues.
However, I have done a Test with IIS 8.0 and a simple ASP.Net Handler (.ashx) that just writes ~625 MB of random data by writing a 327680 bytes array 2000 times to the response:
public class Handler1 : IHttpHandler {
public void ProcessRequest(HttpContext context) {
HttpResponse response = context.Response;
response.ContentType = "text/plain";
response.AddHeader("Content-Disposition", "attachment; filename=abc.txt");
byte[] bytes = new byte[327680];
for (int i = 0; i < bytes.Length; i++) {
bytes[i] = (byte)((i * 12345 + 98237) % 255);
}
using (Stream sout = response.OutputStream) {
for (int i = 0; i < 2000; i++) {
sout.Write(bytes, 0, bytes.Length);
response.Flush();
}
}
}
public bool IsReusable {
get { return true; }
}
}
And I still get ~ 50% CPU usage by the IIS worker process (w3wp.exe) while the transfer speed is about 100 MByte/s.
So it seems that the main performance problem is IIS when using managed code/ASP.Net to write to the response, but I need to do additional testing.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Possible IIS SPDY Redirector for Tomcat
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Konstantin,
On 9/28/13 1:40 PM, Konstantin Preißer wrote:
> Contra:
> - Worse performance than the native ISAPI redirector. I made a test by a Servlet that produces 700 MB of random data, and on a separate machine I used a program to make a HTTP request and read the data. The average transfer speed was ~ 98 MByte/s, and the IIS worker process had around 50% CPU usage, whereas Jetty had only 12 %.
How good of a C# programmer are you? Perhaps you could have someone else
look at it to make sure you aren't doing something that has obvious
performance drawbacks (e.g. using an un-buffered stream often results in
a kernel call for each byte of data to be transferred).
-chris