Dmitry Dedukhin

Сделайте 2 запроса.
Первый выбирает сообщение, включая ID пользователей, с ним связанных.
Второй выбирает обоих пользователей по ID.

В случае использования JOIN изменение в любой таблице влечет за собой сброс кеша запроса в базе.
В случае двух запросов изменения например в таблице messages не будут сбрасывать кеш запроса по таблице пользователей, и наоборот.

Не используйте для дозагрузки решения, базирующиеся на Flash.
Чтение файлов во флэше реализовано криво, файл целиком загружается в память.
Для этих целей подходят Silverlight и Html5 решения (насчет Java не знаю, так что врать не буду).
Зачатки дозагрузки есть в Plupload (chunking-режим, но надо допиливать).
Ну и не могу не предложить моё решение Lightweight Uploader, которое заточено на работу с nginx + nginx_upload_module, но может работать с любым бэкендом, реализующим этот протокол.

Не знаю насчет других БД, но в MySQL мне известен только один способ получения случайной выборки:

SELECT * FROM table ORDER BY rand() LIMIT N;

Это _очень_ медленно работает, т.к. сканируется вся таблица («Using temporary; Using filesort» со всеми вытекающими).

Ваш вариант с двумя переменными по-моему единственно возможный.
Но для хранения в SSI переменных больших кусков текста нужно воспользоваться недокументированной директивой ssi_value_length, которая по умолчанию равна 256 байтам и этого скорее всего не хватает для хранения вашего html-кода (об этом должны быть сообщения в error-логе):

location /random/ {
  ...
  ssi_value_length 32k;
}

точнее

(function(i) {
    $.getScript(onload_js[i]["src"][j],function() {
      if (//Здесь проверка что все остальные скрипты загружены тоже)
        onload_js[i]["callback"]();
    }
})(i);

Если я правильно понял и вам нужно передать текущее значение i, то

(function(i) {
  onload_js[i]["callback"]();
})(i);

Если у вас поиск только по первой части названия новости, то создайте в базе memory-таблицу с индексом по названию и заносите в неё название новости и логотип. Базы данных как бы для того и сделаны, чтобы в них искать, поиск по индексированной таблице в памяти — это не очень дорогое удовольствие.

Это похоже на проблемы самого хабра.
Учитывая, что он судя по всему написан на php (используется куки PHPSESSID) и то, что по умолчанию сессия хранится в файле на диске, то при попадании на другой бэкенд-сервер (например при смене вашего IP при условии, что фронтенд распределяет пользователей по бэкенд-серверам на основании их IP) вы теряете сессию.
Я конечно хочу верить, что разработчики хабра сделали хранение сессий как минимум в мемкешди, но симптомы говорят не в пользу этой версии.

lwu.no-ip.org/

Поддерживает html5, flash и silverlight загрузку, успешно откатывается при наличии банерорезок.
На мой взгляд, имеет набор событий для реализации любых желаний.
Всю кастомизацию очереди загрузки делаете вы сами.
Поддерживает дозагрузку в случае обрыва соединения (только в html5 и silverlight).
Поддерживает междоменную загрузку файлов.
Работает только с nginx + nginx_upload_module, хотя при желании можно реализовать протокол возобновляемой загрузки www.grid.net.ru/nginx/resumable_uploads.ru.html в других серверных компонентах.

2) Очень частой стала ошибка 503, чаще всего при переходе по постраничной навигации почему-то. Поскольку эту страницу отдает nginx — возник вопрос, а зачем вообще хабру nginx на фронтенде? Статики-то тут никакой, одна реклама только. Или на хабре nginx используется не только как фронтенд? Если кто в курсе — расскажите, интересно.

Ну неудивительно, если вы забредаете на 100+ страницу, которая к тому же не закеширована.
В этом случае запрос вида select * from qa order by id desc limit 1000,10 может немного напрячь сервер БД.
А если еще какой-нибудь поисковый бот в это время ходит по «дальним» страницам…

Если нужно отключить кеширование совсем, то по моему мнению самый надежный способ — это генерация случайного числа как описано выше и добавление заголовка Cache-Control: no-cache, no-store в ответ сервера.

для nginx как-то так

location ~* /static/\d+/ {
   alias /path/to/static;
}

в шаблоне при изменении скриптов/стилей увеличиваете циферку

<script src="/static/123/js/core.js"></script>

Может, в сильверлайте размер файла 64-битный.
Возьмите мой загрузчик и проверьте, кто вам мешает?

Самое главное-то я забыл, lightweight uploader
Разрабатываю как альтернативу plupload, сайт еще не доделан, но можно посмотреть примеры.
Из плюсов:
— меньше размер кода
— конкретно заточен на работу со связкой nginx + nginx upload module
— как следствие пункта 2 — возможность дозагрузки файлов

В Опере же работает silverlight, а с ним запросто можно грузить файлы любого размера, причем очень весомое достоинство — можно грузить небольшими кусочками.
С флэшом есть проблема — класс FileReference, с помощью которого и осуществляется загрузка, не позволяет читать файл по смещению, есть единственный метод load() который полностью загружает файл в память компьютера и даже на файле 500мб может повесить машину с 2ГБ озу на борту.
Загрузка чанками имеет огромный плюс в том, что практически исключается влияние всяких прокси на пути файла от браузера к вашему серверу (к таким прокси относятся и некоторые антивирусы), которые [прокси] могут вызывать срыв загрузки из-за таймаутов.

Одна таблица InnoDB легко справится с несколькими десятками и даже сотнями миллионов записей — нужно лишь достаточное количество оперативной памяти на сервере.
Главное — не делать в ней лишних ключей, чтобы при добавлении записи не было масштабного перестроения индексов.
Если же есть задача поиска по тексту комментариев, то либо смотреть в сторону полнотекстовых индексов MyISAM (который гораздо хуже работает при одновременной записи и чтении), либо использовать специализированные решения вроде Sphinx.

Задумайтесь о том, что аватарки — это скорее всего много запросов на чтение.
При отдаче их из базы вы будете насиловать дисковую подсистему, в то время как при отдаче с диска _все_ аватарки (в зависимости от объема памяти сервера) могут быть закешированы системой в памяти и их отдача будет турбореактивной.

Все языковые версии находятся на домене site.com а текущий язык пользователя берем из куки, куда он заносится либо из предпочитаемого языка браузера, либо осознанным выбором пользователя.
Выбор пользователя — это ссылки site.com/fr/, site.com/en/ и т.д. обработчик которых всего лишь устанавливает куку и редиректит либо на реферера (если он в пределах вашего сайта), либо на главную страницу вашего сайта. Соответственно, все надписи на сайте выводятся спец. функцией, аргументом которой является ярлык — короткое, но понятное описание строки, за ним скрывающейся, например T('PLEASE_LOGIN') выводит надпись «Пожалуйста, зарегистрируйтесь» на нужном языке, все метки и их переводы на все языки хранятся в одном месте.
Такой вариант вас не устраивает?

CTPP2

Плюсы:
— высокая скорость работы
— расширяемость (можно добавлять свои функции)
— один набор данных для шаблонизации на сервере и на клиенте (JSON)
— недавно появился модуль для шаблонизации силами nginx, он пока не production-ready, но думаю быстро станет таковым