- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
$username = $vbulletin->userinfo['username'];
.
.
.
.
.
.
$nickname = $username;
$nickname = mysql_real_escape_string($nickname);-
PHP / Говнокод #7574
+163
PHP, булка, Эстонский код.
Запостил:
swat54,
17 Августа 2011
Follow us!
А что плохого в том, чтобы складывать всё в БД? В java-мире это скорее норма, нежели исключение:
1. Легче контролировать доступ, не нужно возиться с хранением в базе путей.
2. Легче делать бэкап всех данных.
3. Легче этот бэкап потом разворачивать.
В контексте наличия вещей наподобие Apache Cassandra проблемы производительности постепенно уходят в прошлое.
и нанять кого-нибудь, кто разбирается в HTTP,
чтобы код, отдающий юзерпики написал
Хотя, да, на маленьком форуме таблица с картинками ВНЕЗАПНО разрослась до трёх гигабайт, делать ей backup было весьма занятно. А если накернилось что, при попытке вылечить таблицу можно было провести немало увеселительных минут.
Я говорю о том, что сам движок буллетина оптимизирован достаточно, чтобы держать сильные нагрузки, - за это можно платить. Именно из-за хорошей оптимизации движка буллетина, на нем сидят http://forums.digitalpoint.com/, наш http://forum.searchengines.ru/ и еще много высоконагруженных форумов.
щито щито? см. говнокод
А еще этот код самое прямое доказательство неоптимизированности движка. Из-за этого кода производительность упала в 10 раз - не иначе.
Хочу объяснений, если не затруднительно, конечно.
Думать надо не о том, будет ли нужен MySQL (нет сомнений, что он еще очень долго будет жить невзирая на развитие NoSQL/NewSQL), а о том, чтобы дать свободу выбора (предложить альтернативу выбора сервера БД), но это уже совсем другая история.
Вопросы, как нетрудно догадаться, риторические.
"PHP сценарий, оптимизированный под высокую нагрузку" -- это АДСКАЯ РЖАКА :))))
Пора бы уже вырасти и понять, что в высокой нагрузке важны инженерные решения окружения, а не гейтвей сценариев, будь это Perl, C++ или PHP. Сценарий будет влиять на нагрузках относительно небольших, но тогда и нет смысла его оптимизировать, нагрузка же невелика. А когда нагрузка большая, то сценарий будет проводить до 80% времени в ожидании ответов иных компонент: сервер, база данных, операционная система. И нет смысла оптимизировать то, где поток проводит 20% времени.
По этой причине, какое бы, извините, говно не было бы написано в PHP, при правильном инженерном проектировании системы её можно растянуть на Jaguar и в секунду обслуживать всех жителей Земли.
Можно поинтересоваться, с какими нагрузками работала спроектированная вами система (или поддерживаемая вами на крайний случай)?
"при правильном инженерном проектировании системы её можно растянуть на Jaguar и в секунду обслуживать всех жителей Земли"
Никто никогда ни в коем случае не проектирует систему "правильно" - она всегда "дотачивается" под нагрузки. Twitter и Facebook - самые яркие примеры.
К стати, я рад, что вы знаете название самого мощного ЭВМ в мире :-)