Во первых нужно найти наименее зашумленный канал. Вероятно у соседей стоит много точек доступа, и они мешают твоей точке (а твоя мешает им). Тебе необходимо просканировать эфир и найти наименее загруженный канал.
В Mac OS это можно сделать утилитой Wireless Diagnostics, которая лежит в /System/Library/CoreServices/Applications.
В Windows для этих целей можно попробовать утилиту www.wifichannelscanner.com (сам не пробовал, виндовсом не пользуюсь).
В линуксе это, на сколько я помню, делается утилитой iwconfig.

Хочу заметить, что, несмотря на то, что в 802.11 каналов 11 или 13, непересекающихся всего 3.



Во вторых нужно посмотреть в каком режиме у тебя работает точка доступа. Для максимальной скорости необходимо поставить режим Native 802.11n или 802.11n only (каждый вендор называет как хочет, но смысл примерно такой). Но в этом случае устройства, не поддерживающие 802.11n (например 802.11g адаптеры) подключиться не смогут.

В любом случае, даже при идеальных условиях скорость передачи полезных данных через WiFi у тебя будет не более 60-70 МБит (7-8 МБайт/сек) с твоей точкой доступа (у нее канальная скорость 150Мбит/с).

Можно ничего не ставя посмотреть какие запросы выполняются сейчас
select * from pg_stat_activity;
Выполнив запрос несколько раз можно понять какие запросы висят долго

Ну сохранять их будет полезно, если у Вас есть, например, форум. А при каждом входе, по хорошему, их нужно синхронизировать. Если Вам имя пользователя и другая его инфа в его отсутствие не нужна, то можно после входа данные хранить в сессии.

1. примерно так

2. Нет, многопоточность с асинхронностью не имеет ничего общего. При многопоточности обычно планировщик ядра (если потоки ядерные) переключает контекст между твоими потоками. Работает это так: ты в своем приложении сообщаешь планировщику что хочешь создать поток (например через pthread_create, если ты программируешь в linux или freebsd), указывая ему функцию, которая должна выполняться в отдельном потоке и аргументы для нее. Ядро создает у себя в таблицах запись для него и ставит этот поток в очередь на выполнение так же как основной поток. Адресное пространство у них будет общее.

3. К примеру ты хочешь обслуживать TCP клиентов, ты создаешь сокет (или несколько), ставишь им неблокирующий режим, затем тебе их в цикле нужно опрашивать. Для этого есть несколько способов: select и poll есть во всех ОС, но они хороши когда у тебя сокетов мало. В linux есть еще epoll, который намного более эффективен, во FreeBSD и MacOS есть kqueue - очень эффективный метод. Когда к тебе, к примеру, придет TCP клиент твой select/poll/epoll/kqueue вернет информацию о сокете, который готов для чтения (твой listen сокет), ты делаешь ему accept, и добавляешь сокет клиента в select/poll/epoll/kqueue. Если происходит событие на клиентском сокете, к примеру на нем сработал read - значит там есть данные, ты их читаешь и обрабатываешь, если сработал write - сокет освободился для записи и можно в него писать. Еще в kqueue и epoll есть таймеры. Главное не использовать при такой архитектуре какие-нибудь sleep, не использовать блокирующие библиотеки с базам данных, нужно обраратывать все быстро и возращать управление в select/poll/epoll/kqueue. Если, к примеру, нужно сделать задержку, выполнение коллбэка нужно прервать, создав какой-нибудь таймер (есть много способов).
В целом - разработка асинхронных приложений требует совершенно иного подхода, это обычно немного сложнее, особенно если тебе нужно будет ходить, например, в базу данных. К примеру, системный резолвер (gethostbyname) является блокирующим - его в такое архитектуре исползовать нельзя, придется взять библиотеку, например, c-ares, которая реализует асинхронный резолвер.

4. то же что и 3, но select/poll/epoll/kqueue запускаем в нескольких потоках, это рационально делать для утилизации нескольких процессоров.