Приветствую!
Коллеги, подскажите пожалуйста, как решить проблему.

Имеется сервер (Intel Xeon W3530 2.8GHz (4 ядра * 2 HT), 24 GB RAM, SSD,
Ubuntu 12.04), на котором nginx 1.2.4 + PHP-FPM 5.3.10-1ubuntu3.4 через IP
сокет, static pool 400. Система оптимизированы под highload (TCP/IP стек,
системные лимиты).

Проблема в следующем: судя по тесту siege и просто нагрузке в часы пик
сервер может выполнять только до 300-350 запросов в секунду.
LoadAvg достигает 100.0, CPU user 85%, sys 15%, все ядра заняты
полностью. Т.е. после часов-пик на продакшене по статистике все app-машины
нагружены на 100%, образуется очередь на балансировщике.

Тестировал с помощью siege: 10 repeats с concurrency 500. Ничего не
отваливается, но Trans Rate всего лишь 350, и среднее время ответа
увеличивается до 700 ms.
Если делаю die() в начале index.php - то без проблем отрабатывает, и trans
rate 500, и время малое. Отсюда вывод - система и nginx оптимизированы и
могут справиться даже хотя бы с 500 rps.

Другой очевидный вывод - что-то не так с кодом приложения. Хорошо,
профилировал с помощью Xhprof - на ненагруженной системе нет видимых
проблем, за в среднем 200ms скрипт отрабатывает. Но когда сервер загружен,
очевидных проблемных функций тоже выявить нельзя - потому что в
каждом профайле они разные... В базу точно не упираемся, (ни в MongoDb, ни
в Redis) - смотрел по нагрузке на них, и NewRelic говорит что код отнимает
большее время.

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

Как побороть? Какие у вас RPS?

PS. Очень не хочется верить в такие комментарии :(
http://stackoverflow.com/a/6182020/927814

Так проблема есть или просто чешутся руки и siege?
Да и ответ вы сами написали — проблема в коде.

Я слабо себе представляю код, по которому xhprof каждый раз выводит разные
результаты.
Либо там лапша и миллион if-ов, либо вы лжёте.
Смотрите что больше и дольше всего делается, да оптимизируйте…

10 ноября 2012 г., 5:49 пользователь Roman Skvazh
<roman.skvazh@gmail.com>написал:

> Приветствую!
> Коллеги, подскажите пожалуйста, как решить проблему.
>
> Имеется сервер (Intel Xeon W3530 2.8GHz (4 ядра * 2 HT), 24 GB RAM, SSD,
> Ubuntu 12.04), на котором nginx 1.2.4 + PHP-FPM 5.3.10-1ubuntu3.4 через IP
> сокет, static pool 400. Система оптимизированы под highload (TCP/IP стек,
> системные лимиты).
>
> Проблема в следующем: судя по тесту siege и просто нагрузке в часы пик
> сервер может выполнять только до 300-350 запросов в секунду.
> LoadAvg достигает 100.0, CPU user 85%, sys 15%, все ядра заняты
> полностью. Т.е. после часов-пик на продакшене по статистике все app-машины
> нагружены на 100%, образуется очередь на балансировщике.
>
> Тестировал с помощью siege: 10 repeats с concurrency 500. Ничего не
> отваливается, но Trans Rate всего лишь 350, и среднее время ответа
> увеличивается до 700 ms.
> Если делаю die() в начале index.php - то без проблем отрабатывает, и trans
> rate 500, и время малое. Отсюда вывод - система и nginx оптимизированы и
> могут справиться даже хотя бы с 500 rps.
>
> Другой очевидный вывод - что-то не так с кодом приложения. Хорошо,
> профилировал с помощью Xhprof - на ненагруженной системе нет видимых
> проблем, за в среднем 200ms скрипт отрабатывает. Но когда сервер загружен,
> очевидных проблемных функций тоже выявить нельзя - потому что в
> каждом профайле они разные... В базу точно не упираемся, (ни в MongoDb, ни
> в Redis) - смотрел по нагрузке на них, и NewRelic говорит что код отнимает
> большее время.
>
> Пробовал и кол-во воркеров увеличивать, и уменьшать - результат не
> меняется.
> Такая же ситуация на остальных пяти идентиных production-серверах.
>
> Как побороть? Какие у вас RPS?
>
> PS. Очень не хочется верить в такие комментарии :(
> http://stackoverflow.com/a/6182020/927814
>

Я для таких задач использую pinba. Ставится на все сервера продакшна.
Паттерн использования такой: сначала просто смотреть на время выполнения
отдельных скриптов (avg, max), определить проблемный скрипт, в коде
проблемного скрипта вешать пинбовские тэги. Дальше мониторить куски кода,
непосредственно по тегам. Таким образом можно определить узкое место, а там
уже профайлить.
10.11.2012 3:01 пользователь "Anatoly Pashin" <b1rdexadm@gmail.com> написал:

> Так проблема есть или просто чешутся руки и siege?
> Да и ответ вы сами написали -- проблема в коде.
>
> Я слабо себе представляю код, по которому xhprof каждый раз выводит разные
> результаты.
> Либо там лапша и миллион if-ов, либо вы лжёте.
> Смотрите что больше и дольше всего делается, да оптимизируйте...
>
> 10 ноября 2012 г., 5:49 пользователь Roman Skvazh <roman.skvazh@gmail.com>написал:
>
>> Приветствую!
>> Коллеги, подскажите пожалуйста, как решить проблему.
>>
>> Имеется сервер (Intel Xeon W3530 2.8GHz (4 ядра * 2 HT), 24 GB RAM, SSD,
>> Ubuntu 12.04), на котором nginx 1.2.4 + PHP-FPM 5.3.10-1ubuntu3.4 через IP
>> сокет, static pool 400. Система оптимизированы под highload (TCP/IP стек,
>> системные лимиты).
>>
>> Проблема в следующем: судя по тесту siege и просто нагрузке в часы пик
>> сервер может выполнять только до 300-350 запросов в секунду.
>> LoadAvg достигает 100.0, CPU user 85%, sys 15%, все ядра заняты
>> полностью. Т.е. после часов-пик на продакшене по статистике все app-машины
>> нагружены на 100%, образуется очередь на балансировщике.
>>
>> Тестировал с помощью siege: 10 repeats с concurrency 500. Ничего не
>> отваливается, но Trans Rate всего лишь 350, и среднее время ответа
>> увеличивается до 700 ms.
>> Если делаю die() в начале index.php - то без проблем отрабатывает, и
>> trans rate 500, и время малое. Отсюда вывод - система и nginx
>> оптимизированы и могут справиться даже хотя бы с 500 rps.
>>
>> Другой очевидный вывод - что-то не так с кодом приложения. Хорошо,
>> профилировал с помощью Xhprof - на ненагруженной системе нет видимых
>> проблем, за в среднем 200ms скрипт отрабатывает. Но когда сервер загружен,
>> очевидных проблемных функций тоже выявить нельзя - потому что в
>> каждом профайле они разные... В базу точно не упираемся, (ни в MongoDb, ни
>> в Redis) - смотрел по нагрузке на них, и NewRelic говорит что код отнимает
>> большее время.
>>
>> Пробовал и кол-во воркеров увеличивать, и уменьшать - результат не
>> меняется.
>> Такая же ситуация на остальных пяти идентиных production-серверах.
>>
>> Как побороть? Какие у вас RPS?
>>
>> PS. Очень не хочется верить в такие комментарии :(
>> http://stackoverflow.com/a/6182020/927814
>>
>
>

1) 200мс это очень много, куда вы столько тратите?
2) статик пул 400 это зачем? 8 ядер не смогут переживать 400 процессов и вы
погибнете на context-switching-е. попробуйте dynamic
3) 350рпс*5 серверов это 1750рпс. очень интересно что это за проект с
такими цифрами, у нас к примеру при _в несколько раз_ большем рпс - в
_несколько десятков раз_ больше серверов. точно ли нельзя избавиться от
хождения в бекенд в некоторых местах?

на самом деле это все советы высосанные из пальца. если ваш код держит 350
рпс, вы можете либо написать код лучше, либо добавить серверов, никакого
чуда ждать не стоит:)

On Friday, November 9, 2012 10:49:30 PM UTC+4, Roman Skvazh wrote:
>
> Приветствую!
> Коллеги, подскажите пожалуйста, как решить проблему.
>
> Имеется сервер (Intel Xeon W3530 2.8GHz (4 ядра * 2 HT), 24 GB RAM, SSD,
> Ubuntu 12.04), на котором nginx 1.2.4 + PHP-FPM 5.3.10-1ubuntu3.4 через IP
> сокет, static pool 400. Система оптимизированы под highload (TCP/IP стек,
> системные лимиты).
>
> Проблема в следующем: судя по тесту siege и просто нагрузке в часы пик
> сервер может выполнять только до 300-350 запросов в секунду.
> LoadAvg достигает 100.0, CPU user 85%, sys 15%, все ядра заняты
> полностью. Т.е. после часов-пик на продакшене по статистике все app-машины
> нагружены на 100%, образуется очередь на балансировщике.
>
> Тестировал с помощью siege: 10 repeats с concurrency 500. Ничего не
> отваливается, но Trans Rate всего лишь 350, и среднее время ответа
> увеличивается до 700 ms.
> Если делаю die() в начале index.php - то без проблем отрабатывает, и trans
> rate 500, и время малое. Отсюда вывод - система и nginx оптимизированы и
> могут справиться даже хотя бы с 500 rps.
>
> Другой очевидный вывод - что-то не так с кодом приложения. Хорошо,
> профилировал с помощью Xhprof - на ненагруженной системе нет видимых
> проблем, за в среднем 200ms скрипт отрабатывает. Но когда сервер загружен,
> очевидных проблемных функций тоже выявить нельзя - потому что в
> каждом профайле они разные... В базу точно не упираемся, (ни в MongoDb, ни
> в Redis) - смотрел по нагрузке на них, и NewRelic говорит что код отнимает
> большее время.
>
> Пробовал и кол-во воркеров увеличивать, и уменьшать - результат не
> меняется.
> Такая же ситуация на остальных пяти идентиных production-серверах.
>
> Как побороть? Какие у вас RPS?
>
> PS. Очень не хочется верить в такие комментарии :(
> http://stackoverflow.com/a/6182020/927814
>

1) Немного ошибся, в спокойное время ответ 20мс, при средней нагрузке
30-40мс, 200мс и более начинается в часы пик. Вот график среднего времени
выполнения php-скрипта

https://lh4.googleusercontent.com/-asN8V7O8QjQ/UJ6H1fmAo8I/AAAAAAAAALw/dI5XUNXvb3I/s1600/Pasted+Image+10.11.12%2C+20%3A58.png
2) Ну а что dynamic даст если он создаст те же самые 400 воркеров и тот же
context-switching будет. Если только просто уменьшить воркеров...
3) 350 * 6 = 2100. API бэкенд для мобильных клиентов. Точно, все запросы
уникальные. А сколько у вас один сервер держит rps? Просто может быть это
нормально наши 350 и реально дешевле брать еще серверов, нежели
переписывать всю систему...

суббота, 10 ноября 2012 г., 3:20:04 UTC+4 пользователь nikitosiusis написал:
>
> 1) 200мс это очень много, куда вы столько тратите?
> 2) статик пул 400 это зачем? 8 ядер не смогут переживать 400 процессов и
> вы погибнете на context-switching-е. попробуйте dynamic
> 3) 350рпс*5 серверов это 1750рпс. очень интересно что это за проект с
> такими цифрами, у нас к примеру при _в несколько раз_ большем рпс - в
> _несколько десятков раз_ больше серверов. точно ли нельзя избавиться от
> хождения в бекенд в некоторых местах?
>
> на самом деле это все советы высосанные из пальца. если ваш код держит 350
> рпс, вы можете либо написать код лучше, либо добавить серверов, никакого
> чуда ждать не стоит:)
>
> On Friday, November 9, 2012 10:49:30 PM UTC+4, Roman Skvazh wrote:
>>
>> Приветствую!
>> Коллеги, подскажите пожалуйста, как решить проблему.
>>
>> Имеется сервер (Intel Xeon W3530 2.8GHz (4 ядра * 2 HT), 24 GB RAM, SSD,
>> Ubuntu 12.04), на котором nginx 1.2.4 + PHP-FPM 5.3.10-1ubuntu3.4 через IP
>> сокет, static pool 400. Система оптимизированы под highload (TCP/IP стек,
>> системные лимиты).
>>
>> Проблема в следующем: судя по тесту siege и просто нагрузке в часы пик
>> сервер может выполнять только до 300-350 запросов в секунду.
>> LoadAvg достигает 100.0, CPU user 85%, sys 15%, все ядра заняты
>> полностью. Т.е. после часов-пик на продакшене по статистике все app-машины
>> нагружены на 100%, образуется очередь на балансировщике.
>>
>> Тестировал с помощью siege: 10 repeats с concurrency 500. Ничего не
>> отваливается, но Trans Rate всего лишь 350, и среднее время ответа
>> увеличивается до 700 ms.
>> Если делаю die() в начале index.php - то без проблем отрабатывает, и
>> trans rate 500, и время малое. Отсюда вывод - система и nginx
>> оптимизированы и могут справиться даже хотя бы с 500 rps.
>>
>> Другой очевидный вывод - что-то не так с кодом приложения. Хорошо,
>> профилировал с помощью Xhprof - на ненагруженной системе нет видимых
>> проблем, за в среднем 200ms скрипт отрабатывает. Но когда сервер загружен,
>> очевидных проблемных функций тоже выявить нельзя - потому что в
>> каждом профайле они разные... В базу точно не упираемся, (ни в MongoDb, ни
>> в Redis) - смотрел по нагрузке на них, и NewRelic говорит что код отнимает
>> большее время.
>>
>> Пробовал и кол-во воркеров увеличивать, и уменьшать - результат не
>> меняется.
>> Такая же ситуация на остальных пяти идентиных production-серверах.
>>
>> Как побороть? Какие у вас RPS?
>>
>> PS. Очень не хочется верить в такие комментарии :(
>> http://stackoverflow.com/a/6182020/927814
>>
>

Проблема есть. Интересует, сколько все-таки может делать PHP-FPM под
реальными нагрузками.
А xhprof, я думаю, элементарно может давать разные результаты на один и тот
же запрос, если процессор подыхает при выполнении этих параллельных
запросов.

суббота, 10 ноября 2012 г., 5:01:22 UTC+4 пользователь B1rdEX написал:
>
> Так проблема есть или просто чешутся руки и siege?
> Да и ответ вы сами написали — проблема в коде.
>
> Я слабо себе представляю код, по которому xhprof каждый раз выводит разные
> результаты.
> Либо там лапша и миллион if-ов, либо вы лжёте.
> Смотрите что больше и дольше всего делается, да оптимизируйте…
>
> 10 ноября 2012 г., 5:49 пользователь Roman Skvazh <roman....@gmail.com<javascript:>
> > написал:
>
>> Приветствую!
>> Коллеги, подскажите пожалуйста, как решить проблему.
>>
>> Имеется сервер (Intel Xeon W3530 2.8GHz (4 ядра * 2 HT), 24 GB RAM, SSD,
>> Ubuntu 12.04), на котором nginx 1.2.4 + PHP-FPM 5.3.10-1ubuntu3.4 через IP
>> сокет, static pool 400. Система оптимизированы под highload (TCP/IP стек,
>> системные лимиты).
>>
>> Проблема в следующем: судя по тесту siege и просто нагрузке в часы пик
>> сервер может выполнять только до 300-350 запросов в секунду.
>> LoadAvg достигает 100.0, CPU user 85%, sys 15%, все ядра заняты
>> полностью. Т.е. после часов-пик на продакшене по статистике все app-машины
>> нагружены на 100%, образуется очередь на балансировщике.
>>
>> Тестировал с помощью siege: 10 repeats с concurrency 500. Ничего не
>> отваливается, но Trans Rate всего лишь 350, и среднее время ответа
>> увеличивается до 700 ms.
>> Если делаю die() в начале index.php - то без проблем отрабатывает, и
>> trans rate 500, и время малое. Отсюда вывод - система и nginx
>> оптимизированы и могут справиться даже хотя бы с 500 rps.
>>
>> Другой очевидный вывод - что-то не так с кодом приложения. Хорошо,
>> профилировал с помощью Xhprof - на ненагруженной системе нет видимых
>> проблем, за в среднем 200ms скрипт отрабатывает. Но когда сервер загружен,
>> очевидных проблемных функций тоже выявить нельзя - потому что в
>> каждом профайле они разные... В базу точно не упираемся, (ни в MongoDb, ни
>> в Redis) - смотрел по нагрузке на них, и NewRelic говорит что код отнимает
>> большее время.
>>
>> Пробовал и кол-во воркеров увеличивать, и уменьшать - результат не
>> меняется.
>> Такая же ситуация на остальных пяти идентиных production-серверах.
>>
>> Как побороть? Какие у вас RPS?
>>
>> PS. Очень не хочется верить в такие комментарии :(
>> http://stackoverflow.com/a/6182020/927814
>>
>
>

Спасибо, смотрел. Наверное, придем к этому, пока пробуем New Relic.

суббота, 10 ноября 2012 г., 12:44:32 UTC+4 пользователь Дмитрий Меньшиков
написал:
>
> Я для таких задач использую pinba. Ставится на все сервера продакшна.
> Паттерн использования такой: сначала просто смотреть на время выполнения
> отдельных скриптов (avg, max), определить проблемный скрипт, в коде
> проблемного скрипта вешать пинбовские тэги. Дальше мониторить куски кода,
> непосредственно по тегам. Таким образом можно определить узкое место, а там
> уже профайлить.
> 10.11.2012 3:01 пользователь "Anatoly Pashin" <b1rd...@gmail.com<javascript:>>
> написал:
>
>> Так проблема есть или просто чешутся руки и siege?
>> Да и ответ вы сами написали — проблема в коде.
>>
>> Я слабо себе представляю код, по которому xhprof каждый раз выводит
>> разные результаты.
>> Либо там лапша и миллион if-ов, либо вы лжёте.
>> Смотрите что больше и дольше всего делается, да оптимизируйте…
>>
>> 10 ноября 2012 г., 5:49 пользователь Roman Skvazh <roman....@gmail.com<javascript:>
>> > написал:
>>
>>> Приветствую!
>>> Коллеги, подскажите пожалуйста, как решить проблему.
>>>
>>> Имеется сервер (Intel Xeon W3530 2.8GHz (4 ядра * 2 HT), 24 GB RAM, SSD,
>>> Ubuntu 12.04), на котором nginx 1.2.4 + PHP-FPM 5.3.10-1ubuntu3.4 через IP
>>> сокет, static pool 400. Система оптимизированы под highload (TCP/IP стек,
>>> системные лимиты).
>>>
>>> Проблема в следующем: судя по тесту siege и просто нагрузке в часы пик
>>> сервер может выполнять только до 300-350 запросов в секунду.
>>> LoadAvg достигает 100.0, CPU user 85%, sys 15%, все ядра заняты
>>> полностью. Т.е. после часов-пик на продакшене по статистике все app-машины
>>> нагружены на 100%, образуется очередь на балансировщике.
>>>
>>> Тестировал с помощью siege: 10 repeats с concurrency 500. Ничего не
>>> отваливается, но Trans Rate всего лишь 350, и среднее время ответа
>>> увеличивается до 700 ms.
>>> Если делаю die() в начале index.php - то без проблем отрабатывает, и
>>> trans rate 500, и время малое. Отсюда вывод - система и nginx
>>> оптимизированы и могут справиться даже хотя бы с 500 rps.
>>>
>>> Другой очевидный вывод - что-то не так с кодом приложения. Хорошо,
>>> профилировал с помощью Xhprof - на ненагруженной системе нет видимых
>>> проблем, за в среднем 200ms скрипт отрабатывает. Но когда сервер загружен,
>>> очевидных проблемных функций тоже выявить нельзя - потому что в
>>> каждом профайле они разные... В базу точно не упираемся, (ни в MongoDb, ни
>>> в Redis) - смотрел по нагрузке на них, и NewRelic говорит что код отнимает
>>> большее время.
>>>
>>> Пробовал и кол-во воркеров увеличивать, и уменьшать - результат не
>>> меняется.
>>> Такая же ситуация на остальных пяти идентиных production-серверах.
>>>
>>> Как побороть? Какие у вас RPS?
>>>
>>> PS. Очень не хочется верить в такие комментарии :(
>>> http://stackoverflow.com/a/6182020/927814
>>>
>>
>>

On 2012-11-10 21:15, Roman Skvazh wrote:
> Проблема есть. Интересует, сколько все-таки может делать PHP-FPM под реальными нагрузками.

Вы же сами говорите, что проблема не в FPM и даже не в связке nginx-FPM.
Очевидно, что со скриптом <?php echo "hello world";?> можно держать over 9000 rps.
Но в реальной жизни ведь всё чуть сложнее.

Веб-машина во что упирается? Память? CPU? Диск? Сеть? Есть статистика по этим параметрам?
Какие внешние ресурсы используются? Базы? Кэши? Смотрели что там происходит во время тормозов?

В общем случае, как вам уже сказали, проще всего - начать с разделения кода на какие функциональные куски и их замерять по-отдельности.
Разделяй и властвуй, ткскзть.

--
Wbr,
Antony Dovgal
---
http://pinba.org - realtime profiling for PHP

app-сервера во время нагрузок в час-пик упираются в CPU. LA под 40-100.
Используется MongoDb и Redis, плюс совсем немного внешних REST API сервисов
(очень малый процент от всех запросов). Конечно смотрел, я всё описал в
вопросе, и по поводу отчетов Xhprof. Т.е. узкого места в коде найти не
можем, и просто напрягает что в общем не слабые сервера могут делать только
350 rps.

Будем пробовать pinba.

воскресенье, 11 ноября 2012 г., 19:57:56 UTC+4 пользователь tony2001
написал:
>
> On 2012-11-10 21:15, Roman Skvazh wrote:
> > Проблема есть. Интересует, сколько все-таки может делать PHP-FPM под
> реальными нагрузками.
>
> Вы же сами говорите, что проблема не в FPM и даже не в связке nginx-FPM.
> Очевидно, что со скриптом <?php echo "hello world";?> можно держать over
> 9000 rps.
> Но в реальной жизни ведь всё чуть сложнее.
>
> Веб-машина во что упирается? Память? CPU? Диск? Сеть? Есть статистика по
> этим параметрам?
> Какие внешние ресурсы используются? Базы? Кэши? Смотрели что там
> происходит во время тормозов?
>
> В общем случае, как вам уже сказали, проще всего - начать с разделения
> кода на какие функциональные куски и их замерять по-отдельности.
> Разделяй и властвуй, ткскзть.
>
> --
> Wbr,
> Antony Dovgal
> ---
> http://pinba.org - realtime profiling for PHP
>

350 rps - в принципе, не так мало
грубо на 1 физическое ядро у вас ~100 запросов в пике, это значит 10
милисекунд процессорных на запрос
если это честный веб со сборкой страниц и тд - это более-мене
нормальный результат
докупайте серваки

--

wbr,
Alexey Rybak
Badoo Development (badoo.com)

Ну не совсем честный веб - API для iOS и Android проекта.
Но в общем по советам наметили куда дальше двигаться - будем пробовать
Pinba, и пока поставим серваков еще :)

PS. Алексей, приятно удивлён Вашему ответу. Вы один из самых популярных
highload-инженеров в нашей стране, который несет это искусство в массы :)
Помню давно-давно Вы мне присылали исходники pinba после вашего доклада, но
тогда жаль не понадобилась :(
Кстати, имеет ли смысл попробовать простейшие счетчики по времени
выполнения или просто по кол-ву вызовов скриптов писать в redis? Просто
чтобы не разворачивать pinba.


воскресенье, 11 ноября 2012 г., 21:45:31 UTC+4 пользователь Alexey A. Rybak
написал:
>
> 350 rps - в принципе, не так мало
> грубо на 1 физическое ядро у вас ~100 запросов в пике, это значит 10
> милисекунд процессорных на запрос
> если это честный веб со сборкой страниц и тд - это более-мене
> нормальный результат
> докупайте серваки
>
> --
>
> wbr,
> Alexey Rybak
> Badoo Development (badoo.com)
>
>

> Кстати, имеет ли смысл попробовать простейшие счетчики по времени выполнения
> или просто по кол-ву вызовов скриптов писать в redis? Просто чтобы не
> разворачивать pinba.

имеет, но "разворачивать" пинбу довольно быстро + сможете обмерить
аккуратно любые таймеры.
поскольку вы упираетесь в цру, то вам придется ставить хитрые таймеры
на разные стадии инициализации приложения.
фактически на ощум искать, что отжирает цпу.
io проблемы искать в этом смысле проще.

--

wbr,
Alexey Rybak
Badoo Development (badoo.com)