?

Log in

No account? Create an account

writev() and other myths...

« previous entry | next entry »
Feb. 12th, 2008 | 06:53 pm

I've been looking from different angles on ways to make memcached_get() (aka from libmemcached) faster.

I keep toying with different ideas... rewriting it in different ways to see if I can get any performance changes in it.

Thus far... nada... no go.

Yesterday I had the idea of "bypass my write buffer, use writev() to push the data to the client".

This would save me in design two memory copies.

Results?

writev() was slower.

D'oh!

What to do, what to do...

I keep a copy of glibc() on my laptop. I do this for just such the occasion.

How is writev() implemented? It alloc's memory large enough to contain the data, does a copy, and then calls write().

Well crap.

I have never used writev() before, the interface has just never been one I wanted to deal with for asynchronous connections.

I had always assumed that it was clever. Somehow saving on system calls, yadda, yadda, yadda...

Nope, it does not.

Oh well :)

Back to the drawing board...

Link | Leave a comment | Share

Comments {7}

James Antill

Not true, libc is just confusing

from: illiterat
date: Feb. 13th, 2008 06:36 am (UTC)
Link

You are looking at the implementation of writev() for systems that don't have it as a syscall. Linux has it as a syscall. You want to look at:

sysdeps/unix/sysv/linux/writev.c

Reply | Thread

Brian "Krow" Aker

Re: Not true, libc is just confusing

from: krow
date: Feb. 13th, 2008 11:49 am (UTC)
Link

Good point. Still slower though in local benchmarks when compared to using my own write buffer.

I also dislike how write partial failures work. Since you have to calculate into the structure to find out where you should startup again.

Reply | Parent | Thread

Why not just use mmap()

from: markxr
date: Feb. 13th, 2008 09:45 am (UTC)
Link

On 64-bit (i.e. most modern servers) there should be no drawback in using mmap(). Map as many large files into memory as you like - you will definitely save system calls. You can either map several small ranges, or map the entire file if you prefer.

It should be more efficient. Please consider it :)

Reply | Thread

Brian "Krow" Aker

Re: Why not just use mmap()

from: krow
date: Feb. 13th, 2008 11:44 am (UTC)
Link

Its a set of tiny strings. mmap() is not really relevant to the problem :)

Reply | Parent | Thread

Re: Why not just use mmap()

from: markxr
date: Feb. 13th, 2008 12:46 pm (UTC)
Link

I thought you were using it for file IO, I can see now you're proposing using writev for sockets.

Have you considered doing the system calls anyway, but using the TCP_CORK linux-specific option to get the kernel to buffer it until your packet is complete? I am not sure whether this would be helpful, I think it's intended for use with sendfile()

Mark

Reply | Parent | Thread

(Deleted comment)

Brian "Krow" Aker

(no subject)

from: krow
date: Feb. 27th, 2008 08:48 pm (UTC)
Link

I think I got something similar... the change was just so tiny that it wasn't worth the effort. I'm looking for bigger gains :)

Reply | Parent | Thread