rPman

Если на вашей стороне нет проблемы с белым IP и открытыми портами, то собираете portable сборку практически любого vnc server, высылаете ее с готовым ярлыком/батником запуска этого сервера с подключением к вашему запущенному vnc viewer в режиме listen connect.

Оформить в виде самораспаковываемого архива думаю сумеете?

Не нужно перебарщивать, решите только одну главную проблему передачи параметров — escaping и quoting параметров, никаких монструозных велосипедов, только поправьте метод выполняющий ваши запросы, :param пусть идут в sql-запрос без изменений (а сам запрос сделать параметризованным, список параметров получается просто поиском всех вхождений /\:(\w+)/), а {param} заменяются по старинке, пусть там останутся куски самого запроса с выражениями.

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

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

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

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

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

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

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

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

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

Очень плохая практика тяжелых монстров подключать к веб-морде напрямую. Это проблема создается разработчиком еще на этапе разработки архитектуры приложения.

Про монстров, я имею в виду mssql/oracle/ibmdb…

Исправить это сложно, особенно если не предусмотрено мест в коде для этого. Основное направление, ставьте что-то по проще, между веб-сервером и базой данных, основанное на document oriented db, какое-нибудь nosql решение (но и mysql+text indexing services поставить между вебом и oracle — тоже нормально), иногда достаточно решений вида 'просто кеш'.

Обязательно этот модуль на себя должен брать вопросы аутентификации и авторизации, да и вообоще вопросы безопасности по максимуму (сам участвовал когда то в решении, где логин пользователя веб был логином в БД oracle, страшно вспомнить, хотя права доступа БД были оттюнены и завернуто было все через пакеджи и вьюхи).

Когда то работая с эмитацией действий пользователей на различных сайтах понял что каждый раз исследовать код сайта, изучать запросы и реверсить логику совсем не верная дорога, не надежная и сложная.

Намного проще оказалось реализовать основную (или часть) логику автоматизации и анализа в самом браузере с помощью javascript (со всей мощью jquery и т.п.), запуская браузер в какой либо компоненте в своем приложении (я использовал mono и компоненту штатную WebBrowser, она основана как я понимаю на firefox), приложение спокойно собирается в cli и работает на 'безголовых' серверах linux, при этом нет нужды бороться с владельцем сайта, который борется с ботами и ддос, выявляя тех кто эмитируют POST и GET запросы с помощью curl…

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

Если не перелопачивать базу данных, простенько, для галочки… то вместо текста в поле храните сериализованный массив {ru:'Бла, бла, бла',en:'Blah, Blah, Blah',..}…

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

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

xdebug?
phpshtorm например поддерживает
p.s. настроить на windows xdebug — будет проблемно, в готовом бинарном виде совместимые версии php и xdebug фиг найдешь, хотя я серьезно и не копал.

Проблема в том что в имени атрибута есть символ '@', решение — преобразовать объект в ассоциативный массив и обратиться к атрибуту как к элементу массива:

$bug_blog=(array)$blog;
var_dump($bug_blog['@attributes']);

а средствами штатного smtp не подходит? не рассылки а просто письма-уведомления спокойно отсылал со своего gmail аккаунта, я так понимаю в не зависимости от того, есть домен или нет, работать все равно должно.

фиктивные таблицы:
select 1 from dual union
select 2 from dual union
…

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

нет, потому как тогда будут валидны следующие конструкции:
$($a)

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

Почти наверняка проблемы с вебсервером или может быть DNS?

gentoo, apache, тормозной старенький AMD Sempron(tm) Processor 3400+

a.php: <?php echo str_repeat('0123456789012345',8192); ?>

# date; curl http://localhost/a.php >/dev/null;date
Втр Авг 9 20:15:03 NOVST 2011
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 128k 0 128k 0 0 31.4M 0 --:--:-- --:--:-- --:--:-- 41.6M
Втр Авг 9 20:15:03 NOVST 2011


p.s. но если у вас тоже самое с cli php то нужно бить тревогу!!!

p.p.s. у меня на first vds был момент, когда простейший lib_curl (точнее вызовы curl_… из php) нещадно подвешивали виртуалку под 100% на секунды, но в то же время консольная утилита curl/wget — работали без проблем… пока вообще выяснял, откуда тормоза, проблема самоустранилась (длилась часами), поэтому записал на счет потенциальных глюков openvz (точнее virtuozzo) и сделал зарубку в памяти, что и такое возможно.

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

Соответственно, можно использовать асинхронные сокеты (см. socket_set_nonblock и socket_set_option, первый же пример в гугле) в php и серверную часть запускать в виде одного процесса (со всеми вытекающими проблемами из-за потенциальных багов в коде, точнее прервутся все соединения, если упадет это приложение), либо на каждое соединение запускать по процессу, с обычными сокетами, но тогда добро пожаловать в мир semaphore и shared memory (конечно, можно и без них, используя типичный LAMP подход, когда за синхронизацию отвечает БД с транзакциями, но производительность будет ужасная и вас засмеют за говнокод).

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

в догонку к вышесказанному:
1. если СЕО позволяет, постарайтесь побольше делать на стороне клиента (javascript templates/ajax/..) и поменьше на сервере

2. не экономьте на разработке кода-управления кластером (а для высконагруженных проектов кластер нужен хотя бы для надежности): скрипты обновления (а и в проекте необходимо учесть что его код и данные могут обновляться), резервирование и восстановление из резервной копии, управление кластером — добавление/удаление/настройка узлов, и т.п.
Просто при плохой организации высоконагруженные проекты глючат чаще :) потому что банально 'тестеров' больше.

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

4. оптимизация sql это круто, но очень часто nosql решения (+что то по сериализации) вполне себе заменяют sql (а уж по скорости безусловно побеждают), как вариант — комбинированные решения (но последнее порождает чуть больше проблем при обновлениях структуры и кода)
* memcached — это кстати тоже nosql, только не является хранилищем (не гарантирует что если данные сохранил, то их можно будет извлечь)
* вот в решениях хранения не стоит городить собственных велосипедов и не стоит изобретать кошмар на файлах. НО, например небольшие статичные (редкоизменяемые) куски БД гораздо эффективнее подгружать прямо в виде PHP массива (до размера сотен кб php код иннициализации переменных работает значительно быстрее любого БД-фреймворка, не говоря уж про накладные расходы на соединения с БД и т.п.)

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