Слава Шевцов, раз уж вы минусами разбрасываетесь, я вам скажу что будет. для вас это будет платное экспертное исследование технологии параллельных запросов библиотеки curl в php.
Работает и 50 кб страничками. Я же чуть выше написал про усложнение теста. жрет 130мб где-то. и это расходуется на буферы, чтобы парсить в самом конце получения данных.
если заморочиться можно переписать на конечный автомат - будет совсем чуть-чуть. но такая техника намного сложнее.
RAS, поподробнее.
а то некоторые продукты вообще не запускаются если у вас установлены некоторые версии eaccelerator :)
таких некоторых случаев для любого софта можно придумать массу.
Мэкс, не все готовы платить за виндовый хостинг.
а экспорт, по-моему, в том же acccess можно провернуть из одного odbc источника в другой и получится уже mysql.
neznaika, вообще-то xcache по умолчанию скрипты компилирует в отображаемую память mmap.
но иногда действительно может похужеть : на массовом виртуальном хостинге, если на сервере дикое число пустышек-сателлитов.
kxk, да и не важно. centos врядли будет включать в себя пакет не благославленный редхатом.
важно, что xcache прошел некий барьер, а eaccelerator нет.
важно, что мейтейнеры тестируют пакеты, а я нет и не хочу.
kxk, и что, какой php-акселератор там входит в комплект?
Однако xcache уже есть в debian-based дистрибутивах, а eaccelerator нет. Я выбираю надежность и автоматическую установку.
;размер памяти, надеюсь, это интуитивно ясно?
xcache.size = 64M
; поставьте равное числу ядер процессора или процессоров
xcache.count = 2
; вроде как помогает включение
xcache.optimizer = On
Остальные параметры вам вряд ли пригодятся. Оставьте все по умолчанию.
Слава Шевцов, раз уж вы минусами разбрасываетесь, я вам скажу что будет. для вас это будет платное экспертное исследование технологии параллельных запросов библиотеки curl в php.
Работает и 50 кб страничками. Я же чуть выше написал про усложнение теста. жрет 130мб где-то. и это расходуется на буферы, чтобы парсить в самом конце получения данных.
если заморочиться можно переписать на конечный автомат - будет совсем чуть-чуть. но такая техника намного сложнее.
AlienZzzz, вот вы наймите меня и все покажу .
Конечно же, я использовал простейшее выражение, ведь я хотел проверить применимость curl_multi и php.
Хлама никакого нету. Я немного усложнил тест:
увеличил размер файла до 50 кб, увеличил скорость отдачи, добавил в конец файла специальный тег и сделал поиск этого тега :
ничего не падает, а значит докачивается без хлама. пхп съел 128 мб и упал. я изменил в php.ini параметр с 128 до 250 мб и все отработало до конца.
да curl multi память любит, вот он запущенный на 1000 потоков, но 71 мб это несмешно даже:
как видно, загрузки практически нет, тк в location я настроил тормозилку :
location /test.html {
set $limit_rate 100;
root /var/www/nginx-default;
}
php-код парсинга тупейший :
if (preg_match("/<title>(.+?)<\/title>/",$content,$titles)){
if ($titles[1]!="Welcome to nginx!") { print"OOPS";exit;}
}
всего 10000 запросов, параллельно до 1000.
это /status от nginx во время работы теста:
кто тут еще против пхп ?
Слава Шевцов, то есть на самом деле вы ничего не тестировали. все ясно.