У меня лично не получилось писать на стену — для сайтов «в общем случае» эту возможность запретили. Нужно просить идти отдельно. Если у Вас получится — расскажите, пожалуйста.
Касательно «поделится» — у меня модуль для Kohana framework. Могу отдать «as is», он сыроват еще.
У нас — виртуалка под Win 2008R2. Выше 1500 одновременных реальных соединений не видел. Не падала «сама по себе», менеджер ноды IISNode ее перезагружает каждые Х запросов. На 1500 отъедало в районе ~75 Мб ОЗУ и 8% проца.
Ну вот про «миллион» коннектов всегда было интересно послушать — с учетом того, что количество открытых TCP/IP соединений в ОС все-таки ограниченно, если мне не изменяет память.
«Рвать» коннект приходится из-за кеширующих антивирусов :(
Long Pooling. Сокет держится где-то в районе 15 секунд (демон, как и у автора поста, на Ноде. У нас разделено понятие «отправки», то есть изначально запрос идет на Ноду, нода внутри себя проксирует ее на локальный пхп (сей изврат нужен для бизнес-логики, к моменту отправки подвязано вычисление рейтингов и других плюшек). После завершения запроса на постинг фразы идет «прочтение» новых мессаг и раздача подключенным клиентам.
Написание демона не есть проблема, потому вопрос был сугубо теоретический — инструмент я выберу уже после осознания нужного пути.
Если я верно Вас понял, то Вы выступаете против денормализации базы в пользу выборок в пользу чего-то похожего на map/reduce (кластеризации видов активности по некоторым первичным признакам, параллельной обработке их отдельными модулями и конечным склеиванием результатов перед выдачей в браузер).
Это довольно близко к тому, что пока вывел для себя я, а именно — хранить долговременные данные в СУБД, кешируя актуальные (например, за последнюю неделю) в noSQL решении типа MongoDB, кластеризируя их, для начала, по типам активности и дате. При новом запросе «на ленту из X событий» изначально запрашивать по X событий из каждого узла данных, сортировать по времени /приватности и сохранять уже в «горячем» кеше приложения.
При обновлении событий менять как сам «горячий» кеш, так и СУБД / noSQL хранилище. В особо сложных случаях «горячий» кеш перегенерируется.
Мне кажется, что производительность такого решения при большом (сотни тысяч, миллионы) количестве пользователей и, соответственно, генерируемого контента и событий является неподъемной ни для одной известной СУБД.
С IFrame вариантом мне сталкиваться не приходилось.
У меня был другой класс задачи: публикация на стену пользователя / друзей пользователя неких сообщений в ответ на некоторое событие на моем сайте. Инициатором публикации сообщения является непосредственно сайт, без окон браузера и прочего (в момент самой публикации пользователя вообще может не быть ни на сайте ни в ВКонтакте).
Эту задачу, к сожалению, решить не удалось штатными средствами.
if (round($sum, 4) != round($a + $b, 4))
Ну вот так у меня хорошо отработало.
Ошибка происходит именно в момент преобразований — разница между начальным числом и суммой составляет -2.2737367544323E-13, потому лучше округлять до какого-то числа между запятой.
Ну у изображения есть определенное количесвто цветов в палитре, которое можно получить через imagecolorstotal. Далее делаете цикл в индексе от 0 до этого числа и дергаете imagecolorsforindex.
На выходе имеете RGB и альфа-канал (прозрачность) для текущего вхождения.
Тогда, если нет охоты много кодировать, то просто делаете из изображения типа TrueColor 256-цветовое (imagetruecolortopalette). Далее — получаете массив цветов (imagecolorsforindex) и проходитесь по нему в поисках не-оттенков серого.
Касательно «поделится» — у меня модуль для Kohana framework. Могу отдать «as is», он сыроват еще.