Можно ли использовать для каждой стат страницы базу SQL (для 1 страницы - 1 ячейка базы). Просто, как по мне это буде намного легче или есть могут быть противоречия?
Спустя 22 минуты, 24 секунды (12.03.2011 - 17:15) imba написал(а):
kent666
Можно и так, можно и так. На файлах работа будет быстрее, если данные страницы не будут подвергаться изменениям, то есть будут полностью статичными. Да и дёргать и перегружать каждый раз БД без надобности не стоит. Обычно эти статичные страницы годами никто не меняет, зачем при каждом запросе лезть в БД для того, чтобы достать содержание страницы? Вот именно не за чем. Процессор на хостинге может тянуть в 100 раз больше нагрузки, чем MySQL, поэтому стоит беречь мускул от количества одновременных обращений.
Можно и так, можно и так. На файлах работа будет быстрее, если данные страницы не будут подвергаться изменениям, то есть будут полностью статичными. Да и дёргать и перегружать каждый раз БД без надобности не стоит. Обычно эти статичные страницы годами никто не меняет, зачем при каждом запросе лезть в БД для того, чтобы достать содержание страницы? Вот именно не за чем. Процессор на хостинге может тянуть в 100 раз больше нагрузки, чем MySQL, поэтому стоит беречь мускул от количества одновременных обращений.
Спустя 1 час, 45 минут, 50 секунд (12.03.2011 - 19:01) neadekvat написал(а):
Цитата (imba @ 12.03.2011 - 14:15) |
Процессор на хостинге может тянуть в 100 раз больше нагрузки, чем MySQL, поэтому стоит беречь мускул от количества одновременных обращений. |
Насколько я помню, MySQL очень даже неплохо заточен именно под чтение.
По сабжу же, никто не мешает хранить содержимое страниц в бд, но при этом кэшировать их в файловой системе сервера.
Главное тут не забыть дописать код, который при редактировании/удалении материала из бд будет обновлять/удалять кэш.
Спустя 35 минут, 4 секунды (12.03.2011 - 19:36) imba написал(а):
neadekvat
Если 10 000 человек поломятся к мускулу -он падёт, если к файлу - выдержит. Цифры вымышлены, просто смысл показать =)
Кеш тоже у мускула не безграничный, если не ошибаюсь, то я где-то читал, что новые записи с кэша вытесняют старые, хотя не уверен в этом, может старая запись была на mysql.ru
Если 10 000 человек поломятся к мускулу -он падёт, если к файлу - выдержит. Цифры вымышлены, просто смысл показать =)
Кеш тоже у мускула не безграничный, если не ошибаюсь, то я где-то читал, что новые записи с кэша вытесняют старые, хотя не уверен в этом, может старая запись была на mysql.ru
Спустя 8 минут, 32 секунды (12.03.2011 - 19:45) neadekvat написал(а):
imba, во-первых, вам не кажется, что эти цифры зависят от конкретного сервера, и обобщать было бы глуп.
Во-вторых, я имел в виду не кэш мускула, а кэш, которым вы будете управлять средствами php. Т.е. создаете класс кэширования, например, гененируете страницу - сохраняете в папочку. При следующих обращениях проверяете, существует ли такая страница в кэше и достаете ее оттуда, обходя путь генерации.
Во-вторых, я имел в виду не кэш мускула, а кэш, которым вы будете управлять средствами php. Т.е. создаете класс кэширования, например, гененируете страницу - сохраняете в папочку. При следующих обращениях проверяете, существует ли такая страница в кэше и достаете ее оттуда, обходя путь генерации.
Спустя 3 минуты, 2 секунды (12.03.2011 - 19:48) imba написал(а):
neadekvat
Именно для этого и была вставка: "цифры вымышлены", потому что резина у каждого сервера своя.
Именно для этого и была вставка: "цифры вымышлены", потому что резина у каждого сервера своя.
Спустя 23 минуты, 21 секунда (12.03.2011 - 20:11) kent666 написал(а):
Спасибо. Значит будем работать в отдельных файлах)))
Спустя 13 часов, 9 минут, 37 секунд (13.03.2011 - 09:21) twin написал(а):
Статические страницы почему так называются? Потому что они статичны. Тоесть их контент не изменяется, выборок там нет и вообще это просто странца. Нет смысла использовать для этого СУБД, она предназначена не столько для хранения, сколько для динамической работы с данными.
Поэтому статические страницы нужно и должно хранить в файлах.
Вообще для облегчения работы серверов даже придуман файловый кэш, так какой смысл делать запросы в статических страницах?
Поэтому статические страницы нужно и должно хранить в файлах.
Вообще для облегчения работы серверов даже придуман файловый кэш, так какой смысл делать запросы в статических страницах?
Спустя 3 часа, 29 минут, 31 секунда (13.03.2011 - 12:50) Trianon написал(а):
Я тут набросал на коленке небольшой примерчик.
Он не претендует на абсолютную истину, далек от идеала, и вероятно, содержит огрехи.
Но, надеюсь, проиллюстрирует мысль достаточно четко.
От того, кто не поленится создать пару-тройку файлов и одну таблицу в базе, а затем попробовать запустить этот пример, интересным было бы услышать ответ на вопросы:
а) Статические ли это страницы?
б) Где они хранятся?
Структура проста:
Каталоги в корне документов:
файл /tests/index.php
файл /tests/page_creator.php
файл /tests/config.inc.php (можно заменить своим)
Дамп таблицы pages в выбранной базе:
и наконец, последний, самый важный файл /tests/pages/.htaccess
Создаем оба каталога, разрешаем скрипту запись в них, создаем файлы, импортируем таблицу.
Вызываем localhosts/tests/index.php и ходим по ссылкам. Туда сюда несколько раз.
А затем заглядываем в файл /tests/creator_log.txt и отвечаем на вопросы.
Он не претендует на абсолютную истину, далек от идеала, и вероятно, содержит огрехи.
Но, надеюсь, проиллюстрирует мысль достаточно четко.
От того, кто не поленится создать пару-тройку файлов и одну таблицу в базе, а затем попробовать запустить этот пример, интересным было бы услышать ответ на вопросы:
а) Статические ли это страницы?
б) Где они хранятся?
Структура проста:
Каталоги в корне документов:
/tests
/tests/pages
файл /tests/index.php
<?php // /tests/index.php
require_once "config.inc.php"; // здесь подключение к БД
$res = mysql_query($sql="SELECT name FROM pages")
or die( "Error in $sql : <br>". mysql_error() );
while($row = mysql_fetch_assoc($res))
{
$page = $row['name'];
echo "<br> <a href=pages/$page.html >$page</a> ";
}
файл /tests/page_creator.php
<?php // /tests/page_creator.php
$page = @$_GET['page'];
if(!preg_match('/^[-0-9a-zA-Z_]+$/', $page))
{
header("Location: 404.php");
exit("No such page");
}
require_once "config.inc.php"; // здесь подключение к БД
$res = mysql_query($sql=
"SELECT body FROM pages WHERE name = "
. ("'".mysql_real_escape_string($page)."'")
) or die( "Error in $sql : <br>". mysql_error() );
if(!mysql_num_rows($res))
{
header("Location: 404.php");
exit("No such page");
}
$name = "pages/$page.html";
$h = fopen($name, 'w');
while($row = mysql_fetch_assoc($res))
fputs($h, $row['body']);
$mt = filemtime($name);
fputs($h, "\r\n<hr>Created at: " . date("r", $mt));
fclose($h);
$mt = filemtime($name);
$gmt = gmdate("r", $mt);
$l = fopen("creator_log.txt", 'a+');
fputs($l, "nm=$name, gmt=$gmt\r\n");
fclose($l);
header("Last-Modified: $gmt");
header("Content-Type: text/html; name=\"$page.html\"; charset=\"utf-8\"");
readfile($name);
файл /tests/config.inc.php (можно заменить своим)
<?php // /tests/config.inc.php
mysql_connect("localhost", "root", "") or die("Unable to connect to DBS: ".mysql_error());
mysql_select_db("test") or die("Unable to select DB: ".mysql_error());
mysql_query("SET NAMES 'utf8'") or die("Unable to SET NAMES" . mysql_error());
Дамп таблицы pages в выбранной базе:
-- Структура таблицы `pages`
CREATE TABLE IF NOT EXISTS `pages` (
`id` int(11) NOT NULL auto_increment,
`name` varchar(50) NOT NULL,
`body` longtext,
PRIMARY KEY (`id`),
UNIQUE KEY `name` (`name`)
) TYPE=MyISAM AUTO_INCREMENT=4 ;
-- Дамп данных таблицы `pages`
INSERT INTO `pages` (`id`, `name`, `body`) VALUES
(1, 'page1', '<html>\r\n <head> \r\n <title>page 1</title>\r\n </head>\r\n <body>\r\n content 1\r\n<hr/>\r\n<a href=page1.html>1</a>\r\n<a href=page2.html>2</a>\r\n<a href=page3.html>3</a>\r\n <body>\r\n</html>'),
(2, 'page2', '<html>\r\n <head> \r\n <title>page 2</title>\r\n </head>\r\n <body>\r\n content 2\r\n<hr/>\r\n<a href=page1.html>1</a>\r\n<a href=page2.html>2</a>\r\n<a href=page3.html>3</a>\r\n\r\n <body>\r\n</html>'),
(3, 'page3', '<html>\r\n <head> \r\n <title>page3</title>\r\n </head>\r\n <body>\r\n content 3\r\n<hr/>\r\n<a href=page1.html>1</a>\r\n<a href=page2.html>2</a>\r\n<a href=page3.html>3</a>\r\n\r\n <body>\r\n</html>');
--
и наконец, последний, самый важный файл /tests/pages/.htaccess
# /tests/pages/.htaccess
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteBase /tests/pages/
RewriteRule ^([-_a-zA-Z0-9]+)\.html$ /tests/page_creator.php?page=$1 [L]
Создаем оба каталога, разрешаем скрипту запись в них, создаем файлы, импортируем таблицу.
Вызываем localhosts/tests/index.php и ходим по ссылкам. Туда сюда несколько раз.
А затем заглядываем в файл /tests/creator_log.txt и отвечаем на вопросы.
Спустя 29 минут, 41 секунда (13.03.2011 - 13:20) neadekvat написал(а):
Вопросы с закавыркой. По сути, если это кэширование (т.е. получается, что данные хранятся в двух местах - в далекой бд и близкой файловой системе), то оно не учитывает возможность изменения страницы. Правда, мы же не видели функции добавления страниц - может, она будет удалять эти страницы из кэша.
А вот контент все-таки статический, по-моему.
Точнее, у страницы есть как минимум два этапа "жизни": пока она еще только в базе, она генерируется динамически. А когда она уже существует в виде копии в кэше - статическая.
Но идея для кэширования офигенная.. никаких там file_exists не надо. Правда, над структурой проекта придется подумать.
А вот контент все-таки статический, по-моему.
Точнее, у страницы есть как минимум два этапа "жизни": пока она еще только в базе, она генерируется динамически. А когда она уже существует в виде копии в кэше - статическая.
Но идея для кэширования офигенная.. никаких там file_exists не надо. Правда, над структурой проекта придется подумать.
Спустя 20 часов, 16 минут, 22 секунды (14.03.2011 - 09:36) twin написал(а):
А зачем так? Для бэкапа наверное только удобно. Хотя можно и файлы сбэкапить, обойдя все каталоги. Ну может для инсталляции.
Страницы действительно статические, изменить что то в них нереально, если только не сносить файлы. Я что то смысла не увидел особого хранить статику в двух местах.
Наверное что-то упускаю?
Страницы действительно статические, изменить что то в них нереально, если только не сносить файлы. Я что то смысла не увидел особого хранить статику в двух местах.
Наверное что-то упускаю?
Спустя 2 часа, 26 минут, 12 секунд (14.03.2011 - 12:02) Trianon написал(а):
а если снести?
Спустя 21 минута, 56 секунд (14.03.2011 - 12:24) twin написал(а):
Ну понятно что будет регенерация. От меня просто смысл этого всего ускользает...
Спустя 56 минут, 59 секунд (14.03.2011 - 13:21) Trianon написал(а):
Собственно, я пытался ответить на исходный вопрос тредстартера.
существует тип контента, который
а) крайне прост по внутренней организации (т.е. не требует при генерации обращения к нескольким таблицам и даже нескольким строкам таблиц)
б) меняется достаточно редко, но тем не менее меняется.
Примером могут быть разного рода статьи, которые правятся лишь когда в них существенные ошибки находят, изображения (о применении подобного подхода к ним я и говорил в соседней ветви.)
Смысл?
Ообеспечить:
а) централизованное хранение, легкий процесс бэкапа, восстановления и переноса контента.
б) мгновенный доступ к повторно запрашиваемым данным, с возможностью клиентского кеширования, частичной докачки и пр., без привлечения ресурсов медлительного интерпретатора php.
Между прочим, такая схема вовсе не означает, что данные дублируются напрочь все.
Кеш-то можно периодически тереть, более того, тереть выборочно, при этом сохраняя данные о частоте востребования.
Сказанное, кстати, вовсе не означает, что подобную схему я советую тут же бросаться прикручивать ко всему, что под руку попадается, тем более не изучив и не поняв, как работают классические схемы доступа.
И что статический контент в виде обычных файлов - старье, не заслуживающее внимания.
Но вот когда некоторое правило, даже очень правильное, начинает кем-либо применяться без понимания процессов, вследствие которых оно сформировалось, то оно (правило) в представлении этого кого-либо превращается в догму.
(Николай, только не прими на свой счет -- я о тех, кто читая рекомендации, кладет их на чистый так сказать лист , незамутненный ни знанием стандартов и протоколов, ни опытом.)
а догмы в программировании вредны чуть менее, чем инновационные идеи на пустом месте.
существует тип контента, который
а) крайне прост по внутренней организации (т.е. не требует при генерации обращения к нескольким таблицам и даже нескольким строкам таблиц)
б) меняется достаточно редко, но тем не менее меняется.
Примером могут быть разного рода статьи, которые правятся лишь когда в них существенные ошибки находят, изображения (о применении подобного подхода к ним я и говорил в соседней ветви.)
Смысл?
Ообеспечить:
а) централизованное хранение, легкий процесс бэкапа, восстановления и переноса контента.
б) мгновенный доступ к повторно запрашиваемым данным, с возможностью клиентского кеширования, частичной докачки и пр., без привлечения ресурсов медлительного интерпретатора php.
Между прочим, такая схема вовсе не означает, что данные дублируются напрочь все.
Кеш-то можно периодически тереть, более того, тереть выборочно, при этом сохраняя данные о частоте востребования.
Сказанное, кстати, вовсе не означает, что подобную схему я советую тут же бросаться прикручивать ко всему, что под руку попадается, тем более не изучив и не поняв, как работают классические схемы доступа.
И что статический контент в виде обычных файлов - старье, не заслуживающее внимания.
Но вот когда некоторое правило, даже очень правильное, начинает кем-либо применяться без понимания процессов, вследствие которых оно сформировалось, то оно (правило) в представлении этого кого-либо превращается в догму.
(Николай, только не прими на свой счет -- я о тех, кто читая рекомендации, кладет их на чистый так сказать лист , незамутненный ни знанием стандартов и протоколов, ни опытом.)
а догмы в программировании вредны чуть менее, чем инновационные идеи на пустом месте.