Re: [PHP-DB] MySQL - separating web and database servers
Hi Piotr,
Everyone else is suggesting edit all of the code.
Alternatively you could setup an iptables rule which forwards all
incoming requests on 127.0.0.1:3306 (or whatever port your mysql server
is running on) to 192.168.0.1:3306 (repolace 192.168.0.1 wit the IP of
your DB server).
This way if your DB moves again, you change your forward rule.
If, however, you try to put the PHP code on another system, you will
need to either put the DB on the same system, or change the iptables
ruleset for the new webserver.
It's worth a shot.
Matt Vos
On Thu, 2004-03-18 at 03:57, Operator wrote:
Hi everyone,
I need to put my database server on the another machine - how can I
configure system(Debian Linux)/php/mysql etc. to make it work without
changing all 'localhost' in a hundreds of customer's scripts?
The problem is, when localhost is specified as a host the connection is made
using unix socket, not TCP (is it possible to change this?). I tried to
export the socket from database server via NFS, but with no success:
(...)
munmap(0x2e1f2000, 4096) = 0
rt_sigaction(SIGPIPE, {SIG_IGN}, {SIG_DFL}, 8) = 0
socket(PF_UNIX, SOCK_STREAM, 0) = 3
fcntl64(3, F_GETFL) = 0x2 (flags O_RDWR)
connect(3, {sin_family=AF_UNIX, path=/var/run/mysqld/mysqld.sock},
110)
= -1 ECONNREFUSED (Connection refused)
shutdown(3, 2 /* send and receive */) = 0
close(3) = 0
(...)
Any ideas?
Regards
Piotr Babula
Re: [PHP-DB] msql perfomance: fast through mysql, slow through php
Try putting a separate network connection between your webserver box and your db, specifically for data between PHP and your DB. Don't route that traffic through the same network as you are using to retrieve the webpage, as the DB connection will eat up all of your bandwidth, leaving none available for sending the data to the browser. On Tue, 2004-02-10 at 23:17, jde wrote: Aha!!! In preparing to give more info, as requested by Sebastian, I have discovered that: You are right, but not exactly for the reasons you describe. The problem is the fact that I was interleaving the mysql_fetch with echo. However, I do not believe it is simply an 'adding the latency'. The two reasons this is probably not the case are because 1) the timing measures I made where from within the code, not by watching the browser, so I knew exactly the time it was taking. Secondly, the mysql server and the web client are co-located (i.e. in my house) and the latency between web server + mysql server would be the same as between web server + web browser, of which I know with high confidence is never as long as the timings would indicate. And actually a third reason for knowing it isn't simply latency is because, when I did perform all the data fetching before doing any output, the times decreased by a factor of 1000: from on order 1 to 6 seconds per fetch down to around .0001 second per fetch. This order of magnitude of difference is too much for simply latency. Nevertheless, clearly the mixing of I/O between the mysql connection and the web client creates a HUGH impact on the php efficiency. Thanks for the discussion!!! This got the job done!!! Question is now: is this a mysql library issue or a php/mysql interaction issue...will make sure the php and mysql folks know this (which they may already know about, I just didn't). Thank you Thank you! jde Brent Baisley wrote: You're also writing out to screen as you get the data, so you may be adding the latency from the web server to the client on top of your data fetching. You can probably get a boost by getting all the data into PHP first and then formatting and sending it to the client. At a minimum you should be able to determine if the client is the big slow down. Matthew Vos Systems Analyst Product Development Techcom Software Solutions Inc. 416.398.5764 [EMAIL PROTECTED] * * * * * * * * * * This message contains information from Techcom Software Solutions Inc. which is confidential and privileged. If you are not an intended recipient, please refrain from any disclosure, copying, distribution or use of this information and note that such actions are prohibited. If you have received this transmission in error, please notify [EMAIL PROTECTED]. This message and any attachments have been scanned for viruses. This message has been digitally signed to ensure authenticity. Key ID: CFEA28EC Fingerprint: 009F E13D 0450 55AF DC1C 4D77 1FE9 0DBB CFEA 28EC signature.asc Description: This is a digitally signed message part
Re: [PHP-DB] Creating temp tables in MSSQL
Hi Frank. When does this table get deleted? when the DB connection closes or does one have to run a process to clear the temp tables? Thanks, Matt On Tue, 2003-12-16 at 17:29, Frank M. Kromann wrote: Hi, Any table that starts with # is a temp table. You can use create table #mytemp (...) or you should be able to use the query you suggest. You just have to make sure you have enough space in tempdb (a system database) - Frank Hi all, I've been handed a query which I'm trying to get to work. I'm using PHP to talk to MSSQL 7. My question is this: Can I create temp tables with mssql without executing the code in a stored procedure? The simplified version of the query is as follows: $query = SELECT distinct convert(varchar(36),traineeID); $query.= INTO #tempdata1; $query.= FROMtblSignIn_trainee a; Later on I could make a stored procedure, but at the moment I would like to just work with the query directly in the code if at all possible. Thanks, John -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php Matthew Vos Systems Analyst Product Development Techcom Software Solutions Inc. 416.398.5764 [EMAIL PROTECTED] * * * * * * * * * * This message contains information from Techcom Software Solutions Inc. which is confidential and privileged. If you are not an intended recipient, please refrain from any disclosure, copying, distribution or use of this information and note that such actions are prohibited. If you have received this transmission in error, please notify [EMAIL PROTECTED]. This message and any attachments have been scanned for viruses. This message has been digitally signed to ensure authenticity. Key ID: CFEA28EC Fingerprint: 009F E13D 0450 55AF DC1C 4D77 1FE9 0DBB CFEA 28EC signature.asc Description: This is a digitally signed message part
