Simple 4.0 - Java HTTP Engine


News: Simple 4.0 - Java HTTP Engine

  1. Simple 4.0 - Java HTTP Engine (31 messages)

    The Simple HTTP engine and framework has released version 4.0. Simple is an asynchronous HTTP engine capable of scaling to large loads with a limited number of servicing threads. It employs NIO at the transport layer which ensures it is both responsive and resource efficient. It also has a fully comprehensive API that provides as much convenience to the developer than the Java Servlet API.
    • High performance HTTP kernel
      Simple has consistently outperformed popular commercial and open source Java HTTP servers. Current benchmarks comparing it against recent versions of Jetty and AsyncWeb show it has signifigantly higher throughput, and scales much better under increasing load. Benchmark Results.
    • Asynchronous processing throughout
      From the outset the goal of the project has been to provide a truly asynchronous HTTP engine. The service model provided allows request completion to be driven using an internal, transparent, monitoring system. This allows Simple to vastly outperform current Servlet Engines, which require request completion to be driven by the servicing thread, particularly in high latency scenarios where transactions require distributed services.
    • Embeddable framework
      Simple is provided as a framework, and as such can be embedded in to any existing application in several lines of code. It integrates seamlessly with environments supporting the Spring framework.
    • Small Footprint
      Despite being highly scalable, Simple has a very small memory footprint. Recent benchmarks show its memory footprint to be almost half that of other lightweight NIO servers, such as Jetty and AsyncWeb.
    • Fully Self Contained
      It has no external dependancies. Other than a Java 5 SDK or above there are no additional libraries required. This keeps the footprint small and ensures there are no compatibility issues when integrating it in to existing applications.
    • Open Source
      Released under the LGPL and so can be fully integrated or adapted for both commercial and open source projects.

    Threaded Messages (31)

  2. Is it an HTTP server only or Servlet container as well? Is it standard-compliant? I'm just not sure how to interpret the "It also has a fully comprehensive API that provides as much convenience to the developer than the Java Servlet API."
  3. Hi, Should have made that clearer, no, Simple is not a Servlet Container, and does not support the Servlet API. For two reasons. 1) The Servlet API is inherently synchronous, an so does not support the concept of true asynchronous events 2) There is already a wide variety of Servlet Containers out there This project originally started out as a Servlet Container some time ago, however I am not a fan of the API or the service model it advocates. Servlet Engines do not scale well in multi-tier environments where the servicing thread is blocked waiting for a resource to become available or some event to complete. Also, I don't see JSR 315 really making much of an improvement to this. This does however mean there is a little more leg work involved in getting existing Java web frameworks to work with it. However, I intend to adapt several according to suitability to the asynchronous event based service model.
  4. Nial, Do you plan to build some sort of "adapters" for supporting servlet API then? Or perhaps some popular web frameworks? I wonder what is your vision of typical use of Simple. What tasks does it fit into better than servlet container does? Do you see it as a complementary server or replacement for servlet container in an typical N-tier application? Thanks.
  5. re: Simple 4.0 vs Jetty[ Go to top ]

    Nial, can you make your benchmark setup for Jetty available? I fear you may be comparing apples with oranges, as the default setup for Jetty will have a lot of servlet baggage that it sets up for each request (contexts, classloaders, security and session checks). These are all optional in Jetty and it can be simply stripped back to an async HTTP core plus handler. If you just want to server a single static file, then Jetty also has a non-servlet handler for that that will flush the file asynchronously using NIO gather writes. Also, it would be very iteresting to see a comparison of dynamic content generation. Static content is easy, as you can delegate most of the IO work to the JVM/OS. Finally, what hardware/OS was used for your benchmark. For static content, Jetty makes use of file mapped buffers, which tend to be better implemented on unixes.
  6. Re: re: Simple 4.0 vs Jetty[ Go to top ]

    Hi, Here I am attempting to measure first byte sent to last byte received for an HTTP transaction over an established TCP connection, pipelining a fixed number of requests over each one. I have used a static file to measure the containers performance as it will typically provide best execution times, this is important as it avoids the scenario where the service execution times affect the benchmark. For example, lets say I wanted to measure the performance of Apache, measuring it using a perl based CGI script would not provide an accurate reflection of the servers performance. As the time taken to execute the script would contribute signifigantly to the overall result. With regard to comparing the performance of each servers ability to deliver dynamic content, this is exactly what I have done. My goal was to measure the performance of Jetty through the Servlet API, as this is how it will be used. Dynamic content is a sequence of bytes, like a static file, however a static file when served through the Servlet API does not contribute as much computational latency to the test. So I am measuring the servers performance, rather than the logic surrounding composition of the dynamic response. To create a level playing field where I am comparing like for like, I have disabled Jettys file mapping capabilities, as they are not available through the Servlet API. However Simple gained no advantage by using these features either, I measured its performance sending the file contents through a conventional output stream. So I believe this was a fair representation of each servers performance. If you would like to suggest a configuration to use the test then I will be happy to use it, I am releasing a minor version of the server shortly and will be performing the some performance tests then.
  7. Re: Simple 4.0 - Java HTTP Engine[ Go to top ]

    Hi Niall, Can you publish the configuration settings you used for each of the servers in the comparison? thanks, Jan
  8. I am happy to know that we can now run servers in a jiffy. Apart from the fact that it doesnt support Servlet specs, I would like to know if it lends itself to some kind of unit testing/integration testing (The documentation doesnt tell about any). To be more precise, I want to know what is the developers motive to write a Java based HTTP Engine when we have so many HTTP engines? Is it Unit Testing? Profiling?
  9. The primary motivation is to provide a HTTP server capable of asynchronous transaction processing. Services implemented around the Servlet API can not scale beyond a certain threshold when service completion is dependant on an asynchronous event. This can be anything from a database transaction to a messaging event. With Simple it is possible to scale to many times (hundreds of times is quite feasable) a many concurrent clients in such an scenario with very little resource overhead. However, if you want to embed it to use for unit testing this is possible also, take a look at the following unit test, which tests several thousand requests simulating approx two hundred concurrent clients. I use it to test some of the API features of Simple.
  10. quite intersting[ Go to top ]

    A long time ago I was looking to get a .NET app to talk to a Java application, but I had to keep it very lightweight. Another item was I wanted to communicate via a Web Service. A web service really only requires SOAP, however I couldn't find a good small HTTP only engine in Java to service my SOAP interfaces. Of course I could of used any of the servlet containers, but they were too bulky for my task at hand. This seems quite handy, and if my need to get a .NET app talking to Java in a standards compliant model (Web Services) with the smallest possible footprint, this may be the avenue I'm looking for.
  11. How does Simple stand up against xlightweb? (xSocket-based http server Is it possible (makes sense) to use Simple for non-http NIO server?
  12. I am not familiar witht he feature set of xLightweb, so can't really make a good comparison. I have broken out the Reactor API in to a separate package, this provides simpler access to asynchronous IO than the lower level Java NIO packages. However the vast majority of work done in Simple is directly related to HTTP processing, from state machines to accumulate the request entity to asynchronous events to parallize transaction execution. If your interested you can grab them from. Reactor Source Reactor Javadoc However, you may find it easier to use a more comprehensive API such as Apache MINA for non-HTTP services.
  13. Asynch HTTP overhyped[ Go to top ]

    1) HTTP is a synchronous protocol, not asynch messaging. In most Web apps, adding asynch HTTP will hurt performance and degrade application maintainability. 2) Really, its only COMET-like apps that scale better with asynch HTTP as you have a client blocking on a socket receive for new posted messages. The majority of apps don't need COMET messaging. 4) Asynchronous IO to conserve threading really belongs in the VM. Take a look at Erlang for example. I know JRockit used to support N/M green to kernel threads. No reason this can't be improved on. 5) Many of the Erlang vs. Apache benchmarks were done on old Linux kernels where threads were really expensive. 6) OS's will improve on how many threads they can handle. 7) With multi-core, 64-bit machines, falling memory prices, conserving threads not the biggest deal. So, with that all said, do you *really* want to complicate your application design with something that will generally have no affect on the performance of your app? THAT BEING SAID... I do intend to look at Simple 4.0 as I want to add an embeddable COMET abstraction to RESTEasy. I wasn't too impressed with the code quality of Grizzly when a looked at it 6+ months ago (maybe it has changed a lot?). Also, what advantages would Simple 4.0 have over embedding something like Jetty? -- Bill Burke JBoss, a division of Red Hat
  14. Re: Asynch HTTP overhyped[ Go to top ]

    Hi, I agree with most of what you have said, in my experience for low loads, thread per requst will probably give you best performance. However, I believe for scenarios where the HTTP server must collaborate with other distributed services Simple will without question provide vast performance gains under high load, and I believe it will make your application both simpler to develop and produce a more elegant result. The only fundamental difference between the Servlet API and that provided by Simple is that you must close the response output stream. Thats it. You can work with it and implement services as you would implement a HttpServlet. For example, if my HTTP service had to send a request to an out of process Web Service. I do not need to wait for the round trip time of this request to complete. I can simply queue the request for a callback and release the servers servicing thread, then when the Web Service responds I can emit a suitable response to the connected client. So as the client sees it its synchronous HTTP, but internally you can treat the Request and Response as truly independant objects/events. They are not tied to any service model or thread. With regards to why you would choose it over Jetty, I believe it has advantages in performance, scalabality, and simplicity (see the performance comparison link above). Take a look at the tutorial, it really is very easy to get up and running with it. No web.xml or configuration files to write, you can simple assemble your own HTTP server in a couple of minutes without any dependancies.
  15. Re: Asynch HTTP overhyped[ Go to top ]

    Hello Bill, I agree with you that there have been huge improvements in implementations of threading the last couple of years. Both at OS and CPU level. However, CPUs still like doing one small thing very well. Something that fits in their cache. They don't like context switching, synchronization, and moving data to their brothers due to threading. I use brothers here, since in my experience women are much better multitaskers than men are. For example, if you have to serve 10K requests per second, then you waist a lot of time with context switching using a thread per request model. I don't even know if modern JVMs and OSs support this number of threads. I can remember that Apache had an upper bound below 1K threads, but I don't know if this is still true. Hence, in general you should minimize the number of threads per CPU/core in order to maximize throughput. Unfortunately this often conflicts with the minimization of latency. And that's where threads come into play... In other words: it very much depends on the requirements you have and you'll often have to find the right balance. Grizzly, for example, just uses a couple of threads to accept connections and read the first block of data received. However, it then continues with a thread per request model to read the rest of the data. Regarding complexity: I can absolutely imagine that it's hard for people to get into Java NIO or asynchronous communication. Therefore it's great that frameworks like Simple, Grizzly, MINA, xSocket, etc exist, since they shield their users from the nitty-gritty details. For an interesting read on the subject, see the influential thesis of Matt Welsh: An Architecture for Highly Concurrent, Well-Conditioned Internet Services, also know as Staged Event Driven Architecture (SEDA). Matt was also involved in the design of Java NIO. Regards, Hans de Boer
  16. Re: Asynch HTTP overhyped[ Go to top ]

    Regarding complexity: I can absolutely imagine that it's hard for people to get into Java NIO or asynchronous communication. Therefore it's great that frameworks like Simple, Grizzly, MINA, xSocket, etc exist, since they shield their users from the nitty-gritty details.
    What I'm saying is that unless you are implementing a message queue, asynchronous coding should not be bleeding into your application codebase. -- Bill Burke JBoss, a division of Red Hat
  17. Re: Asynch HTTP overhyped[ Go to top ]

    Hello Bill, Asynchronous communication or event handling implies that you don't block to wait for an event such as a response. Instead you, for example, specify a callback/completion handler that is automatically triggered when the response is received. This is also very common in other areas, such as GUI frameworks. Imagine that you would have to create a thread for every single GUI element on your screen (buttons, menu items, text boxes, etc) in order to capture events like mouse clicks and typing. You could even say that in general server side web applications are based on an asynchronous model, since web applications often request the user for a response. For example, when a form is sent to the user, the application doesn't wait for the user to respond. Instead, the form contains an URL to which the form information is sent when the user presses submit. The server uses this URL to dispatch the form submission to the appropriate piece of application logic, such as a servlet. This can very well be seen as a callback mechanism used to implement asynchronous communication. Hence, asynchronous communication and event handling is all around us. Fortunately many frameworks hide the complexities from us. Regards, Hans de Boer
  18. Compliancy[ Go to top ]

    Hello Niall, Could you please tell me whether Simple is fully HTTP 1.0 and/or 1.1 compliant? Thanks, Hans de Boer
  19. Re: Compliancy[ Go to top ]

    Hi, Yes its fully HTTP/1.1 compliant. One exception is "Expect: 100-continue". Which is not yet supported. It was supported in previous versions however I have found it is very rarely requird. I hope to add it in the next version. By default it supports all multipart types out of the box as it were. Even recursive multipart lists as used in protocols like MM7 and SOAP with attachments for example. Niall
  20. Re: Compliancy[ Go to top ]

    Also, just to mention it also supports HTTP/1.0, it works well with both. As required when HTTP/1.1 compliant.
  21. Hi, Jetty is Servlet container and also performs very good with asynchronous events and scales efficiently... Please see this article: Ajax, Comet and Jetty. -- Nishant Saini SimplyJava - Solutions for everyone
  22. Well its actually not doing the same job, what is proposed in the new Servlet API is quite different to how it has been implemented in Simple. Jetty attempts to wedge in asynchronous functionality to an API which has been historically synchronous. Handling asynchronous events in Simple is completely transparent, you can choose to do it any way you want. Also, on performance comparisons I have performed Simple has about half the memory footprint, scales much better under load and has higher throughput. See the following. Performance Comparison
  23. Integration into Tomcat ???[ Go to top ]

    Hi Niall, is it possible to integrate your Simple into Tomcat as internal HTTP Engine? I find your concept of ASYNC or NON-blocking while the Threads invoking backend-services so cool. On Tomcat man can configure the max number of Threads with Thread-Pooling. But they when they receive HTTP request, they invoke backend-services -> they are blocked. So man hat many Threads but they dont really work continuos all.
  24. SEDA stages?[ Go to top ]

    I'm interested in implementing SEDA like processing with Simple. Can you let me know the timing of network interactions with respect to Container.handle being called? ie is Container.handle called before or after the request is fully read from the network. Because if the request is fully read before Container.handle is called then the data must be buffered in memory, which must be handled carefully. But if its streamed in from the network it will be blocking and i'll need to put that into its own stage. Similarly with the response, is data written to the network as it is written to the response outputStream, or does Simple buffer the data and then transmit it once its complete? Looks great, by the way. Thanks, Brad
  25. Re: SEDA stages?[ Go to top ]

    Hi, The Simple and SEDA architectures are comparable, in that there is an event driven approach taken to the stages involved in processing requests. In Simple there are several stages, differing depending on the type of connection. For SSL there is an extra stage for SSL handshakes and SSL termination. Simple is non-blocking throughout regardless of how the data is streamed to the server. Bytes are accumulated as they arrive and each pipeline has a state machine and transport cursor, which enable it to compose a header wihout blocking the collection threads. Basically it is broken in to two main chambers, the collection chamber collects bytes that form the request header and body, once its been collected its forwarded to the dispatch chamber where the request can be executed. When delivery is complete (not-necessarily when execution has complete) the transport is handed back to the collection chamber so the next request can be collected. This architecture also allows for parallel request processing, which I don't believe SEDA has. Parallel request processing is performed by monitoring the output, when the output has been fully written (according to HTTP semantics) by the service the pipeline is handed back for collection, however the associated service my still be executing, it knows nothing of the pipeline handover and this parallelism can improve performance greatly for pipelined requests.
  26. Simple vs. Jetty[ Go to top ]

    We used previous version of Simple for our application with velocity templates in web pages. Recently, I rewrite the application to use Jetty6 with Wicket web framework. The main problem was documentation and community. Simple community is not an active one and also, there are few documents for developing. Also, I made some primitive benchmarks to compare Simple versus Jetty. I used JMeter and Yourkit on my development PC with 1GB RAM and Windows XP OS. In high request rate, Simple response was better. About the thread creation, Jetty in first requests created about 256 threads but Simple just create 50 threads. The overall throughput of Simple was 30 request/per sec and for Jetty it was 27 request/per sec. Anyway, development with Simple is hard. Simple may be good for some custom, specific purpose applications without support of AJAX, session management, security issues and so.
  27. Re: Simple vs. Jetty[ Go to top ]

    Hi, Not being a Servlet Container makes it difficult to leverage the wide array of existing web frameworks. However I intend to remedy this, and Wicket is currently top of my list. Also, previously the tutorial has been pretty poor and this can pose problems for developers that just want to get up and running. I have currently been adding to the tutorial and plan to add additional sections on how it can bee used as a standalone server and with Spring. Hopefully this will make things much easier to get up and running. Also session management should be much improved in 4.0 as should security.
  28. Does Simple 4.0 also support an HTTP-Client? Or is it only a HTTP-Server? I'm interested in using Simple 4.0 as an async HTTP-Server, but also need an async http-client (to access web-services out-there in the internet)
  29. Hi, The code is already there to implement an asynchronous HTTP client, it would not really differ too much from how the core server operates. However, instead of reading the HTTP request line you would be reading the HTTP status line. The ReplyConsumer provided within the test code can be used to read a HTTP response asynchronously.
  30. Does anyone have some sample code showing how an HTTP client request could be coded using Simple?
  31. simple[ Go to top ]

    [code] import org.simpleframework.http.core.Container; import org.simpleframework.transport.connect.Connection; import org.simpleframework.transport.connect.SocketConnection; import org.simpleframework.transport.*; import org.simpleframework.util.thread.*; import org.simpleframework.http.Response; import org.simpleframework.http.Request; import; import; import; import java.util.*; import java.text.*; public class MiniServer implements Container { Scheduler queue; public static class Task implements Runnable { private final Response response; private final Request request; public Task(Request request, Response response) { this.response = response; this.request = request; } public void run() { long time = System.currentTimeMillis(); String tstamp = dFormat("yyyy-MM-dd hh:mm:ss aaa"); PrintStream body; try { body = response.getPrintStream(); response.set("Content-Type", "text/html"); response.set("Server", "MiniServer/1.0"); response.setDate("Date", time); response.setDate("Last-Modified", time); body.println("

    Hello World - " + tstamp + "

    "); body.close(); } catch (Exception e) { e.printStackTrace(); } } } public MiniServer(Scheduler q) { this.queue = q; } public void handle(Request request, Response response) { Task task = new Task(request, response); this.queue.execute(task); } public static String dFormat (String format) { TimeZone tz = TimeZone.getDefault(); Date today = new Date(); long offset = tz.getOffset(today.getTime()); if (offset < 0) offset = offset * -1; SimpleDateFormat formatter = new SimpleDateFormat(format); String datenewformat = formatter.format(new Date(today.getTime() + offset)); return datenewformat; } public static void main(String[] list) throws Exception { Scheduler queue = new Scheduler(16); Container container = new MiniServer(queue); Connection connection = new SocketConnection(container); SocketAddress address = new InetSocketAddress(8080); connection.connect(address); } } [/code]
  32. Re: simple[ Go to top ]

    Thanks for the code, but I wanted to know how to implement a client, not a server. Niall said "The code is already there to implement an asynchronous HTTP client" and I was asking about that since it wasn't obvious.