hi tchecking

checking

Read More......

Re: new

On Sat, Jan 16, 2010 at 9:23 PM, Unni Krishnan <unni21@gmail.com> wrote:

On Sat, Jan 16, 2010 at 9:14 PM, Unni Krishnan <unni21@gmail.com> wrote:

ESME to SMSC network architecture

--
Thanks & Regards,

Unni Krishnan.R
Web Developer
Mob:09895983845

--
Thanks & Regards,

Unni Krishnan.R
Web Developer
Mob:09895983845

--
Thanks & Regards,

Unni Krishnan.R
Web Developer
Mob:09895983845

Read More......

Re: new

On Sat, Jan 16, 2010 at 9:14 PM, Unni Krishnan <unni21@gmail.com> wrote:

ESME to SMSC network architecture

--
Thanks & Regards,

Unni Krishnan.R
Web Developer
Mob:09895983845

--
Thanks & Regards,

Unni Krishnan.R
Web Developer
Mob:09895983845

Read More......

new

ESME to SMSC network architecture

--
Thanks & Regards,

Unni Krishnan.R
Web Developer
Mob:09895983845

Read More......

register_shutdown_function possible use cases

Eirik Hoem on his blog provides an overview of PHP’s register_shutdown_function, and suggests using it for the cases when for whatever reason your Web page ran out of memory, fatal’ed, and you don’t want to display a blank page to the users.

register_shutdown_function is also useful for command-line scripts with PHP. Pretty frequently your script has to do some task like parse a large XML file, and the test examples when it was originally written did not account for the XML file possible being huge. Therefore your script dies with like 23% completion, and you’re left with 23% of the XML file parsed. Not ideal, but a quick duct-tape-style fix, would be to introduce a register_shutdown_function call to system(), to which you pass the script itself.

If you happen to keep track of which line you’re on while parsing, you can pass the line number as the first parameter to your own script, and make it start off after that 23% mark, or wherever it died. The script then needs to be launched with 0 passed as the first parameter. It will run out of memory, die, launch register_shutdown_function, which will launch another copy of the script (while successfully shutting down the original process) with a new line number, which will repeat the process.

Again, this is a duct tape approach to PHP memory consumption issues while working with large data sets.

Read More......

24 Web site performance tips

Yahoo! Developer Network blog had an entry by Stoyan Stefanov and presentation from PHP Quebec conference. A few points to take away, in case you don’t feel like going through 76-slide presentation:

1. A drop of 100ms in page rendering time leads to 10% in sales on Amazon. A drop of 500 ms leads to 20% less traffic to Google.
2. Make fewer HTTP requests - combine CSS and JS files into single downloads. Minify both JS and CSS.
3. Combine images into CSS sprites.
4. Bring static content closer to the users. That usually means CDNs like Akamai or Limelight, but sometimes a co-location facility or data center in a foreign country is the only option.
5. Static content should have Expires: headers way into the future, so that they’re never re-requested.
6. Dynamic content should have Cache Control: header.
7. Offer content gzip’ed.
8. Stoyan claims nothing will be rendered in the browser till the last piece of CSS has been served, and therefore it’s critical to send CSS as early in the process as possible. I happen to have a document with CSS declared at the very end, and disagree with this statement - at least the content seems to render OK without CSS, and then self-corrects when CSS finally loads.
9. Move the scripts all the way to the bottom to avoid the download block - Stoyan’s example shows placing the javascript includes right before and , although it’s possible to place them even further down (well, you’d break XHTML purity, I suppose, if you declare your documents to be XHTML).
10. Avoid CSS expressions.
11. Consider placing the minified CSS and JS files on separate servers to fight browser’s default pipelining settings - not everybody has FasterFox or tweaked pipeline settings.
12. For super-popular pages consider inlining JS for fewer HTTP requests.
13. Even though placing content on external servers with different domains will help you with HTTP pipelining, don’t go crazy with various domains - they all require DNS lookups.
14. Every 301 redirect is a wasted HTTP request.
15. For busy backend servers consider PHP’s flush().
16. Use GET over POST any time you have a choice.
17. Analyze your cookies - large number of them could substantially increase the number of TCP packets.
18. For faster JavaScript and DOM parsing, reduce the number of DOM elements.
19. document.getElementByTagName(’*').length will give you the number of total elements. Look at those abusive

s.
20. Any missing JS file is a significant performance penalty - the browser will browse the 404 page you generate, trying to see if it has valid

Read More......

FirePHP for PHP and AJAX development

FirePHP is a package consisting of a Firefox extension and server-side PHP library for quick PHP development on top of Firebug. It allows you to include the PHP library, and issue logging calls like


fb('Log message' ,FirePHP::LOG);
fb(’Info message’ ,FirePHP::INFO);
fb(’Warn message’ ,FirePHP::WARN);
fb(’Error message’,FirePHP::ERROR);

This is visible only to the Firefox version that has FirePHP installed on top of Firebug. You can also dump entire array and objects to the fb() function call, and have them displayed in Firebug UI.

Read More......

PHP Top scalability mistakes

1. Define the scalability goals for your application. If you don’t know how many requests you’re shooting for, you don’t know whether you’ve built something that works, and how long it’s going to last you.
2. Measure everything. CPU usage, memory usage, disk I/O, network I/O, requests per second, with the last one being the most important. If you don’t know the baseline, you don’t know whether you’ve improved.
3. Design your database with scalability in mind. Assume you’ll have to implement replication.
John Coggeshall, CTO of Automotive Computer Services, and author of Zend PHP Certification Practice Book and PHP5 Unleashed, gave a talk at OSCON 2008 on top 10 scalability mistakes. I wasn’t there, but he posted the slides for everybody to follow. Here’re some lessons learned.

1. Define the scalability goals for your application. If you don’t know how many requests you’re shooting for, you don’t know whether you’ve built something that works, and how long it’s going to last you.
2. Measure everything. CPU usage, memory usage, disk I/O, network I/O, requests per second, with the last one being the most important. If you don’t know the baseline, you don’t know whether you’ve improved.
3. Design your database with scalability in mind. Assume you’ll have to implement replication.
4. Do not rely on NFS for code sharing on a server farm. It’s slow and it’s got locking issues. While the idea of keeping one copy of code, and letting the rest of the servers load them via NFS might seem very convenient, it doesn’t work in practice. Stick to some tried practices like rsync. Keep the code local to the machine serving it, even if it means a longer push process.
5. Play around with I/O buffers. If you’ve got tons of memory, play with TCP buffer size - your defaults are likely to be set conservatively. See your tax dollars at work and use this Linux TCP Tuning guide. If your site is written in PHP, use output buffering functions.
6. Use Ram Disks for any data that’s disposable. But you do need a lot of available RAM lying around.
7. Optimize bandwidth consumption by enabling compression via mod_deflate, setting zlib.put_compression value to true for PHP sites, or Tidy content reduction for PHP+Tidy sites.
8. Confugure PHP for speed. Turn off the following: register_globals, auto_globals_jit, magic_quotes_gpc, expose_php, register_argc_argv, always_populate_raw_post_data, session.use_trans_sid, session.auto_start. Set session.gc_divisor to 10,000, output_buffering to 4096, in John’s example.
9. Do not use blocking I/O, such as reading another remote page via curl. Make all the calls non-blocking, otherwise the wait is something you can’t really optimize against. Rely on background scripts to pull down the data necessary for processing the request.
10. Don’t underestimate caching. If a page is cached for 5 minutes, and you get even 10 requests per second for a given page, that’s 3,000 requests your database doesn’t have to process.
11. Consider PHP op-code cache. This will be available to you off-the-shelf with PHP6.
12. For content sites consider taking static stuff out of dynamic context. Let’s say you run a content site, where the article content remains the same, while the rest of the page is personalized for each user, as it has My Articles section, and so on. Instead of getting everything dynamically from the DB, consider generating yet another PHP file on the first request, where the article text would be stored in raw HTML, and dynamic data pulled for logged-in users. This way the generated PHP file will only pull out the data that’s actually dynamic.
13. Pay great attention to database design. Learn indexes and know how to use them properly. InnoDB outperforms MyISAM in almost all contexts, but doesn’t do full-text searching. (Use sphinx if your search needs get out of control.)
14. Design PHP applications in an abstract way, so that the app never needs to know the IP address of the MySQL server. Something like ‘mysql-writer-db’, and ‘mysql-reader-db’ will be perfectly ok for a PHP app.
15. Run external scripts monitoring the system health. Have the scripts change the HOSTS if things get out of control.
16. Do not do database connectivity decision-making in PHP. Don’t spend time doing fallbacks if your primary DB is down. Consider running MySQL Proxy for simplifying DB connectivity issues.
17. For super-fast reads consider SQLite. But don’t forget that it’s horrible with writes.
18. Use Keepalive properly. Use it when both static and dynamic files are served off the same server, and you can control the timeouts, so that a bunch of Keep-alive requests don’t overwhelm your system. John’s rule? No Keep-alive request should last more than 10 seconds.
19. Monitor via familiar Linux commands. Such as iostat and vmstat. The iostat command is used for monitoring system input/output device loading by observing the time the devices are active in relation to their average transfer rates. The iostat command generates reports that can be used to change system configuration to better balance the input/output load between physical disks. vmstat reports information about processes, memory, paging, block IO, traps, and cpu activity.
20. Make sure you’re logging relevant information right away. Otherwise debugging issues is going to get tricky.
21. Prioritize your optimizations. Optimization by 50% of the code that runs on 2% of the pages will result in 1% total improvement. Optimizing 10% of the code that runs on 80% of the pages results in 8% overall improvement.
22. Use profilers. They draw pretty graphs, they’re generally easy to use.
23. Keep track of your system performance. Keep a spreadsheet of some common stats you’re tracking, so that you can authoritatively say how much of performance gain you got by getting a faster CPU, installing extra RAM, or upgrading your Linux kernel.

Read More......

Sphinx search ported to PECL

Anthony Dovgal reported on adding open source SQL full-text search engine sphinx to PECL. The documentation is available on the PHP site, the engine is available upon including sphinxapi.php in your application.

You know the usual InnoDB vs. the MyISAM trade-offs, where the former is faster, but the latter has the full-text search? Sphinx is a free open-source full-text search engine that works with many RDMBS, and now is pretty easy to incorporate into PHP. A simple example of calling Sphinx is available here:

$s = new SphinxClient;
$s->setServer("localhost", 6712);
$s->setMatchMode(SPH_MATCH_ANY);
$s->setMaxQueryTime(3);
$result = $s->query("test");

Read More......

Best practices in PHP development

1. Use source control
1. First, choose between distributed and non-distributed
2. Then, if you chose non-distributed, choose between CVS and SVN
3. In Subversion, use trunk/ for ongoing development and bug fixes, branches/ for ongoing large projects that later need to be merged in, and tags/ for releases
4. Use svn externals to connect to remote repositories
5. Subversion supports pre-commit and post-commit hooks for better code maintainability and checks



2. Implement coding standards
1. Develop class, variable, function, package, etc. naming conventions
2. Agree on common formatting as far as spacing, braces, etc.
3. Implement comment standards
4. PHP_CodeSniffer can run on pre-commit to check whether the commit adheres to the standards
5. Don’t forget to enforce coding standards on any outsourced projects
3. Unit testing and code coverage
1. Use PHPUnit for unit testing
2. For continuous integration, check out phpUnderControl
3. For integration testing, check out Selenium, a general Web application testing suite
4. Documentation
1. Don’t invent your own standards, see what phpDocumentor has to offer. Doxygen also supports phpDoc tags
2. For documenting the software project, try DocBook - XML-based format that allows you to quickly publish a PDF document, or a Website with documentation
5. Deployment
1. Have a standard deployment process that a rookie can familiarize with quickly
2. Support 3 environments - development, staging, and production
3. Deploy code only from repository tags, don’t run trunk, or allow code editing on server
4. Check out a new tag from SVN, point the symlink to it. If something goes wrong during release, change the symlink back to the previous version - easy rollback strategy
5. Everything that needs to be done on the production servers needs to be automated
6. You can do another Selenium test after the release is deployed
7. Check out Monit and Supervisord for deployment monitoring

Read More......