Можно частично избежать негативного влияния большого объёма javascript, сделав подключение файлов внизу страницы (перед тегом "</body>").
На самом деле, при должном умении в большинстве случаев, можно с помощью минимального набора исправлений (то есть без смены БД или глобального рефакторинга) добиться значительного прироста производительности, это я по своему опыту знаю :)
А также, очень важно не заниматься преждевременной оптимизацией, то есть, нужно составить некоторые объективные технические условия работы и стремится их выполнить (например, время отклика - 0.1с при нагрузке 500 запросов в секунду). Оптимизация без таких условий может оказаться напрасной тратой сил (или денег заказчика или своих денег, если бюджет проекта фиксированный), поэтому не переусердствуйте с оптимизацией :)
Лично я занимался оптимизацией уже после сдачи проектов (делал несколько высоконагруженных систем), когда уже отдавал в работу и было видно, что под нагрузкой они начинают работать медленно...
Если вы решили сменить БД, то могу посоветовать смотреть в сторону MSSql или Oracle (в Oracle точно есть хранение в памяти + журналирование, а также работа с несколькими дисками), но, ничего конкретного сказать не могу, так как сам мало работал с этими БД. Да и стоят они дороговато для рядовых проектов :) И ещё: следует предупредить, что в рабочих проектах (особенно под такой нагрузкой) менять БД очень сложно и чревато большими проблемами, я бы, на вашем месте, продолжал работать с той БД, которая есть, используя дополнительные средства.
SAG, в memcached есть атомарные операции (сложить, вычесть), этого достаточно для снятия опасности записи одной и той же ячейки несколькими потоками одновременно (при правильном программировании, разумеется). Про наличие атомарных операций в APC не знаю.
Пуховой, смысл в том, что, в общем случае, запись:
$abal = $db->fetchOne( 'SELECT abal FROM `user` WHERE `name` = "' . $name. '" LIMIT 1 FOR UPDATE' ); $abal = $abal - 0.001; $db->query( 'UPDATE `owls`.`user` SET `abal` = "' . $abal . '" WHERE `user`.`name` = "' . $name. '" LIMIT 1' );
Эквивалентна записи:
$db->query( 'UPDATE `owls`.`user` SET `abal` = `abal` - 0.001 WHERE `user`.`name` = "' . $name. '" LIMIT 1' );
Но в частном случае всё может отличаться. Чтобы сказать конкретно, нужно увидеть всю картину (весь код).
Shagabutdinov добавил 09.08.2011 в 10:14
Почему-то сразу подумалось о кэширующем буфере, который накапливает изменения, а потом выдаёт один sql-запрос. То есть, приложение сохраняет изменения где-то в быстрой памяти (вроде memcache), а потом списывает не по одной копейке, а сразу по рублю. Это бы сняло нагрузку с БД.
Если говорить о снятии нагрузки с сервера в целом, то я бы посоветовал следующее:
1. Системы кэширования оп-кода (вроде APC)
2. Более быстрый сервер (например, nginx)
3. Кэширование
4. Оптимизация алгоритов
5. Переписывание узких мест системы на что-нибудь более быстрое, чем php (до этого пункта редко доходят)
Вообще, про оптимизацию приложений много написано, нужно просто поискать :)
Топикстартер, для опытного php-ера странно задавать такие вопросы :)
Google помог и на этот раз
Не рассматривали следующий вариант?
UPDATE `owls`.`user` SET `abal` = `abal` - 0.01 WHERE `user`.`name` = '$name' LIMIT 1;
Так будет быстрее работать при большом количестве потоков (потоки будут блокироваться на меньшее время).
Если хостинг на линуксе, можно выставить специальные права на этот файл (запретить запись файла), тогда, скорее всего, DLE не сможет затереть ваши правки.
Shagabutdinov добавил 04.08.2011 в 08:17
И не забудьте разрешить запись файла, когда сами будете его редактировать :)
За что же вы так не любите jQuery? :)
Тс, смотря с какой целью будете писать CMS. Если с целью получения опыта, то надо обязательно делать. Если интересует доход с CMS (продажи или с целью сделать много сайтов на ней), то, на мой взгляд, лучше воспользоваться готовыми решениями.
По своему опыту могу сказать, что, чтобы создать качественный продукт, нужно потратить много времени и совершить много ошибок. Если вас это не пугает, тогда за дело :)
С DLE тесно не работал, но я думаю, что смогу разобраться в ней при необходимости.
