Форум PHP

Нет, не пройдет этот вариант - я наверное плоховато смог объяснить действие. Суть в том, что всё должно работать на сервере - клиентская программа не подходит, это во-первых. Во-вторых, в конечном счете - всё нужно писать в базу. Но сразу писать туда - нагружно. Поэтому - нужно писать в файлы. А это уже... что Си, что Php - тут просто количество процессов в sleep... при переносе этого всего на RAM-диск - Load уменьшился. Но при увеличении одновременных соединений в wapt (программка стресс-теста) более определенного числа - Load начинает расти. И вот это определенное число - грустно выглядит.

Проще говоря... вы зашли на страничку. Тут же происходит:

$fp=fopen($dir."/".$ip,"w+");fclose($fp);

и таких "происходит" - шесть-восемь штук. Если вы - не "вы", а "вы*N" - то начинаются проблемы.. если эта N больше, чем некий потолок. Но я не люблю низкие потолки...

p.s. Только что подумал... а насколько работоспособна запись fclose(fopen($dir."/".$ip,"w+")); ? Ведь должна же работать...

Может тогда пойти другим путем и сделать финт ушами?
Если у вас это специализированный проект и много пользователей (т.е. проект востребован), то может имеет смысл перенести его с ХТМЛ платформы?
Т.е. напишите на С++/Делфи/Фоксе специальную программу-клиент которая будет работать с сервером читать/писать данные. Тогда отпадет нужда в ХТТП сервере. Нужен будет только сервер баз данных MySQL или PgSQL, или другой.
Минус такого подхода - если изменятся выходные формы то придется переписывать программу клиент. Плюс - будете экономить на объеме траффика передаваемого по сети (передаете только данные, а не 5% данных и 95% ХТМЛ оформления).

Нельзя. Нет там никакого контента. Это система статистики. Основная нагрузка происходит из-за записи сатистических данных.

Почему бі не сделать кеширование?

Скажем кеш не обновлять до тех пор, пока контент не поменяется, кешировать не всю страницу, а отдельное звено! Т.е. если это блок голосования то кешировать его, вывод главного контента то и его кешировать! При изменении главного контента кеш обновляется! Вы сократите свои запросы к БД к минимуму таким образом! ДА и время генерирования страниц!

Пропустил это:

"А можно описать задачу подробнее - нельзя RAM диск или MEMORY-таблицы использовать? У вас пользователи читают информацию или также записывают?"

Использовать можно. Только - что это? Насколько я знаю - MEMORY-таблицы уничтожаются сразу, как только происходит отсоединение от Mysql... а оно происходит. И только потом - новое соединение и считывание. А что такое RAM-диск - лишь догадываюсь, что это объем оперативки, выделенный под сохранение данных... Но как это все выгляди и происходит - не понимаю. Что-то нужно настроить каким-то макаром, видимо...

Пользователи - записывают. А раз в пять минут по файлам проходит скрипт и перекидывает информацию в базу.

Если честно, то не уверен - скорее всего узнаете толко если попробуете...

Значит, если я переведу на файлы всё - это не поможет?

Делают так, покупают несколько серверов и объединяют их в локальную сеть, ставят несколько Web-серверов (для начала можно один) с одинаковым содержимым и один MySQL-сервер к которому обращаются несколько Web-серверов (т.е. будет писаться не localhost, а адрес сервера в локальной сети). Так как под MySQL отведена вся память - он выдерживает значительные нагрузки. На вход всей этой конструкции ставят обратный кэширующий сервер, который по возможности кэширует статичные странцы, чтобы снизить нагрузки на сервера.

PS Начиная с MySQL 5.1 в бета-тестирование переходит кластерный вариант MySQL - т.е. теперь можно одну базу данных хранить на нескольких серверах.

Я даже уверен, что аналогичный проект поддерживает несколько серверов. Но я не понимаю схемы. Вы ее можете представить и описать мне?

Что касается пятисот.. понимаете - поставлено пятьсот, а я тестировал - сотню одновременно (программка wapt)... сотня - уже убивала сервер. Сотня. Это же в ой-ой раз меньше..

>Я прав? Нет?
Да неплохо, это может ускорить процесс значительно, учитывая что почти сразу файлы будут помещены в дисковый кэш, правда спрогнозировать точно нельзя, так как обращение к диску будет гораздо медленее, чем к оперативной памяти, в которой располагается кэш MySQL.

PS Вместо mysql_fetch_array() в этом случае лучше использовать mysql_result().
PPS А можно описать задачу подробнее - нельзя RAM диск или MEMORY-таблицы использовать? У вас пользователи читают информацию или также записывают?