linux 有名信号量semaphore性能探究

起因

最近想基于共享内存加有名信号量实现一个进程间的共享栈，来取代thrift, 优化下ipc的延迟。

测试

首先测试了下thrift消息传递的延迟，分别在client调用前和server（client server位于同一台机器）收到消息打印微秒

start  end    us
776912 777005 93
777152 777228 76
777340 777422 82
777502 777572 70

测试结果表明thrift一次通信大概需要80us的延迟。

如果我们改为信号量来通知server读取共享栈的参数，那么我们有必要测试下信号量在阻塞的情况下，被sem_post唤醒的性能。

贴下测试使用的client 和server代码

 

client

#include <semaphore.h>
#include <fcntl.h>
#include <stdio.h>
#include <unistd.h>
#include <sys/time.h>


int main()
{

  sem_t *lock = sem_open("lock_test", O_CREAT | O_RDWR, 0777, 0); 
  int id = 0;
  while(1) {
        sleep(1);
        struct timeval tv; 
        gettimeofday(&tv, NULL);
        sem_post(lock);
        printf("id=%d, usec=%d\n", id, tv.tv_usec);
        id++;
  }
}

server

#include <semaphore.h>
#include <fcntl.h>
#include <stdio.h>
#include <unistd.h>
#include <sys/time.h>


int main()
{

  sem_t *lock = sem_open("lock_test", O_CREAT | O_RDWR, 0777, 0); 
  int id = 0;
  while(1) {
        sem_wait(lock);
        struct timeval tv; 
        gettimeofday(&tv, NULL);
        printf("id=%d, usec=%d\n", id, tv.tv_usec);
        id++;
  }
}

 测试结果

client
id=0, usec=279236
id=1, usec=279418
id=2, usec=279542
id=3, usec=279660
id=4, usec=279777
id=5, usec=279902
id=6, usec=280030
id=7, usec=280147
id=8, usec=280261
id=9, usec=280380
id=10, usec=280512
id=11, usec=280635
id=12, usec=280748
id=13, usec=281623
id=14, usec=281731
id=15, usec=281854
id=16, usec=281991
id=17, usec=282119
id=18, usec=282240
id=19, usec=282353
id=20, usec=282471
id=21, usec=282604
id=22, usec=282719

server
id=0, usec=279284
id=1, usec=279445
id=2, usec=279569
id=3, usec=279693
id=4, usec=279810
id=5, usec=279942
id=6, usec=280060
id=7, usec=280176
id=8, usec=280293
id=9, usec=280413
id=10, usec=280547
id=11, usec=280665
id=12, usec=280773
id=13, usec=281679
id=14, usec=281764
id=15, usec=281910
id=16, usec=282024
id=17, usec=282166
id=18, usec=282287
id=19, usec=282379
id=20, usec=282520
id=21, usec=282638
id=22, usec=282747

测试发现信号量在阻塞的情况下被唤醒，需要大概20-40个us的时间（猜测涉及到了linux内核的调度）。

总结

基于上述结果，综合了下实际情况，没有改造的必要。首先自己实现协议栈的解析，会带来延迟。并且所有的client都需要被改造，最重要的是，操作栈的时候，要锁住共享栈，导致并发数将为1。通过这次测试对信号量的性能心中有底了。