aktuba: Не, нельзя так считать. Иначе придется считать, что запрос данных из базы начинается до того, как пришел юзер
Чушь же! Или передёргивание, как будет угодно. В "грязном" виде процесс выглядит так:
1. запрос страницы юзером
2. начало генерации
while (..)
{
3. запросы в БД\к файлам
4. генерация по результатам
5. (опционально) запросы (ы) к запрашивающему ЮА
}
endwhile;
5. конечный результат генерации
6. Обработка сервером для выдачи (gzip например)
aktuba: Мы про какие винты говорим? Сата? Скази? Ссд? Это во первых. Во-вторых, кто говорит, что надо использовать именно диски? Что, религия запрещает создавать виртуальные диски в памяти? )
понеслись фантазии... :)
aktuba: это практический опыт, а не теория
Т.е. были проведены сравнивания работы высоконагруженных проектов вначале на БД а потом, после их переноса, на ФС? Сравнивали при максимально одинаковых условиях? Нет? Тогда это не более чем "у меня, в конкретном случае тормозит БД". И потому подобные прямые заявления (без конкретной точки приложения) я считаю полным бредом, чушью и тп.
Как и по всему остальному утомительно (и бессмысленно) дискутировать.. Особенно без конкретных задач\условий. (читаем стартпост ТСа).
aktuba: время на генерацию результата мизерно, по отношению к получению данных из базы.
ууу как всё запущено... Опять мешаешь тёплое с мягким..
Что не может быть один точный запрос на доли мс при времени генерации страницы до 1 сек? Очень даже может. Это вообще никак не связано (ну почти ;)).
А вообще можно считать генерация начинается ДО запроса в БД, а заканчивается много позже. Так что подобные заявления - бред
А скорость чтения винтов на серверах. Это воще самый тяжелый момент
aktuba: В реале, кеширование спасает именно от обращения к базе, а не от генерации результатов, верно? )
Именно. Но есть куча нюансов... Таже генерация (создание) кеша - это доп. нагрузка на хостинг. И опять про скорость чтения винтов...
Stek: Тормоза в БД означают то, что если перевести эти же операции на файловую систему - она просто сдохнет в момент со всем сервером. Кеширование же используют для того, что бы не выбирать одно и то же по сотне раз, когда результат не меняется. Так что не надо путать обработку/поиск данных и получение уже готовых данных.
+1
aktuba: с более-менее нагруженными проектами (от 50к уников в сутки). Во всех, без исключений, случаях проблемы были только с базой.
Ключевой момент - выделен бодом. Но задай себе (и им вопрос) - можно ли избавиться от БД и перевести хранение данных на ФС? Ответ, думаю, очевиден.
Чтобы заменить стандартный the_exerpt() нужно просто заменить the_exerpt(); на kama_excerpt(); Все это должно быть внутри цикла the loop. ВАЖНО! Парметр text при замене the_exerpt(); указывать не надо!
Да ладно! "Элементарная" операция - поиск уже при нескольких (10ков) тыщ "данных" и уже выигрыш в скорости на лицо. Потому что индексация...
aktuba: И кстати, практически все движки баз данных имеют внутреннюю систему кеширования именно по причине НЕ быстрой работы с данными.
Не надо путать тёплое с мягким. А именно кол-во запросов, время их выполнения и скорости генерации страниц по их результатам.
А кеширование - это такой скользкий момент.. Не всё с ним так хорошо, как на него молятся. (убивают советы для ВП - поставь кеш-плаг для ускорения ВП.. повбывавбы)
Знаю по наслышке о существовании iGiveTest.
Получается что статья доступна по двум разным ссылкам, а это - дубль.
а посмотреть в код страниц и найти там каноникал? ;)
Как так можно сделать?
Вначале прочитать начало стартпоста и изучить данные там ссылки.
пишет Hacking attempt!
исправляй дурацкий хтацесс от ДЛЕ.
stundr, см. логи сервера
сделать чтобы показывался раздел темы
тож не хватает этого.
почему не делать с нуля для клиентов?
Клиенту надо "ещё вчера", а не пребывать в неизвестности неск. месяцев по итогу которых он может кривое поделие, которое ещё год нужно отлаживать.
Далее подпишусь под каждым словом Garin33а.
Не, нельзя так считать. Иначе придется считать, что запрос данных из базы начинается до того, как пришел юзер
Чушь же! Или передёргивание, как будет угодно. В "грязном" виде процесс выглядит так:
1. запрос страницы юзером
2. начало генерации
while (..)
{
3. запросы в БД\к файлам
4. генерация по результатам
5. (опционально) запросы (ы) к запрашивающему ЮА
}
endwhile;
5. конечный результат генерации
6. Обработка сервером для выдачи (gzip например)
Мы про какие винты говорим? Сата? Скази? Ссд? Это во первых. Во-вторых, кто говорит, что надо использовать именно диски? Что, религия запрещает создавать виртуальные диски в памяти? )
понеслись фантазии... :)
это практический опыт, а не теория
Т.е. были проведены сравнивания работы высоконагруженных проектов вначале на БД а потом, после их переноса, на ФС? Сравнивали при максимально одинаковых условиях? Нет? Тогда это не более чем "у меня, в конкретном случае тормозит БД". И потому подобные прямые заявления (без конкретной точки приложения) я считаю полным бредом, чушью и тп.
Как и по всему остальному утомительно (и бессмысленно) дискутировать.. Особенно без конкретных задач\условий. (читаем стартпост ТСа).
время на генерацию результата мизерно, по отношению к получению данных из базы.
ууу как всё запущено... Опять мешаешь тёплое с мягким..
Что не может быть один точный запрос на доли мс при времени генерации страницы до 1 сек? Очень даже может. Это вообще никак не связано (ну почти ;)).
А вообще можно считать генерация начинается ДО запроса в БД, а заканчивается много позже. Так что подобные заявления - бред
А скорость чтения винтов на серверах. Это воще самый тяжелый момент
В реале, кеширование спасает именно от обращения к базе, а не от генерации результатов, верно? )
Именно. Но есть куча нюансов... Таже генерация (создание) кеша - это доп. нагрузка на хостинг. И опять про скорость чтения винтов...
Тормоза в БД означают то, что если перевести эти же операции на файловую систему - она просто сдохнет в момент со всем сервером. Кеширование же используют для того, что бы не выбирать одно и то же по сотне раз, когда результат не меняется.
Так что не надо путать обработку/поиск данных и получение уже готовых данных.
+1
с более-менее нагруженными проектами (от 50к уников в сутки). Во всех, без исключений, случаях проблемы были только с базой.
Ключевой момент - выделен бодом. Но задай себе (и им вопрос) - можно ли избавиться от БД и перевести хранение данных на ФС? Ответ, думаю, очевиден.
Поэтому прямые заявления типа
больше всего на сайте тормозит MySQL
тормоза ВСЕГДА именно в БД
являются бредом диагональночитающих..
Неправильная постановка вопроса.
Правильная: кто и почему меняет файл?
ВП этого сам не делает.
Один из методов защиты - поставить такие права, что бы пхп-скрипты не могли в него писать.
чочото я весь сайт уже скачал, нету там этого эксерпта ни в одном файле (
Если ты про функцию Тимура, то видимо в файле loop.php
он прост букву C случайно пропустил
+1 :)
Перешли не из-за скорости работы,
Да ладно! "Элементарная" операция - поиск уже при нескольких (10ков) тыщ "данных" и уже выигрыш в скорости на лицо. Потому что индексация...
И кстати, практически все движки баз данных имеют внутреннюю систему кеширования именно по причине НЕ быстрой работы с данными.
Не надо путать тёплое с мягким. А именно кол-во запросов, время их выполнения и скорости генерации страниц по их результатам.
А кеширование - это такой скользкий момент.. Не всё с ним так хорошо, как на него молятся. (убивают советы для ВП - поставь кеш-плаг для ускорения ВП.. повбывавбы)