Is level triggered or edge triggered more performant?

I wouldn't expect to see a huge performance difference between edge and level triggered.

For edge-triggered you always have to drain the input buffer, so you have one useless (just returning EWOULDBLOCK) recv syscall. But for level triggered you might use more epoll_wait syscalls. As the man page points out, avoiding starvation might be slightly easier in level triggered mode.

The real difference is that when you want to use multiple threads you'll have to use edge-triggered mode (although you'll still have to be careful with getting synchronization right).

The difference is only visible when you use long-lived sessions and you're forced to constantly stop/start because of buffers full/empty (typically with a proxy). When you're doing this, you most often need an event cache, and when your event cache is processing events, you can use ET and avoid all the epoll_ctl(DEL)+epoll_ctl(ADD) dance. For short-lived sessions, the savings are less obvious, because for ET you'll need at least one epoll_ctl(ADD) call to enable polling on the FD, and if you don't expect to have more of them during the session's life (eg: exchanges are smaller than buffers most of the time), then you shouldn't expect any difference. Most of your savings will generally come from using an event cache only since you can often perform a lot of operations (eg: writes) without polling thanks to kernel buffers.

When used as an edge-triggered interface, for performance reasons, it is possible to add the file descriptor inside the epoll interface (EPOLL_CTL_ADD) once by specifying (EPOLLIN|EPOLLOUT). This allows you to avoid continuously switching between EPOLLIN and EPOLLOUT calling epoll_ctl(2) with EPOLL_CTL_MOD.

Q9 Do I need to continuously read/write a file descriptor until EAGAIN when using the EPOLLET flag (edge-triggered behavior) ?

   A9  Receiving  an  event  from epoll_wait(2) should suggest to you that
       such file descriptor is ready for the requested I/O operation.  You
       must  consider  it  ready  until  the next (nonblocking) read/write
       yields EAGAIN.  When and how you will use the  file  descriptor  is
       entirely up to you.

       For packet/token-oriented files (e.g., datagram socket, terminal in
       canonical mode), the only way to detect the end of  the  read/write
       I/O space is to continue to read/write until EAGAIN.

       For  stream-oriented  files  (e.g., pipe, FIFO, stream socket), the
       condition that the read/write I/O space is exhausted  can  also  be
       detected  by checking the amount of data read from / written to the
       target file descriptor.  For example, if you call read(2) by asking
       to read a certain amount of data and read(2) returns a lower number
       of bytes, you can be sure of having exhausted the  read  I/O  space
       for  the  file  descriptor.   The  same  is true when writing using
       write(2).  (Avoid this latter technique  if  you  cannot  guarantee
       that  the  monitored file descriptor always refers to a stream-ori‐
       ented file.)