[Gluster-devel] Performance problems in our web server setup

[Anand Avati]

Actually having io-threads as the 'bottommost' is the preferred mode.
io-threads is meant to push blocking operations (disk read, disk write,
network write) to a seperate thread, so that the 'logic' (read-ahead,
io-cache, write-behind) work over a non-blocking base. A thread-count of 16
might be a bit high though.

thanks,
avati

2007/7/24, Harris Landgarten <harrisl at lhjonline.com>:
>
> Bernard,
>
> Try moving io-threads to the end of the chain on your client. Gluster
> looks at the chain bottom up so that will put io-threads at the top. You
> should also test with and without readahead. As it has been explained to me,
> readahead only helps on IB or other very fast connections that can swamp the
> processor. In my app, readahead's overhead was actually slowing things down.
>
> I have been on 2.5 for a while so I am not sure if all of this translates
> to 2.4 but if you are going to stay on 2.4 you should update to patch-184.
> There were many bugs fixed and if I remember there were a lot of io-threads
> fixes.
>
> Harris
>
> ----- Original Message -----
> From: "Bernhard J. M. Grün" <bernhard.gruen at googlemail.com>
> To: gluster-devel at nongnu.org
> Sent: Tuesday, July 24, 2007 10:22:36 AM (GMT-0500) America/New_York
> Subject: [Gluster-devel] Performance problems in our web server setup
>
> Hello!
>
> We experience some performance problems with our setup at the moment.
> And we would be happy if someone of you could help us out.
> This is our setup:
> Two clients connect to two servers that share the same data via AFR.
> The two servers hold about 13.000.000 smaller image files that are
> sent out to the web via the two clients.
> First I'll show you the configuration of the servers:
> volume brick
>   type storage/posix                   # POSIX FS translator
>   option directory /media/storage       # Export this directory
> end-volume
>
> volume iothreads    #iothreads can give performance a boost
>    type performance/io-threads
>    option thread-count 16
>    subvolumes brick
> end-volume
>
> ### Add network serving capability to above brick.
> volume server
>   type protocol/server
>   option transport-type tcp/server     # For TCP/IP transport
>   option listen-port 6996              # Default is 6996
>   option client-volume-filename /opt/glusterfs/etc/glusterfs/client.vol
>   subvolumes iothreads
>   option auth.ip.iothreads.allow * # Allow access to "brick" volume
> end-volume
>
> Now the configuration of the clients:
> ### Add client feature and attach to remote subvolume
> volume client1
>   type protocol/client
>   option transport-type tcp/client     # for TCP/IP transport
>   option remote-host 10.1.1.13     # IP address of the remote brick
>   option remote-port 6996              # default server port is 6996
>   option remote-subvolume iothreads        # name of the remote volume
> end-volume
>
> ### Add client feature and attach to remote subvolume
> volume client2
>   type protocol/client
>   option transport-type tcp/client     # for TCP/IP transport
>   option remote-host 10.1.1.14     # IP address of the remote brick
>   option remote-port 6996              # default server port is 6996
>   option remote-subvolume iothreads        # name of the remote volume
> end-volume
>
> volume afrbricks
>   type cluster/afr
>   subvolumes client1 client2
>   option replicate *:2
> end-volume
>
> volume iothreads    #iothreads can give performance a boost
>    type performance/io-threads
>    option thread-count 8
>    subvolumes afrbricks
> end-volume
>
> ### Add writeback feature
> volume writeback
>   type performance/write-behind
>   option aggregate-size 0  # unit in bytes
>   subvolumes iothreads
> end-volume
>
> ### Add readahead feature
> volume bricks
>   type performance/read-ahead
>   option page-size 65536     # unit in bytes
>   option page-count 16       # cache per file  = (page-count x page-size)
>   subvolumes writeback
> end-volume
>
> We use Lighttpd as web server to handle the web traffic and it seems
> that the image loading is quite slow. Also the used bandwidth between
> one client and its corresponding AFR-Server is low - about 12 MBit/s
> over a 1 GBit line. So there must be a bottleneck in our
> configuration. Maybe you can help us.
> At the moment we are using 1.3.0 (mainline--2.4 patch-131). At the
> moment we can't easily switch to mainline--2.5 because the servers are
> under high load.
>
> We also have seen that each client uses only one connection to each
> server. In my opinion this means that the iothreads subvolume on the
> client is (nearly) useless. Wouldn't it be better to establish more
> than just one connection to each server?
>
> Many thanks in advance
>
> Bernhard J. M. Grün
>
>
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at nongnu.org
> http://lists.nongnu.org/mailman/listinfo/gluster-devel
>
>
>
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at nongnu.org
> http://lists.nongnu.org/mailman/listinfo/gluster-devel
>



-- 
Anand V. Avati