edogs

При Вашей стратегии - разумеется не хватит.
Даже если Вы не из Москвы, офис Вам дешевле 500уе в месяц найти вряд ли получится. 3 месяца - 1500уе. Остается 2500уе. Делим на 3 месяца. Получается 800 (допустим)уе в месяц. Делим на 2-3 программистов. Получается по 280-400уе в месяц на программера. За эти деньги профессионалов Вы не найдете, без вариантов.

В Вашем случае оптимальный вариант это забыть об офисе уйдя на фриланс (сэкономили 1500) и нанять одного программера вместо 2-3. Получится 1300уе в месяц программеру. Уже та сумма, за которую можно найти прогера среднего уровня, не делающего явных косяков. А отсутствие синхронизации между 2-3 прогерами - сэкономит до кучи еще и время.

По сумме 4000уе за цмс - в принципе реально, так что для Вашей ситуации - ищите 1 прогера на фрилансе.

В чем причина не знаем, но если все на одном сервере — сокеты использовать правильнее в большинстве случаев.
Заодно убедитесь, что мемкэш не доступен из внешнего интернета, по умолчанию доступен.

Если чужой колхоз годится, то stackoverflow.com/questions/2690654/how-to-get-the-real-type-of-a-value-inside-string можно за базу взять, чутка ошибок поправить и типов добавить:)
А вообще для такой задачи лучше свой колхоз сделать, т.к. задача у Вас какая-то атипичная видимо.

на загрузку 1 картинки уходит около 0.7 секунд

На что уходят эти 0.7 секунд? Установка соединения, днс резолвинг, скачка, что-то еще?

copy, если это в прямом смысле copy обычное по http — худший вариант. На днс резолвинг, например, в ряде случаев может уходить 0.5 секунды, а он будет происходить каждый раз при copy с хорошей вероятностью.
Делайте curl, все скачки в одной сессии и включайте кэш днс в опциях курла хороший по времени. Уже одно это может на порядок улучшить результат.

php-шный мультикурл вещь пока несовершенная:( Мы бы запускали что-нибудь шелловское через exec, тот же wget например в несколько потоков или что-то мультипоточное изначально.

Решали такую задачу.
По совокупности параметров и с учетом ограниченности бюджета сделали так.
Со всех адресов идет форвард/копия на один адрес, откуда они и забираются пхп скриптом по крону.
Тупо, просто, надежно, масштабируемо… дешево. Можно было сделать лучше, но было бы дороже:)

Скрипт именно работает бесконечно долго?
Потому что

Функция set_time_limit() и директива max_execution_time влияют на время выполнения только самого скрипта. Время затраченное на различные действия вне скрипта, такие как системные вызовы функции system(), потоковые операции, запросы к базам данных и т.п. не включаются в расчет времени выполнения скрипта.

То есть если допустим у Вас граббер где 50 секунд file_get_contents отрабатывает, а потом 30 секунд запрос в базу идет и еще sleep-ом догоняетесь к примеру секунд на 40, то все эти 50-30-40 не в счет.

И еще на всякий случай. set_time_limit Вы же один раз выполняете? Просто если он случайно в цикл попал и выполняется на каждой итерации, то эти выставляемые 10 секунд они отсчитываются с момента задания значения set_time_limit_ом

Сессии блокируются индивидуально под каждого юзера, поэтому ситуация «висит абсолютно все и ждет» очень необычна.
Учитывая что у Вас iSCSI, более логичным было бы предположение о том, что кончился лимит на кол-во коннектов с файлохранилищу по tcp/ip, и поэтому все висит — т.к. ждет пока свободные коннекты освободятся. Проверьте эту версию. Если она верна, то скорее всего по какой-то причине не рвется (или не всегда рвется) коннект после отработки пхп скрипта и они накапливаются.
Быстрый фикс — сбрасывать долго висящие соединения или увеличить лимит на их количество. Долгий — разобраться почему не рвутся и пофиксить.
Похожая проблема иногда возникает с persistent соединениями с базой или с мемкешем, поэтому их использовать стремно в реальных проектах, хотя теоретически они круты.

В четвертой версии данная проблема решалась добавлением
mysql_query («set character_set_client='utf8'»);
mysql_query («set character_set_results='utf8'»);
mysql_query («set collation_connection='utf8_general_ci'»);

Не знаем как в 5-той, но в 4-той, равно как и в 3-ей версии по правильному это решалось не добавлением тех 3 строк, а раскомментом includes/config.php строчки
$config['Mysqli']['charset'] = 'utf8';

В базе все отлично, ну по крайней мере в phpmyadmin все отлично просматривается.

А phpmyadmin какое соединение с базой по умолчанию имеет? Если просто скрипт сделать для чистоты эксперимента, который берет из базы запись, устанавливая и/или не устанавливая чарсет — проблема где будет?

Попробуйте
а) Фклозить файл даже в случае если флок не удался (сейчас у Вас fclose только внутри блока с успешным flock-ом, это не вполне корректно).
б) clearstatcache перед вторым файлсайзом.

p.s.: Если php запущен как cgi, то на блокировку полагаться нельзя.

На запрос именно в браузере он это выдает? Прокси и прочего нет?
Не так давно сталкивались с аналогичным и там тоже было HTTP/1.1 100 Continue.
Но когда стали тащить не первую часть (не вспомним уже сейчас почему отдавалась только 1-ая часть, но изменения с нашей стороны привели к нормальному результату в итоге), а полный ответ, то в остатке сразу после var_dump был нормальный полноценный xml ответ.
В общем проверьте реально ли полностью Вы получаете ответ, нет ли чего после этого print_r-а.

Посмотрите браузером какой контент_тайп _реально_ отдается сервером.
Вполне возможно что какие-то настройки оверрайдят Вашу попытку отдать utf8, например www.php.net/manual/ru/ini.core.php#ini.default-charset или какие-то настройки сервера. А дальше разбирайтесь по ситуации, ищите что и где меняет.

Один запрос.
Это самый распространенный (и к счастью самый легко устраняемый косяк), когда делают нечто вроде foreach() mysql_query; что при всего-то даже при 100 элементах массива дает результатом 100 запросов. Жуть страх и трепет.

Перед <? php нет пустых мест? bom символов, например? Печеньки с номером сессии могут не уходить если так.

Время на сервере корректное? Печеньки с номером сессии могут удаляться сразу если так.

5.2.17 не течет, так что на 5.2.* крест-то не ставьте.
Так же очень любопытно зачем Вам в cms addslashes, уж не для работы ли с базой случаем?