Естественно, при соблюдении правильной структуры сайта, при выдаче ошибок 404 где требуется. Например, сейчас у вас некоторые ссылки каталога ведут на страницы с 404 — это тоже надо исправить. Не делайте похожие ссылки на одну и ту же страницу если возможно (у которых в конце ?list, ?gallery и т д.).
И вообще, мне не нравится такой подход, «возвращать на сайт пользователя». Кроме вашего сайта, в сети есть куча других сайтов, наверняка некоторые из них даже лучше вашего, так почему он должен возвращаться именно к вам? Зачем? Пусть идет туда, где лучше.
Хоть бонус какой-то давайте за возврат, а то смысл на это время тратить?
Если у вас есть какой-то проект, где начинаются проблемы с нагрузкой на БД, вы можете протестировать этот способ, и убедиться, что он работает, при правильном подходе. Если у вас такой задачи нет, смысл что-то обсуждать? Доказывать, что 2 или 3 сервера могут обработать больше запросов, чем 1, я не вижу смысла.
> очень хочу узнать про проект в котором это таки понадобилось сделать
А что не так с этим вариантом? Есть такой проект, (даже думаю не один), где сервер БД не выдерживает нагрузки (даже с учетом мемкеша, правильных индексов и прочего, так как там в секунду много хитов и большие размеры таблиц, много пользователей) и таблицы раскиданы по нескольким серверам. Что за проект, называть не хочу.
> Возникает вопрос: а если результатом первого запроса будет 1k идентификаторов?
Ну в этом случае все равно у вас код, который эти записи будет отображать в шаблоне, будет тормозить гораздо сильнее, чем код выборки 1000 записей из БД. Так что не стоит беспокоиться.
При использовании сложных запросов риск появления необъяснимых тормозов возрастает в разы.
Еще в онлайн играх баланс правят, исходя из статистики: например, если мы видим, что люди бросают игру после 13 уровня, значит там что-то не так, надо разобраться. Может, слишком долго проходить. Может, баг в программе, который не дает выполнить заданием некоторым. Может, неинтересно. Может, непонятно написано. И так далее.
Если люди бросают игру, не доходя до «платных» уровней, на тех уровнях, которыет должны приносить им позитивные эмоции и повышение ЧСВ, значит дела совсем плохи.
Вообще, OpenVZ плохо подходит для линуксовых программ, так как OpenVZ считает зарезервированную память, а линуксовые программы ее резервируют не стесняясь. Например, MySQL на сервере с 128 Мб имеет 13 Мб RSS и 125 Мб VSS. И OpenVZ посчитает ее по максимуму, так что ваши 512 Мб на OpenVZ — это где-то 256 обычных мегабайт.
Потребление памяти MySQL контроллируется параметрами в конфиге. То есть можно явно указать число процессов и размеры буферов, которые они используют. Не факт, что по умолчанию значения подойдут для вас.
Ок, тогда предлагаю другой вариант. Если разработчик игры не идиот и не копипастер, то все эти цифры берутся не из воздуха, а путем логических и математических рассуждений. Силы персонажей, возможности оружия и их расположение и стоимость, скорость и график респавна нейтральных войск подбираются таким образом, чтобы игрок сталкивался с максимально сложным соперником, но чтобы его все еще можно было в итоге победить. Чтобы не было ситуаций, когда активной игры не ведется, а игрок тупо сидит и копит ресурсы (для борьбы с этим можно похимичить с кривой развития войск ИИ, чем дольше ждешь, тем враги сильнее, ждать невыгодно). Играть с простым соперником неинтересно. Играть с непобедимым принципиально соперником (потому, что у него в 5 раз больше шахт и лесов) невозможно.
Что касается браузерных игр и игр для вконтакта. Тут главная цель — развести игрока на деньги. Поэтому надо сделать с одной стороны, первые левелапы простыми и быстрыми (чтобы принести игроку приятные эмоции и подсадить на игру, и чтобы ему было жалко бросить полученные трудом достижения), а следующие делать нудными, типа убить 1000 монстров или купить за СМС какое-нибудь заклинание, чтобы грохать их пачками. Чтобы игроку не надоело, не надо делать однотипные левелапы, типа убей 100 драконов, поймай 100 летучих мышей и так далее, каждый раз надо придумывать что-нибудь новенькое и тут же подсовывать подходящие по случаю артефакты за деньги.
Если душа возмущается против того, что схема совсем примитивна, можно слегка усложнить покупку — например, вещи можно покупать только в определенных местах, которые еще надо найти, причем для каждой вещи свои, но это ударит по доходам, лучше делать игру с расчетом на идиотов.
Да. Потому что документация никогда не отражала всех особенностей системы и не будет, хотя бы потому, что код переписывают, меняют, и т.д, и зачастую ответ можно узнать только экспериментом. Ну или анализируя исходный код — и по отзывам тех, кто его смотрел, это отнюдь не самый простой и понятный код. Описанный же эксперимент отнимет максимум полчаса времени.
Если лень делать таблицу на 10 млн записей, сделайте на 1 млн, но с большими таблицами интереснее, когда например индексы перестают влезать в память, и т.д.
Что плохого в функции в глобальной области видимости? Если боитесь, что могут конфликтовать функции при открытии сайта в нескольких вкладках, вы можете при открытии окна генерировать номер вроде callback09090976 и передавать имя коллбека через GET-параметры открываемому окну.