php-general Digest 23 Apr 2013 02:42:02 -0000 Issue 8205
Topics (messages 320958 through 320961):
Re: mysql_connect noob question
320958 by: tamouse mailing lists
320960 by: Jim Giner
Re: [ask] convert unknown Korean's string to readable string
320959 by: Richard Quadling
Load testing an app
320961 by: Andrew Ballard
Administrivia:
To subscribe to the digest, e-mail:
php-general-digest-subscr...@lists.php.net
To unsubscribe from the digest, e-mail:
php-general-digest-unsubscr...@lists.php.net
To post to the list, e-mail:
php-gene...@lists.php.net
----------------------------------------------------------------------
--- Begin Message ---
After all this, the OP remains unenlightened. This is just a waste of time.
"You are doing this wrong." "There are existing tools that do what your
client wants." "A command line tool is not the same as the php library."
are all met with "I don't want to learn, just tell me what isn't working."
Too bad.
--- End Message ---
--- Begin Message ---
On 4/21/2013 7:35 PM, Glob Design Info wrote:
A very complex solution that takes time to learn, configure, and
install, vs. a single file I can toss on the server.
Over-engineering is what is daft.
As has been pointed out to you - your simplistic approach to this task
is going to cost you big-time down the road. When (and it will) the
credentials to your mysql database get out and somebody(!) misuses them,
you will be the one called to answer on this security breach. The last
creds that you give out in an application are the keys to the kingdom.
Your usage of the db access values should be confined to a script
snippet that does the connecting for all scripts that seek data from the
database. This snippet is included in those scripts from a folder that
is outside of your webroot. Users have their own credentials that, once
accepted, allow the user to make their requests. This is just such
basic security practice, why can you not see it and accept the advice
you are being given?
As for why your connect statement doesn't work, that is truly a problem.
I certainly don't know as much as the people on this group who have
been trying to help you, but I know enough to listen to them and I know
the basics of best security practices. You have spent two days trying
to get answers to a question that shouldn't be answered. That's a slice
of development time wasted. You need to backup, rework your db access
and then simply change your current authentication script to use an
ordinary user id and pswd that steers the users to a script that helps
them access their data views without revealing to them the connect values.
And personally, I think PHP is the best thing I've ever taken up since
my first Univac assembler course back in 1971.
--- End Message ---
--- Begin Message ---
On 18 April 2013 08:06, Morning Star <morning.star.c...@gmail.com> wrote:
> $string = \uc548\ub155\ud558\uc138\uc694
<?php
$string1 = '\uc548\ub155\ud558\uc138\uc694';
$string2 = preg_replace('/\\\u([0-9a-f]+)/', '&#x$1;', $string1);
$string3 = html_entity_decode($string2, ENT_COMPAT, 'UTF-8');
echo
'Original : ', $string1, PHP_EOL,
'Entities : ', $string2, PHP_EOL,
'Decoded : ', $string3, PHP_EOL,
PHP_EOL;
?>
outputs (at least for me) ...
안녕하세요
Based upon
http://stackoverflow.com/questions/7274183/php-convert-unicode-to-character.
Hope this helps.
--
Richard Quadling
Twitter : @RQuadling
--- End Message ---
--- Begin Message ---
I'm looking for ideas to help load test a PHP site my office wrote and
maintains. Peak usage for this site is during the fall when new students
arrive, and for the first time this past fall the traffic rendered the web
server completely unresponsive, almost as quickly as we could restart it.
The only major change to the site last year was to upgrade the database
server the site uses, but the curious thing is that it was the web server
rather than the database that became unresponsive. Other apps could
continue to use the database without any performance issues, and the
database server performance counters suggest it wasn't even breaking a
sweat.
The other developer in our office spent some time profiling the site with
xdebug and found that an exec() call to netsh used on a couple pages seems
to take 2-4 seconds to complete. Unfortunately, those exec() calls are the
one function that we cannot test in our development environment. We are
considering some optimizations, but since load on the production server is
at a seasonal low we want to duplicate the problem so we can measure the
impact of any changes we make. We spent most of today hammering the site
with JMeter today in an attempt to reproduce the issue. While we were
easily able to slow the site to a crawl (some samples taking over 2 minutes
to complete), the server returned to normal as soon as the test concluded
and it never became totally unresponsive like it did this past fall.
We're both new to JMeter. I know a single test server may not be able to
create enough simultaneous requests to accurately simulate real traffic,
but I'm fairly confident that our tests involved far more (roughly-)
simultaneous connections than we were experiencing live. (The first test
used 20 threads; we gradually increased the threads for each test to 500
threads before we quit for the day.) The site is on a private subnet, so
distributed and/or cloud-based testing are probably not options.
The site is running PHP 5.3 on IIS/Windows Server 2003. The netsh calls are
to a DHCP server on a separate Windows server, and the database is SQL
Server 2008 (previously 2000).
So, any ideas we can try?
Andrew
--- End Message ---
