iWeb, ну они там пишут, что ищут проект превратился в полный опенсорс и ищут ментейнера.
Да в принципе им там некуда развиваться. Все основные фичи работают.
Разве что для совместной работы с nginx могли бы сделать поддержку X-Accel-Redirect и скорости скачивания. Это важно когда файлы большие и любители покачать наседают с качалками.
Но до этого надо еще дорасти.
Andreyka, только вот получается, что любой лишний запрос к memcached - смерть*1.10 .
А бенчмарки там адекватные и воспроизводимые.
Outsourcenow, ну а что? у memcached, насколько я помню, других вариантов кроме tcp/ip нет.
а еще он в 2006 сделал тест, где хваленый биороботами memcached, отстает от mysql на 10%
http://www.mysqlperformanceblog.com/2006/08/09/cache-performance-comparison/
Memcached Cache (TCP/IP) - 12200
MySQL Query Cache (Unix Socket) - 13500
Outsourcenow, при этом предводитель "людей которые занимаются тюнингом" пишет статейки, как его использовать : http://www.mysqlperformanceblog.com/2006/07/27/mysql-query-cache/
Нестыковочка.
Outsourcenow, ну вот. 90% апдейтов в вебе это нетипично. Специфика вашего проекта совсем не дает вам право утверждать, что у mysql хреновый query_cache.
А так, попробуйте уменьшать (как ни странно) размер кеша. Сделайте профилирование. Скорее всего, накладные расходы возникают не при поиске в кеше, а при удалении затронутых обновлением запросов из кеша. Это не значит, что бороться этим явлением невозможно.
Outsourcenow, так вы не ответили почему он тормозит именно в вашем приложении. hitrate хотя бы какой у вас?
Outsourcenow, надо. у вас, видимо, приложение специфическое.
Andreyka, ну мне что, опять написать программу, которая покажет вам 5K qps ? :)
факт на лице : в mysql есть query_cache и он работает, причем даже раньше парсинга sql.
кешировать запросы в унылых варезных ГС практически бессмысленно. лучше кешировать полностью готовые элементы html страниц.
Andreyka, бредовый вопрос. вы должны понимать что и 50 запросов не помеха, если они очень простые и кешируются самим mysql. Конечно, однажды наступит момент, когда накладные расходы mysql станут значимым, но к тому времени большинство обзаводятся постоянным админом и задают тупые вопросы за деньги.
