unsorted ~ Новый сервер

Возраст: 39 C нами с 30.09.2004 Репутация: **102.4**

Petro писал(а):

Ну скажем так, что существует такая штука, как кэширование на уровне сайта. И если грамотно продумать кэширование, то можно добиться лучших результатов, чем в статике...

Кешировать можно только для гостя, для остальных кешировать "на уровне сайта" (если мы говорим об одном и том же) невозможно, хотябы потому что различается фрагмент страницы "Выход [ iZz ]". Не говоря о том что разные пользователи видят по разному одно и тоже, разные права, стили.

И еще: как можно добиться результатов что-то кешируя лучше чем в статике, которая по своей сути и так образец быстродействия.

splav, а bt.unsorted.ru сильно грузит?

Возраст: 36 C нами с 22.01.2006 Репутация: **256.8**

На вскидку ~80 запросов в секунду к сайту не относятся - почта, торрент, jabber. В основном естественно jabber и торрент.

Возраст: 39 C нами с 04.05.2006 Репутация: **63.9**

iZz писал(а):

Кешировать можно только для гостя, для остальных кешировать "на уровне сайта" (если мы говорим об одном и том же) невозможно, хотябы потому что различается фрагмент страницы "Выход [ iZz ]".

Все возможно Подмигивание

Я бы даже сказал нужно. Кэширование непростой и интересный вопрос, и обсуждать его можно очень долго... Подмигивание

Например можно кэшировать страницу частично, использовать несколько уровней кэша, и на клиенте в том числе...

iZz писал(а):

И еще: как можно добиться результатов что-то кешируя лучше чем в статике, которая по своей сути и так образец быстродействия.

Ну к примеру если кэш храниться в памяти, а за доступом к статике надо всегда обращаться к диску. Практического смысла конечно такая фигня не имеет, но теоритически время отклика будет меньше. )))

Возраст: 57 C нами с 08.03.2005 Репутация: 95

splav писал(а):

А поп поводу оценки - позвольте не согласиться. В крокодилам может даже точнее будет. Потому как общее количество запросов не говорит ни о чем.

Перед тем, как производить измерения крокодилами очень хотелось - бы посмотреть нормальную статистику например как тут: http://www.mysqlstat.org/

iZz писал(а):

Меня убивают просто показатели "колличество SQL запросов в секунду" и "колличество HTTP запросов в секунду"

iZz Производительность сервера БД имеет размерность транзакция/секунду - это условность, такая - же как то, что длина измеряется в метрах, вес в килограммах, а сила тока в амперах.
Так как MySQL транзакции не поддерживает, то для измерения производительности остается наиболее близкая величина - запросы.

iZz писал(а):

Как можно сравнивать запрос SELECT xname, xdata FROM xtable WHERE id = 4365, где id - PRIMARY KEY. Пусть хоть в этой таблице миллион строк. Сравнивать с запросами по выводу списка блогов, с присоединенными к ним таблицами с записями блогов, пользователями, какиминибудь сессиями, "настроениями" и т.п. Во время выполнения второго запросы успет выполниться тысяча первых.

Парсер БД разбивает сложный запрос на кучу простых - вот эту кучу простых запросов и отображает статистика сервера.
В случае если парсер бессилен - то в статистике такой запрос отображается как Slow Queries (типа - наколбасил г..на - ну и е..сь с ним сам) правда критерий "бессилия" задаётся от лукавого (Время выполнения запроса) - но к этому можно привыкнуть - главное результат.
Поэтому ждемс нормальную статистику и разбора полётов запросов с маркером Slow а вот уж потом поговорим о мощности сервера для БД.

Возраст: 36 C нами с 22.01.2006 Репутация: **256.8**

ИМХО на выбор сервера это никак повлиять не может. Запросы в секунду это почти как мерить производительность дисковой подсистемы в файлы с секунду. Предлагаю вернуться к конфигурации сервера и оставить спор по оценке производительности БД...

Добавлено спустя 3 минуты 9 секунд:

Кстати статистику по медленным запросам я тоже привёл... На скринах того сборщика статистики ничего нового и интересного не увидел.

C нами с 15.04.2005 Репутация: **133.2**

zelen писал(а):

Так как MySQL транзакции не поддерживает, то для измерения производительности остается наиболее близкая величина - запросы.

Разработчики MySQL шокированы не меньше моего... Я в шоке

Транзакции поддерживаются для таблиц типа InnoDB и BDB.

Цитата:

7.31 BEGIN/COMMIT/ROLLBACK Syntax
By default, MySQL runs in autocommit mode. This means that as soon as you execute an update, MySQL will store the update on disk.

If you are using BDB or InnoDB tables, you can put MySQL into non-autocommit mode with the following command:

SET AUTOCOMMIT=0

After this you must use COMMIT to store your changes to disk or ROLLBACK if you want to ignore the changes you have made since the beginning of your transaction.

И далее по тексту с примерами...

Кроме этого, транзакции могут быть сносно сымитированны с помощью LOCK TABLES (без rollback'a ессно).

Впрочем, транзакции/сек, по сути, тоже меряет в неких условных попугаях, потому что в одной транзакции может быть один запрос, а может несколько сотен (без учёта сложности отдельных запросов!). Эти величины можно использовать только для сравнительной оценки, но никак не для абсолютной.

Возраст: 57 C нами с 08.03.2005 Репутация: 95

splav писал(а):

ИМХО на выбор сервера это никак повлиять не может. Запросы в секунду это почти как мерить производительность дисковой подсистемы в файлы с секунду.

А производительность современных файловых систем так и измеряется. И называется это транзакций в секунду. Минимальный размер транзакции = кластеру диска а максимальный - размеру непрерывного блока данных, с которым работают (читают или пишут ) обычно - не более 1-го файла. Только за последние 7 лет в этой области прогресс почти нулевой, поэтому маркетологи и околокомпютерная литература и придумали кучу тестов, которые с жизнью не имеют ниичаго общего. Зато простой обыватель, читает "умные" статьи и клюёт на эти уловки.

splav писал(а):

Кстати статистику по медленным запросам я тоже привёл...

Медленные запросы - это тот бич, который нужно устранять. В статистике - же видно что средняя скорость их выполнения - 3 шт/сек. - какой бы новый сервер ни купили - проблемы останутся.

splav писал(а):

На скринах того сборщика статистики ничего нового и интересного не увидел.

На самом деле там очень много интересной и полезной информации собранной в хорошее наглядное представление.

splav писал(а):

Предлагаю вернуться к конфигурации сервера и оставить спор по оценке производительности БД...

А для этого нужно составить карту производительности текущей конфигурации и выяснить "узкие места". Например из приведённых выше данных видно что у MySQL очень плохая статистика попаданий в кеш - 69.5%. можно узнать сколько памяти использует MySQL и какого размера временные таблицы он создаёт.
P.S. У меня начинает складывается такое впечатление что толку от нового сервера будет - пшык.

Добавлено спустя 6 минут:

Рыся писал(а):

жуткий оффтопик, но я требую сатисфакции!]И далее по тексту с примерами...

Кроме этого, транзакции могут быть сносно сымитированны с помощью LOCK TABLES (без rollback'a ессно).
[/quote]
Рыся Версию MySQL посмотри хелпа и ту что на unsorted.

Возраст: 36 C нами с 22.01.2006 Репутация: **256.8**

наиболее существенная часть my.cnf :

concurrent_insert                       = 2
low_priority_updates                    = 1
key_buffer                              = 1024M
max_allowed_packet                      = 4M
max_user_connections                    = 200
max_connections                         = 220
table_cache                             = 1024
sort_buffer_size                        = 128M
read_buffer_size                        = 128M
myisam_sort_buffer_size                 = 128M
join_buffer_size                        = 128M

record_buffer                           = 64M
thread_cache_size                       = 180 

query_cache_size                        = 512M
query_cache_type                        = 1
thread_concurrency                      = 4 
tmp_table_size                          = 512M
max_heap_table_size                     = 512M