Я был вежлив.. и буду (IMG:
style_emoticons/default/smile.gif)
В ответ на твое мнение о моем комментарии - поделюсь своим мнением о твоем: нужно спокойнее относится к критике.
Цитата
А я что не так написал? Или мне нужно было уточнять ЧТО КОНКРЕТНО будет тормозить НА сервере или это имеет такую важную роль?! Мой урок не для даунов, а для новичков. Поэтому считаю разумным не объяснять что когда тормозит сервер из-за нехватки ресурсов - сфера тоже будет тормозить.
Ты перепутал причину и следствие - ты написал, что тормозить будет сфера. Я могу понять неточные выражения с целью упрощения понимания, но здесь такого не наблюдается.
Цитата
Для изучения моего урока человек не отходя от собственного домашнего компа где у него стоит сфера - качает xampp и поднимает веб-сервер за два клика. Хочешь рассказать как поднимать мускул на винде без веб-сервера, а потом настраивать сторонний софт для работы с базой - валяй, я использую для этого свой подход. А уж если закрыто удаленное подключение, то с базой работать только через "удаленный рабочий стол+сторонни_софт" что весьма не удобно. Я некому ничего не навязываю, я рассказываю свой подход если это еще не понятно. Хочешь рассказать другой подход - в виде отдельного урока.
А я лишь делюсь своим мнением, чтобы ваше не было единственно верным. Зачем в штыки-то ?
Цитата
Можно. А нужно ли? Лично я использую кеширование данных на 5 минут и делаю выборку данных с базы не каждое обновление страницы. В вашем случае селект к базе будем делать каждый рефреш страницы. А стоит ли этого того? Мне кажется лишнее, достаточно "живого" статуса онлайн внутри игры.
Вы не уловили суть. Еще раз вас процитирую:
>>Дурные идеи типа живого статуса обновляющегося без задержки - выкиньте нафиг, это сильно убьет вашу базу.
Это бред. Так яснее, что я хотел сказать?
Цитата
Делит понятнее для новичков. Учитывая что работают два подхода, я выбрал тот что понятнее для прочтения кода.
Есть принципиальная разница между двумя командами.
Еще понятнее будет - если выбрать все записи и по одной их удалять, чтобы в таблице совсем-совсем ничего не осталось, но что-то я не вижу активистов использовать такой способ (вернее один раз встретился, поэтому и припомнил).
Да и насчет понятнее - сомнительно, так ли понятнее использовать неправильную команду?
http://dev.mysql.com/doc/refman/5.0/en/truncate-table.htmlПочитайте, узнаете новую для себя команду.
Mirage, когда я отвечал - я видимо не заметил его ответ. В любом случае - все то, что написал автор вы можете найти самостоятельно в интернете и даже больше, что я собственно говоря и посоветовал.
Мне даже будет не лень заглянуть в гугл и привести из него цитаты соответствующие каждому пункту, который указал автор. Нужно?
Добавлено:Вы, кстати, не там ставите кэширование. Запись в локальную СуБД, раз уж вы её используете - операция слабо напряжная.
А вот дергать каждый раз сервер спрашивая с него данные - весьма затратно.
Соответственно - там кэширование можете убрать и сделать обновление по заходу/выходу, нагрузки это не даст. А вот где данные берутся:
Код
$cache_file = "accounts.info"; // файл кэша
$cache_time = 5*60; // время кэширования - 5 минут
if( ! is_readable( $cache_file ) || time() - $cache_time > filemtime( $cache_file ) ){
$content = file_get_contents("http://ваш_реальный_ip_сервера/");
file_put_contents( $cache_file, $content );
}
else{
$content = file_get_contents( $cache_file );
}
Тут может быть проблемка, в случае двух параллельных запросов.. Но это уже отдельная тема про кэш для highload-проектов - с местными нагрузками проблемы не будет.
Еще было бы полезно добавить проверку на доступность удаленного хоста. Помнится на Антаресе не было такой проверки (и там использовался такой же подход, в плане передачи данных между серверами) и выскакивала ошибка с указанием кучи интересной информации.