Добрый день, есть приложение с фреймворком Django и есть сервер на питоне+twisted (который от джанги берет модели и разные функции, которые так же используются в приложении), на этот сервер приходят сообщения двух видов:
1. проверка наличия сообщений
2. ответ на сообщение.
Клиент подключаясь к этому серверу в первый раз запрашивает о наличии сообщений и если в базе есть сообщения для этого клиента, то выдает текст этого сообщения, после чего клиент обрабатывает это сообщение и возвращает ответ на него, сервер помещает ответ в базу и при наличии еще одного сообщения так же отправлять его клиенту и т.д. до тех пор пока сообщения не кончатся или клиент не отвалится.
Клиентов, которые будут подключаться к серверу будет не много (в пределах 10 наверное, основную нагрузку берет на себя другой сервер написанный на Си, который и будет в роли клиента подключаться к пайтоновскому серверу). И соответственно вопрос на сколько такая работа с базой будет критической? частые запросы, записи и можно ли это дело как-то оптимизировать? База в данный момент mysql.

hound
на сколько такая работа с базой будет критической?

Так вы ничего не сказали. Ни сколько запросов в секунду, ни какие это запросы, ни размер сообщений. Вообще и одним запросом базу данных можно подвесить на несколько часов. Детализируйте вопрос, тогда и можно будет что-то сказать.

1 очевидно запрос из таблицы пары чисел базу не нагрузит.
2 очевидно если интересует производительность базы то данные лучше и брать и класть одним запросом а не поштучно.

Если база узкое место, то выгребите все сообщения из БД и потом начинайте обрабатывать. Правильно говорит doza_and. Зачем мучить сервер частыми микрозапросами. Это раз. Во-вторых. Структура сообщения. Это важно. Частота таких сообщений (ну хотя-бы планируемая). Возможно рационально будет использовать какую-нибудь прослойку типа редис. Очень мало информации. По-типу: “У меня машина легковая зеленого цвета. Двигатель 1.8. Не хочет быстро ехать. Как можно сделать, чтобы она ехала быстрее”

Да, ступил с описанием…
В общем, смысл вот в чем:
частота запросов базу может сильно различаться, от нескольких в секунду до простоев на несколько минут.
Вид запроса будет в двух вариантах:
1 - какой-то идентификатор по которому будет в базе искаться запись, если для этого идентификатора записей несколько, то будет возвращена самая первая запись, если записей нет, то соответственно сервис ответит, что записей и нет.
2 - грубо говоря ответ на полученную ранее запись. С этим ответом ранее полученная запись должно обновиться.
И дальше снова пункт 1 и т.д по кругу.

Ну и как выше писал клиентов, которые будут подключены к этому сервису может быть несколько.