Hali,
A véleményetekre vagyok kiváncsi, hogy milyen hardvert ajánlotok a következő paraméterekkel rendelkező webáruház alá?
Jelenleg is működik, de kicsit köhög és szerintem a vas nem bírja, az hogy mi van most alatta azt nem árulták el nekem. LOLA következő infóm van róla:
Az hogy majd frissíteni kell a rendszert, most nem ide tartozik.
Oprendszer: Archlinux 3.0.27 kernel
Szolgálatások: LAMP (Apache 2.2.22, PHP 5.3.10, MySQL 5.5.23)
Apache virtualhost: 2 (http és https)
Server Version: Apache/2.2.22 (Unix) mod_ssl/2.2.22 OpenSSL/1.0.1a DAV/2 PHP/5.3.10 with Suhosin-Patch
Server Built: Feb 8 2012 10:27:28
Server loaded APR Version: 1.4.5
Compiled with APR Version: 1.4.5
Server loaded APU Version: 1.4.1
Compiled with APU Version: 1.4.1
Timeouts: connection: 60 keep-alive: 5
MPM Name: Prefork
MPM Information: Max Daemons: 250 Threaded: no Forked: yes
Server Architecture: 64-bit
Server Root: /etc/httpd
Config File: /etc/httpd/conf/httpd.conf
Server Built With:
-D APACHE_MPM_DIR="server/mpm/prefork"
-D APR_HAS_SENDFILE
-D APR_HAS_MMAP
-D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
-D APR_USE_SYSVSEM_SERIALIZE
-D APR_HAS_OTHER_CHILD
-D AP_HAVE_RELIABLE_PIPED_LOGS
-D HTTPD_ROOT="/etc/httpd"
-D SUEXEC_BIN="/usr/sbin/suexec"
-D DEFAULT_ERRORLOG="logs/error_log"
-D AP_TYPES_CONFIG_FILE="conf/mime.types"
-D SERVER_CONFIG_FILE="conf/httpd.conf"
php.ini
session.auto_start = 1
short_open_tag = On
error_reporting = E_ALL & ~E_NOTICE
max_execution_time = 60
max_input_time = 120
memory_limit = 300M
max_input_vars = 2000
register_globals = Off
magic_quotes_gpc = Off
register_long_arrays = Off
register_argc_argv = Off
display_errors = Off
post_max_size = 128M
allow_url_include = On
file_uploads = On
upload_tmp_dir = /tmp
upload_max_filesize = 128M
max_file_uploads = 50
extension = bcmath.so
extension = bz2.so
extension = gd.so
extension = iconv.so
extension = imap.so
extension = mcrypt.so
extension = mssql.so
extension = mysqli.so
extension = mysql.so
extension = openssl.so
extension = pdo_mysql.so
extension = posix.so
extension = soap.so
extension = tidy.so
extension = xmlrpc.so
extension = xsl.so
extension = zip.so
my.cnf
bind-address = 0.0.0.0
port = 3306
socket = /var/run/mysqld/mysqld.sock
pid-file = /var/run/mysqld/mysqld.pid
log-error = /var/log/mysql/mysqld.err
basedir = /usr
tmpdir = /mnt/database/tmp
datadir = /mnt/database/mysql
skip-external-locking
back_log = 50
max_connections = 200
max_connect_errors = 100000
wait_timeout = 7200
interactive_timeout = 7200
connect_timeout = 10
net_buffer_length = 16384
table_open_cache = 200000
table_definition_cache = 200000
max_seeks_for_key = 1000
group_concat_max_len = 1024
max_allowed_packet = 256M
binlog_cache_size = 1M
read_buffer_size = 1M
join_buffer_size = 1M
read_rnd_buffer_size = 2M
sort_buffer_size = 4M
thread_cache_size = 1024
thread_concurrency = 16
concurrent_insert = 2
query_cache_type = 1
query_cache_size = 256M
query_cache_limit = 8M
query_prealloc_size = 262144
query_alloc_block_size = 65536
range_alloc_block_size = 4096
transaction_alloc_block_size = 8192
transaction_prealloc_size = 4096
ft_min_word_len = 4
default-storage-engine = MyISAM
thread_stack = 256K
tmp_table_size = 512M
max_heap_table_size = 512M
open_files_limit = 8192
key_buffer_size = 24G
bulk_insert_buffer_size = 8M
myisam_sort_buffer_size = 1G
myisam_repair_threads = 1
myisam_recover
skip-innodb
Átlagos napi látogatók száma: 9000
Nincs sehol too many connection, nincsenek hibák, csak néha baromi lassú. MySQL-ben kb. 3000 tábla van, külön fájlokban, a legnagyobb 30GB, kb. 10 tábla 1-10GB közötti, a többi 1GB alatti, összesen 130GB.
Néha a query/sec:30 ezer is lehet, de átlagban 12 ezer közül van.
Néhány MySQl adat, igaz csak 2 órás üzemidő.
Questions since startup: 49,825,059
ø per hour: 25,954,307
ø per minute: 432,572
ø per second: 7,210
Traffic ø per hour
Received: 20.3 GiB 10.6 GiB
Sent: 107.9 GiB 56.2 GiB
Total: 128.2 GiB 66.8 GiB
Connections: ø per hour %
max. concurrent connections 33 --- ---
Failed attempts 1 0.52 <0.01%
Aborted 0 0 0%
Total 299 k 155.76 k 100.00%
Statements # ø per hour %
change db 38,446 k 20 M 77.16%
select 9,226 k 4,806.1 k 18.52%
set option 569 k 296.2 k 1.14%
begin 525 k 273.6 k 1.05%
commit 525 k 273.6 k 1.05%
update 277 k 144.1 k 0.56%
insert 116 k 60.3 k 0.23%
replace 56,518 29.4 k 0.11%
delete 44,031 22.9 k 0.09%
insert select 37,069 19.3 k 0.07%
show status 934 486.5 <0.01%
show fields 642 334.4 <0.01%
show slave status 557 290.1 <0.01%
show master status 557 290.1 <0.01%
show processlist 383 199.5 <0.01%
show table status 322 167.7 <0.01%
show tables 107 55.7 <0.01%
replace select 83 43.2 <0.01%
optimize 70 36.5 <0.01%
show variables 53 27.6 <0.01%
show binlogs 5 2.6 <0.01%
show databases 4 2.1 <0.01%
show grants 1 0.5 <0.01%
show plugins 1 0.5 <0.01%
Created tmp disk tables: 28.3 k
The number of temporary tables on disk created automatically by the server while executing statements. If Created_tmp_disk_tables is big, you may want to increase the tmp_table_size value to cause temporary tables to be memory-based instead of disk-based.
Handler read rnd: 36.2 M
The number of requests to read a row based on a fixed position. This is high if you are doing a lot of queries that require sorting of the result. You probably have a lot of queries that require MySQL to scan whole tables or you have joins that don't use keys properly.
Handler read rnd next: 531 M
The number of requests to read the next row in the data file. This is high if you are doing a lot of table scans. Generally this suggests that your tables are not properly indexed or that your queries are not written to take advantage of the indexes you have.
Select full join:109
The number of joins that do not use indexes. If this value is not 0, you should carefully check the indexes of your tables.
Slow queries:295
The number of queries that have taken more than long_query_time seconds.Documentation
Sort merge passes:253
The number of merge passes the sort algorithm has had to do. If this value is large, you should consider increasing the value of the sort_buffer_size system variable
Table locks waited:105.8 k
The number of times that a table lock could not be acquired immediately and a wait was needed. If this is high, and you have performance problems, you should first optimize your queries, and then either split your table or tables or use replication.
Amit én ezekből leszűrök, hogy az adatbázis a szűk keresztmetszet, és eléggé meg van hajtva, azt mondják, hogy a top process a mysqld és kb. 60% CPU-t folyamatosan eszik.
Ezek alapján én valamilyen Xeon E5-ös 8 magos 3GHz szervert, leglalább 64GB RAM-al, SAS 15k-s diszkekkel pakolnék alá.
Hozzászólások
Ezek az információk semmik... statisztikai adatok kellenének leginkább (memoria, swap, cache, buffer, CPU terhelés, iowait, olvasás/írás etc...) mi az h. 60% CPU -t eszik?
Leginkább az sql és a cache SSD -re pakolásával lehetne segíteni meg a megfelelő beállításokkal finomhangolni. Persze legyen azért 32GB RAM meg elég CPU.
Amíg nincsen megfelelően tervezve, méretezve a várható ill. valós terheléssel addig csak szócséplés az egész :-)
A top szerint a mysqld a CPU-kat 60%-ban terheli. A CPU 4 magos 32GB van alatta, disk io alig van, szerintem az SQL többnyire a memóriában dolgozik.
Valszeg az egészet át kell gondolni újra, és több mint finomhangolni ... egyébként nem írod milyen CPU, csak hogy 4 magos. Bár igazából mindegy is. Ez alá normális szerver kell és az egészet kb. újra tervezni, javítani (főleg az SQL rész)
+1 az újratervezésre. Valamit baromira elbasztak a megalkotáskor.
--
Fontos! Ha berágok, nem feltétlen személyed ellen szól...
openSUSE 13.1 x86_64
nginx + rendes I/O alá és százszorozod a teherbírást.
Mondjuk 3000 tábla elég betegnek hangzik egy webshophoz. Ráadásul napi 9000 látogatóhoz 30.000query/sec? Ott valami nagyon komoly programozási hiba van abban a webshopban (ciklusban selectben ciklusban selectben ciklusban select?)
Ne egy jóskapista általi 1 személyes webshopra gondolj, hanem több tízezer termékes webáruház, rendeléskövetéssel, garanciális ügyintézéssel, hitelügyintézés integrálás, stb. Az a gond, hogymár túl van bonyolítva és csak toldozva vannak hozzá az új funkciók.
Ez csak annyit jelent, hogy sok munkaórával fog járni. Ne azt képzeld, hogy ezt bárki áttoldozza jóra... Szarból nem lehet várat építeni(ezt ne vedd magadra, nem téged akarlak minősíteni). Ilyenkor le szokás ülni, specifikálni hogy mi kell(minden ami van, meg ilyenkor megjelennek a dejólennehamégeztis igények), terveznek, majd felépítenek egy rendszert, amibe ha a tesztek rendben mentek, migrálják az adatbázist egy szép pénteki éjszakán, hogy aztán hétfőre biztosan fusson.
Első körben mindenképpen próbálj meg megmérni minél több paramétert működés közben, mert enélkül nem fogsz tudni viszonyítani.
Ha csak hardvercserét engednek, akkor SSD, nginx, APC, Xcache, stb. Nem ragoznám írtak nagyon jókat: http://hup.hu/node/135716#comment-1787113
Lehet nem engedik a rendszert újraírni, de ha szép komótosan bevezettek apróbb dolgokat és mellékeled a mért számokat, hogy a kód fejlesztése százalékosan többet hozott mint a hardvercsere, akkor lehet hagyni fogják, hogy rendesen megcsinálja valaki.
"Átlagos napi látogatók száma: 9000. MySQL-ben kb. 3000 tábla van, külön fájlokban, a legnagyobb 30GB, kb. 10 tábla 1-10GB közötti, a többi 1GB alatti, összesen 130GB. Néha a query/sec:30 ezer is lehet, de átlagban 12 ezer közül van."
Ennek eléggé félretervezett "szaga" van, valószínűleg nincs az a hardver, amivel ez jól fog működni... :/
--
http://wiki.javaforum.hu/display/~auth.gabor/Home
Mielőtt csillióbilliót fogtok HW-re költeni:
- MySQL-ből a régi, fölösleges adatok törlése vagy archiválása (gyanítom, hogy borzasztó mennyiségű adatot küld vissza a MySQL a php-nak...)
- MySQL tuning, pl. a query cache tekintetében
- PHP-nál Opcode cache (XCache, APC ízlés szerint) beállítása és egyéb apró tuningok (file cache idők és méretek)
- Szintén PHP-nál megvizsgálni, hogy fastcgi+php-fpm -re át lehet-e térni
- Fölösleges Apache és PHP csomagok kikapcsolása
- A borzalmas mennyiségű mysql query okát meg kell vizsgálni, mert szinte biztos vagyok benne, hogy a fejlesztők tudnak rajta faragni/optimalizálni.
Ha ezek megvannak, akkor kell nézni valamilyen vasat, de egyébként egy single CPU E5 jó lehet, bár erős overkill lesz elsőre.
Milyen bolti keretrendszer van alatta?
Nem kereskedelmi, saját fejlesztés a rendszer (több mint 10 éves). Az adatbázis azért ekkora, mert több helyen is van értékesítés + az admin felület és ezért az egész SQL körbe van replikálva.
9000 látogatóval ~30query/sec-nak ha kéne lennie, de lehet sokat mondok. Nagyon durva kód minőségi hiba van.
ezert is javasoltam neki #1 lepeskent az alkalmazas lecsekkolasat...
--
"A politikat, gazdasagot es a tobbi felsorolt faszsagot leszarom, amig engem nem erint (nem erint)" (bviktor)
szerintem forditva ulod meg a lovat, mert az alkalmazas mellett kene lenni annak az infonak, hogy a hw igenye ez es ez. Aztan ha 'kohog a vas', ahogy irod, akkor nem az az 1. lepes, hogy 2x akkora vasat teszel ala, hanem eloszor azt szoktak megkeresni, hol a bottleneck?
Sorrendben:
#1: az alkalmazas koser-e?
#2: a kapcsolodo alkalmazasok (elsosorban apache, mysql es php) rendben vannak-e? Pl. tablakon ertelmes indexek, etc. A mysql optimalizalas onmagaban egy kulon topik lehet
#3: az OS megfeleloen van-e beallitva, pl. max open files, etc.
Ha pedig az elobbiek mar mind ki vannak maxolva, ami az optimalizalast illeti, akkor johet a vegyunk meg memoriat, ssd-t, ...
Ha van 10-30k sql query / sec, akkor erdemes lenne memcached vagy hasonlo beiktatasan elgondolkodni. Vagy pl. elore legyartani par kritikusabb query eredmenyet (a google sem hajtja vegre 200 csillio pornora valo select-et, hanem legyartjak a query eredmenyet, aztan neked mar csak az elore elkeszitett eredmenyt adjak oda). De ehhez tudni kene, hogy miket kerdezel le, lehet-e ertelmesen cache-elni, etc. Es persze ehhez az alkalmatast is modositani kell.
Ha mar mysql, akkor erdekes, hogy egy webaruhaznal miert van 20M "change db" query. Ill. a myisam-ot preferalod az innodb, etc. helyett. Erdemes lenne az adatokat es a felhasznalast is figyelembe veve elgondolkodni, hogy ez jol van-e igy? Lehet, hogy az jon ki, hogy igen, de esetleg az is lehet, hogy nem.
Ugy latatlanban ennyi kezdeskent.
--
"A politikat, gazdasagot es a tobbi felsorolt faszsagot leszarom, amig engem nem erint (nem erint)" (bviktor)
Most min fut, milyen hardver?
Slow queries log van, azt nézted?
Sakk-matt,
KaTT :)
Értem én, hogy mit írtok, meg tudom is, hogy mi a probléma. A kérdés az volt, hogy szerintetek milyen vas szolgálja ezt ki? Ugyanis meg kell győzni a vezetőséget, hogy vagy optimalizálással és hibakereséssel folglalkoznak ("ami szerintük időpazarlás és nem hoz pénzt") vagy erősebb vas kell alá.
Remélem így már értitek, hogy mi a kérdésem? Mert szerintük a mostani vas teljesen jó és biztos valami el lett állítva.
Azt hittem a kérdés egyértelmű, mert nem azt kérdeztem, hogy mit lehet javítani rajta? Azzal én is tisztában vagyok.
Hát a vas tuningban egy nginx webszervert próbáljatok apache2 helyett, és SSD-t szerintem. De a baj az, hogy a szoftverben nem kis optimalizálni való van, hanem nagyon-nagyon-nagyon-nagyon-NAGYON durva tervezési hiba.
Az általad említett látogatószámnak egy $99-s robotos TV játékoson el kellene mennie (ha nincs benne online GD-s kép manipuláció), de ha egy közepes fejlesztő csinálja, akkor is 1 darab Xeonnak 2G RAM-mal nevetve vinnie kellene. Ennyire nagy a szoftveres baj.
meg kell győzni a vezetőséget, hogy vagy optimalizálással és hibakereséssel folglalkoznak ("ami szerintük időpazarlás és nem hoz pénzt") vagy erősebb vas kell alá.
azt is mondd el nekik, hogy ha egy kalap kakamassziv optimalizalas szukseges a webaruhazon, akkor az konnyen lehet, hogy nem tudja megfeleloen kihasznalni azt sem, ha 2-3-4x akkora hw eroforrast tolsz ala, ami igy csak penzkidobas lesz, es ugyanott vagytok, hogy meg mindig 'kohog a cucc'...
--
"A politikat, gazdasagot es a tobbi felsorolt faszsagot leszarom, amig engem nem erint (nem erint)" (bviktor)
" A kérdés az volt, hogy szerintetek milyen vas szolgálja ezt ki? "
Ha nem jó a kód, akkor semmi nem fogja kiszolgálni mert idővel kimerít bármit. Kb. mintha a csöpögő csap problémáját egy nagyobb fazék alárakásával szeretnéd megszüntetni. Nem fog menni. Ha neked nem hisznek, linkeld nekik a topicot. Bár az azért elég meredek, hogy egy vezető a 10 éves rendszert ne legyen hajlandó felülvizsgálni. Egyrészt 10 éve is lehetett nagyon jó minőségű kódot írni, másrészt azóta születtek olyan megoldások, amik csak segítik a folyamatot. Sajnos sok vezető képtelen rendszerben gondolkodni és megérteni, hogy a programozó olyan dolgokat tud megoldani, amit a puszta hardver vásárlása nem oldana meg. Ha a szoftver és a hardver nincsenek összehangolva, akkor nem lesz optimális megoldás.
Ha a vas szerintük jó és a 10 évvel ezelőtti rendszer is jó, akkor hagyd rájuk.
Egyetértek. Ráadásul ha PHP-s (és 10 éves), akkor 99.99%, hogy mysql modullal ("mysql_query()" parancsokról gyorsan fel lehet ismerni a kódban) oldották meg, ami depracated és mindenképpen bele kell nyúlni a kódba.
Csináltattam rendszert. Ott kezdődött, hogy a programozók egy hónapig _tervezték_ az adatbázist a követelménjegyzék meg a speckó alapján. Kívülről annyit lehetett látni, hogy álló nap kávéznak. Sok vezető ezt a részt nem képes elfogadni, mert az a kényszerképzetük, hogy a programozás megállás nélküli kódolásból áll. Amelyik programozó nem kódol éppen, az lopja a napot. Ja, meg ugye a másik fixa-ideájuk, hogy a bikavas mindent megold. Mindent.
"Nincs végtelen ciklus, csak gyenge a processzorod" :D
Én hobbi szinten scriptelek, de még az is nagyon sokat számít, hogy az SQL-ben milyen a WHERE feltétel sorrendje. Plusz a kezdő/lusta/buta fejlesztők előszeretettel kérdezik le a teljes táblát, válogatják ki PHP-val ciklusban, majd ugyanebben a ciklusban kérdeznek le meg komplett táblát és válogatnak benne és így tovább... A JOIN, HAVING, WHERE, GROUP BY, LIMIT esetleg prepared statementek mesébe sincsenek... Pedig ezek még alap dolgok.
"Én hobbi szinten scriptelek..."
Én nem. Jobb szeretem kitalálni mit akarok, aztán szeretett fejlesztőim fölös idejét kitölteni vele.
Rossz a megkozelites. Javitani azon tudsz, amit meg tudsz merni. Ha valakit meg akarsz gyozni nem art ha ugyanazt a nyelvet beszeled, amit ok.
"Tests at Amazon revealed similar results: every 100 ms increase in load time of Amazon.com decreased sales by 1% (Kohavi and Longbotham 2007). Experiments at Microsoft on Live Search showed that when search results pages were slowed by 1 second: (Kohavi 2007)"
" Shopzilla found that by moving their page load time from 4 - 6 seconds to around the 1 second mark resulted in a 7 - 12% increase in conversion rate."
http://www.websiteoptimization.com/speed/tweak/psychology-web-performan…
http://assets.en.oreilly.com/1/event/29/Shopzilla%27s%20Site%20Redo%20-…
Ha a "penz" a fenti mutatoknak is a fuggvenye, akkor miert nincsenek ezek is merve?
Miert nincs minden egyes funkciohoz es muvelethez "koltseg" (eroforrashasznalat, kesletetes, sql lekerdezesek szama, stb) rendelve?
"Ugyanis meg kell győzni a vezetőséget, hogy vagy optimalizálással és hibakereséssel folglalkoznak ("ami szerintük időpazarlás és nem hoz pénzt") vagy erősebb vas kell alá."
Fontos kérdés: van tesztkörnyezet, ahol lehet szabadon játszani?
--
http://wiki.javaforum.hu/display/~auth.gabor/Home
Biztos van, ebbe nem mentem bele.
Ezek után mérget nem vennék rá, hogy van olyan tesztkörnyezet, ahol lehet különféle méréseket folytatni... :)
--
http://wiki.javaforum.hu/display/~auth.gabor/Home
Mert szerintük a mostani vas teljesen jó
Hát, 4 core és 32GB RAM eléggé úgy hangzik, mint ami bármire elég, már ha nem meteorológiai vagy atomrobbantás szimulációkról beszélünk, mert arra az világ összes CPU-ja sem elég.
Diszk I/O szintjén ha most nincs benne SSD, akkor azzal azért sokat lehet dobni a gép tudásán (ergó legyen), a 30k meg 12k query/sec-eken viszont az sem segítene.
és biztos valami el lett állítva.
Látatlanban azt mondom, hogy igen, valami biztosan el lett állítva, mégpedig az alkalmazás architektúrája.
Ezt már csak az is alátámasztja, hogy egy >10 éves, php-ban megírt, azóta toldozgatott-foldozgatott alkalmazáshoz szinte biztos, hogy architektúra szintjén hozzá kellene nyúlni (a sok query/sec is erősen errefelé mutat).
Azon lehet elmélkedni, hogy súlyos műtét (gerinc- és agyátültetés szintjén), vagy mint a cigánygyerekes viccben: kidobni és csinálni újat. Ha nincs meg az a csapat, aki tervezte/álmodta/írta a jelenlegi php-s kódot, és/vagy azóta se fejlődtek szakmailag, akkor valószínűleg az utóbbi megoldás a nyerőbb...
Mit csinalnak a mysql threadek? aka. Poor Man Profiler gdb alapon:
#!/bin/bash
nsamples=1
sleeptime=0
pid=$(pidof mysqld)
for x in $(seq 1 $nsamples)
do
gdb -ex "set pagination 0" -ex "thread apply all bt" -batch -p $pid
sleep $sleeptime
done | \
awk '
BEGIN { s = ""; }
/^Thread/ { print s; s = ""; }
/^\#/ { if (s != "" ) { s = s "," $4} else { s = $4 } }
END { print s }' | \
sort | uniq -c | sort -r -n -k 1,1
3000 tábla? Azonnal ki kell rúgni azt akinek bármi köze van hozzá.
--
arch,debian,windows,android
dev: http://goo.gl/7Us0GN
BCI news: http://goo.gl/fvFM9C
És igen, tényleg ezzel kellene kezdeni az optimalizálást :D :D :D
----
올드보이
http://molnaristvan.eu/
Folytattás: egy vízfejű vezető béréből hány fejlesztő bére jön ki? :P
+1
Az adatok (tablak) particionalasa nem feltetlen az ordog muve - kulonosen ha gyors a (be- es kiaramlo) adatfolyam.
50k+ tabla felett mar izgalmasabb az elet a rengeteg metaadat miatt, ami mar nem feltetlen fer el memoriaban.
Ha mar a hatarokat feszegetjuk, erdemes ezt a projectet is megemliteni (~34h ideig futott, ~8000 tabla / sec amit elert):
"The Billion Tables Project
Aka how long a "\dt" takes on a 1B tables database
Usually “large” databases are considered as such for the high number of records they hold, reaching billions or even more than that. But what about creating a billion... tables?"
http://www.pgcon.org/2013/schedule/events/595.en.html
+1
Ennyibol (legalabbois szamomra) nem derul ki, h mi a szuk keresztmetszet, igy nem is lehet megmondani, h mi szolgalna ki. Ha vaktaban alateszel vmit, attol nem lesz jobb feltetlenul.
Ha a HW-t akarjatok fejleszteni, akkor nezd meg, mi a szuk keresztmetszet es azon fejlessz.
Ezert kapsz mindenkitol olyan valaszt, amilyet. Meg lehet erobol is oldani, de ahhoz is utana kell jarnod.
Az apache2 lepaktált a RAM gyártókkal, plusz a sok query erősen I/O intenzív. Szal' ha olcsón és gyorsan akarja, akkor egy nginx és egy jó SSD akár 10x sebességnövekedést is eredményezhet, de csak rövid időre, mert a kód bármin túl fog nőni.
Köszönöm mindenkinek a hozzászólását. Úgy nézki, hogy kód és adatbázis optimalizálás lesz ebből.
Jó döntésnek tűnik...
te vagy a "rendszergazda"? mert akkor neked se ártana egy erős tovább képzés az írásaid alapján..
Sütővasat....
Az átlag napi 9000 felhasználó mellett nem lehet még napi kismillió keresőrobot, spamrobot, jelszó próbálgatás,...?
A statisztikák (Google analitika,...) ezeket ki szokták szűrni, viszont az adatbázis terhelésben (is) látványosan megjelenhet.
Mivel azt írod, sok termék van, azaz sok oldal,... ez biztosan jelentős terhelés lehet.
Persze a 3000 tábla még így is elgondolkodtató...
3000 tábla még egy ultra komoly ERP-ben sem szokott lenni.
A mi ERP-nkben 700 körüli tábla van de az nem webshop kategória (btw van benne webshop is) :)
--
Gábriel Ákos
http://i-logic.hu
Azt már többen is kifejtették. Lehet, hogy minden terméket külön táblában tartanak :)
Viszont ha ki tudják szűrni a felesleges/káros robotok nagy részét (ha jelenleg nincs így), jelentősen csökkenne a szerver terhelése.
Arról nem írt, hogy mennyi az adatbázis műveletet is érintő oldal letöltések száma. A napi 9000 (webshop) látogató nem akarom elhinni, hogy túl tud terhelni egy mai szervert.
Fail2ban, ipset, különböző szűrések a webszerveren... csodákra képesek, ha az a gond, amit írok.
Hát már hogyne tudna, a fejlesztők mindenre képesek. Nekem a kedvenc példám egy konkrét webáruház, ami olyan 1Mbit/sec kimenő forgalomhoz (tehát képekkel, javascripttel, css-el, html-el és minden kutyafülével együttes 1Mbit/sec-ről beszélünk) olyan 4-5Mbit/sec MySQL adatbázis forgalmat generál. Mindezt úgy, hogy az előző fejlesztő csapat 30-40db fölöslegesnek ítélt lekérdezéstől megszabadította a lapletöltést. Természetesen a jelenlegi forgalom nagyon kényelmesen fut, de ha véletlenül megszalad a látogatók száma, akkor azért már feltorlódnak a juzerek és érezhetően lelassul. Külön bónusz, hogy a kliens oldalt is szivatják, mert nem használnak (még) CSS vagy JS aggregálást és +20 hit a szerver felé, valamint olyan 10 féle ilyen beépülő google statisztika szerint cucc van.
Nulladik körben itt érdemes megnézni, hogy mit mond a weboldalról: http://tools.pingdom.com/fpt
Szerk: A robokat nem lehet érdemben szűrni, csak időszakosan és hellyel-közzel. A referük szinte biztosan változik vagy eleve teljesen összevissza IP címekről és normál kliensnek "álcázva" jönnek.
Azért remélem a példád elég szélsőséges.
Amióta a Google nyomja a "gyorsítsuk fel a webet", és adja hozzá az ötleteket, eszközöket, szerintem sokat javult a helyzet. A CSS, JS aggregálás, a böngésző oldali gyorsítótárazás,... is egyre jobban terjed.
Van olyan oldalunk, amit kb fél éve folyamatosan bombáznak olyan kérésekkel, amik tartalmazzák a action=login részt. Könnyű szűrni. Fogalmam sincs miért nem kopnak le (lehet vagy napi 50000 kérés, ha kikapcsoljuk a szűrést), mert semmit nem érnek el. Lehet hasonló probléma ott is. De csak egy ötletnek szántam, mert többször találkoztunk ilyennel.
Tény, hogy nem mindent lehet könnyen szűrni, de a saját tapasztalat az, hogy jelentősen lehet javítani a helyzeten.
Nem, teljesen a való életből jön. :)
Az ilyen könnyen szűrhetőek nyilván könnyű egy rewriterule-t vagy bármi hasonlót írni. Az ötlet egyébként alapvetően jó, de remélhetőleg ezeken már túlvannak.
Azon kivul hogy egyetertek a kod/adatbazis optimalizalas elsobsegevel, mert mar megtalaltad a leggyengebb lancszemet, van valami amit nem ertek.
"hogy mi van most alatta azt nem árulták el nekem"
Hogyan varja el barki hogy megjavits valamit amirol azt sem tudod hogy nez ki, pontos spec es foleg monitoring nelkul az egesz vaktaban talalgatas, tudni kell hogy a HW melyik resze a kritikus IO / MEM / CPU stb, aztan hogy milyen aranyban zabaljak fel az processek az eroforrasokat, stb stb.
Szerverenkent legalabb 2-300 metric az ami alapjan lehet felelos dontest hozni, lehetoleg hosszabb mintavetel alapjan.
Es csatlakozva kiuka hozzaszolasahoz itt egy gondolatebreszto http://puppetlabs.com/presentations/puppet-camp-london-2014-how-measure…