![]() |
|
Модераторы: skyboy, MoLeX, Aliance, ksnk |
![]()
|
|
| Dima 2015 |
|
|||
|
Опытный ![]() ![]() Профиль Группа: Участник Сообщений: 287 Регистрация: 16.3.2008 Где: SPb Репутация: нет Всего: 2 |
Добрый день, друзья!
Решил написать в топик для профи т.к. вопрос по видимому очень специфический и связан с memcache, а там где мемкеш там сплошь профи, да Итак, возникла задача положить в memcache очень большой массив данных, порядка 120к элементов. При работе с таким массивом рнр-скрипт занимает порядка 100мб памяти. Так вот $memceche->set() просто не кладет такой массив в память, возвращает false, при попытке взять потом этот массив из кеша его там не оказывается и скрипт все время лезет в базу. Пробовал уменьшать размер массива чтобы понять на какой критической точке начинает отваливатся мемкеш, выяснилось, что это примерно 10к элементов и соответственно 7 мб памяти. При этом в пхп валятся ошибки Notice: MemcachePool::set() [memcachepool.set]: send of 32768 bytes failed with errno=11 Resource temporarily unavailable in /var/www/... валятся по несколько раз (видимо несколько раз пытается положить, и на какой-то раз таки ему это удается). Дело происходит на VDS, т.е. есть рут-доступ ко всему и вся. Поковырял конфиг мемкеша, дал ему 300+ Мб памяти, не помогло. Что посоветуете делать? У меня была мысль - может правильнее не огромный массив класть весь в один ключ мемкеша а каждый его элемент положить сделать для них уникальные ключи, может так правильней? --- --- --- Правила хорошего тона велят рассказать задачу целиком. Задача такая: есть некое приложение, которое занимается складированием фоток из групп ВКонтакте во внутреннюю базу данных. Из-за особенностей АПИ ВКонтакте происходит это порциями по 3-4 тыс. фоток, всего же фоток может быть порядка 100к. Далее возникла задача обновлений, т.е. сравнения того что сейчас в группе с тем, что сохранено в базе. Как я уже сказал, делается это порциями, т.е. на клиенте аяксом дергаются блоки фотографий и отправляются в пхп-скрипт для апдейта. Апдейтящему скрипту надо иметь все фотки из базы для сравнения, так вот хочется сложить их в кеш с ключем - id-фотки, ибо каждый раз тащить 100к из базы это убиться можно. Благодарю заранее за помощь. |
|||
|
||||
| solenko |
|
||||
|
Эксперт ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 1473 Регистрация: 15.1.2006 Где: Украина Репутация: 2 Всего: 67 |
Ну как бы не удивительно
Добавлено через 5 минут и 14 секунд
Не знаком с ВКонтактовским API, потому возник дополнительный вопрос: У фото есть атрибуты updated_at, created_at ? Зачем лопатить все, если можно забирать только обновленные (с момента последнего вызова)? -------------------- Ла-ла-ла-ла Заметьте, нет официального подтверждения, что это не просто четыре слога. |
||||
|
|||||
| Dima 2015 |
|
|||
|
Опытный ![]() ![]() Профиль Группа: Участник Сообщений: 287 Регистрация: 16.3.2008 Где: SPb Репутация: нет Всего: 2 |
solenko, большое спасибо за ссылку, зря не приучил себя к англоязычному интернету. Но конечно мысли печальные меня посетили... это чуть ли не первый мой опыт работы с мемкешем, я всегда про него такие дифирамбы читал, мол панацея от любой нагрузки. И тут на тебе, при первой же задаче фигвам, рекемпильте понимаешь ли...
По поводу даты апдейта, увы. Мысль здравая, но дату апдейта ВК-апи выдает только для альбомов целиком, для фоток не отдает. Если есть учетка можешь сам глянуть доку: http://vkontakte.ru/developers.php?o=-1&p=photos.get Я в принципе уже выкрутился - рассовываю как раз по альбомам, порциями по 500-600 фотографий. С костылями но будет работать, придется по 2м ключам доставать фотку - сначала альбом из мемкеша, потом фотку из альбома в ПХП массиве уже. Но лучше чем ничего. Еще попробовал распихать 100к фоток каждую по своему ключику в МС, ну это убийство. 1 большой массив положить это раз в 10 быстрее чем каждый из его элементов. |
|||
|
||||
![]()
|
| 0 Пользователей читают эту тему (0 Гостей и 0 Скрытых Пользователей) | |
| 0 Пользователей: | |
| « Предыдущая тема | PHP: Для профи | Следующая тема » |
|
|
По вопросам размещения рекламы пишите на vladimir(sobaka)vingrad.ru
Отказ от ответственности Powered by Invision Power Board(R) 1.3 © 2003 IPS, Inc. |