Вопрос по memcache

[Garret]

Вопрос по memcache

Переписал свой драйвер мускуля с поддержкой memcache.

Возникла проблема, данные очень долго кэшируются, например идет 100 запросов с вложеным запросом который возвращает 1000 записей, сами запросы не тяжелые. И все это добро кэшируется около 30 секунд

В чем может быть проблема?

З.Ы. memcached стоит на той же машине

-~{}~ 01.02.07 19:10:

И вообще может ли быть нормальная скорость при кэшировании если пересылаются данные через сокеты...?

-~{}~ 01.02.07 19:10:

В инете инфы по мемкэшу почти нету.

 

[MiksIr]

Re: Вопрос по memcache

Переписал свой драйвер мускуля с поддержкой memcache.

Зачем?

Возникла проблема, данные очень долго кэшируются, например идет 100 запросов с вложеным запросом который возвращает 1000 записей, сами запросы не тяжелые. И все это добро кэшируется около 30 секунд

Перечитал раз 10. Не понял нефига.

И вообще может ли быть нормальная скорость при кэшировании если пересылаются данные через сокеты...?

База, кстати, тоже работает через сокеты.

 

[Garret]

Зачем?

Странный вопрос, нужно, оптимизация.

Перечитал раз 10. Не понял нефига.

Очень долго пишутся не особо большие данные в кэш.

База, кстати, тоже работает через сокеты.

Сокеты бывают разные

 

[Макс]

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

По мемкешу есть полезная (ИМХО) рассылка http://lists.danga.com/mailman/listinfo/memcached
(или через веб-интерфейс http://blog.gmane.org/gmane.comp.web.cache.memcached)

 

[MiksIr]

Странный вопрос, нужно, оптимизация.

Не странный. Применение мемкеша должно быть взевешно, равно как взвешено и то, что в нем кешировать. Тупо кешировать возвращаемые базой данные - не лучший вариант, СУБД и сами это умеют.

Очень долго пишутся не особо большие данные в кэш.

Server's version: 1.1.12
Connect time: 0.00663495063782 sec
Store to memecache string with strlen: 1000000
Store time (w/o zlib): 0.0473020076752 sec
Store time (with zlib): 0.00882387161255 sec
Вот результат моего теста. Но, я загонял строку, а если ты загоняешь более сложные структуры, то плюсуй еще время на их сериализацию, что процесс довольно длительный.

Сокеты бывают разные

Базы очень часто работают на tcp. Ибо вообще разделение серверов DB и серверов приложений - нормальная практика. И что же теперь, все безумно теряют в скорости?

 

[Alexandre]

Переписал свой драйвер мускуля с поддержкой memcache

а вот с этого места, можно по подробнее, ось, что переписал, как переписал (алгоритм), что это дало, и нет ли там ошибки...

ЗЫ. кеширование в мускуле уже предусмотренно. Если ты переписал эту часть с использованием мемкеша...я проникнусь к тебе уважением.
есле написан буферообменник с кешированием между мускулем и пхп_апи, то вопрос - нужен ли он? если есть встроенное кеширование. может стоит переписать сам пхп_апи_мускуль с внедрением кеширования?

 

[Garret]

Не странный. Применение мемкеша должно быть взевешно, равно как взвешено и то, что в нем кешировать. Тупо кешировать возвращаемые базой данные - не лучший вариант, СУБД и сами это умеют.

Нужно кэширование. С начала просто остановил свой выбор на мэмкэше.

а вот с этого места, можно по подробнее, ось, что переписал, как переписал (алгоритм), что это дало, и нет ли там ошибки...

ОСь Линух, адгоритм не имеет значения, он примитивный, ошибки там не может быть.

Насчет кэширования мускулем, я как то не особо интересовался им, дает ли оно нормальные результаты? И где побольше инфы о нем почитать?

 

[Alexandre]

адгоритм не имеет значения, он примитивный

где и в каком месте идет кеширование, что кешируется... нам интересно. где стоит твой кеш-буфер, как к нему идет обращение?

Насчет кэширования мускулем, я как то не особо интересовался им, дает ли оно нормальные результаты? И где побольше инфы о нем почитать?

http://www.mysql.com/search/?q=caching&charset=

 

[Garret]

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

 

[MiksIr]

Мемкеш имеет смысл, когда идет очень много простых выборок из таблицы. Но тогда не нужно делать "запрос - кеш, запрос - кеш". В таких случаях ты берешь всю таблицу, загоняешь ее в кеш и потом уже все выборки делаешь из этого кеша.
Пойми, что задача мемкеша - не ускорение производительности. Это еще вопрос долгого изучения под конкретную задачу, что быстрее будет. Но задача мемкеша - снизить нагрузку на базу, когда она является узким местом, и перенести часть математики в приложение.
Что ж до того, что мемкеш "тормозит и работает 30 секунд", то пока не будет ясно, что именно работает и где тормоза, никто ничего не скажет. Если у тебя там жуткие цикдлы и скрипт с базой работает 300 секунд, а с мемкешом 330, то да, запросто. Если скрипт работает секунду, а с мемкешом 30 - то "не верю", ищите косяк =)

 

[Garret]

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

Сейчас после небольшой оптимизации одного вложеного запроса(оптимизация состоит в том что теперь выбираются не все данные, а одно поле), время выполнения составило 5 сек.

З.Ы. Может посоветуете что то с кэшированием в шарэд мемори?

 

[MiksIr]

Определяй контрольные точки, ставь туда замеры времени, смотри где тормоза. Проблема в логике, имхо.
Еще есть APC http://ru2.php.net/manual/ru/ref.apc.php и eAccelerator http://bart.eaccelerator.net/doc/phpdoc/
Если у тебя только один сервер, то можешь пробовать их.

 

[Garret]

Посмотрел getStats(), мне вывело такое:
Array
(
[pid] => 850
[uptime] => 1189510
[time] => 1170668104
[version] => 1.1.12
[rusage_user] => 0.600000
[rusage_system] => 0.750000
[curr_items] => 508
[total_items] => 1337
[bytes] => 331976
[curr_connections] => 1
[total_connections] => 658
[connection_structures] => 4
[cmd_get] => 11333
[cmd_set] => 1337
[get_hits] => 10094
[get_misses] => 1239
[bytes_read] => 1695302
[bytes_written] => 79437723
[limit_maxbytes] => 67108864
)
Что за астрономические данные в bytes_written и bytes_read?

-~{}~ 05.02.07 12:39:

Все, понял, это с начала работы мэмкэшеда...

-~{}~ 05.02.07 12:41:

Нет, все таки астрономические:
Array
(
[pid] => 23423
[uptime] => 49
[time] => 1170668375
[version] => 1.1.12
[rusage_user] => 0.120000
[rusage_system] => 0.120000
[curr_items] => 291
[total_items] => 291
[bytes] => 124601
[curr_connections] => 1
[total_connections] => 3
[connection_structures] => 2
[cmd_get] => 1452
[cmd_set] => 291
[get_hits] => 1161
[get_misses] => 291
[bytes_read] => 173399
[bytes_written] => 24464844
[limit_maxbytes] => 67108864
)

-~{}~ 05.02.07 12:55:

Кстати, странно, это что висят коннекшены незакрытые? [total_connections] => 3?
хотя я их закрываю.

-~{}~ 05.02.07 13:20:

Посчитал, обьем всех отправляемых данных на кэш за один раз составляет 82Кб. По статам же, за раз отправляется 25Мб, что за гон?

-~{}~ 05.02.07 13:37:

Вот результат моего теста.

Кстати, это memcache_debug такое показал?

 

[MiksIr]

Кстати, это memcache_debug такое показал?

Не, свой код с microtime

Посчитал, обьем всех отправляемых данных на кэш за один раз составляет 82Кб. По статам же, за раз отправляется 25Мб, что за гон?

Вы вот что попробуйте. Возьмите свою структуру, сериализуйте ее и посмотрите размер итоговой строки. Можете даже посчитать время, которое тратится на сериализацию и на загон в память. Например, у нас получилось на одномерном массиве в 1'000'000 элементов сериализация занимала около 7 секунд, а сам загон в мемкеш - доли секунды.

Кстати, странно, это что висят коннекшены незакрытые? [total_connections] => 3?

total_connections Total number of connections opened since the server started running
Т.е. общее число коннектов. А текущие открытые в curr_connections

 

[Garret]

Ок, спс, попробую.

-~{}~ 05.02.07 14:46:

Мда, в принципе все выяснилось.

select * from table1
Proceed time: 0.0505 sec.
All time: 0.0505 sec.

select count(*) from table2 where id=N1
Proceed time: 0.0076 sec.
All time: 0.0581 sec.

select count(*) from table2 where id=N2
Proceed time: 0.0056 sec.
All time: 0.0637 sec.

Для одного запроса время записи/чтение из мэмкэша нормальное, но из за того что после основного в цикле выполняется еще около 300 запросов, то и набегает такое время Прийдется что то переделать.

Всем спасибо за помощь.