Логика системы продажи билетов
В настоящее время у нас есть система управления билетами, и, как и все системы продажи билетов, она должна распределять дела между агентами в циклическом порядке. Кроме того, в то же время агент может применять свою собственную логику фильтрации и работать со своей очередью.
Проблема,
- Таблица с билетами сейчас очень большая, охватывает более 10 миллионов строк.
- Один билет никогда не должен назначаться двум разным пользователям.
- Чтобы решить указанную выше проблему, это поток, который у нас есть,
- Запрос выбора запускается с критериями фильтрации и ограничением 0,1
- Затем строка, возвращаемая вышеуказанным запросом, выбирается на основе идентификатора и блокируется для обновления.
- Наконец, мы запускаем обновление, говоря пользователь X выбрал дело.
- Пока выполняется шаг 3, другой пользователь не может получить блокировку для того же случая, поэтому они запускают 3. запрос может быть несколько раз, чтобы получить следующий доступный случай.
- По количеству пользователей увеличение этого времени на шаге 4 идет все выше и выше.
Мы пытались выполнить выбор для обновления в запросе на самом шаге 4, но это замедляет весь запрос. Предполагая, что это связано с огромным количеством строк в запросе выбора.
Вопросы, Intel (R) Xeon (R) CPU E5-2650 0 @ 2,00 ГГц
Скорость 2000,050 МГц
кэш 20480 КБ
ОЗУ - 8 ГБ
Текущее использование памяти
total used free shared buffers cached
Mem: 8027740 7674716 353024 26052 928848 2992492
-/+ buffers/cache: 3753376 4274364
Swap: 1048572 210260 838312
Total: 9076312 7884976 1191336
Операционная система Linux
Размер базы данных Mysql - 3782 МБ
у нас более 40К SKU
У нас есть аналогичный сайт, работающий в США, с другое имя и время отклика сервера - это хорошо, но у него меньше трафика.
Может ли кто-нибудь помочь / предложить какое-нибудь решение для уменьшения времени отклика сервера?
Спасибо Праджош
Если вы еще этого не сделали, вам следует установить мониторинг, собрать данные и применить научный метод.
Вам нужно потратить время на то, чтобы посмотреть на свою систему, понять, как она работает, и соотнести это с тем, что происходит в вашем приложении.
Как происходит с вашими процессорами? Высока ли загрузка системы? Что вызывает это?
Есть ли у вас высокие значения I/O Wait Wait? Почему?
Ваши запросы оптимизированы? Есть ли у вас правильная индексация ? Проверяли ли вы длинные запросы ?
...
Вы пытались использовать не apache, а nginx? 
он также использует намного меньше оперативной памяти.
и может обрабатывать больше запросов.
Вероятно, PHP ограничен. В этом случае nginx не поможет. Вы можете использовать Varnish в сочетании с аддоном Turpentine , чтобы страницы каталога стали намного быстрее. Это снимает 90% вашей нагрузки. Однако оформление заказа по-прежнему будет медленным.