tokio-rs / tokio-minihttp Goto Github PK

View Code? Open in Web Editor NEW

440.0 440.0 50.0 594 KB

Protocol implementation experimentations

License: Apache License 2.0

Rust 100.00%

tokio-minihttp's People

Contributors

Stargazers

Watchers

Forkers

jcsoo alexcrichton zypeh bgourlie chrivers axlrose makevoid aturon liftoff stevej sudharsh seppo0010 xrmx maciejhirsz alexxnica kryndex hawkw vird grepz uppi billyevans zippunov nayato tobybot11 estin foodgambit lgphp xoac attackgoat kerollmops jonathanstrong trezm jekshmek seyi konstankinollc doytsujin fauxfaux phynalle dut3062796s isgasho lanlan8872 chmarp hoangpq cjh9004 bells307 iq-scm shabbirhasan1

tokio-minihttp's Issues

Fresh git pull doesn't compile

   Compiling tokio-core v0.1.0 (https://github.com/tokio-rs/tokio-core#60796f40)
error[E0432]: unresolved import `futures::sync::BiLock`
 --> /home/riskable/.cargo/git/checkouts/tokio-core-ec1bf80948dd483b/60796f40fdd3ea4e06f8d2f44a91ce3ec1208f93/src/io/split.rs:4:5
  |
4 | use futures::sync::BiLock;
  |     ^^^^^^^^^^^^^^^^^^^^^ Could not find `sync` in `futures`

error: aborting due to previous error

error: Could not compile `tokio-core`.

FYI: I did a git clone of the latest tokio-core and that compiles fine.

Panic in BufMut::put under load

This may be the wrong place to report this, but it's not clear to me if the problem lies in bytes, tokio-* or in how those crates are used in this repo.

After the update to tokio-io, the examples panic when put under non-trivial load.

Trace:

RUST_BACKTRACE=full cargo run --example hello-world
    Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs
     Running `target/debug/examples/hello-world`
thread 'main' panicked at 'assertion failed: self.remaining_mut() >= src.remaining()', /Users/ketilovre/.cargo/registry/src/github.com-1ecc6299db9ec823/bytes-0.4.1/src/buf/buf_mut.rs:227
stack backtrace:
   0:        0x105bd4513 - std::sys::imp::backtrace::tracing::imp::unwind_backtrace::h7b906ec435ded35c
   1:        0x105bd6354 - std::panicking::default_hook::{{closure}}::h44d92332f38028b9
   2:        0x105bd5f6d - std::panicking::default_hook::ha8486ead32221b33
   3:        0x105bd8ab7 - std::panicking::rust_panic_with_hook::hdbc3bba6a9dc0bb9
   4:        0x105b4e9e8 - std::panicking::begin_panic::h0f47c8d04ec91556
   5:        0x105b53852 - bytes::buf::buf_mut::BufMut::put::hc5f5bd330eeee7a9
   6:        0x105b57802 - <tokio_minihttp::response::FastWrite<'a> as core::fmt::Write>::write_str::h792143836f1f5834
   7:        0x105bfbc71 - core::fmt::write::h58310826cef1ccf3
   8:        0x105b578de - <tokio_minihttp::response::FastWrite<'a> as core::fmt::Write>::write_fmt::h2652f00186740201
   9:        0x105b57463 - tokio_minihttp::response::encode::h2185b8a1f48158f6
  10:        0x105b57bd7 - <tokio_minihttp::HttpCodec as tokio_io::framed_write::Encoder>::encode::h5ca278959f9b8bac
  11:        0x105b38ee3 - <tokio_io::framed::Fuse<T, U> as tokio_io::framed_write::Encoder>::encode::h85dd5e9bdfdc7b8c
  12:        0x105b35ef4 - <tokio_io::framed_write::FramedWrite2<T> as futures::sink::Sink>::start_send::h4130b348317693b0
  13:        0x105b34181 - <tokio_io::framed::Framed<T, U> as futures::sink::Sink>::start_send::h1bd88f74077d8308
  14:        0x105b0324f - <tokio_proto::simple::pipeline::lift::LiftTransport<T, E> as futures::sink::Sink>::start_send::hebe49de85d193657
  15:        0x105b02ab1 - <tokio_proto::streaming::pipeline::advanced::DispatchSink<T> as futures::sink::Sink>::start_send::h208d0f44e9991630
  16:        0x105b34f69 - <tokio_proto::buffer_one::BufferOne<S> as futures::sink::Sink>::start_send::hfbfc5c8c5430a97f
  17:        0x105b062c9 - tokio_proto::streaming::pipeline::advanced::assert_send::hf5dca39ad84063ac
  18:        0x105b2da78 - <tokio_proto::streaming::pipeline::advanced::Pipeline<T>>::write_in_message::h96142417c70f858b
  19:        0x105b2cb85 - <tokio_proto::streaming::pipeline::advanced::Pipeline<T>>::write_in_frames::hc73697a5153b606a
  20:        0x105b02deb - <tokio_proto::streaming::pipeline::advanced::Pipeline<T> as futures::future::Future>::poll::h5086eacdfcb8a0cd
  21:        0x105b283f7 - <futures::future::chain::Chain<A, B, C>>::poll::hdde88008f9a841a7
  22:        0x105b01ccb - <futures::future::and_then::AndThen<A, B, F> as futures::future::Future>::poll::h50c8f2cc62409c1c
  23:        0x105b39356 - <futures::future::map_err::MapErr<A, F> as futures::future::Future>::poll::h4a2d08077cc84387
  24:        0x105b7dfe1 - <alloc::boxed::Box<F> as futures::future::Future>::poll::h9a960269f9a76152
  25:        0x105b6913c - <futures::task_impl::Spawn<F>>::poll_future::{{closure}}::ha0b202d821be324b
  26:        0x105b6956e - <futures::task_impl::Spawn<T>>::enter::{{closure}}::hc64329dbab7744a3
  27:        0x105b80343 - futures::task_impl::set::{{closure}}::habfb871a03b7dd50
  28:        0x105b6aa51 - <std::thread::local::LocalKey<T>>::with::h9ae714bd6e7eb97f
  29:        0x105b800ef - futures::task_impl::set::h570c5abc832e47b3
  30:        0x105b6933e - <futures::task_impl::Spawn<T>>::enter::h647e6c6ef6939275
  31:        0x105b690bf - <futures::task_impl::Spawn<F>>::poll_future::hca31303e3d536d67
  32:        0x105b8c7d2 - tokio_core::reactor::Core::dispatch_task::{{closure}}::h44990ee43a8db0c0
  33:        0x105b65484 - <scoped_tls::ScopedKey<T>>::set::h99534fc75e0aad19
  34:        0x105b8c2ba - tokio_core::reactor::Core::dispatch_task::h27cfe92f36bc634c
  35:        0x105b8b625 - tokio_core::reactor::Core::dispatch::hfe5d7b05d4c77ffd
  36:        0x105b8b19d - tokio_core::reactor::Core::poll::h86199da1274f8a32
  37:        0x105b03a65 - tokio_core::reactor::Core::run::hed937874801fc25b
  38:        0x105b05641 - tokio_proto::tcp_server::serve::h2e7a3dcb2e45af2c
  39:        0x105b2773e - <tokio_proto::tcp_server::TcpServer<Kind, P>>::with_handle::h1e9b6824f4250ecf
  40:        0x105b28072 - <tokio_proto::tcp_server::TcpServer<Kind, P>>::serve::hac80897fbd6b48ac
  41:        0x105b3a3d6 - hello_world::main::h5741a7b6e7843651
  42:        0x105bd8785 - std::panicking::try::do_call::h24a2756282b9a31c
  43:        0x105bd9a6a - __rust_maybe_catch_panic
  44:        0x105bd8eb0 - std::rt::lang_start::hd19f94db0c6a490e
  45:        0x105b3a519 - main

This can be reproduced consistently by starting the example and using wrk or similar to generate load. Tested on OS X with rustc 1.17.0-nightly (a559452b0 2017-03-17) and rustc 1.16.0 (30cf806ef 2017-03-10), with and without --release. The same panic occurs in all cases.

Strange post/body parse issue. Response didn't send.

Here is test case
https://gist.github.com/vird/b5251bf298a9365401c3f25df223ee51
My output

Hello, world!
Hello, world!
Hello, world!
Hello, world!
Hello, world!
Hello, world!
Hello, world!
now fail comes
curl: (52) Empty reply from server
curl: (52) Empty reply from server
curl: (52) Empty reply from server
curl: (52) Empty reply from server
curl: (52) Empty reply from server

My env

# uname -a
Linux calculate 4.8.6 #1 SMP PREEMPT Sat Nov 12 20:07:16 EET 2016 x86_64 AMD A10-7850K Radeon R7, 12 Compute Cores 4C+8G AuthenticAMD GNU/Linux
# rustc -V
rustc 1.15.1

All request are parsed ok by server (you can add)

println!("{:?}", _request);

With this "hello world" will produce such output

<HTTP Request GET />
<HTTP Request POST />
<HTTP Request POST />
<HTTP Request POST />
<HTTP Request POST />
<HTTP Request POST />
<HTTP Request POST />
<HTTP Request POST />
<HTTP Request POST />
<HTTP Request POST />
<HTTP Request POST />
<HTTP Request POST />

So all request are processed by server, but not all responses are sent properly.

Why so slow on multiple queries?

I was just wondering why the benchmarks on techempower has a very slow speed on multiple queries?

HTTP2/QUIC plan

Do you have any plan to add Http2 or QUIC protocol to this code?

Setup dependency

Hello~
I'm trying to implement simple web server with this project, but cannot find how to setup dependency in cargo file. I tried to search library in https://crates.io/ but there was no module tokio-minihttp.

How could I do?

Thanks.

Possible to get access to peer's name?

I'm trying to find a way to get access to the peer's name (i.e., sockaddr_in equivalent) but this information doesn't seem to get propagated past the tokio-proto and tokio-io layers. Is this by design or just a missing feature? If this is by design, is the appropriate place to implement my idea (something that needs access to peer's name but also implementing a protocol/service) directly atop tokio-core?

Really, what I want is what is described in https://tokio.rs/docs/getting-started/pipeline-server/ examples, but with the socket and/or peer name passed through to the service.

Any changes get POST data?

Request.data is private
Request.slice is private

D:\Apache24\bin>ab -c 1 -n 100 -k http://127.0.0.1:8080/ nothing happen

F:\tokio-minihttp\target\debug\examples> cargo run --example hello_world
Compiling tokio-minihttp v0.1.0 (file:///F:/tokio-minihttp)
Running .\hello_world.exe

but
D:\Apache24\bin>ab -c 1 -n 100 -k http://127.0.0.1:8080/ nothing happen ,

Compilation on macOS Sierra fails with "Could not find `easy` in `tokio_core`"

Hi!
I'm unable to build on macOS 11.12 with rustc 1.13.0 (2c6933acc 2016-11-07).

Step to reproduce the problem:

git clone https://github.com/tokio-rs/tokio-minihttp.git
cd tokio-minihttp
cargo build

Output:

Updating registry https://github.com/rust-lang/crates.io-index
Updating git repository https://github.com/tokio-rs/tokio-service
Updating git repository https://github.com/alexcrichton/futures-rs
error: no matching package for override futures:0.1.3 found
location searched: https://github.com/alexcrichton/futures-rs
version required: = 0.1.3

Edit Cargo.toml to remove the line

"futures:0.1.3" = { git = "https://github.com/alexcrichton/futures-rs" }

cargo build

Output:

Updating git repository https://github.com/tokio-rs/tokio-proto
Updating registry https://github.com/rust-lang/crates.io-index
Updating git repository https://github.com/tokio-rs/tokio-service
Updating git repository https://github.com/tokio-rs/tokio-core
error: no matching package for override tokio-core:0.1.0 found
location searched: https://github.com/tokio-rs/tokio-core
version required: = 0.1.0

Edit Cargo.toml to remove the line

"tokio-core:0.1.0" = { git = "https://github.com/tokio-rs/tokio-core" }

cargo build

Output:

Updating registry https://github.com/rust-lang/crates.io-index
Updating git repository https://github.com/tokio-rs/tokio-service
Updating git repository https://github.com/tokio-rs/tokio-proto
Updating git repository https://github.com/carllerche/bytes
Compiling httparse v1.2.0
Compiling bitflags v0.4.0
Compiling log v0.3.6
Compiling void v1.0.2
Compiling lazycell v0.4.0
Compiling scoped-tls v0.1.0
Compiling take v0.1.0
Compiling libc v0.2.17
Compiling byteorder v0.5.3
Compiling semver v0.1.20
Compiling smallvec v0.2.1
Compiling cfg-if v0.1.0
Compiling winapi-build v0.1.1
Compiling futures v0.1.6
Compiling kernel32-sys v0.2.2
Compiling rand v0.3.15
Compiling net2 v0.2.26
Compiling rustc_version v0.1.7
Compiling nix v0.7.0
Compiling slab v0.3.0
Compiling bytes v0.4.0-dev (https://github.com/carllerche/bytes#93c08064)
Compiling winapi v0.2.8
Compiling tokio-service v0.1.0 (https://github.com/tokio-rs/tokio-service#4d1c0256)
Compiling time v0.1.35
Compiling mio v0.6.1
Compiling tokio-core v0.1.1
Compiling tokio-proto v0.1.0 (https://github.com/tokio-rs/tokio-proto#97063d84)
Compiling tokio-minihttp v0.1.0 (file:///Users/gio/Projects/tokio-minihttp)
error[E0432]: unresolved import tokio_core::easy::EasyBuf
--> src/request.rs:3:24
|
3 | use tokio_core::easy::{EasyBuf, Decode};
| ^^^^^^^ Could not find easy in tokio_core
error[E0432]: unresolved import tokio_core::easy::Decode
--> src/request.rs:3:33
|
3 | use tokio_core::easy::{EasyBuf, Decode};
| ^^^^^^ Could not find easy in tokio_core
error[E0432]: unresolved import tokio_core::easy::Encode
--> src/response.rs:3:5
|
3 | use tokio_core::easy::Encode;
| ^^^^^^^^^^^^^^^^^^^^^^^^ Could not find easy in tokio_core
error[E0432]: unresolved import tokio_core::easy::EasyFramed
--> src/lib.rs:24:5
|
24 | use tokio_core::easy::EasyFramed;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Could not find easy in tokio_core
error: cannot continue compilation due to previous error
error: Could not compile tokio-minihttp.
To learn more, run the command again with --verbose.

How can I proceed?

task error

Under high load by siege I have next errors:
ERROR:tokio_proto::server: task error: Connection reset by peer (os error 104)

I suppose we should try read socket again.

PS my current performance results really bad. sapper on hyper 2x faster

How to get request payload?

Hi,
I am calling an ajax post. How can I get the payload data at the Service? Am I missing something or do I have to implement my own Request?

Hello-World benchmark

I found this repository from this blog post. There is a benchmark result at the end of that blog post which demonstrates the notable performance of futures. However, I performed a benchmark test to compare fasthttp and minihttp:

minihttp cargo run --example hello-world

fasthttp

func fastHTTPHandler(ctx *fasthttp.RequestCtx) {
	fmt.Fprintf(ctx, "Hello World")
}

func main() {
	fasthttp.ListenAndServe(":8080", fastHTTPHandler)
}

The test was performed using wrk tools: wrk -d 10s http://localhost:8080

and here is the result:
minihttp:

Running 10s test @ http://localhost:8080
  2 threads and 10 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   568.17us   44.22us   2.63ms   92.61%
    Req/Sec     8.84k   353.74     9.27k    72.00%
  175785 requests in 10.00s, 17.27MB read
Requests/sec:  17576.79
Transfer/sec:      1.73MB

fasthttp:

Running 10s test @ http://localhost:8080
  2 threads and 10 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   527.98us    1.68ms  24.07ms   92.74%
    Req/Sec    70.65k     4.19k   79.65k    74.50%
  1407234 requests in 10.01s, 187.89MB read
Requests/sec: 140552.40
Transfer/sec:     18.77MB

What is the reason for this big difference in the results? How can I reach the throughput of fasthttp using futures?

Succession of this project to Thruster?

How well does Thruster follow the goals of this project?

Problems with compiling examples

grzegorz@grzegorz:~/Pulpit/rust/tokio-minihttp$ cargo run --example hello_world
    Updating git repository `https://github.com/tokio-rs/tokio-ssl`
    Updating registry `https://github.com/rust-lang/crates.io-index`
    Updating git repository `https://github.com/tokio-rs/tokio`
    Updating git repository `https://github.com/carllerche/bytes`
error: no matching package named `tokio-ssl` found (required by `tokio-minihttp`)
location searched: https://github.com/tokio-rs/tokio-ssl
version required: *
grzegorz@grzegorz:~/Pulpit/rust/tokio-minihttp$ 
grzegorz@grzegorz:~/Pulpit/rust/tokio-minihttp$ 
grzegorz@grzegorz:~/Pulpit/rust/tokio-minihttp$ cargo run --example ssl_server
    Updating registry `https://github.com/rust-lang/crates.io-index`
    Updating git repository `https://github.com/carllerche/bytes`
    Updating git repository `https://github.com/tokio-rs/tokio`
    Updating git repository `https://github.com/tokio-rs/tokio-ssl`
error: no matching package named `tokio` found (required by `tokio-minihttp`)
location searched: https://github.com/tokio-rs/tokio
version required: *
grzegorz@grzegorz:~/Pulpit/rust/tokio-minihttp$ 
grzegorz@grzegorz:~/Pulpit/rust/tokio-minihttp$ 
grzegorz@grzegorz:~/Pulpit/rust/tokio-minihttp$ cargo --version
cargo 0.13.0-nightly (c7ffb3e 2016-08-28)

This code has no license

AFAICT, this code is currently proprietary. I'm sure you meant to apply a free license, like GPL, BSD, MIT or Apache, similar to Tokio core.

compile-time error

grzegorz@grzegorz:~/Pulpit/tokio-minihttp$ cargo run --example hello_world
    Updating git repository `https://github.com/tokio-rs/tokio-proto`
    Updating git repository `https://github.com/tokio-rs/tokio-service`
    Updating git repository `https://github.com/alexcrichton/futures-rs`
    Updating registry `https://github.com/rust-lang/crates.io-index`
    Updating git repository `https://github.com/carllerche/bytes`
    Updating git repository `https://github.com/tokio-rs/tokio-core`
   Compiling winapi v0.2.8
   Compiling utf8-ranges v0.1.3
   Compiling winapi-build v0.1.1
   Compiling kernel32-sys v0.2.2
   Compiling semver v0.1.20
   Compiling rustc_version v0.1.7
   Compiling nix v0.6.0
   Compiling byteorder v0.5.3
   Compiling regex-syntax v0.3.5
   Compiling bitflags v0.4.0
   Compiling libc v0.2.16
   Compiling cfg-if v0.1.0
   Compiling take v0.1.0
   Compiling lazycell v0.4.0
   Compiling smallvec v0.2.0
   Compiling thread-id v2.0.0
   Compiling thread_local v0.2.6
   Compiling log v0.3.6
   Compiling futures v0.1.1 (https://github.com/alexcrichton/futures-rs#1b05e0e2)
   Compiling httparse v1.1.2
   Compiling slab v0.3.0
   Compiling time v0.1.35
   Compiling void v1.0.2
   Compiling memchr v0.1.11
   Compiling aho-corasick v0.5.3
   Compiling regex v0.1.77
   Compiling env_logger v0.3.5
   Compiling bytes v0.4.0-dev (https://github.com/carllerche/bytes#f693e038)
   Compiling rand v0.3.14
   Compiling futures v0.1.1
   Compiling tokio-service v0.1.0 (https://github.com/tokio-rs/tokio-service#4dfeaba1)
   Compiling net2 v0.2.26
   Compiling mio v0.6.0
   Compiling scoped-tls v0.1.0
   Compiling tokio-core v0.1.0
   Compiling tokio-proto v0.1.0 (https://github.com/tokio-rs/tokio-proto#63028a16)
   Compiling tokio-core v0.1.0 (https://github.com/tokio-rs/tokio-core#418a9735)
   Compiling tokio-minihttp v0.1.0 (file:///home/grzegorz/Pulpit/tokio-minihttp)
error[E0432]: unresolved import `tokio_proto::NewService`
  --> src/lib.rs:24:37
   |
24 | use tokio_proto::{pipeline, server, NewService};
   |                                     ^^^^^^^^^^ no `NewService` in `tokio_proto`

error: cannot continue compilation due to previous error

error: Could not compile `tokio-minihttp`.

To learn more, run the command again with --verbose.
grzegorz@grzegorz:~/Pulpit/tokio-minihttp$ 
grzegorz@grzegorz:~/Pulpit/tokio-minihttp$ git log -1
commit 1e8ec6a8cb11d7c0306651a240ba90ff78c4ab16
Author: Carl Lerche <[email protected]>
Date:   Thu Sep 8 19:29:48 2016 -0700

    Track tokio-service changes
grzegorz@grzegorz:~/Pulpit/tokio-minihttp$

reading the request data

Hello, rust newbie here. I haven't found a way to read the data from the requested and thus added the following patch. Am i missing something?

diff --git a/src/request.rs b/src/request.rs
index a74d022..25cdb85 100644
--- a/src/request.rs
+++ b/src/request.rs
@@ -43,6 +43,10 @@ impl Request {
     fn slice(&self, slice: &Slice) -> &[u8] {
         &self.data.as_slice()[slice.0..slice.1]
     }
+
+    pub fn data(&self) -> &str {
+        str::from_utf8(self.data.as_ref()).unwrap()
+    }
 }
 
 impl fmt::Debug for Request {

hanging connection - tests with ab

I have this code :

extern crate tokio_proto;
extern crate tokio_service;
extern crate tokio_minihttp as http;
extern crate futures;
extern crate futures_cpupool;
extern crate env_logger;

use tokio_service::Service;
use futures::{Async, Future};
use std::io;
use futures_cpupool::CpuPool;
use std::time;
use std::io::Read;
use std::fs::File;
use std::sync::{Arc, Mutex};

#[derive(Clone)]
struct HelloWorld {
    pool: CpuPool,
    counter: Arc<Mutex<u32>>,
}

impl HelloWorld {
    fn new() -> HelloWorld {
        HelloWorld {
            pool: CpuPool::new(4),
            counter: Arc::new(Mutex::new(0)),
        }
    }

    fn get_counter(&self) -> u32 {
        let mut guard = self.counter.lock().unwrap();

        let counter = *guard;
        *guard += 1;
        counter
    }
}

impl Service for HelloWorld {
    type Request = http::Request;
    type Response = http::Response;
    type Error = io::Error;
    type Future = Box<Future<Item=http::Response, Error=io::Error>>;

    fn call(&self, _request: http::Request) -> Self::Future {

        //let (sender, receiver) = futures::oneshot();
        let mut resp = http::Response::new();
        let request_number = self.get_counter();

        println!("spanw run: {:?}", request_number);

        self.pool.spawn_fn(move || -> Result<String, io::Error> {
            let s = get_file("./test.txt".to_owned());
            println!("open file {:?}", request_number);
            Ok(s)
        }).and_then(move |str| {
            resp.body(str.as_str());
            Ok(resp)
        }).boxed()
    }

    fn poll_ready(&self) -> Async<()> {
        Async::Ready(())
    }
}

fn get_file(path: String) -> String {
    let mut f = File::open(path.as_str()).unwrap();
    let mut s = String::new();
    f.read_to_string(&mut s).unwrap();

    s
}

pub fn main() {
    let _ = ::env_logger::init();

    let addr = "0.0.0.0:8080".parse().unwrap();

    println!("start server at: 0.0.0.0:8080");

    http::serve(addr, HelloWorld::new());
}

When I run ab :

grzegorz@grzegorz:~/Pulpit/rust/test_http_futures$ ab -n 100 -c 10 http://127.0.0.1:8080/
This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 127.0.0.1 (be patient)...apr_pollset_poll: The timeout specified has expired (70007)

Out from server :

grzegorz@grzegorz:~/Pulpit/rust/test_http_futures$ cargo run --example static
    Finished debug [unoptimized + debuginfo] target(s) in 0.0 secs
     Running `target/debug/examples/static`
start server at: 0.0.0.0:8080
spanw run: 0
open file 0
spanw run: 1
open file 1
spanw run: 2
open file 2
spanw run: 3
open file 3
spanw run: 4
open file 4
spanw run: 5
open file 5
spanw run: 6
open file 6
spanw run: 7
open file 7
spanw run: 8
open file 8
spanw run: 9
open file 9

It seems that the server can not handle another request in the same connection.

help please :)

PR needs review. Fixed tokio-core change to Encoder/Decoder

Request: Techempower benchmarks

I've seen a bit of data from @alexcrichton 's blog suggesting the minihttp framework built on top of tokio performs extremely well while sporting a fairly ergonomic design. Unfortunately a couple of the links are dead and the current benchmarks on the page don't have any other frameworks for comparison.

Would the possibility of pushing a benchmark to the techempower benchmarks be something that you guys could do? These benchmarks get a fair amount of traffic and promising results would increase visibility to the tokio project. It would help validate any performance claims that're being made about the project as well.

Right now, in preliminary results, rust isn't fairing too well across the board.

Techempower's github

Is it possible to combine minihttp with anything else in the same loop?

I can't just call tokio_minihttp::serve for that because I don't have the access to Core this way. And I can't copy the code from tokio_minihttp::Server::serve because there are lots of private stuff.

Am I missing something obvious?

Current HTTP implementation problem?

I am wondering what is meant by:

This implementation of HTTP, while far from complete...

I've used this implementation to base my RESTful API, and I'm wondering if there are any pitfalls that will come up eventually? The performance is great, and I don't see any downsides atm.

tokio-rs / tokio-minihttp Goto Github PK

tokio-minihttp's People

Contributors

Stargazers

Watchers

Forkers

tokio-minihttp's Issues

Step to reproduce the problem:

Output:

Output:

Output:

Recommend Projects

Recommend Topics

Recommend Org