-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Оптимизация, кэширование и "многокомпьютерность" программы
- Автор темы Tronyх
- Дата начала
Tronyх
Новичок
Задаю 
1. SqlRelay
- на сколько стабильно работает?
- сколько ресурсов съедает по сравнению с "обычнами" mysql_* функциями, а так же во время подключения?
- скорость отправки и получения результата от БД?
- Как много подключений может выдержать?
2. SRM
- на сколько стабильно работает?
- как быстро работают банана классы?
- сколько ресурсов нужно демону?
- как много подключений может выдержать?
- какие глюки возможны?
- если на базе его делать чат-демон, какое соотношение производительности по сравнению с таким же демоном, но на Си?
- кэширование данных (до 40 Мб) на чём лучше делать на СРМ или мемкэш?
3. Memcache
- стабильность?
- потреблнение ресурсов?
- одновременные подключения?
- скорость передачи данных?
1. SqlRelay
- на сколько стабильно работает?
- сколько ресурсов съедает по сравнению с "обычнами" mysql_* функциями, а так же во время подключения?
- скорость отправки и получения результата от БД?
- Как много подключений может выдержать?
2. SRM
- на сколько стабильно работает?
- как быстро работают банана классы?
- сколько ресурсов нужно демону?
- как много подключений может выдержать?
- какие глюки возможны?
- если на базе его делать чат-демон, какое соотношение производительности по сравнению с таким же демоном, но на Си?
- кэширование данных (до 40 Мб) на чём лучше делать на СРМ или мемкэш?
3. Memcache
- стабильность?
- потреблнение ресурсов?
- одновременные подключения?
- скорость передачи данных?
AnToXa
prodigy-одаренный ребенок
3.
- все стабильно, есть аптаймы больше 3 месяцев
- оверхед в среднем получается процентов 20-30, бо там данные хранятся в кусках памяти по степеням 2, т.е. если положить 100 байт, то будет юзаться кусок 128байт, но это не критично, ес честно
- сколько разрешишь открытых дескрипторов на процесс, столько и выдержит, epoll - страшная штука
- скорость передачи - ну а какова скорость передачи по tcp ?
скорость работы - супер, слышал что на некоторых тестах отдается 1.5-2M гетов в _секунду_
- все стабильно, есть аптаймы больше 3 месяцев
- оверхед в среднем получается процентов 20-30, бо там данные хранятся в кусках памяти по степеням 2, т.е. если положить 100 байт, то будет юзаться кусок 128байт, но это не критично, ес честно
- сколько разрешишь открытых дескрипторов на процесс, столько и выдержит, epoll - страшная штука
- скорость передачи - ну а какова скорость передачи по tcp ?
скорость работы - супер, слышал что на некоторых тестах отдается 1.5-2M гетов в _секунду_
AnToXa
prodigy-одаренный ребенок
ну не на 286 конечно
в основном данные хавают
я же говорил epoll
(читаем http://danga.com/memcached/)
про СРМ ничего не могу сказать.
memcache специально сделан для кеширования данных в памяти.
Tronyх
Новичок
Ещё один вопрос, вызван сообщением si
Кто-нибудь ещё это заметил? Каким образом тогда лучше постоянное соединение сделать? СРМ? И что из себя будет представлять работа с БД через СРМ? И на сколько быстра/удобна?
-~{}~ 25.01.05 13:00:
Ни кто не юзал SqlRelay?
http://phpclub.ru/talk/showthread.php?s=&threadid=42814&highlight=SqlRelay
Кто-нибудь ещё это заметил? Каким образом тогда лучше постоянное соединение сделать? СРМ? И что из себя будет представлять работа с БД через СРМ? И на сколько быстра/удобна?
-~{}~ 25.01.05 13:00:
Ни кто не юзал SqlRelay?
Yurik
/dev/null
fisher
накатила суть
>>А на русском есть что?
по-моему, это очевидно - нет, и вряд ли в ближайшее время будет.
но в FAQ и приложениях fido7.ru.unix.prog есть небольшой документ "как писать сервера"
http://www.opennet.ru/base/dev/server_way.txt.html
http://www.dore.ru/perl/nntp.pl?f=1&gid=22&mid=17451
по-моему, это очевидно - нет, и вряд ли в ближайшее время будет.
но в FAQ и приложениях fido7.ru.unix.prog есть небольшой документ "как писать сервера"
http://www.opennet.ru/base/dev/server_way.txt.html
http://www.dore.ru/perl/nntp.pl?f=1&gid=22&mid=17451
Yurik
/dev/null
Имхо ты не оттуда начал. Начинать надо с разделения данных как это делают разные большие сервисы (например почтовые сервера раскидывают по физическим серверам ящики, счётчики посещений тоже раскидывают и т.д.)
Масштабировать приложение интенсивным путём (мемкеш, постоянные соденинения, оптимизация алгоритмов и т.д.) можно лишь в небольших пределах (ну в пределах порядка), большие системы как бы то ни было работают на многих серверах (Например тут разрабатывают на 100-150 серверов)
Если у тебя всё динамическое и интерактивное то это наверняка какая-то СУБД, с которой общаются SELECT/INSERT/UPDATE/DELETE запросами (ну разные внутренности типа процедур, тригеров, вьюшек затрагивать не будем)
Т.е. надо разносить типы запросов к данным (например INSERT/UPDATE/DELETE на 1 мастере и репликация на N слейвов которые будут получать также часть SELECT запросов)
Если этого не будет достаточно, то надо разносить также и разнородные данные (например часть таблиц реплицировать на одни сервера, часть на другие) или даже однородные данные (если все тормоза упираются в них) - для примера четные/нечетные посты из форума идут по разным зеркалам (ну конечно тут сильно усложняется интерфейсная часть и лишние конекты, но возможно это единственная возможность масштабироваться дальше)
Если мастер не будет справляться с нагрузкой INSERT/UPDATE можно убрать на мастере с таблиц все индексы которые нужны только для SELECTов (оставить только нужные для UPDATE/DELETE)
Когда будет проделана эта работа можно писать интерфейсную часть и раскидывать её по серверам и думать о SRM, SqlRelay, Memcache, демоны, екстеншены etc
Тут тоже возможно можно распаралелить выполнение между разными серверами: скрипт-обертка раздаёт задания и "клеит" результат
Масштабировать приложение интенсивным путём (мемкеш, постоянные соденинения, оптимизация алгоритмов и т.д.) можно лишь в небольших пределах (ну в пределах порядка), большие системы как бы то ни было работают на многих серверах (Например тут разрабатывают на 100-150 серверов)
Если у тебя всё динамическое и интерактивное то это наверняка какая-то СУБД, с которой общаются SELECT/INSERT/UPDATE/DELETE запросами (ну разные внутренности типа процедур, тригеров, вьюшек затрагивать не будем)
Т.е. надо разносить типы запросов к данным (например INSERT/UPDATE/DELETE на 1 мастере и репликация на N слейвов которые будут получать также часть SELECT запросов)
Если этого не будет достаточно, то надо разносить также и разнородные данные (например часть таблиц реплицировать на одни сервера, часть на другие) или даже однородные данные (если все тормоза упираются в них) - для примера четные/нечетные посты из форума идут по разным зеркалам (ну конечно тут сильно усложняется интерфейсная часть и лишние конекты, но возможно это единственная возможность масштабироваться дальше)
Если мастер не будет справляться с нагрузкой INSERT/UPDATE можно убрать на мастере с таблиц все индексы которые нужны только для SELECTов (оставить только нужные для UPDATE/DELETE)
Когда будет проделана эта работа можно писать интерфейсную часть и раскидывать её по серверам и думать о SRM, SqlRelay, Memcache, демоны, екстеншены etc
Тут тоже возможно можно распаралелить выполнение между разными серверами: скрипт-обертка раздаёт задания и "клеит" результат
Tronyх
Новичок
Я уже это продумал. Система вообще без проблем делится на 17 компьютеров (этого должно хватить с головой): 7 серверов со скриптами, 8 серверов с БД, 1 сервер для картинок и статики, 1 сервер для публичной части сайта. Но тем не менее на данный момент не хочется тратить деньги на два сервера, сейчас у нас будет стоять одна машина, всё равно посещаемость сначала далека от планируемой и будет идти тестирование сайта, а через пол года уже можно будет прикупить ещё одну машину. Но тем не менее "плодить сервера" тоже не хочется. Так что вопрос по библиотекам думаю в тему
Всё нормально - есть деньги, есть 4 человека которые это будут делать.Tronyх
Новичок
Показать что? Проект? Думаю в июне на тестирование выйдет.
-~{}~ 08.02.05 13:30:
Ещё для оптимизации вариант - есть таблица с данными игроков. Человек залогинился - копируем всю инфу о нём в другую таблицу хранящуюся в памяти. В итоге получаем рабочую таблицу размером в 15-25 раз меньше да ещё и хранящуюся в памяти. Но тут меня очень сильно смущает ситуация когда пришло пользователей больше чем расчитано - и память кончается... Ваши мнения?
-~{}~ 08.02.05 13:30:
Ещё для оптимизации вариант - есть таблица с данными игроков. Человек залогинился - копируем всю инфу о нём в другую таблицу хранящуюся в памяти. В итоге получаем рабочую таблицу размером в 15-25 раз меньше да ещё и хранящуюся в памяти. Но тут меня очень сильно смущает ситуация когда пришло пользователей больше чем расчитано - и память кончается... Ваши мнения?