Многие дешёвый дороже нормального китайского смартфона на Android с двуядерным процессором. Поэтому китайцы тормозят прогресс. Если б они развили торговую сеть и сервис по всему миру, телефоны с плохими браузерами уже бы умерли…
конечно быстрее… либо у вас в dom тысячи тегов, из-за которых браузер съест не мало памяти, а ОС будет страницы памяти писать на винт и при скроллинге вы будете ждать свой винт… либо у вас пару десятков тэгов, которые ничего не весят… даже слабинький проц с перерендерингом 2х десятков тэгов справится на ура…
в виртуальном скроллинге главное реализовать: выделить всё, выделить часть(которая больше видимой) и естественно копировать, быстрый переход на 1523 строку, возможность табличку раздвоить и видеть рядом две разные части таблицы, ну и другие фишки которые устранят недостатки постраничного просмотра
на мастере выполняйте insert, update чтобы запись на диск быстрая была и никакого чтения с диска приэтом. на слэйве в этоже время делайте select с множеством inner join и критерием по всем соединяемым табличкам, ну чтоб таблички были гигов по 5 минимум… это приведёт к тому что на слэйве диск будет сильно занят чтением, поэтому не будет успевать писать с той же скоростью с какой пишет мастер. вот тут можно получить десинхранизацию минут на 10 — 30, а то и вообще слэйв отпадёт!
Нужно добавить в sort, ksort krsort и т.п. параметр с дефолтным значением константа SM_QUICKSORT(SM типа Sort Method или чё нить другое) и будет возможность юзать например SM_TIMSORT
99% процентов(а я наблюдаю все 100% ежедневно) народу юзает svn up и svn commit, а остальное так для интереса попробовали и забыли… в таком случае эти 5 причин очень убедительны…
простота, гибкость, динамика — вот чего мы ждём…
вообще жду когда появится возможность в реальном времени разрешать конфликты, начал набирать в строчке, а СКВ сказала «Лена тут впрогала это», есть повод с Леной пообщаться а не поругаться :-)
откройте firefox с firebug, chrome, opera, netbeans(5 больших проектов по 50 Мб без .svn) c кучей вкладок поиска, pgadmin и там сильно необходимые в работе аськи всякие и т.п… на 2Gb сижу активно своплюсь, но терпимо.
по сравнению с eclipse'ом конечно он летает, т.к. eclipse постоянно перебирает, перечитывает эти тысячи файлов php.
джава любит запускать всякие «сборщики мусора» и на таких объёмах он захлёбывается подвисая на пару часов в самый ответственный момент до которого пол дня пишешь регулярки в поиске чтобы найти и исправить бяку…
не помогает… один случайный клик пяткой правой кнопки мыши с драгом и любое джава приложение виснет часа на 2, а потом как ни в чём не бывало продолжает работать…
strace говорит что он роется в памяти… тока не понятно чего потерял.
данный пост предлагает не ждать, а вы своим комментом опять предлагаете ждать… зачем???
нужно просто начинать делать SQL запрос раньше времени устаревания на время выполнения запроса(среднее время выполнения запроса + запас)… т.к. в разное время суток(или по др. признаку) среднее время может меняться, то его хорошо бы всегда считать и хранить вместе с результатами запроса…
таким образом 1 процесс зависнет на 1 секунду выполняя запрос, а остальные в это время ещё получают актуальные(т.к. время жизни ещё не истекло) данные из memcached…
ааа вон о чём речь… ну тут я проблемы не вижу… это ж с какой надо скоростью мышкой кликать чтоб больше 8 картинок параллельно отправить на сервер… 30 штук на одной странице это всего лишь юзерфрендли, а не распараллеливание…
больше интересует как обойти политики безопасности в разных браузерах… например IE6-7 при 2х iframe'ах после 2 — 3го клика на сайте врубают блокировку и например при обращении к document.location.hash или document.location.protocol получаем ACCESS DENIED… В других браузерах тоже начинаются свои косяки… только в Firefox начиная с 4й версии боле-менее всё стало лояльно…
но больше меня интересует другое… все и вся пытаются всё сделать динамичным… здесь вы предлагаете аяксом картинки грузить, кто-то comet серверы изобретают, ну и т.д… Тестировалось ли это совместно? Какие результаты? Какие проблемы и пути их решения?
А что если на странице потребуется, ну допустим, 30 кнопочек «загрузить изображение»(это может быть в комментах, в футере, хедере, в левом столбце и т.д. и т.п.)… Реально такое может понадобиться…
V — объём базы
S — объём разделяемой памяти
K — средний объём данных на запрос
m — % базы в памяти (S*100)/V
d — % базы на диске V — m
R — средний объём данных считанных с диска на запрос (K*d)/100
— при R близком к 0 можно ставить max_connection = 256, но если в запросах нет длительных сортировок и агрегаций, либо число процессоров близко к max_connection
— при R 2кб и более нужно искать золотую середину. как правило чем меньше параллельных запросов, тем быстрее. всё зависит от кол-ва дисков
я со всем согласен, везде все параметры рассчитаны в зависимости от объёма памяти и др. аттрибутов, кроме max_connection… у вас max_connection зависит от кол-ва кроновых заданий, а нет от числа процессоров, скоростных характеристик дисковой подсистемы и т.д.
var table = [
{
'user_id': 12254,
'login': 'ddv'
},
{
'user_id': 12255,
'login': 'Fedcomp'
},
{
'user_id': 12256,
'login': 'zapimir'
}
];
в виртуальном скроллинге главное реализовать: выделить всё, выделить часть(которая больше видимой) и естественно копировать, быстрый переход на 1523 строку, возможность табличку раздвоить и видеть рядом две разные части таблицы, ну и другие фишки которые устранят недостатки постраничного просмотра
простота, гибкость, динамика — вот чего мы ждём…
вообще жду когда появится возможность в реальном времени разрешать конфликты, начал набирать в строчке, а СКВ сказала «Лена тут впрогала это», есть повод с Леной пообщаться а не поругаться :-)
# top
top — 16:21:41 up 7:54, 3 users, load average: 1.10, 0.96, 0.72
Tasks: 378 total, 3 running, 375 sleeping, 0 stopped, 0 zombie
CPU0: 13.0%us, 5.6%sy, 0.0%ni, 78.4%id, 3.0%wa, 0.0%hi, 0.0%si, 0.0%st
CPU1: 99.0%us, 0.7%sy, 0.0%ni, 0.3%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 2050156K total, 1953088K used, 97068K free, 12000K buffers
Swap: 4088536K total, 389832K used, 3698704K free, 410400K cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
10651 ddv 20 0 1218M 764M 12M R 98.9 38.2 7:58.69 java
4654 ddv 20 0 481M 20M 8672 S 6.0 1.0 0:33.50 konsole
3535 root 20 0 216M 22M 9300 S 5.0 1.1 9:00.56 X
4931 ddv 20 0 692M 38M 13M R 2.0 1.9 8:21.32 chromium-browse
11317 ddv 20 0 407M 13M 9160 S 2.0 0.7 5:32.79 krdc
4580 ddv 20 0 870M 56M 14M S 0.7 2.8 3:22.16 plasma-desktop
10655 ddv 20 0 1218M 764M 12M S 0.7 38.2 1:32.51 java
4914 ddv 20 0 1181M 73M 20M S 0.3 3.7 2:23.46 chromium-browse
4930 ddv 20 0 1181M 73M 20M S 0.3 3.7 0:56.74 SignalSender
10708 ddv 20 0 1218M 764M 12M S 0.3 38.2 178:22.92 java
15531 ddv 20 0 1131M 50M 27M S 0.3 2.5 1:54.96 chromium-browse
…
…
…
# strace -p 10651
Process 10651 attached — interrupt to quit
mprotect(0x7fd77d323000, 4096, PROT_READ) = 0
futex(0x41195ab4, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x41195ab0, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
futex(0x44bfa928, FUTEX_WAKE_PRIVATE, 1) = 1
mprotect(0x7fd77d322000, 4096, PROT_READ) = 0
mprotect(0x7fd77d322000, 4096, PROT_READ|PROT_WRITE) = 0
mprotect(0x7fd77d323000, 4096, PROT_NONE) = 0
mprotect(0x7fd77d323000, 4096, PROT_READ) = 0
futex(0x41195ab4, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x41195ab0, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
futex(0x44bfa928, FUTEX_WAKE_PRIVATE, 1) = 1
mprotect(0x7fd77d322000, 4096, PROT_READ) = 0
mprotect(0x7fd77d322000, 4096, PROT_READ|PROT_WRITE) = 0
mprotect(0x7fd77d323000, 4096, PROT_NONE) = 0
mprotect(0x7fd77d323000, 4096, PROT_READ) = 0
futex(0x41031fa4, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x41031fa0, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
futex(0x7fd771ef7328, FUTEX_WAKE_PRIVATE, 1) = 1
mprotect(0x7fd77d322000, 4096, PROT_READ) = 0
mprotect(0x7fd77d322000, 4096, PROT_READ|PROT_WRITE) = 0
futex(0x7fd7717cac04, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x7fd7717cac00, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
mprotect(0x7fd77d323000, 4096, PROT_NONE) = 0
mprotect(0x7fd77d323000, 4096, PROT_READ) = 0
futex(0x404f53a4, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x404f53a0, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
futex(0x404e5628, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x40f87774, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x40f87770, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
futex(0x7fd770e18228, FUTEX_WAKE_PRIVATE, 1) = 1
mprotect(0x7fd77d322000, 4096, PROT_READ) = 0
mprotect(0x7fd77d322000, 4096, PROT_READ|PROT_WRITE) = 0
mprotect(0x7fd77d323000, 4096, PROT_NONE) = 0
mprotect(0x7fd77d323000, 4096, PROT_READ) = 0
futex(0x41031fa4, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x41031fa0, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
futex(0x40f87774, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x40f87770, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
futex(0x7fd770e18228, FUTEX_WAKE_PRIVATE, 1) = 1
mprotect(0x7fd77d322000, 4096, PROT_READ) = 0
mprotect(0x7fd77d322000, 4096, PROT_READ|PROT_WRITE) = 0
mprotect(0x7fd77d323000, 4096, PROT_NONE) = 0
mprotect(0x7fd77d323000, 4096, PROT_READ) = 0
futex(0x41031fa4, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x41031fa0, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
futex(0x40f87774, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x40f87770, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
futex(0x7fd770e18228, FUTEX_WAKE_PRIVATE, 1) = 1
mprotect(0x7fd77d322000, 4096, PROT_READ) = 0
mprotect(0x7fd77d322000, 4096, PROT_READ|PROT_WRITE) = 0
mprotect(0x7fd77d323000, 4096, PROT_NONE) = 0
…
…
…
по сравнению с eclipse'ом конечно он летает, т.к. eclipse постоянно перебирает, перечитывает эти тысячи файлов php.
джава любит запускать всякие «сборщики мусора» и на таких объёмах он захлёбывается подвисая на пару часов в самый ответственный момент до которого пол дня пишешь регулярки в поиске чтобы найти и исправить бяку…
strace говорит что он роется в памяти… тока не понятно чего потерял.
2. данные есть, всегда берём из memcached и только один готовит новую порцию данных заранее… остальные никогда не ждут.
3. если ключ зависит от тега, а тег изменился — значит по новому ключу данных нет, а это 1й случай… (даже прогать ничё не надо)
PS: Коль уж зачем городить огород, зачем вообще браться за memcached, брать из базы да и всё… Да и вообще зачем прогать…
нужно просто начинать делать SQL запрос раньше времени устаревания на время выполнения запроса(среднее время выполнения запроса + запас)… т.к. в разное время суток(или по др. признаку) среднее время может меняться, то его хорошо бы всегда считать и хранить вместе с результатами запроса…
таким образом 1 процесс зависнет на 1 секунду выполняя запрос, а остальные в это время ещё получают актуальные(т.к. время жизни ещё не истекло) данные из memcached…
больше интересует как обойти политики безопасности в разных браузерах… например IE6-7 при 2х iframe'ах после 2 — 3го клика на сайте врубают блокировку и например при обращении к document.location.hash или document.location.protocol получаем ACCESS DENIED… В других браузерах тоже начинаются свои косяки… только в Firefox начиная с 4й версии боле-менее всё стало лояльно…
как автор статьи решал данные проблемы?
но больше меня интересует другое… все и вся пытаются всё сделать динамичным… здесь вы предлагаете аяксом картинки грузить, кто-то comet серверы изобретают, ну и т.д… Тестировалось ли это совместно? Какие результаты? Какие проблемы и пути их решения?
Работать будет?
S — объём разделяемой памяти
K — средний объём данных на запрос
m — % базы в памяти (S*100)/V
d — % базы на диске V — m
R — средний объём данных считанных с диска на запрос (K*d)/100
— при R близком к 0 можно ставить max_connection = 256, но если в запросах нет длительных сортировок и агрегаций, либо число процессоров близко к max_connection
— при R 2кб и более нужно искать золотую середину. как правило чем меньше параллельных запросов, тем быстрее. всё зависит от кол-ва дисков