rPman

Выглядит, как будто процессы где то обращаются к общему ресурсу и ждут его освобождения (какой-нибудь кривой метод реализации очереди), выше уже посоветовали тщательно отладить и выявить где именно в коде образуется затык, обычным подробным логированием.

Переложить весь код генерации в отдельный процесс, запускаемый вне сессии IIS (отдельным сервисом или даже standalone приложением) на том же php через какую-либо простенькую очередь, а вебсерверу оставить задачу — поместить задание в очередь, ждать его завершения, отдать результат.

Достоинство такого разделения — более полный контроль над нагрузкой (процесс, обрабатывающий задания в очереди может быть многопотоковым) и самое главное, он будет запускаться в контексте обычного приложения без каких-либо внутренних особенностей и глюков, которые порождает IIS (ведь вы же сами показали что только под IIS возникает проблема).

И главное, переписывать ничего не придется, фактически только добавить очередь задач и ее обработку.

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

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

Весь путь считать не актуально, достаточно рассчитывать в пределах 1-2 ячеек вперед (по уже известным вам алгоритмам) и получать ответ, есть ли вообще возможность попасть к цели. Добавить к алгоритму пересчет пути в зависимости от игровых объектов актуальных для расчета коллизий (тут проблема — возможны ли заторы).

Такие ячейки — это аналог памяти юнитов о том, как можно было бы примерно пройти в соответствующую зону.
Добавит даже больше реализма, например поведение при заторах, юнит как бы еще не видит что путь впереди закрыт, но послушно топает, пока не попадет в ячейку с этим затором… тогда возникнет событие что путь достигнуть нельзя… так как меду ячейками вариантов перемещения всегда несколько, это создает не один путь перемещения по ячейкам несколько, соответственно временно помечаем что путь закрыт и выбираем следующий.

Не надо мучиться, напишите на моно простейшее консольное приложение использующее штатный контрол WebBrowser (при запуске под mono используется firefox), и пишите всю логику на javascript, запуская тут же на этой же странице на onload (точнее его аналог события на контроле).
Оно действительно получается очень простым, вся логика влезает в javascript с использованием jquery (его можно грузить в отличный от '$' идентификатор). И при этом запускается такое приложение на любом самом дешевом vps linux.

Я думаю между этим приложением и своим на php обмен сообщениями осилите c простейшими push ajax запросами или даже websocket?

Выбор между с++ и java (добавьте сюда .net c# ) это больше не выбор между языками программирования и синтаксическим сахаром, а выбор между фреймворками (библиотеками) которые идут вместе (или для) с этим языком как 'стандарт по умолчанию'.
Тем более эти языки на столько похожи, они вышли то и одного лона 'старого c++'!

А это значит выбирайте то что вам нравится, но будьте готовы просто выучить еще один фреймворк (и чуть чуть языковых конструкций), ведь программист, не готовый изучать что то новое… слабовато выглядит и заранее обречен на провал.

omnimod, с грубым приближением, какая получается цена внедрения описанного вами решения только за счет лицензий на софт, и это без учета лицензирования приложений, для которых собственно и строится такая архитектура (с чем там работают эти 40 пользователей)?

Если с железом проблем не будет (переброс пока не очень хорошо работает, может попасться видеокарта, которую не удается перебросить, или будут проблемы при установке драйверов… но они решаемы, и т.п.), то может возникнуть другая проблема: к примеру anti chit guard система frost у игры aion от innova может не позволить запускаться из виртуальной машины (не пробовал, но на форумах жалобы были).

прежде чем менять интерфейс необходимо:
1. спросить пожелания пользователей (записать по максимуму, даже противоречивые)
2. собрать статистику использования полей (по базе данных или вставить хуки в коде)
a) определить, как часто люди щелкают мышкой а когда пользуются кнопками (tab или еще как)
b) проанализировать время между вводом каждой данной
c) в идеале добавить анализ движения глаз (уже есть такое оборудование, включая софт для качественных веб-камер)
d) связать эти данные с пользователями, разделив их на классы (новый/старый или опытный/новичок или умный/глупый или мужской/женский пол и т.п.) так же необходимо как то определить набор типичных бизнесситуаций, при которых открывается эта форма

на основе данных п.2 выявить затыки, часто используемые поля и места, которые ищут пользователи, как отличаются интервалы от типа пользователей и многое другое… в общем чем лучше проанализируете данные тем больше у вас будет информации о том что нужно сделать

затем посмотрите, какие пожелания ложатся на исправление выявленных затыков

вот только тогда нужно думать что изменить

Подумайте все таки по выбору города не только по названию.
Пример для размышлений:
maps.yandex.ru

Россия, Москва
Польша, Восточно-Лодзинский повят, Новосольна, Москва

'Доступно всем' без вариантов нужно хранить в виде bolean у content, даже хотя бы в виде копии, заполняемой тригером у таблицы content_share.

'Доступно друзьям' и 'Доступно конкретному пользователю'… так ли важно разделять эти понятия. это бы имело смысл, если бы количество действий по созданию нового пользователя и добавлению прав было бы сравнимо с количеством запросов на права доступа, а это маловероятно, наверняка в вашей задаче количество запросов на чтение на порядок (или обычно это логарифм) больше изменений.
Может быть достаточно правила 'Доступно конкретному пользователю', а значит обойдетесь таблицей content_share_user {user_id,content_id}

Дальше, никогда не нужно надеяться на чистую реляционную модель. Делайте дополнительную копию на все, что читается чаще чем пишется в удобном для этого месте. Сериализованный список идентификаторов user_id в content.authorised_list (если это числа, то к примеру через ',' с обязательным ',' в конце), если их количество меньше определенного, удобен для запросов вида like '%12345,%', и ведь его можно заполнять не сразу, а периодически отдельным процессом и очищать по триггеру на изменении. Тогда основная нагрузка ляжет не на выполнение тригера, а на запросы только последних измененных данных, а их обычно не так много.
content
.authorised_list varchar = '123,234,345,' или null — для данных, которые нужно запросить из content_share_user
.authorised_all boolean
content_share_user {user_id,content_id}

Тут два пути — поэлементный поиск (последовательно или рекурсивно, циклом или callback, не важно) либо сериализуем (самое быстрое — JSON.stringify) все данные или поэлементно и уже ищем подстроки ",7,", "[7" и ",7]"

Черт, неужели это произошло?! Конечно, метод пока еще кривой, но:

Купить bitcoin на любой из 100500 биржах и продать на btc-e.com (1-2 суток но итоговые потери будут высокие ~7%-8%) или metabank.ru (возможно это долго, ~1-2 недели, но меньше получится комиссия ~6%).

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

p.s. а обязательно скайп? вам же нужна связь только до одного человека, никакого интерфейса, может собрать что-нибудь на основе готовых компонентов приложение, показывающее видеотрансляцию и ожидающее тапа по экрану для его запуска/останова. Не такое уж и сложное получается приложение.

Нашел пока это
gist.github.com/bebraw/507756

Код заливки трехугольника градиентой по цветам на вершинах

Так как вопросы производительности не были озвучены… то подойдет любой планшетный компьютер или ноутбук/нетбук (монитор как бонус), как готовое решение (главная сложность поиска железа на текущий момент — требование наличия встроенного аккумулятора).
А самосбор — миллион вариантов, от MiniITX для x86 платформ + обычный бесперебойник до всяких DiY платок.

Ни с сокетами, ни с семафорами, ни с шаред мемори из php у меня не было никаких проблем, память не утекала, обрабатывалось быстро… но дальше все зависит от того что вы будете делать и использовать.

А дальше — выбор языка, чисто холиварный разговор. У питона перед php больший выбор готовых модулей (и гораздо аккуратнее их организация), нет проблем с целыми числами (32bit vs 64bit) и кому то сам язык больше нравится, но потребление памяти у питона значительно выше чем в php, да и синтетические тесты по работе с примитивами у php показывают выше скорость.

p.s. А если у вас мало внешних вызовов и много внутренних расчетов, может сразу посмотреть на c++? :)

Ссылка? одноразовый код отображается на мониторе и вводится в мобильном в спец-приложении, код вычисляется на основе личных данных и текущего времени. Количество цифр не обязательно большое. В крайнем случае qr-code.

-

Самое простое, что можно попробовать, сделайте 2 базы данных и настройте репликацию master->slave, из слейва читать, в мастер писать.
Даже в пределах одного сервера это может дать неплохой прирост (правда в результате нагрузка на сам сервер немного повысится), дальше можно крутить индексы, так же можно делать разные индексы на разных серверах master/slave. Главное постараться разделить физически хранилища для этих баз.

Можно периодически приостанавливать репликацию, увеличивая интервал между актуальными данные в мастере и анализируемыми данными в слейве.

Можно поднять слейв на ненадежном хранилище (tmpfs или включить принудительное кеширование записи, например в опциях монтирования ext3/ext4 — data=writeback), это увеличит скорость копирования данных в слейв.

Учить начиная с Си не советую, начинайте с простого, лучше спускаться вниз с верхов: JavaScript -> Java или C# -> C++ -> C (такая иерархия слишком образная и холиварная, но сойдет).

В данном случае это поэтапно позволит изучать сначала просто алгоритмы (JavaScript), затем объектно-ориентированный подход (Java или C#), затем к этому добавляется самостоятельный контроль за памятью (C++) а уже после этого вычитаем синтаксический сахар и объектную ориентированность и получаем голый C (дальше только ассемблер и машинные коды).

При обучении именно Си без понимания более высоких языков программирования поставит в тупик то, как и что в нем реализуют другие программисты, дело в том что в библиотеках очень старательно реализуют вкусности, которые появились позже в более высокоуровневых языках, и делают это ограниченными средствами языка — например на макросах (язык над языком — предпроцессор), и пытаться понять даже самые простые конструкции будет очень сложно.